EKSをECSへ移行するやり方をチームで考えた

はじめに

この記事は bellFace Advent Calendar 2021 の23日目の記事です。

本項では、AWSでコンテナを利用したアプリケーション運用を行う際に、昨今メインストリームとして利用されている EKS (Elastic Kubernetes Service) と ECS (Elastic Container Service) について比較しながら、当社ベルフェイスで行った直近の技術選択についてお話します。

自己紹介

ベルフェイス System GroupでSREをしています、大沼こと @numa-numa と申します

コア領域はネットワークと情報セキュリティ(のはず…)なのですが、YAMAHA RTX1210を傍らにGCPのインフラコーディングをしたり、社内情シスをやったり、Goスクリプトを開発したり…
WEBサービス数社で取っ散らかったことをいろいろ経験してきました

ベルフェイスでは入社1年余となり、インフラ/基盤まわりの改善を担当しています

コンテナとは何か？

記事に関してはいろいろな方が読む可能性があると思っており、なるべく前提知識がなくても分かりやすくします

• AWSのマネージドサービスである EKS (Elastic Kubernetes Service) の Kubernetes って何？
• そもそもコンテナって何？

…というあたりについて詳しく知りたい方は、私が年初に書きました以下の記事を、先にお読みいただけると良いかもしれません
【コンテナの話をはじめから】

ベルフェイスのインフラ担当組織について

ベルフェイスはベンチャー企業であり、2021年現在プロダクトをはじめいろいろなことが怒涛の勢いで改善されています。

組織に関しても例外ではなく、これまでのいろいろな経緯もありインフラを担当する組織もいくつかに分かれてきました。

そのうち、

• Platform Infraチーム
• DevOpsチーム

と呼ばれていた2つの主要チームが、2021年春から1チーム (これより後は、単純にSREチームとのみ記載します) として働くことになり、インフラ組織としてのシナジーも上がっています

ベルフェイスのSREチームが担当しているシステム

私たちが担当している主要システムについて、簡単な概念図で示すと以下のようになります。

実は先ほど紹介した、旧組織ごとで受け持っている範囲が異なっており、それぞれ担当範囲分けをしていたため、結果として上図のようなシステムとなっています。
(一部を切り取って、非常に簡略化しています。)

• Platform Infraチーム
  • EC2(仮想マシン)の構築/運用をメインで行う
• DevOpsチーム
  • EKSのコンテナ開発/運用をメインで行う

図内では点線を引いてある所を主な分解点とし、左側はおよそEC2を利用して基本的なAWSの使い方でインフラが構成されており、一部のアプリケーションにのみ右側のEKSを利用する、少し不揃いな構成になっています。

ベルフェイスとしては、コンテナ運用を主軸としてシステム改善/運用負荷低減を進めたく、その方針にずっとブレはありません。

ただかなり以前のことですが、これありきでKubernetesを採用し、結局のところやや持て余してしまっていた昨今の現状もあり、これを解消するプロジェクトをSREチーム一丸で進めることになったのでした。

なお、図内で "ポイント!!" と書いている箇所は通信が発生しており、今回の技術判断のポイントになった箇所です。
順番に、詳しくご説明していきます。

ECS・EKSの話

まずは、本項の目玉の技術要素でもあるECS・EKSとはどういったものなのか、改めて特徴とメリデメをご紹介します。

ECS (Elastic Container Service)

ECSはタスク定義と呼ばれる、動作アプリケーションコンテナに関するある種のひな形となる設定を、タスク (コンテナの実体) としてクラスタへ反映/実行させることで動作する、シンプルな作りになっています。

これを図にしてみると以下のようになります。

ここでは、ざっくりした技術の全体感を見ていただきたいので個別的な説明は行いませんが、とてもシンプルなもの…という感覚は伝わると思います。

続いてEKSについて見ていきましょう。

EKS (Elastic Kubernetes Service)

EKSはマネージドのKubernetesサービスです。
つまり、クラスターとはKubernetesクラスターであり、それにかかわる管理機能は、クラスター内に全て有するということになります。
Kubernetesは、基本的にサービス稼働コンテナのスケジューリングを行うMaster Nodeと、実際にサービス稼働コンテナを受け持つWorker Nodeを、Kubernetesクラスター内に両方持つことになります。

これを図にしてみると以下のようになります。

相当に簡略化はしていますが、ECSよりかなり複雑な構成となることが分かるでしょう。

というよりも、ここで出ている技術要素はほとんどKubernetesのことであって、これらをもし個別理解しようとすれば、とても大変そうだ…という感覚は伝わると思います。

ちなみにマネージドサービスなので、Master Node (コントロールプレーン) は、実際にはユーザーは見ることもできません。Kubernetesのバージョンだけは、AWSがサポートするものから選ぶことができます。

ECSのメリット/デメリット

ECSについては、以下のようにまとめました。

