EC2起動タイプとFargateの比較

ECSには、コンテナをどこで実行するかを定義する2つの起動タイプがあります。EC2起動タイプでは、クラスター内にプロビジョニングして管理するEC2インスタンス上でコンテナを実行します。Fargate起動タイプは、基盤となるサーバーをAWSが全面的に管理するサーバーレスのコンピューティングエンジンです。両者のタスク定義とサービス設定はほぼ同じで、主な違いはインフラストラクチャの管理責任とコストモデルにあります。

EC2起動タイプでは、ECS Container Agent（ECS最適化AMIにプリインストールされています）を使用して、EC2インスタンスをクラスター内のコンテナインスタンスとして登録します。インスタンスタイプの選択、OSレベルの設定の管理、カスタムセキュリティベースラインの適用、コスト削減のためのSpot Instancesの利用が可能です。ECSは、ビンパッキングまたは分散配置戦略に基づいて、登録済みインスタンスにタスクを配置します。基盤となるEC2フリートのパッチ適用、スケーリング、保守はお客様の責任です。

Fargateでは、タスクごとにCPUとメモリを指定すると、AWSが基盤となるコンピューティングリソースを透過的にプロビジョニングします。登録、パッチ適用、スケーリングが必要なEC2インスタンスはなく、すべてAWSが管理します。タスクにはそれぞれ分離されたカーネル（Firecracker microVMによる）が割り当てられるため、複数のタスクが同じホストを共有するEC2コンテナインスタンスよりも、強固なセキュリティ分離が実現します。Fargateではawsvpcネットワークモードが必須です。つまり、各タスクに専用のENIとVPC IPアドレスが割り当てられます。

料金モデルは根本的に異なります。EC2起動タイプでは、タスクが実行されているかどうかにかかわらず、基盤となるEC2インスタンスに対して料金を支払います。ただし、割引のためにリザーブドインスタンスやSavings Plansを利用でき、中断可能なワークロードではSpot Instancesにより最大90%のコストを削減できます。Fargateでは、タスクごとに消費したvCPUとメモリについて、1秒単位で実際に使用した分だけ支払います。タスク間のアイドルコストはありません。負荷が急増するワークロードやバッチワークロードではFargateのほうが安くなることが多く、継続的に高い使用率で稼働するワークロードでは、リザーブドインスタンスを利用したEC2のほうが安くなる場合があります。

Fargate Spotは、AWSがキャパシティを回収する必要が生じた際に中断される可能性がある代わりに、大幅に割引された料金（最大70%オフ）でFargateのコンピューティングリソースを提供します。Fargate Spotは、バッチ処理、CI/CDパイプライン、開発環境やステージング環境に適しています。キャパシティプロバイダー戦略を設定して、Fargate（オンデマンド）とFargate Spotを組み合わせられます。Fargateにbase=1を設定して少なくとも1つの保証されたタスクを確保し、weightの値で残りのキャパシティを両方に分配します。

次の要件がある場合はEC2起動タイプを選択します。GPUインスタンス（FargateのGPUサポートには制限があります）、Fargateでは利用できない特定のインスタンスタイプ、カスタムOS設定（カーネルチューニングやカスタムドライバー）、プレイスメントグループや拡張ネットワーキングを必要とするネットワーク性能、Windowsコンテナ（EC2はWindows Serverコンテナをサポートしますが、FargateのWindowsサポートには制限があります）、または継続的に高い使用率で実行し、EC2のリザーブドインスタンスによってFargateの1秒単位の課金よりも大幅なコストメリットが得られる場合です。

次の目的がある場合はFargateを選択します。EC2管理のオーバーヘッドをなくす（OSのパッチ適用やクラスターのスケーリングが不要）、1秒単位で使用した分だけ支払う、アイドル状態のEC2キャパシティを確保するほどではない負荷変動の大きいワークロードやバッチワークロードを実行する、Firecracker microVMによってより強固なタスク分離を実現する、またはアプリケーションコードに集中して開発を加速する、といった目的です。SAA-C03試験では、特別なEC2要件が示されていない限り、新しいECSワークロードにはFargateが推奨されます。

キャパシティプロバイダーは、コンピューティング層をECSサービスから抽象化します。EC2の場合、キャパシティプロバイダーはAuto Scaling Groupに関連付けられます。キャパシティ不足によってタスクを配置できない場合、ECSがASGを自動的にスケールします。Fargateでは、FARGATEとFARGATE_SPOTが組み込みのキャパシティプロバイダーとして用意されています。サービスにキャパシティプロバイダー戦略を定義すると、オンデマンドとSpot/Fargate Spotを組み合わせ、ワークロードごとのコストと可用性のトレードオフを細かく制御できます。

起動タイプによって運用オーバーヘッドは大きく異なります。EC2起動タイプでは、AMIの選択と更新、EC2 Auto Scalingの設定、SSMまたはカスタムスクリプトによるOSのパッチ適用、コンテナインスタンスのキャパシティ管理、インスタンスレベルのセキュリティ強化が必要です。Fargateでは、これらがすべて不要になります。Fargateプラットフォームへのパッチ適用はAWSが行い、管理するインスタンスもクラスターのキャパシティ計画も必要ありません。ただしFargateは、OSレベルのカスタマイズやネットワーク性能のチューニングに関する柔軟性が低くなります。

Fargateのタスク定義では、固定された組み合わせからCPUとメモリを指定する必要があります。CPUの値は256、512、1024、2048、4096、8192、16384です（vCPU単位で、1024 = 1 vCPU）。メモリはCPUの値ごとに定められた範囲内で指定する必要があります。たとえば、CPUが256の場合、メモリは512～2048 MBに設定できます。タスク内のコンテナは、タスクに設定されたCPUとメモリの上限を共有します。適切なサイズ設定が重要です。Fargateでは指定した量に対して正確に課金されるため、ワークロードがCPUバウンドの場合、実際の性能向上がないまま過剰プロビジョニングによってコストが無駄になります。

ECS Execを使用すると、SSHや踏み台ホストを使わずに、実行中のコンテナ（EC2とFargateの両方）で直接インタラクティブなシェルセッションを開けます。内部ではAWS Systems Manager Session Managerを使用します。サービスで有効化し、execute-command CLIを使ってbashセッションを開始します。コンテナ上の本番環境の問題をデバッグする際に非常に役立ちます。タスクロールにはssmmessages:CreateControlChannelおよび関連するSSM権限が必要です。

このレッスンで扱ったAWS Solutions Architect（SAA-C03）の概念について、理解度を確認します。

このレッスンでは、次のことを学びました。EC2起動タイプは、基盤となるインスタンス群を管理する代わりに、インスタンスタイプとOS設定を完全に制御できます。GPU、特殊なハードウェア、または継続的に高い使用率のワークロードに適しています。Fargateは、1秒単位のタスク課金とFirecrackerによる強力な分離を提供しながら、インフラストラクチャ管理を不要にします。多くのWeb/APIワークロードやバッチジョブに適しています。Fargate Spotは、中断を許容できるワークロードのコストを最大70%削減します。次は、コンテナイメージを保存および取得するためのAmazon ECRについて学びます。