228-AWS SAP AWS 「理論・実践・一問道場」EKS マネージドノードグループ

type

status

date

slug

summary

理論

こちらがECS FargateとEKSマネージドノードグループの簡潔な比較表です。

特徴	ECS Fargate	EKS マネージドノードグループ
管理の簡便さ	フルマネージド、インフラ管理不要	ノード管理は必要だが、マネージドサービスで簡素化
スケーラビリティ	自動スケーリング、リソースに応じて動的に拡張	Kubernetesでスケーリング管理、自動化可能
インフラ管理	完全にAWSが管理	ノードの管理が必要だが、EKSで簡略化
コスト管理	実行したリソース分のみ課金（サーバーレス）	EC2インスタンス料金、オーバーヘッドあり
適用例	シンプルなアプリケーション、サーバーレス	複雑なアプリケーション、大規模なクラスター
柔軟性	サーバー管理が不要	高い柔軟性、カスタマイズ可能
対応するコンテナオーケストレーション	ECS（AWS独自）	Kubernetes（EKSによるマネージド）

ECS Fargateはサーバーレスで、インフラの管理不要で簡単にスケーリングできる一方、EKSマネージドノードグループはKubernetesの柔軟性を活かして、より大規模かつ複雑なアプリケーションに対応できます。

マルチティアWebアプリケーションに関して、ECS FargateとEKSマネージドノードグループのどちらが適切かは、アプリケーションの規模、複雑さ、スケーラビリティ要求などに依存しますが、以下の要素を基に選択できます。

ECS Fargateが適している場合:

シンプルでサーバーレスな環境が必要な場合:

インフラ管理を最小限に抑え、開発に集中したい場合。

アプリケーションが比較的単純で、コンテナオーケストレーションを管理する必要がない場合。

管理の負担を減らしたい場合:

ECS Fargateは、コンテナインフラの管理をAWSが代行するため、オペレーショナルオーバーヘッドを減らしたい場合に最適です。

動的スケーリングが必要な場合:

Fargateはリソースを自動で管理し、必要に応じてスケールするため、動的なリソース要件を持つマルチティアWebアプリケーションに向いています。

EKSマネージドノードグループが適している場合:

Kubernetesの利点を活かしたい場合:

複雑なアプリケーションやマイクロサービスアーキテクチャの管理を行いたい場合。特に、Kubernetesの高度な機能（例: デプロイメント、ローリングアップデート、サービスディスカバリ、自己修復機能）を利用したい場合に適しています。

高いカスタマイズ性と柔軟性が必要な場合:

EKSはKubernetesで動作し、柔軟なカスタマイズが可能です。たとえば、複数の異なるタイプのアプリケーション（Webサーバ、バックエンドAPI、データベースサーバ）を同じクラスター内で管理する場合に便利です。

大規模なマルチティアアーキテクチャが必要な場合:

EKSは、スケーラビリティの高い大規模なシステムや、データベースやキャッシュなどの他のバックエンドサービスと連携する複雑なアーキテクチャに向いています。

結論

ECS Fargateは、シンプルで運用負荷を軽減したいマルチティアWebアプリケーションに最適です。特に、インフラの管理やKubernetesの詳細な設定を気にせず、スケーラブルで柔軟なリソース配分が必要な場合に最適です。

EKSマネージドノードグループは、より複雑で柔軟なマルチティアアーキテクチャを管理し、高度なオーケストレーションやカスタマイズを行いたい場合に適しています。

アプリケーションの規模や運用のニーズに合わせて選択することが重要です。

実践

略

一問道場

質問 #228

トピック 1

ある企業が、オンプレミスのデータセンターからAWSにマルチティアWebアプリケーションを移行し、コンテナ化したいと考えています。アプリケーションにはWeb、アプリケーション、データベースの各ティアが含まれています。企業は、アプリケーションを障害に強く、スケーラブルにする必要があります。頻繁にアクセスされるデータは、アプリケーションサーバー間で常に利用できる必要があります。フロントエンドWebサーバーはセッションの永続性を必要とし、トラフィックの増加に対応するためにスケールする必要があります。

どのソリューションが、最小限の運用オーバーヘッドでこれらの要件を満たすでしょうか？

A. Amazon Elastic Container Service (Amazon ECS)をAWS Fargateで実行し、頻繁にアクセスされるデータはWebおよびアプリケーションティア間で共有されるように、Amazon Elastic File System (Amazon EFS)を使用する。フロントエンドWebサーバーのセッションデータはAmazon Simple Queue Service (Amazon SQS)に保存する。

B. Amazon Elastic Container Service (Amazon ECS)をAmazon EC2で実行し、フロントエンドWebサーバーのセッションデータをキャッシュするためにAmazon ElastiCache for Redisを使用する。複数のアベイラビリティゾーンに分散したEC2インスタンスにAmazon Elastic Block Store (Amazon EBS)をMulti-Attachで使用する。

C. Amazon Elastic Kubernetes Service (Amazon EKS)でアプリケーションを実行し、EKSにマネージドノードグループを使用する。WebサーバーとアプリケーションをReplicaSetsで実行し、Amazon Elastic File System (Amazon EFS)を作成して、すべてのEKSポッドにEFSファイルシステムをマウントし、フロントエンドWebサーバーのセッションデータを保存する。

D. Amazon Elastic Kubernetes Service (Amazon EKS)でアプリケーションをデプロイし、EKSにマネージドノードグループを使用する。WebサーバーとアプリケーションをKubernetesのデプロイメントとして実行し、フロントエンドWebサーバーのセッションデータをAmazon DynamoDBテーブルに保存する。アプリケーションがデプロイされる際に、すべてのアプリケーションがマウントするAmazon Elastic File System (Amazon EFS)ボリュームを作成する。

解説

この問題に関する解説は以下の通りです。

シナリオ：

企業が複数のレイヤー（Web、アプリケーション、データベース）からなるアプリケーションをコンテナ化して、オンプレミスからAWSへ移行したいと考えています。アプリケーションの可用性とスケーラビリティを確保する必要があります。さらに、頻繁にアクセスされるデータはアプリケーションサーバ間で常に利用可能でなければなりません。フロントエンドのWebサーバはセッションの保持が必要で、トラフィックの増加に応じてスケールできる必要があります。

主要な要件：

アプリケーションのスケーラビリティ - 負荷に応じてスケールできる。

フォールトトレランス - 高可用性を確保する。

セッション管理 - フロントエンドWebサーバはセッションを維持しなければならない。

データの共有 - 頻繁にアクセスされるデータをWebとアプリケーション層間で共有。

各選択肢の説明：

A. ECS + AWS Fargate + EFS + SQS

Amazon ECS（Elastic Container Service） を利用してFargate上でアプリケーションを実行し、Amazon EFS を利用して頻繁にアクセスされるデータを共有する。

ただし、SQS はセッション管理には不適切です。セッションデータはキューではなく、セッションストレージに保存するべきです。

セッション情報はキューに保存せず、ElastiCache や DynamoDB に保存する方が適切です。

SQS は非同期処理向けであり、セッション管理には不向きなので、この選択肢は不適切です。

B. ECS + EC2 + ElastiCache + EBS

Amazon ECS をEC2上で運用し、ElastiCache for Redis を使用してセッションデータをキャッシュします。EBS（Elastic Block Store）はEC2インスタンスのストレージですが、EBSを複数のインスタンスで共有するのは困難であり、特にEBSのMulti-Attachは一部の特殊なユースケースに対応しています。