こんにちは！ エンタープライズクラウド部技術2課の日高です。
今回は、Amazon ECSのクラスター、タスク定義、サービスのパラメータ一覧についてまとめてみます。
Amazon ECSの概要
Amazon Elastic Container Service (以下、ECS) は、コンテナ型のアプリケーションを実行するためのマネージド型コンテナオーケストレーションサービスです。
コンテナは単体で動作させるケースは少なく、通常のワークロードでは複数のコンテナが連携して動作します。
その際、コンテナの起動・停止、アクセス制御、信頼性やスケーラビリティの担保等を一元的に管理するのがコンテナオーケストレーションツールの役割です。
コンテナオーケストレーションとはコンテナを管理するというものであり、コンテナを動かす実行環境のサービスではないことをご注意ください。
下記に、Amazon ECSの全体像になります。
主要なコンポーネントを、以降で記載していきます。
タスク(Task)
ECS 上でアプリケーションを起動するためにはコンテナが必要となります。
このコンテナが動作するコンポーネントを ECS では「タスク」と呼んでいます。
タスクは1つ以上のコンテナから構成されるアプリケーションの実行単位となり、タスク内のコンテナは同⼀ホスト上で実⾏されます。
タスク定義(Task Definition)
タスクを作成するテンプレート定義となり、JSON で記述されます。
テンプレート定義の中で、デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAM ロール、CloudWatch Logs の出力先等を指定します。
タスク定義に含めるコンテナ定義は複数設定可能です。
サービス(Service)
指定した数だけタスクを維持するスケジューラで、サービス作成時は起動するタスクの数や関連付けるロードバランサー、ネットワーク等を指定できます。
また、タスクが何らかの理由で終了した場合は、タスク定義をベースに新しいタスクを生成して指定したタスク数を維持します。
クラスター
クラスターは、サービスもしくはタスクの論理グループです。
クラスター単位が、実行環境やIAM権限（クラスタに対する操作）の境界となります。
クラスターのパラメータ
インフラストラクチャ
コンテナの実行環境を設定します。（デフォルトでは、 AWS Fargateのみが選択されています。）
AWS Fargate、Amazon EC2、ECS Anywhere から複数選択が可能になります。
AWS Fargate
Fargate は、コンテナ用のクラスタを構築し、コンテナを実行するためのマネージド型のコンピューティングリソースです。
クラスタとして EC2 でも構築できますが、Fargate 自体のパッチ適用やウイルス対策等のホストレベルでのセキュリティ対策等は AWS によって実行されるため、ユーザはホストレベルの運用を意識する必要がなくなります。
ただし、運用負荷が軽減される代わりに Fargate が実行されているホストにssh等の手段でログインし、ログ確認を行うといった作業はできません。
そのため、コンテナのログを Fargate 内から取得する実装を、設計時に検討する必要があります。
デメリットとしては、Amazon EC2と比べると料金が高額になります。
ですが、OS側運用から解放されることは非常に大きなメリットだと考えられるため新規構築の際にFargate が利用できるか検討してみてください。
※ AWS Fargateの料金について、詳しくは以下をご覧ください。
Amazon EC2
Amazon EC2を使用する場合は、Amazon ECS-optimized AMI（コンテナインスタンスの要件/推奨事項にしたがって事前構成されたAMI）を使って構築するのがおすすめになります。
DockerデーモンやECSコンテナエージェントがあらかじめインストール済みなので起動後すぐ利用が開始できるためです。
Auto Scaling グループ (ASG)
インフラストラクチャにて、Amazon EC2を選択した場合はAuto Scaling グループの設定をする必要があります。
この設定は後述するAmazon EC2 起動タイプのキャパシティープロバイダーとして機能します。
ECS Anywhere
ユーザーが所有する任意のインフラ環境（オンプレミスなど）で、ECS を利用してコンテナを実行することができる機能です。
仕組みとしては、インスタンス内で動いているSystems Manager AgentがDockerを操作します。
そして、そのDockerの中で動いているECS AgentがECSと手を組んで、タスクやコンテナの動きをコントロールしています。
そのため、 ECS Anywhere を利用する際にはDocker、SSM Agent、ECS Agentを導入する必要があります。
モニタリング（CloudWatch Container Insights）
有効にすることで、CloudWatchによりカスタムメトリクスが収集できるようになります。（デフォルトでは無効）
標準のCloudWatchメトリクスでも、クラスターやサービスで使用されている CPU の割合などは確認できます。
ただ、タスク単位でメトリクスを確認した場合や、標準のCloudWatchメトリクスで取得できないメトリクスを確認したい場合に有効をおすすめします。
※標準で取得できるメトリクス
※Container Insightsで取得できるメトリクス
タスク定義のパラメータ
インフラストラクチャの要件
起動タイプ
タスク定義で選ぶ起動タイプによって、Amazon ECSでのタスクやサービスの実行環境が決まります。
サービスやタスク作成時に、タスク定義で指定している起動タイプが指定されないと、エラーが出ます。
デフォルトで「AWS Fargate」が選ばれていて、「Amazon EC2 インスタンス」も選択可能です。
ネットワークモード
Amazon ECS (Elastic Container Service) でタスクを実行する際に、コンテナがどのようにネットワークに接続されるかを定義するモードのことです。
起動タイプでFargateを選択した場合、ネットワークモードはawsvpcが選択されます。
また、起動タイプがEC2かつOSがLinuxの場合はどのモードでも使用可能ですが、起動タイプがEC2かつOSがWindowsの場合はdefault と awsvpc のみ選択可能になります。
bridge（default）
- Dockerのhostモード。
- ECSインスタンス（EC2）の任意のポートをコンテナのポートにマッピングする。
- 同じECSインスタンス上の複数のタスクが同じENIとSecurityGroupを共用。
- 役割が異なる複数のタスクが1つのECSインスタンス内に存在する場合、必要な全てのポートを解放する必要がある。
- 通信帯域はタスク間で共有。
- ALBとの組み合わせでは、動的ポートの利用が一般的。
- Dockerの公式ページ が詳細情報の参考ソースとして挙げられる。
host
- Dockerのhostモード。
- コンテナでexposeされたポートが、ECSインスタンス（EC2）でもそのまま利用される。
- 同じホスト上で同じポートを利用する複数のタスクの同時起動は不可能。
awsvpc
- タスクごとにENIが直接アタッチされるモード。
- タスク間のポートマッピングの考慮が不要。
- ENIが独立しているため、ネットワークパフォーマンスの向上が期待される。
- ENIごとにSecurityGroupを割り当て可能。
- ECSインスタンス本体とタスク間でのSecurityGroup分離も可能。
- VPC FlowLogを利用しての観測が可能。
- ALBやNLBにIPターゲットとして登録が可能。
- 注意点: ECSインスタンス（EC2）のENI上限。大きなインスタンスタイプで、固定数のタスクを起動させる場面での利用が適している。
なし
- コンテナの外部接続がなくなるモード。
- ポートマッピングは設定不可。
- 可能な用途としては、ECSインスタンス（EC2）とディスクマウントし、コンテナ内での計算に利用することなどが考えられる。
タスクサイズ
タスクサイズで、タスクのCPUとメモリの量を設定できます。
CPUはvCPU数、メモリはGBで指定します。
起動タイプが、AWS Fargateの場合指定が必須になります。
各vCPUの設定に応じて、以下のようにメモリを選べます。
- .25 vCPU：.5 GB、1 GB、2 GB
- .5 vCPU：1 GBから4 GB
- 1 vCPU：2 GBから8 GB
- 2 vCPU：4 GBから16 GB
- 4 vCPU：8 GBから30 GB
- 8 vCPU：16 GBから60 GB (4 GB刻み)
- 16 vCPU：32 GBから120 GB (8 GB刻み)
- 8 vCPU以上の設定は、Linux プラットフォーム 1.4.0以降で利用できます。
※詳しくは以下をご覧ください。
起動タイプが、Amazon EC2の場合はオプションになります。
利用可能なCPUユニットが使用できるEC2インスタンスがクラスター内にないと、タスクは失敗します。
条件付きのタスクロール
タスクロールとタスク実行ロールがあります。
違いは下記の通りです。
- タスクロール：コンテナ上のアプリケーションがAWS API を呼び出すために必要なIAMロールです。
- タスク実行ロール：ECRからDockerイメージをプルしたり、CloudWatchへのログを転送するなどECSなどに必要な権限を付与するIAMロールです。
※詳しくは以下をご覧ください。
コンテナ
プライベートレジストリ
AWS 外部のプライベートレジストリに存在するコンテナイメージを参照する必要がある場合、有効にします。
有効にする場合は、Secrets Manager に認証情報を保存されている必要があります。
※詳しくは以下をご覧ください。
読み取り専用ルートファイルシステム
WindosOS以外でコンテナを起動する際に指定する設定です。（デフォルトは無効）
ルートファイルシステムに対する読み取りが必要な場合は有効にします。
リソース割り当て制限
コンテナのリソース割り当てを制御するための設定オプションになります。
- CPU: コンテナに予約するCPUユニットの数。
- GPU: EC2インスタンス上のGPUユニットの数。1つのGPUは1つのGPUユニットとしてカウントされます。
- メモリのハード制限 (GB):
- コンテナに提供する最大メモリ量。
- Docker 20.10.0以降: 最小6 MiB、Docker 19.03.13-ce以前: 最小4 MiB。
- この制限を超えるとコンテナは停止する。
- メモリのソフト制限 (GB):
- システムメモリが不足するときのコンテナのメモリ制限。
- タスク全体でメモリ指定がない場合、ハード制限またはソフト制限、あるいは両方を指定する必要がありますが、ハード制限はソフト制限より大きくなければならない。
※Windowsコンテナではこの制限はサポートされていません。
上記にも記載がある通り、制限を超えるとコンテナが停止してしまうため、リソース制限をどうしてもやりたい場合を除いては設定しないことをお勧めします。
Log collection
有効にすることで、コンテナインスタンスからログを自動的に収集するスクリプトを使い、一般的なOSのログ、Docker ログ、および Amazon ECSコンテナエージェントのログ収集します。（デフォルトでは無効です。）
デフォルトでは、/ecsプレフィックスとタスク定義ファミリー名でCloudWatch Logsにログがルーティングされますが、ログのルーティング先として以下の指定が可能です。
- Splunk：Splunk トークンと Splunk URLを指定します。
- Amazon Kinesis Data Firehose：AWS リージョンとログストリーム名を指定します。
- Amazon Kinesis Data Streams：AWS リージョンとデータストリーム名を指定します。
- Amazon OpenSearch Service：インデックスとタイプを指定します。
- Amazon S3 バケット：S3 バケット名を指定します。
※詳しくは以下をご覧ください。
HealthCheck
コンテナが正常に動作しているかどうかを確認する機能になります。
コマンド
ヘルスチェックを実行するためのコマンドを指定します。
このコマンドは、CMD または CMD-SHELL のいずれかのプレフィックスとともに文字列配列として提供されます。
例として、以下のコマンドはローカルホストのページの可用性を確認します。
bashCopy code CMD-SHELL, curl -f http://localhost/ || exit 1
正常な動作の場合、終了コードは0を返し、それ以外の場合は失敗とみなされます。
間隔
ヘルスチェックを実行する間隔を指定します。設定可能な範囲は5秒から300秒で、デフォルトの設定は30秒です。
タイムアウト
ヘルスチェックが反応するまでの最大の待ち時間を定義します。この値は2秒から60秒の間で指定可能で、デフォルトは5秒です。
開始期間
この期間は、コンテナが正常にブートストラップされるまでの猶予期間として考えることができます。設定範囲は0秒から300秒までで、デフォルトではこのオプションはオフに設定されています。
再試行
ヘルスチェックが連続して失敗した場合の再試行回数を定義します。コンテナが異常と見なされる前に、1回から10回までの再試行が可能です。デフォルトの設定は3回の再試行です。
コンテナタイムアウト
コンテナの待機時間を設定するオプション設定になります。
設定値としてStartTimeoutと、StopTimeoutが存在します。
- StartTimeout：コンテナの依存関係の解決を断念するまでの待機時間。
- StopTimeout：コンテナが自動的に正常に終了しない場合に、コンテナーが強制的に強制終了されるまで待機する時間。
Docker 設定
オプション設定で、設定することでDockerfile 内の値の一部を上書きすることができます。
- エントリポイント: 実行されるコンテナの起動点を設定します。--entrypoint オプションを使用すると、Dockerfile の ENTRYPOINT 命令を上書きできます。
- コマンド: コンテナで実行するコマンドを設定します。COMMAND オプションを使用して、Dockerfile の CMD 命令を変更することができます。
- 作業ディレクトリ: コンテナ内でコマンドを実行する際のディレクトリを指定します。--workdir オプションを使うことで、Dockerfile の WORKDIR 命令を上書きできます。
Dockerの操作やコンテナの作成時に、既定のDockerfileの指示をカスタマイズする際に利用すると考えています。
リソース制限
オプション設定で、設定することでOSのデフォルトのリソース上限の設定を上書きすることができます。
こちらで設定した内容は、Docker リモート API のセクションdocker run--ulimitの オプションとしてマッピングされます。
※詳しくは以下をご覧ください
Dockerラベル
オプション設定で、設定することでコンテナに追加するラベルのキー/値を指定できます。
こちらで設定した内容は、。Docker リモート APIのセクションdocker run--labelのオプションとしてマッピングされます。
※詳しくは以下をご覧ください
ストレージ
エフェメラルストレージ
オプション設定です。この設定はLinuxの場合はプラットフォームバージョン1.4.0以降、Windowsの場合はプラットフォームバージョン1.0.0以降のFargateでのみ利用可能で、Amazon EC2でホストされるタスクでは使用できません。
Fargateを使ったタスクでは、基本的に20 GiBの一時的なストレージ（エフェメラルストレージ）が与えられますが、必要に応じて最大200 GiBまでこの設定で指定することができます。
エフェメラルストレージに保存されるデータとしては、コンテナイメージ等が保存されます。
そのため全体のストレージ量を考慮する際には、コンテナイメージのサイズがエフェメラルストレージの利用可能な空き容量に影響を及ぼすため注意が必要です。
例として、Fargateのエフェメラルストレージとして20 GiBが割り当てられているとき、コンテナイメージが5 GiBの場合、実質的にタスクで利用できるエフェメラルストレージの容量は残りの15 GiBとなります。
このことから全体のストレージ量を考える際には、使用するコンテナイメージのサイズを差し引くことを忘れないようにご注意ください。
ボリューム
オプション設定です。ボリュームは、コンテナ間でデータを共有するためのストレージ領域を指定します。
ストレージ領域としてサポートされているのは下記があります。
ボリュームは、コンテナ間でデータを共有するためのストレージ領域です。Amazon EC2やECSで使用できる主なボリュームタイプを以下に示します。
| 種別 | 説明 |
|---|---|
| Amazon EFSボリューム | AWSの永続ファイルストレージサービスであるAmazon EFSを利用する。ECSのコンテナにEFSのストレージをボリュームとしてマウントする。特徴として、使用量により自動的にサイズが変わる。ホストはFargate、EC2のいずれでも可。 |
| FSx for Windows File Server ボリューム | AWSのフルマネージドWindowsファイルサーバサービスを利用。Windowsタスクでの静的や共有ファイルストレージに適しているが、FargateのWindowsコンテナでは使用不可。ホストはEC2、Fargateのいずれでも可。 |
| Dockerボリューム | Amazon EC2のホストで直接管理されるストレージ。外部ストレージシステム（例: Amazon EBS）と連携可能な Docker ボリュームドライバー がある。EC2がホストの場合のみ使用可。 |
| バインドマウント | ホスト上の特定のファイルやディレクトリをコンテナに直接マウントする方法。ホストはFargate、EC2のいずれでも可。 |
通常、各コンテナのデータはコンテナ内に保存されますが、コンテナが破棄された場合保存したデータも消えてしまいます。 そのため、データを永続的に保存したい場合や、コンテナ同士でデータを共有したい場合にボリュームの設定をしていただけるといいと考えています。
モニタリング
以下の「トレースの収集」と「メトリクスの収集」を行うためには、アプリケーションに OpenTelemetry SDK が組み込まれている必要があるためご注意ください。
※詳細については以下をご覧ください。
トレースの収集
有効にすることで、アプリケーションの動作を詳細に追跡（トレース）するためのツールであるAWS X-Rayに情報を収集して送信することができます。
具体的には、AWS Distro for OpenTelemetryという特別なサイドカーコンテナ（アプリケーションの隣で動作する補助的なコンテナ）を使用して、アプリケーションからの情報を収集し、AWS X-Rayに送信します。
※詳しくは以下をご覧ください。
メトリクスの収集
有効にすることで、タスクのアプリケーションメトリクスをCloudWatch Container InsightsやAmazon Managed Service for Prometheusに送信することができます。
この設定を行う際、適切なアクセス許可を持つIAMロールをタスクに割り当てる必要があります。
- CloudWatchの場合：アプリケーションメトリクスはAmazon CloudWatchにカスタムメトリクスとして送られます。デフォルトで5つのディメンションが設定されていますが、不要なものは新しいタスク定義のリビジョンで削除できます。
- Prometheus (Prometheus ライブラリ実装)の場合：アプリケーションやインフラのメトリクスはAmazon Managed Service for Prometheusに送られます。デフォルトで全てのディメンションが利用できます。メトリクスを送るための特定のエンドポイントの情報を提供する必要があります。
- Prometheus (OpenTelemetry 実装)の場合：同様に、メトリクスはAmazon Managed Service for Prometheusに送信されますが、エンドポイントの指定方法が異なります。
※CloudWatch Container Insightsはインフラの情報を収集するのに対して、トレースの収集やメトリクスの収集はアプリケーションの情報を収集するという違いがあります。
サービスのパラメータ
コンピューティングオプション
どうやってタスクを実行するかを指定できる設定です。
キャパシティープロバイダー戦略と、起動タイプから選択できます。
キャパシティープロバイダー戦略
キャパシティープロバイダーを使用することで、クラスター内のタスク量に応じた適切なスケーリングを管理してくれる機能になります。
各クラスターには複数のキャパシティプロバイダーが関連付けられており、これらをどのように使用するかをこの設定で決定します。
AWS FargateやAmazon EC2インスタンスでのタスク実行に使用されますが、外部コンテナインスタンス（Amazon ECS Anywhere）では利用できません。
※詳しくは以下をご覧ください。
起動タイプ
タスクがどこで動くかを手動で指定します。
下記の中から選択できます。
- Fargate 起動タイプ:AWS Fargate のサーバーレスインフラストラクチャでタスクを実行します。
- EC2 起動タイプ:クラスターに登録した Amazon EC2 インスタンスでタスクを実行します。
- 外部起動タイプ:Amazon ECS クラスターに登録してリモートで管理しているオンプレミスサーバーや仮想マシン (VM) でタスクを実行します。
※詳しくは以下をご覧ください。
サービスタイプ
サービススケジューラが従うサービスタイプを指定します。
指定されたスケジュール戦略に基づき、タスクが適切に実行されているか確認し、問題があれば再スケジュールします。
タスクが失敗すると、自動的に新しいタスクを起動して置き換えます。
具体的な例としては、下記になります。
•コンテナやロードバランサーのヘルスチェックに基づき、タスクの状態を監視し、異常と判断されたタスクを置き換えます。
•タスクの状態やスケジューリングに関するパラメータ（maximumPercent、desiredCountなど）に従って、タスクの管理や再スケジュールが行われます。
利用可能なスケジューリング戦略は下記から選択できます。
- REPLICA
- タスクをクラスタ全体に配置し、必要な数を維持します。
- タスク配置戦略や制約を使ってカスタマイズが可能。
- DAEMON(Fargate タスクは、対応していません。)
- クラスタ内のアクティブなコンテナインスタンスごとに1つのタスクをデプロイします。
- タスク数や配置戦略の指定は不要。
※詳しくは以下をご覧ください。
Service Connectとサービス検出
Service Connectとサービス検出は、共にECSサービスの名前解決を提供する機能になります。
- Service Connect
- Amazon ECS サービス間のみで名前解決をする時に使用
- AWS Cloud Map にある同一の名前空間(例：service)に所属するECSサービス同士(例：a.service / b.service)のみで名前解決できる。
- ECSサービスと同一の VPC 内にある他の AWSサービス (EC2、Lambda など) は、ECS サービスの名前解決ができない。
- サービス検出と異なり、「VPC内の DNS サーバー (Route 53 Resolver) 」と、「VPCに紐づいた Route 53 プライベートホストゾーン」に依存しない名前解決方式となるため。
- 名前解決要求に関するメトリクスやログの出力が可能
- サービス検出
- Amazon ECS サービス間の他、Amazon ECS サービスに他のAWSサービスから名前解決する時
- ECSサービスと同一の VPC 内にある他の AWSサービス (EC2、Lambda など) は、ECS サービスの名前解決をすることができる。
- サービス検出は、「VPC内の DNS サーバー (Route 53 Resolver) 」と、「VPCに紐づいた Route 53 プライベートホストゾーン」に依存した名前解決方式となるため。
- 該当の Route 53 プライベートホストゾーン と関連付けた VPC の中にあるリソースから、名前解決ができる。
- 制約として、既存のサービス検出の名前空間に ECS サービスを追加するには、同じVPC にある ECS サービス である必要がある。
- 名前解決要求に関するメトリクスやログの出力は不可能
※詳しくは弊社ブログをご覧ください。
サービスの Auto Scaling
CloudWatch アラームに応じてサービス内のタスク数を指定範囲内で調整してくれる機能になります。
デフォルトでは無効です。
タスク配置
起動タイプがAmazon EC2の場合に指定する設定になります。
Amazon ECS のタスク配置オプションは、タスクをクラスター内のインスタンスにどのように配置するかを指定します。
AZバランススプレッド/AZバランスビンバック/ビンバック/ホストごとに１つのタスク/カスタム/ランダムから選択できます。（デフォルトでは、AZバランススプレッドが指定されています。）
大まかに下記の３種類に大別できます。
- binpack：コンテナを効率的に配置して、EC2インスタンスの数を最小限にする方法。コンテナが必要とするCPUやメモリに合わせて配置します。
- random：利用可能なインスタンスの中から適当に選んで、コンテナを増やしたり減らしたりします。
- spread：コンテナを平等にわけ、各インスタンスやエリアに均等に配置します。
※詳しくは以下をご覧ください。
ECSのログ設定の補足（2023.12.13追記）
ECSの勉強をしていると取得できるログがたくさんあり、混乱するというお声をいただきました。
ですので下記に大枠の概要を書かせていただきます。
- クラスターで設定するCloudWatch Container Insights：クラスターやタスク単位でメトリクスを収集する。（CPU使用率など）
- タスク定義で設定するログ収集：コンテナ内で実行されるプロセスやアプリケーションによって生成される（標準出力や標準エラー出力）情報を収集（アプリケーションの状態、実行結果、通常のログメッセージなど）
- タスク定義で設定するトレース収集：アプリケーションやシステムの動作を詳細に追跡するプロセス。（関数呼び出し、リクエストの流れ、サービス間のインタラクションなど）
- タスク定義で設定するメトリクス収集：システムやアプリケーションのパフォーマンスを測定するための定量的なデータ。（CPU 使用率、メモリ使用量、レスポンスタイム、リクエスト数など）
まとめ
Amazon ECSはパラメータが多く、よくパラメータの意味を忘れてしまうのでブログにまとめてみました。
本記事が誰かの助けになれば幸いです。
日高 僚太(執筆記事の一覧)
EC部ソリューションアーキテクト2課 / AWS認定資格 12冠
2022年IT未経験で新卒入社しました。
最近はダーツとサウナが気になっています！
記事に関するお問い合わせや修正依頼⇒ hidaka@serverworks.co.jp
