タスク定義パラメータオペレーティングシステムとアーキテクチャタスク CPU とメモリタスクネットワークタスクリソースの制限ログ記録タスクストレージ SOCI コンテナイメージの遅延読み込み

Fargate 起動タイプでの Amazon ECS タスク定義の違い

Fargate を使用するには、Fargate 起動タイプを使用するようにタスク定義を設定する必要があります。Fargate の使用については他にもいくつかの考慮事項があります。

タスク定義パラメータ

Fargate 起動タイプを使用するタスクは利用可能な Amazon ECS タスク定義パラメータのすべてをサポートするわけではありません。一部のパラメータはサポートされていません。また、Fargate タスクでは動作が異なるパラメータがあります。

次のタスク定義パラメータは Fargateタスクでは無効です:

disableNetworking
dnsSearchDomains
dnsServers
dockerSecurityOptions
extraHosts
gpu
ipcMode
links
placementConstraints
privileged
maxSwap
swappiness

以下のタスク定義パラメータはFargateタスクで有効ですが、注意すべき制限があります:

linuxParameters – コンテナに適用される Linux 固有のオプションを指定する場合、capabilities に追加できる機能は CAP_SYS_PTRACE のみです。devices、sharedMemorySize、および tmpfs パラメータはサポートされません。詳細については、「Linux パラメータ」を参照してください。
volumes – Fargateタスクはバインドマウントのホストボリュームのみをサポートするため、dockerVolumeConfiguration パラメータはサポートされません。詳細については、「ボリューム」を参照してください。
cpu - AWS Fargate での Windows コンテナの場合、値は 1 vCPU 未満にすることはできません。

タスク定義が Fargateでの使用が有効であることを確認するために、タスク定義を登録する際に以下を指定できます:

AWS Management Console の [Requires Compatibilities (互換性が必要)] フィールドで、FARGATE を指定します。
AWS CLI で、--requires-compatibilities オプションを指定します。
Amazon ECS API で、requiresCompatibilities フラグを指定します。

オペレーティングシステムとアーキテクチャ

AWS Fargate のタスク定義とコンテナの定義を構成する場合、コンテナが実行するオペレーティングシステムを指定する必要があります。以下のオペレーティングシステムが AWS Fargate でサポートされています。

Amazon Linux 2

注記
Linux コンテナは、ホストオペレーティングシステムのカーネルおよびカーネル設定のみを使用することに留意してください。例えば、カーネル構成には sysctl システムコントロールが含まれます。Linux コンテナイメージは、任意の Linux ディストリビューションのファイルとプログラムを含むベースイメージから作成できます。CPU アーキテクチャが一致すると、どの OS 上で実行しているどの Linux コンテナイメージからでもコンテナを実行できます。
Windows Server 2019 Full
Windows Server 2019 Core
Windows Server 2022 Full
Windows Server 2022 Core

AWS Fargate で Windows コンテナを実行する場合、X86_64 CPU アーキテクチャを備えている必要があります。

AWS Fargate で Linux コンテナを実行する場合、ARM ベースのアプリケーションに X86_64 CPU アーキテクチャ、または ARM64 アーキテクチャを使用できます。詳細については、「64 ビット ARM ワークロードでの Amazon ECS タスク定義」を参照してください。

タスク CPU とメモリ

AWS Fargate の Amazon ECS タスク定義では、CPU とメモリをタスクレベルで指定する必要があります。Fargateタスクのコンテナレベルで CPU とメモリを指定することもできますが、これはオプションです。ほとんどのユースケースでは、タスクレベルでこれらのリソースを指定するだけで十分です。以下の表に、タスクレベル CPU とメモリの有効な組み合わせを示します。タスク定義では、メモリの値を MiB または GB の文字列として指定できます。例えば、メモリの値を 3072 (MiB) または 3 GB (GB) のいずれかで指定できます。JSON ファイルでは、CPU 値を CPU ユニットまたは仮想 CPU (vCPU) の文字列として指定できます。例えば、CPU 値を 1 vCPU (CPU ユニット) または 1024 (vCPU) として指定できます。