• メリット
  • シンプルさ
  • 運用の手軽さ
  • 学習コストが高くない
• デメリット
  • ベンダーディペンド (AWS) でクラウド間の可搬性がない
  • コンテナ間通信を行う仕組みが標準では存在しない

これらについては、ほぼ同様のことを書いているサイトやQiita記事などもあるので、特に目新しい情報はないと思います。

EKSのメリット/デメリット

EKSについても、以下のようにまとめました。

• メリット
  • 多機能でプラグインも豊富
  • デファクトスタンダードであり、クラウド間の可搬性がある
  • 複数種のリソース種を扱え、DBやバッチ処理のようなものもワンストップでの構成も可能
• デメリット
  • まだ成長途上であり、破壊的なアップデートが走ることがある
    • 総じて運用負荷が高くなりがち
  • 学習コストがかなり高い

こちらも同様に目新しい情報はないと思いますが、運用に関してのデメリットに、特に重要なポイントがあるように思いました。そのため太字で記載しました。

えっ、逆じゃないの！？

経験者の方は「えっ、逆じゃないの！？」という感想を持たれるかもしれません。
題名からもお分かりのように…

• ベルフェイスは主要システムの1つでEKSをやめ、ECSに移行するという決断を行いました！

昨今の潮流としては、Kubernetesがすでにコンテナオーケストレーションのデファクトスタンダードとなっているので、「影響度の低いシステムからECS→EKSへの移行を検討しようかな…」という会社が多いという所感を、私も持っています。

そんな中で、当社が主要システムの1つでEKSをやめることにした大きな理由としては、以下の3つです。

1. アプリとインフラ役割分担の明確化
2. 既存のEC2環境の統一化を考えた時に、統一的なアーキテクチャへの移行の際に、シンプルなECSにしたい
3. アップデートに対する知識の追従コストが高かった点の改善

Kubernetesは、アプリケーション開発者がインフラを意識しなければならず、結果論としてアプリケーション開発に集中できない状況が生じたり、インフラ/アプリケーションの権限分離が難しくなったりする点も運用上の考慮を要します。

EKSからECSへの移行でハマった箇所

EKS稼働していたシステムをECSに移行するだけであれば、基本的にはDockerベースであり、その難易度はさほど高くないです。
むしろ、EKSでは自家運用せざるを得ない点を、ECSはAWSマネージドで持っている点も多いので、構成はより簡単になるようにも思われます。

ただ、当社では非常に難しい点がありました。

それは、こちらで紹介した "ポイント!!" の箇所に関係があります。
図中のUser管理機能をさらにブレイクダウンした図が以下です。

EKSのデファクトとして外部通信のために ALB Ingress Controller というリソースを利用します。
その中で、URLの階層を利用したサービスルーティングを行っており、ALB (Application Load Balancer = AWS標準のWEBサービス終端) を通さず、他のAWSアカウントにあるベルフェイスのコアアプリケーションにアクセスするという設計が行われていました

ALBについては、先ほど終端 (エンドポイント) と書きましたが、終端であるがために ALB -> ALB へ通信するという構成は作ることができません。
つまり、ECS移行システムを作ったとしても、以下のような設計をすることはできません。

実際に問題を解決した方法

私たちは完全にこの問題に頭を悩ませていましたが、最終的には ALB Ingress Controller に依存していることにより、類似の構成は作ることができないことを悟りました。

通常、上位のサービスルーティングにはCDN (WEBのアクセス負荷を軽減するものだが、今回の用途にも合う) を使用することが多いのですが、完全に頭を切り替えてそちらで実現できるように、設計しなおしました。

CDNとしては、AWSで提供されるCloudFrontを採用しました。
全ての通信においてキャッシュしない (負荷分散用途にはしない) 設定を行い、以下のように構成しました。

まとめ

ベルフェイスのSREチームでは、会社の状況の変化や技術的な方針転換もあり、一部ではEKSで構成していたコンテナインフラを捨て、ECSへ移行するという決断を行いました。ECS移行を行う中で見えてきたポイントを、以下の2点にまとめます。

• 単純なWEBをコンテナ化する目的では、EKSよりECSから検討すべし！
• ALB -> ALBへ通信したいような要件では、CDNを利用すべし！

今後の展望として、現在EC2上で稼働している既存アプリケーションも、徐々にECSへ移行することを計画しています。
ベルフェイスは、1チームで改善に取り組んでいます

We are Hiring !!!

ベルフェイスでは、プロダクトやシステムのメンバーを引き続き積極採用しています！！

エンジニアの方は以下から
https://hrmos.co/pages/bellface/jobs/014

それ以外の各ポジションの方は以下から
https://hrmos.co/pages/bellface/jobs?category=1441373246841167872

カジュアル面談も行ってます
https://meety.net/articles/t2--7_60ljhphb

Who's NEXT

明日の bellFace Advent Calendar 2021 のエントリーはシークレット
お楽しみに