AWSでコンテナを支えるサービスについて ECS、EKS、Fargateの違いは？　第２回（最終回）

第１回では、ECS、EKS、Fargateの各サービスについて、お伝えしました。今回はサービスのメリットやデメリット、どのようなシーンで活用するのかについて、お伝えします。

■それぞれのメリット・デメリットについて考える

まずはコントロールプレーンについて考えます。

Kubernetesに馴染みがなく、開発者がKubernetesに対する学習時間を確保出来ないと見積もれる場合は、間違いなくECSを選ぶべきと考えます。

EKSはKubernetesという広く知られたプラットフォームである反面、AWSが「Kubernetesの開発に合わせてEKSを開発する」ため、バージョンアップによって互換性のないAPIの変更や下位互換性が破棄されている仕様に関して、開発者自身がそれらの変更点をキャッチアップしなければならないという大きなデメリットがあります。

また、そのような事情からKubernetesクラスターのバージョンアップを行う際には同等の別環境を構築してバージョンアップの検証を行い、実際に本番環境のバージョンアップを行う際にはアップデートの失敗を考慮してブルーグリーンデプロイメントと呼ばれるような、「現在の本番環境を維持したまま新しい本番環境を構築して、DNSの切り替えによって環境移行を行う」ようなオペレーションが必要になります。

ECSはAWSによってコントロールプレーンの管理はある程度気にせず済むようになっているため、コントロールプレーン自体の破壊的変更は無いとみなして、開発・運用を行うことが出来ます。ただし、ECSを取り巻く構成を記述することはKubernetesと同様に、相応の学習が必要となることに注意してください。

2019年末にEKS on Fargateがサポートされ、EKS、ECSのどちらからでもFargate、EC2のデータプレーンを選択できる状態になったため、単純にEKSとECSで「出来る・出来ない」を比較することは難しくなりました。

コントロールプレーンの選定に関して考える点はやはり、Kubernetesの文脈でコンテナを管理したいかそうではないか、という事に尽きます。

データプレーンに関しては、Fargateの「フルマネージドされたサーバーリソース」に対するメリットデメリットで考える必要があり、EC2のレイヤーを気にする必要がない場合やアドホックなバッチ実行等の不規則なシステムリソースの増減が考えられる場合、Fargateを選ぶべきと思います。

なお、以前は「Fargateは高い」と言われていましたが、現在では余剰リソースが出ないようタスクを定義しつつSaving PlansやFargate Spotの仕組みを利用する事により、場合によってはEC2よりも低コストで運用する事が可能となっています。

■ケースごとに考えるおすすめの組み合わせ

さて、EKS, ECS, Fargate（とEC2）について大まかに紹介したので、実際に何らかのサービスをデプロイするとしてどのような構成が選ばれるのか考えてみましょう。

※あくまで一例で、開発チームの構成や実際のアプリケーション設計によっては紹介例とは別の構成が最適な場合もあります。

【例①】小規模（コンテナの種類が少ない）なWebアプリケーション」

よくあるNginx + Java/PHPで構成された単純なWebアプリケーションの場合、少ないタスクの定義とインスタンス管理の手間が少ないECS+Fargate構成を選ぶべき、と考えられます。

【例②】マイクロサービスでスケーラブルな大規模Webアプリケーション

最初からコンテナ利用を想定したマイクロサービスを構築し、更にはマイクロサービスごとの負荷の監視とスケーリングを設計レベルで盛り込んだアプリケーションの場合、コンテナの立ち上げまでに掛かる時間がFargateではやや掛かることや、大規模アプリケーションで複数チームによってアプリケーションが開発される（マルチテナント）場合にはインフラエンジニアが入って、EKS+EC2構成を選ぶべき、と考えられます。

【例③機械学習やDWHを活用したETL処理等、外部アクセスを考慮しないアプリケーション

これらのような「単発・短期・不定期実行」のいずれかを持っている場合、複雑な死活監視やスケーリングについて考える必要が無いためサクっと作れるECSをコントロールプレーンに選ぶべきと考えられます。

また、EKSのクラスターはECSと違い「立ち上がってるだけ」で課金されるため、コスト面からもECSにメリットがあります。

データプレーンにFargateを使えば更にデータプレーンも「使った分だけ」になるのでサーバーレスでお得！と思いきや実際はAWS SWF等のサーバーレスでワークフローを実行するためのサービスと競合してしまうので、ある程度仕様が定まっていてパフォーマンスを求めたい場合はそれらもあわせて検討する必要があります。