みなさんこんにちは、技術部プラットフォームグループのそめやポチ@kesompochyです。
ペパボが提供しているサービスの一つであるminneのプラットフォームがかっこいい構成に進化したので、その構成についてこの記事で紹介します。
簡単に説明すると、以前はLB（Load Balancer）とWAF（Web Application Firewall）がVM（仮想マシン）上で動いていましたが、現在はKubernetesクラスタ内で完結する形になりました。
この変更によってサービスの運用にかかる時間と費用の両面におけるコストが最適化されたため、余ったリソースを活用してもっとおもしろいことに挑戦できるようになりました。やったあ！
これまでの構成
ざっくり解説
minneのアプリケーションはKubernetesクラスタ内のコンテナで動作しています。
しかし、アプリケーションに到達するまでの経路、すなわちLBとWAFはVMによって構成されていました。
具体的には、LBからWAFを経由してクラスタ内のIstio ingress gatewayに接続されるという経路でした。TLS終端はVMのLBでおこなっていました。
従来の構成だとここが苦しい
今回のアーキテクチャ変更を実施した主な目的は、運用効率の改善でした。
サービスの公開に必要なロールであるLBとWAFが複数のVMで稼働していたため、コンテナ環境と比較して運用効率が低い状態でした。
まず、それぞれのVMに対するメンテナンス作業など、コンテナ環境では発生しない対応が必要でした。ゼロからKubernetes環境を構築する場合は、Kubernetes自体やコンテナランタイムの管理が必要タスクとして増えることになりますが、minneの場合はすでにアプリケーションがKubernetesクラスタで動いているためVMをKubernetesに移行するだけお得な状況だったのです。 また、アプリケーションがKubernetesで動いているにもかかわらずその前段はVMであるため、サービスメッシュによるトレーサビリティの恩恵を受けられません。例えば、障害発生時の調査には多大な労力が必要です。
minneがリリースされた頃はアプリケーションもすべてVMで動いていました。技術の変遷に追いつくために、アプリケーション部分からコンテナ化していき、徐々にアプリケーションはKubernetesクラスタ上で動くようになりました。しかし、アプリケーションの前段は従来の構成のままだったため、このような課題が生まれていたのです。
そこで今回、次のような構成に変更しました。
現在の構成
ざっくり解説
現在の構成では、アプリケーションへのリクエストは、まずクラウドプラットフォームにより提供されるLBを通ります。
minneでは、OpenStackで構築されたプライベートクラウド上のKubernetesクラスタとEKSを併用しています。それぞれのクラウドプラットフォームはKubernetesクラスタに対して負荷分散機能を持つコンポーネントを提供します。そのLBからレイヤ4でIstio ingress gatewayに接続されます。 TLS終端はクラスタ内の新しいIstio ingress gatewayがおこないます。
さらに、Kubernetesクラスタ内にはWAFとして動作するコンテナが配置されるようになり、アプリケーションに到達する前にWAFコンテナを通るようになりました。
新しい構成だとここがうれしい
この新しい構成によって、いくつかの大きなメリットを受けられるようになりました。
まず、運用の時間的コストが削減されます。 管理すべきインスタンスの数が減少するため、それらの運用・管理タスクも減少するからです。OSのEOL対応のための検証・アップデート作業や、複数インスタンス間のトラフィックルーティングを調整するための管理作業から解放されました。
次に、運用の金銭的コストも大きく削減されます。 Kubernetesクラスタ内のコンテナはリクエストの規模に応じてスケールできるため、必要な時に適切な量のリソースを使用できるようになりました。
さらに、すべてがクラスタ内で扱われるようになったことで、サービスメッシュによるトレースがより容易になり、システム全体の可観測性を向上させられるようになりました。
移行時の裏話
工夫したこと
ダウンタイムを最小限に抑えながら新アーキテクチャに移行したかったため、二つの経路を並立させた状態で、新しい経路の割合を少しずつ増やしていくリリース戦略をとりました。
先述の通りminneはマルチクラスタで動いているため、片方のクラスタだけを新しい経路を通る状態にできます。そこで、AWS Route53の加重ルーティング機能を用いてルーティング先のクラスタの割合を調整することで、漸進的なリリースを実現しました。
この工夫によって、サービスを停止させることなく、かつ新環境でのサーバー負荷やエラー数を確認しながら新アーキテクチャをリリースすることができました。
苦労したこと
この移行プロジェクトは一年以上の長期間にわたるものになりました。そのため、新旧の経路を並行して運用しながら、アーキテクチャの他の部分が変化していく状況もありました。その変化に対応するために、どちらの経路でも問題が出ないようにシステムを調整する必要がありました。
また、WAFの設定も大きな課題でした。minneではNginxをベースにしたWAFを使用しています。VMのWAFの挙動と差異がなくなるように、新しいコンテナWAFの設定をNginxとWAFに対して行う必要がありました。セキュリティに関わる部分であるため、これは細心の注意を払いながら行わなければならない作業でした。
まとめ
以上、よりクラウドネイティブになったminneのプラットフォームの説明でした。
このように、ペパボの技術部プラットフォームグループでは、どうすればサービス運用をもっとおもしろくできるかを考えながら日々手と頭を動かし続けています。しかし、まだまだ取り組むべき課題を抱えていることも事実です。
「クラウドネイティブ」という単語にときめきを覚えたそこのあなた、ペパボの技術部プラットフォームグループでお待ちしております。