Container Hosting Platformを選択する

コンテナ化されたアプリケーションの実行基盤を決めるとき、

Amazon ECS
Amazon EKS
AWS Fargate
Amazon ECR

を同じ役割のサービスとして比較してはいけません。

コンテナホスティング基盤は、大きく、

コンテナイメージを保存する
↓
コンテナを配置・維持する
↓
実際にコンテナを実行する

という複数のレイヤーで構成されます。

したがって、レジストリ、オーケストレーション、コンピューティングを分けて選択することが重要です。

1. コンテナ基盤を3つのレイヤーに分ける

代表的な構成を整理すると、

Amazon ECR
↓
コンテナイメージ

Amazon ECS / Amazon EKS
↓
オーケストレーション

AWS Fargate / EC2ベースのコンピューティング
↓
実際の実行基盤

となります。

それぞれの役割は異なります。

この3レイヤーを分離すると、

ECSかFargateか

のような誤った二者択一を避けられます。

2. Amazon ECRはコンテナイメージを保存する

Amazon ECRはAWSマネージドのコンテナイメージレジストリです。

DockerイメージやOpen Container Initiative（OCI）イメージなどを保存できます。

例えば、

アプリケーションソース
↓
コンテナイメージをビルド
↓
Amazon ECR
↓
Amazon ECS / Amazon EKS

という流れです。

Amazon ECR自身が、コンテナ数を維持する、Podをスケジューリングする、タスクを配置する、CPUやメモリを提供する、わけではありません。

Amazon ECRの責任は、コンテナイメージを保存し、実行基盤から取得できるようにすることです。

3. イメージレジストリとオーケストレーターは独立して考える

例えば現在、

Amazon ECR
↓
Amazon ECS

という構成でも、将来一部のワークロードをAmazon EKSへ変更したからといって、

Amazon ECRも必ず変更する

必要はありません。

Amazon EKSからもAmazon ECRのイメージを利用できます。

したがって、

コンテナイメージレジストリ
=
オーケストレーター

ではありません。

オーケストレーション方式を変更しても、イメージ保管方式を継続できる場合があります。

ただし、レジストリにイメージが存在することと、そのイメージが新しい実行環境で動作できることは別問題です。

OSやCPUアーキテクチャ、アプリケーション依存関係などの互換性は別途確認します。

4. Amazon ECS / Amazon EKSはオーケストレーションレイヤー

Amazon ECSとAmazon EKSは、コンテナをどのように配置・維持するかを担当します。

Amazon ECSでは、タスク定義、タスク、サービスなどのAmazon ECS固有モデルを使用します。

Amazon EKSでは、Pod、Deployment、Service、DaemonSetなどKubernetesのAPIモデルを使用します。

Kubernetes APIや既存のKubernetes資産が必要かという基本判断だけで終わるのではなく、選択したオーケストレーター上で、ワークロードに必要な実行機能を提供できるコンピューティングを選ぶ必要があります。

5. AWS Fargateはオーケストレーターではない

AWS Fargateは、コンテナ向けのサーバーレスコンピューティングです。

例えば、

Amazon ECS
↓
AWS Fargate

または、

Amazon EKS
↓
AWS Fargate

という構成が可能です。

Fargateを使用すると、コンテナを実行するためのEC2インスタンス群を利用者が直接プロビジョニング・パッチ適用・スケーリングする必要がありません。

しかし、

Fargate
=
Amazon ECSの代替

でも、

Fargate
=
Amazon EKSの代替

でもありません。

Amazon ECS / Amazon EKSがオーケストレーションを担当し、Fargateがコンテナの実行コンピューティングを提供します。

6. サーバーレスコンテナでも機能制約は確認する

Fargateではコンテナホストの管理をAWSへ委譲できます。

しかし、

サーバー管理不要
=
すべてのコンテナ機能を利用可能

ではありません。

例えばAmazon ECSのFargateタスクでは、gpu、privilegedなど、一部のタスク定義機能を利用できません。

したがって、

コンテナ化できる
↓
必ずFargateで実行できる

とは判断しません。

まずアプリケーションが必要とする、GPU、ホストレベルアクセス、Linux機能、デバイスアクセス、その他の実行要件を確認し、Fargateとの互換性を評価します。

7. Fargateが適合しなくてもAmazon ECSを捨てる必要はない

例えば、