CPU の値	メモリの値	AWS Fargate でサポートされるオペレーティングシステム
256 (.25 vCPU)	512 MiB、1 GB、2 GB	Linux
512 (.5 vCPU)	1 GB、2 GB、3 GB、4 GB	Linux
1,024 (1 vCPU)	2 GB、3 GB、4 GB、5 GB、6 GB、7 GB、8 GB	Linux、Windows
2,048 (2 vCPU)	4 GB ～ 16 GB (1 GB のインクリメント)	Linux、Windows
4,096 (4 vCPU)	8 GB ～ 30 GB (1 GB のインクリメント)	Linux、Windows
8192 (8 vCPU) 注記このオプションには Linux プラットフォーム `1.4.0` 以降が必要です。	16 GB～60 GB (4 GB のインクリメント)	Linux
16384 (16vCPU) 注記このオプションには Linux プラットフォーム `1.4.0` 以降が必要です。	32 GB～120 GB (8 GB のインクリメント)	Linux

タスクネットワーク

AWS Fargate の Amazon ECS を使用するタスクでは、awsvpc ネットワークモードが必要です。これは各タスクに Elastic Network Interface を提供します。このネットワークモードを使用したタスクの実行またはサービスの作成時に、ネットワークインターフェイスにアタッチするサブネットを 1 つ以上、またはネットワークインターフェイスに適用するセキュリティグループを 1 つ以上、指定する必要があります。

パブリックサブネットを使用している場合は、ネットワークインターフェイスにパブリック IP アドレスを指定するかどうかを決定します。パブリックサブネットの Fargate タスクを使用してコンテナイメージをプルするには、タスクの Elastic Network Interface に、インターネットへのルートまたはリクエストをインターネットにルーティングできる NAT ゲートウェイを持つパブリック IP アドレスが割り当てられている必要があります。　　プライベートサブネットのFargateタスクでコンテナイメージをプルするには、リクエストをインターネットにルーティングするためのNATゲートウェイがサブネットに必要です。Amazon ECR でコンテナイメージをホストする場合、 Amazon ECR を設定してインターフェイス VPC エンドポイントを使用するようにできます。この場合、タスクのプライベート IPv4 アドレスがイメージのプルに使用されます。Amazon ECRインターフェイスエンドポイントの詳細については、Amazon Elastic Container Registry ユーザーガイドの Amazon ECR Interface VPC エンドポイント (AWS PrivateLink)を参照してください。

Fargate サービス向け networkConfiguration セクションの例を以下に示します。


"networkConfiguration": { 
   "awsvpcConfiguration": { 
      "assignPublicIp": "ENABLED",
      "securityGroups": [ "sg-12345678" ],
      "subnets": [ "subnet-12345678" ]
   }
}

タスクリソースの制限

AWS Fargate での Linux コンテナのAmazon ECS タスク定義では、コンテナに設定するリソース制限を定義するための ulimits パラメータがサポートされます。

AWS Fargate での Windows の Amazon ECS タスク定義では、コンテナに設定するリソース制限を定義するための ulimits パラメータがサポートされます。

Fargate でホストされる Amazon ECS タスクは、オペレーションシステムで設定されたデフォルトのリソース制限値を使用します。ただし、nofile リソース制限パラメータを除きます。nofile リソース制限は、コンテナが使用できるオープンファイルの数の制限を設定します。Fargate では、デフォルトの nofile ソフト制限は 65535 で、ハード制限は 65535 です。両方の制限の値を設定できます (最大 1048576)。

以下は、2 倍になったカスタム nofile 制限を定義する方法を示すタスク定義スニペットの例です。


"ulimits": [
    {
       "name": "nofile",
       "softLimit": 2048,
       "hardLimit": 8192
    }
]

調整可能なその他のリソース制限の詳細については、リソースの制限を参照してください。

ログ記録

イベントログ

