Amazon ECS・EKS・AWS Fargateの全体像

コンテナの保存・配置管理・実行基盤を分けて、ECS・EKS・Fargateの全体像を理解します。似た名前のサービスを一列の代替候補とみなさず、組み合わせる役割を整理します。

この単元で学ぶこと

コンテナとイメージの関係を説明する
ECS・EKS・Fargate・ECRの役割を区別する
管理責任と実行方式を組み合わせて判断する

本文解説

1. イメージと実行コンテナイメージはアプリと必要な依存関係等をまとめた実行用の材料です。そのイメージからコンテナを起動して処理します。イメージを保存したこととアプリが稼働していることは別です。例えば新しい版を登録しても、既存の実行中コンテナが自動的に新しい版へ変わるとは限りません。

2. 三つの役割イメージを保管するレジストリ、どこへ何個配置するか管理する仕組み、実際に計算を行う基盤を分けます。ECRは保管、ECSやEKSは配置・管理、FargateやEC2等は実行の基盤に関係します。これらは同じ仕事をする四つの製品というわけではありません。

3. ECSの位置付け ECSはAWSのコンテナオーケストレーションです。タスク定義でイメージや資源等を定め、タスクとして実行します。サービスで必要数を維持する使い方もあります。KubernetesのAPIを必須としない場合に、AWSと統合した管理方式として検討します。

4. EKSの位置付け EKSはKubernetesを利用するためのマネージドサービスです。標準構成ではAWSがコントロールプレーンを管理し、実行するワークロードや権限等は利用者が管理します。既存のKubernetesの知識、API、ツールを利用したい場合に比較します。

5. Fargateの位置付け FargateはECSのタスクや、対応条件を満たすEKSのPodを、利用者がサーバー群を管理せず実行する仕組みです。ECSとEKSの代わりのオーケストレーション名ではありません。アプリ、CPU・メモリ、ネットワークや権限の指定は利用者に残ります。

6. 実行方式は一つではない ECSやEKSでEC2を使う構成もあります。自社管理のEC2とFargateではホストの管理自由度が異なります。現行にはECS Managed InstancesやEKS Auto Mode等の管理を軽減する方式もあるため、EC2という単語だけで担当範囲を決めず、選んだ方式の条件を確認します。

7. 共通して残る責任マネージド基盤でもアプリのコード、イメージの依存関係、データ、業務権限等は利用者が管理します。イメージを直した後は配備済みの実体を確認します。タスクやPodが入れ替わることを前提に、重要なデータを一時領域だけへ置かない設計を考えます。

8. 要件から組み合わせる Kubernetesの互換性が必要ならEKS、ECS固有の管理を使うならECSを比較します。その上でサーバー管理を減らしたいか、特殊なホスト機能が必要かを確認して実行基盤を選びます。イメージ保管のECR、監視や負荷分散、保存先も必要に応じて組み合わせます。

図解

重要ポイント

保存・オーケストレーション・実行基盤を分ける。
ECSとEKSには異なる管理APIがある。
Fargateは両者と組み合わせる実行基盤。

間違えやすい点

ECRへ保存したことを配備完了と考える。
FargateをEKSの別名と考える。

用語解説

コンテナイメージ: アプリや依存関係等をまとめた実行の材料。
オーケストレーション: コンテナの配置・起動・必要数等を管理する仕組み。
レジストリ: コンテナイメージを保存・配布する仕組み。
Pod: Kubernetesで配置・実行する一つ以上のコンテナの単位。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。