Amazon ECSを使用したい
+
GPUが必要

という場合を考えます。

FargateではGPUを利用できないため、

Amazon ECS
↓
AWS Fargate

という組み合わせは要件を満たしません。

しかし、これは、

Amazon ECSそのものが利用できない

という意味ではありません。

Amazon ECSでは、コンピューティングレイヤーとしてEC2ベースの選択肢を利用できます。

現在は、Amazon ECSマネージドインスタンス、Auto Scaling groupベースのEC2キャパシティなどがあります。

Amazon ECSマネージドインスタンスでは、AWSが基盤EC2のプロビジョニング、スケーリング、パッチ適用、メンテナンスを管理しながら、GPUや特定CPUアーキテクチャなどEC2の機能を利用できます。

したがって、

オーケストレーター
Amazon ECS
↓
コンピューティング
Fargateから別方式へ変更

という判断も可能です。

8. Amazon EKSでもFargate互換性を確認する

Amazon EKSでもAWS Fargateを利用できますが、すべてのKubernetesワークロードをそのままFargateへ移せるわけではありません。

EKS Fargateでは、例えばDaemonSet、privilegedコンテナ、GPUなどに制約があります。

例えば各ノード上へセキュリティエージェントをDaemonSetとして配置する必要がある場合、

Amazon EKS
+
AWS Fargate

だけでは要件を満たせません。

この場合は、Amazon EKSというオーケストレーターを維持したまま、要件を満たせるノードベースのコンピューティングを評価するという判断が必要です。

つまり、

Kubernetesが必要
=
必ずEKS Fargate

ではありません。

オーケストレーターとコンピューティングは別々に判断します。

9. 「サーバーレスコンテナ」は管理境界を表す

Fargateを使用する大きな理由は、コンテナホストとなるEC2インスタンスの選定、OS管理、パッチ適用、基盤キャパシティ管理などを利用者が直接行わなくてよいことです。

一方で利用者は、コンテナイメージ、アプリケーション設定、CPU / メモリ要求、IAM、ネットワーク設定、オーケストレーション設定などを引き続き設計します。

したがってサーバーレスコンテナを、

設計不要

と解釈してはいけません。

正しくは、コンテナホストの管理責任をAWSへ移す実行モデルとして扱います。

10. 3つのレイヤーは独立して変更できる

Amazon ECSのままコンピューティングだけ変更

Amazon ECR
↓
Amazon ECS
↓
AWS Fargate

から、

Amazon ECR
↓
Amazon ECS
↓
EC2ベースのコンピューティング

へ変更できます。

Amazon EKSのままコンピューティングだけ変更

Amazon ECR
↓
Amazon EKS
↓
AWS Fargate

から、

Amazon ECR
↓
Amazon EKS
↓
ノードベースのコンピューティング

へ変更することもできます。

レジストリを維持してオーケストレーターを変更

Amazon ECR
↓
Amazon ECS

から、

Amazon ECR
↓
Amazon EKS

へ変更することも可能です。

つまり、あるレイヤーの変更が、必ず他のすべてのレイヤー変更を意味するわけではありません。

11. コンテナ選択では「どの組み合わせが成立するか」を見る

コンテナホスティング基盤では、1つのサービス名を選ぶのではなく、組み合わせを評価します。

ここで、

Kubernetes不要
↓
ECS

だけで判断を終了してはいけません。

その後に、

ECS
↓
Fargateで要件を満たすか
↓
別のコンピューティングが必要か
↓
イメージレジストリは何を利用するか

まで確認します。

Amazon EKSでも同様です。

12. 判断フロー

コンテナ化されたワークロード要件を確認
↓
必要なオーケストレーションモデルを確認
↓
Amazon ECS / Amazon EKSを選択
↓
GPU / privileged / DaemonSetなど
実行基盤固有要件を確認
↓
AWS Fargateで成立するか
├─ 成立する
│   ↓
│  Fargateを候補
│
└─ 成立しない
    ↓
   要件を満たすEC2ベースのコンピューティングを評価
↓
Amazon ECRなど
イメージレジストリを選択
↓
レジストリ / オーケストレーター / コンピューティング
の組み合わせを確定

重要なのは、Amazon ECS、Amazon EKS、AWS Fargate、Amazon ECRを同列の代替サービスとして比較するのではなく、それぞれの責任を分けて組み合わせることです。