# 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 パラメータ](task_definition_parameters.md#container_definition_linuxparameters)」を参照してください。
+ `volumes` – Fargateタスクはバインドマウントのホストボリュームのみをサポートするため、`dockerVolumeConfiguration` パラメータはサポートされません。詳細については、「[ボリューム](task_definition_parameters.md#volumes)」を参照してください。
+ `cpu` - AWS Fargate での Windows コンテナの場合、値は 1 vCPU 未満にすることはできません。
+ `networkConfiguration` – Fargate タスクは、常に `awsvpc` ネットワークモードを使用します。
タスク定義が Fargateでの使用が有効であることを確認するために、タスク定義を登録する際に以下を指定できます:
+ AWS マネジメントコンソール の [**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\$164 CPU アーキテクチャを備えている必要があります。
AWS Fargate で Linux コンテナを実行する場合、ARM ベースのアプリケーションに X86\$164 CPU アーキテクチャ、または ARM64 アーキテクチャを使用できます。詳細については、「[64 ビット ARM ワークロードでの Amazon ECS タスク定義](ecs-arm64.md)」を参照してください。
## タスク CPU とメモリ
AWS Fargate の Amazon ECS タスク定義では、CPU とメモリをタスクレベルで指定する必要があります。ほとんどのユースケースでは、タスクレベルでこれらのリソースを指定するだけで十分です。以下の表に、タスクレベル CPU とメモリの有効な組み合わせを示します。タスク定義では、メモリの値を MiB または GB の文字列として指定できます。例えば、メモリの値を `3072` (MiB) または `3 GB` (GB) のいずれかで指定できます。JSON ファイルでは、CPU 値を CPU ユニットまたは仮想 CPU (vCPU) の文字列として指定できます。例えば、CPU 値を `1 vCPU` (vCPU) または `1024` (CPU ユニット) として指定できます。
| 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)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)を参照してください。
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
}
]
```
調整可能なその他のリソース制限の詳細については、[リソースの制限](task_definition_parameters.md#container_definition_limits) を参照してください。
## ログ記録
### イベントログ
Amazon ECS は、実行したアクションを EventBridge にログ記録します。Amazon ECS の Eventbridge イベントを使用して、Amazon ECS クラスター、サービスおよびタスクの現在の状態に関するほぼリアルタイムの通知を受け取れます。さらに、これらのイベントに対応するアクションを自動化できます。詳細については、「[EventBridge を使用して Amazon ECS エラーへの対応を自動化する](cloudwatch_event_stream.md)」を参照してください。
### タスクライフサイクルログ
Fargate で実行されるタスクは、タイムスタンプを公開してタスクライフサイクルの状態を追跡します。AWS CLI および SDK でタスクを説明することにより、AWS マネジメントコンソール のタスク詳細でタイムスタンプを確認できます。例えば、タイムスタンプを使用して、タスクがコンテナイメージのダウンロードに費やした時間を評価し、コンテナイメージのサイズを最適化するか、Seekable OCI インデックスを使用するかを判断できます。コンテナイメージのプラクティスに関する詳細については、「[Amazon ECS コンテナイメージのベストプラクティス](container-considerations.md)」を参照してください。
### アプリケーションログ
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 に送信する](using_awslogs.md)を参照してください。
タスク定義での `awsfirelens` ログドライバーの詳細については、「[Amazon ECS ログを AWS サービスまたは AWS Partner に送信する](using_firelens.md)」を参照してください。
タスク定義での `splunk` ログドライバーの使用の詳細については、「[`splunk` ログドライバー](example_task_definitions.md#example_task_definition-splunk)」を参照してください。
## タスクストレージ
Fargate でホストされた Amazon ECS タスクでは、次のストレージタイプがサポートされています:
+ Amazon EBS ボリュームは、データ集約型のコンテナ化されたワークロード向けに、費用対効果と耐久性に優れた高性能なブロックストレージを提供します。詳細については、「[Amazon ECS での Amazon EBS ボリュームの使用](ebs-volumes.md)」を参照してください。
+ 永続的ストレージ用のAmazon EFS ボリューム。詳細については、「[Amazon ECS での Amazon EFS ボリュームの使用](efs-volumes.md)」を参照してください。
+ エフェメラルストレージ用のバインドマウント。詳細については、「[Amazon ECS でのバインドマウントの使用](bind-mounts.md)」を参照してください。
## 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 (SOCI) は AWS によって開発されたオープンソースのテクノロジーであり、コンテナイメージを遅延読み込みすることでコンテナをより速く起動できます。SOCI は、既存のコンテナイメージ内のファイルのインデックス (SOCI インデックス) を作成することで機能します。このインデックスは、イメージ全体をダウンロードする前にコンテナイメージから個々のファイルを抽出できるため、コンテナをより速く起動するのに役立ちます。SOCI インデックスは、コンテナレジストリ内のイメージと同じリポジトリにアーティファクトとして保存する必要があります。インデックスはイメージのコンテンツの信頼できるソースなので、信頼できるソースからの SOCI インデックスのみを使用してください。詳細については、「[コンテナイメージを遅延ロードするためのSeekable OCIの導入](https://aws.amazon.com/about-aws/whats-new/2022/09/introducing-seekable-oci-lazy-loading-container-images/)」を参照してください。
SOCI の使用を検討しているお客様は、SOCI Index Manifest v2 のみを使用できます。Fargate で SOCI を以前使用したことのある既存のお客様は、引き続き SOCI Index Manifest v1 を使用できますが、SOCI Index Manifest v2 に移行することを強くお勧めします。SOCI Index Manifest v2 は、一貫したデプロイを確保するために、コンテナイメージとその SOCI インデックスの間に明示的な関係を作成します。
**考慮事項**
Fargate に SOCI インデックスを使用してコンテナイメージをタスクに遅延読み込ませる場合は、次の点を考慮してください。
+ Linux プラットフォームバージョン `1.4.0` で実行されるタスクのみ SOCI インデックスを使用できます。Fargate で Windows コンテナを実行するタスクはサポートされていません。
+ X86\$164 または ARM64 CPU アーキテクチャ上で実行されるタスクがサポートされています。
+ タスク定義内のコンテナイメージは、互換性のあるイメージレジストリに保存する必要があります。以下に互換性のあるレジストリを示します。
+ Amazon ECR プライベートレジストリ
+ gzip 圧縮を使用する、または圧縮されていないコンテナイメージのみがサポートされます。zstd 圧縮を使用するコンテナイメージはサポートされていません。
+ SOCI Index Manifest v2 の場合、SOCI インデックスマニフェストを生成すると、SOCI インデックスの注釈を追加するときにコンテナイメージマニフェストが変更されます。これにより、新しいコンテナイメージダイジェストが作成されます。コンテナイメージのファイルシステムレイヤーの内容は変更されません。
+ SOCI Index Manifest v2 の場合、コンテナイメージがすでにコンテナイメージリポジトリに保存されている場合、SOCI インデックスが生成されたら、コンテナイメージを再プッシュする必要があります。コンテナイメージを再プッシュしても、ファイルシステムレイヤーが重複することでストレージコストは増加せず、新しいマニフェストファイルのみをアップロードします。
+ 圧縮サイズが 250 MiB より大きいコンテナイメージを使用して遅延読み込みを試すことをお勧めします。小さいイメージを読み込む時間が短くなる可能性は低くなります。
+ 遅延読み込みによってタスクの開始にかかる時間が変わる可能性があるため、Elastic Load Balancing のヘルスチェック猶予期間など、さまざまなタイムアウトを変更する必要がある場合があります。
+ コンテナイメージが遅延ロードされないようにするには、SOCI インデックスをアタッチせずにコンテナイメージを再プッシュする必要があります。
**Seekable OCI インデックスの作成**
コンテナイメージを遅延ロードするには、SOCI インデックス (メタデータファイル) を作成し、コンテナイメージと共にコンテナイメージリポジトリに保存する必要があります。SOCI インデックスを作成しプッシュするには、GitHub にあるオープンソースの [soci-snapshotter CLI ツール](https://github.com/awslabs/soci-snapshotter)を使用できます。または、CloudFormation AWS SOCI Index Builder をデプロイすることもできます。これは、コンテナイメージが Amazon ECR にプッシュされるときに SOCI インデックスを自動的に作成してプッシュするサーバーレスソリューションです。ソリューションとインストール手順の詳細については、GitHub の「[CloudFormation AWS SOCI Index Builder](https://awslabs.github.io/cfn-ecr-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` に設定されます。コンテナイメージに SOCI インデックスマニフェスト v2 がアタッチされていることを確認するには、AWS CLI を使用して Amazon ECR からイメージインデックスを取得できます。
```
IMAGE_REPOSITORY=r
IMAGE_TAG=latest
aws ecr batch-get-image \
--repository-name=$IMAGE_REPOSITORY \
--image-ids imageTag=$IMAGE_TAG \
--query 'images[0].imageManifest' --output text | jq -r '.manifests[] | select(.artifactType=="application/vnd.amazon.soci.index.v2+json")'
```
コンテナイメージに SOCI インデックスマニフェスト v1 がアタッチされていることを確認するには、OCI Referrers API を使用できます。
```
ACCOUNT_ID=111222333444
AWS_REGION=us-east-1
IMAGE_REPOSITORY=nginx-demo
IMAGE_TAG=latest
IMAGE_DIGEST=$(aws ecr describe-images --repository-name $IMAGE_REPOSITORY --image-ids imageTag=$IMAGE_TAG --query 'imageDetails[0].imageDigest' --output text)
ECR_PASSWORD=$(aws ecr get-login-password)
curl \
--silent \
--user AWS:$ECR_PASSWORD \
https://$ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/v2/$IMAGE_REPOSITORY/referrers/$IMAGE_DIGEST?artifactType=application%2Fvnd.amazon.soci.index.v1%2Bjson | jq -r '.'
```