Amazon ECS は、実行したアクションを EventBridge にログ記録します。Amazon ECS の Eventbridge イベントを使用して、Amazon ECS クラスター、サービスおよびタスクの現在の状態に関するほぼリアルタイムの通知を受け取れます。さらに、これらのイベントに対応するアクションを自動化できます。詳細については、「EventBridge を使用して Amazon ECS エラーへの対応を自動化する」を参照してください。

タスクライフサイクルログ

Fargate で実行されるタスクは、タイムスタンプを公開してタスクライフサイクルの状態を追跡します。AWS CLI および SDK でタスクを説明することにより、AWS Management Console のタスク詳細でタイムスタンプを確認できます。例えば、タイムスタンプを使用して、タスクがコンテナイメージのダウンロードに費やした時間を評価し、コンテナイメージのサイズを最適化するか、Seekable OCI インデックスを使用するかを判断できます。コンテナイメージのプラクティスに関する詳細については、「Amazon ECS コンテナイメージのベストプラクティス」を参照してください。

アプリケーションログ

AWS Fargate の Amazon ECS タスク定義はログ設定の awslogs、splunk、および awsfirelens ログドライバーをサポートします。

このawslogsログドライバーは、Amazon CloudWatch Logs にログ情報を送信するように Fargate タスクを設定します。以下に、awslogs ログドライバーが設定されているタスク定義のスニペットを示します。


"logConfiguration": { 
   "logDriver": "awslogs",
   "options": { 
      "awslogs-group" : "/ecs/fargate-task-definition",
      "awslogs-region": "us-east-1",
      "awslogs-stream-prefix": "ecs"
   }
}

タスク定義で awslogs ログドライバーを使用してコンテナログをCloudWatch Logs に送信する方法の詳細については、Amazon ECS ログを CloudWatch に送信するを参照してください。

タスク定義での awsfirelens ログドライバーの詳細については、「Amazon ECS ログを AWS サービスまたは AWS Partner に送信する」を参照してください。

タスク定義での splunk ログドライバーの使用の詳細については、「splunk ログドライバー」を参照してください。

タスクストレージ

Fargate でホストされた Amazon ECS タスクでは、次のストレージタイプがサポートされています:

Amazon EBS ボリュームは、データ集約型のコンテナ化されたワークロード向けに、費用対効果と耐久性に優れた高性能なブロックストレージを提供します。詳細については、「Amazon ECS での Amazon EBS ボリュームの使用」を参照してください。
永続的ストレージ用のAmazon EFS ボリューム。詳細については、「Amazon ECS での Amazon EFS ボリュームの使用」を参照してください。
エフェメラルストレージ用のバインドマウント。詳細については、「Amazon ECS でのバインドマウントの使用」を参照してください。

Seekable OCI (SOCI) を使ったコンテナイメージの遅延読み込み

Linux プラットフォームバージョン 1.4.0 を使用する Fargate 上の Amazon ECS タスクは、Seekable OCI (SOCI) を使用してタスクをより速く開始できます。SOCI では、コンテナは起動前にイメージプルに数秒しかかからないため、イメージがバックグラウンドでダウンロードされている間、環境のセットアップとアプリケーションのインスタンス化に時間を割けます。これは遅延読み込みと呼ばれています。Fargate が Amazon ECS タスクを開始すると、Fargate はタスク内のイメージに SOCI インデックスが存在するかどうかを自動的に検出し、イメージ全体がダウンロードされるのを待たずにコンテナを起動します。

SOCI インデックスなしで実行されるコンテナの場合、コンテナイメージはコンテナを起動する前に完全にダウンロードされます。この動作は、Fargate の他のすべてのプラットフォームバージョンと Amazon EC2 インスタンス上の Amazon ECS 最適化された AMI でも同じです。

Seekable OCI インデックス

Seekable OCI (SOCI) は AWS によって開発されたオープンソースのテクノロジーであり、コンテナイメージを遅延読み込みすることでコンテナをより速く起動できます。SOCI は、既存のコンテナイメージ内のファイルのインデックス (SOCI インデックス) を作成することで機能します。このインデックスは、イメージ全体をダウンロードする前にコンテナイメージから個々のファイルを抽出できるため、コンテナをより速く起動するのに役立ちます。SOCI インデックスは、コンテナレジストリ内のイメージと同じリポジトリにアーティファクトとして保存する必要があります。インデックスはイメージのコンテンツの信頼できるソースなので、信頼できるソースからの SOCI インデックスのみを使用してください。詳細については、「コンテナイメージを遅延ロードするためのSeekable OCIの導入」を参照してください。

考慮事項

Fargate に SOCI インデックスを使用してコンテナイメージをタスクに遅延読み込ませる場合は、次の点を考慮してください。

Linux プラットフォームバージョン 1.4.0 で実行されるタスクのみ SOCI インデックスを使用できます。Fargate で Windows コンテナを実行するタスクはサポートされていません。
X86_64 または ARM64 CPU アーキテクチャ上で実行されるタスクがサポートされています。
タスク定義内のコンテナイメージには、イメージと同じコンテナレジストリに SOCI インデックスが必要です。
タスク定義内のコンテナイメージは、互換性のあるイメージレジストリに保存する必要があります。以下に互換性のあるレジストリを示します。
- Amazon ECR プライベートレジストリ
gzip 圧縮を使用する、または圧縮されていないコンテナイメージのみがサポートされます。zstd 圧縮を使用するコンテナイメージはサポートされていません。
圧縮サイズが 250 MiB より大きいコンテナイメージを使用して遅延読み込みを試すことをお勧めします。小さいイメージを読み込む時間が短くなる可能性は低くなります。
遅延読み込みによってタスクの開始にかかる時間が変わる可能性があるため、Elastic Load Balancing のヘルスチェック猶予期間など、さまざまなタイムアウトを変更する必要がある場合があります。
コンテナイメージが遅延読み込みされないようにするには、コンテナレジストリーから SOCI インデックスを削除します。タスク内のコンテナイメージが考慮事項のいずれかを満たさない場合、そのコンテナイメージはデフォルトの方法でダウンロードされます。

Seekable OCI インデックスの作成

コンテナイメージを遅延ロードするには、SOCI インデックス (メタデータファイル) を作成し、コンテナイメージと共にコンテナイメージリポジトリに保存する必要があります。SOCI インデックスを作成しプッシュするには、GitHub にあるオープンソースの soci-snapshotter CLI ツールを使用できます。または、CloudFormation AWS SOCI Index Builder をデプロイすることもできます。これは、コンテナイメージが Amazon ECR にプッシュされるときに SOCI インデックスを自動的に作成してプッシュするサーバーレスソリューションです。ソリューションとインストール手順の詳細については、GitHub の「CloudFormation AWS SOCI Index Builder」を参照してください。CloudFormation AWS SOCI Index Builder は SOCI の導入を自動化できる手段ですが、オープンソースの SOCI ツールの方がインデックス生成に関してはより柔軟性があり、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインにインデックス生成を統合できます。

注記

イメージの SOCI インデックスを作成するには、そのイメージが soci-snapshotter を実行しているコンピュータ上の containerd イメージストアに存在する必要があります。イメージが Docker イメージストアにある場合、イメージは見つかりません。

タスクが遅延読み込みを使用したことの検証

SOCI を使用してタスクが遅延読み込みされたことを確認するには、タスク内部からタスクメタデータエンドポイントを確認します。タスクメタデータエンドポイントバージョン 4 をクエリすると、クエリ元のコンテナのデフォルトパスに Snapshotter フィールドが存在します。さらに、/task パス内のコンテナごとに Snapshotter フィールドがあります。このフィールドのデフォルト値は overlayfs であり、SOCI が使用されている場合、このフィールドは soci に設定されます。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

コンテナスワップメモリ空間の管理

Windows を実行している EC2 インスタンスでのタスク定義の違い