79. タスク定義は設計図、タスクは実体である — クラスター・サービス・タスクの3層と宣言の分離

DynamoDB編のパーティションキー、Lambda編の関数設定と実行環境と同じ「宣言と実体の分離」が、コンテナではどう現れるか。ECSの登場人物を、宣言側(何を動かしたいか)と実体側(いま動いているもの)に仕分けながら、1枚ずつ図で追っていきます。

① 設計図と実体は別物

タスク定義JSONで書く設計図(blueprint)

「このイメージを、このCPU・メモリで動かせ」と宣言

タスク実際に動く実体

公式の言い回し: task definition は "a blueprint for your application. It is a text file in JSON format that describes the parameters and one or more containers that form your application"(設計図=JSON形式のテキストファイル)。
task は "the instantiation of a task definition within a cluster"(クラスター内でタスク定義が実体化されたもの)。
設計図を作ったあと "you can specify the number of tasks to run on your cluster"(動かすタスク数を指定できる)=1枚の図から複数の実体。

タスク定義は「動かしたいものの宣言」、タスクはそれが実際に動いている実体。この分離は、Lambda編で見た「関数の設定」と「その実行環境で実際に走るプロセス」の関係、オブジェクト指向でいう「クラス(設計図)」と「インスタンス(実体)」そのものです。

② 設計図に書くこと

タスク定義JSONに宣言で書き切る

イメージDocker image

CPU/メモリタスク/コンテナ単位

ネットワークnetworking mode

ログ設定logging

IAMロールtask role

ボリュームdata volumes

起動コマンドcommand

実行基盤capacity

公式自身が "The following are some of the parameters" と書くとおり一部抜粋で、他にコンテナのOS指定、コンテナ終了/失敗時にタスクを継続するか等の項目もある。
実行基盤の原文: "The capacity to use, which determines the infrastructure that your tasks are hosted on"。イメージは "The Docker image to use with each container in your task"。
CPU/メモリは "How much CPU and memory to use with each task or each container within a task"(タスク単位でもコンテナ単位でも指定できる)。
必須は family と container definitions のみ。原文: "The family and container definitions are required in a task definition. In contrast, task role, network mode, volumes, and launch type are optional."
パラメータリファレンスは現在、Managed Instances / Fargate / EC2 の実行基盤別にページが分かれている(required/optional の文は Fargate 版パラメータページ冒頭より)。

設計図には「使うイメージ・リソース量・ネットワーク・ログ・権限・起動コマンド」までを宣言で書き切る。実行時に手で組み立てるのではなく、あらかじめ全部書いておく――これが宣言的状態管理の入口です。

③ リビジョンを積み上げる

my-app:1family「my-app」の revision 1

my-app:2連番で積まれる

my-app:3最新の ACTIVE リビジョン

"my-app" とだけ指定すると、ここが使われる

"When you register a task definition, you give it a family, which is similar to a name for multiple versions of the task definition, specified with a revision number."
"The first task definition that's registered into a particular family is given a revision of 1, and any task definitions registered after that are given a sequential revision number."(初回は revision 1、以降は連番)
RunTask の taskDefinition パラメータ: "The family and revision (family:revision) or full ARN of the task definition to run. If a revision isn't specified, the latest ACTIVE revision is used."(リビジョン省略時は最新のACTIVEリビジョン)

設計図そのものが family:revision の形でイミュータブルに積み上がる。既存を上書きせず新しい版を足し、指定がなければ最新版が選ばれる――これは前レッスンで見た「イメージは書き換えずタグで積む」思想の設定版であり、DynamoDB編の追記ログ(append-only)と同じ発想です。

④ サービスとクラスター

クラスタータスク・サービスの論理的グルーピング

リージョンに閉じる

それぞれの実体

サービス「N個維持し続けよ」という長期の宣言

単発タスクstandalone task

タスク×3desired=3。1つ落ちたら自動で1つ立て直す

タスク→終了バッチ: work して stop。維持されない

service(公式): "An Amazon ECS service runs and maintains your desired number of tasks simultaneously in an Amazon ECS cluster ... if any of your tasks fail or stop for any reason, the Amazon ECS service scheduler launches another instance based on your task definition ... to maintain your desired number of tasks in the service."(望んだ数を維持し続ける/落ちたら再起動)
Featuresでの一言表現: service = "A long running stateless application"、task = "An application such as a batch job that performs work, and then stops."
cluster: "An Amazon ECS cluster is a logical grouping of tasks or services that provides the infrastructure capacity for your containerized applications."(論理的なグルーピングであり、実行基盤=キャパシティを提供する側とも結びつく)
"Clusters are AWS Region specific."(クラスターはリージョン固有)

同じ設計図から生まれた実体でも、扱い方は2種類。「やって終わる」バッチは単発タスク、「動き続けてほしい」ものはサービスで N 個維持を宣言する。サービスの「望ましい数を宣言し、実行系がそれを実現し続ける」構図は、認証暗号編の「ポリシー文書(宣言)を書き、評価エンジンが実現する」のと同じ宣言的状態管理です(サービスの深掘りは次レッスン)。

⑤ 公式の3層モデル

Provisioning操作口: コンソール / CLI / SDK / CDK

「こう動かして」と伝える入口

実体を配置し、望んだ状態に維持

ControllerECSスケジューラ = アプリを管理するソフトウェア

基盤は横並びで選べる

Capacityコンテナが実際に動く土台

Fargateサーバレス

EC2自分で管理

Managed InstancesAWSが基盤運用

新規ワークロードの推奨

ECS Anywhereオンプレ/VM

公式: "There are three layers in Amazon ECS"。Capacity = "The infrastructure where your containers run"、Controller = "Deploy and manage your applications that run on the containers"、Provisioning = "The tools that you can use to interface with the scheduler"。
Fargate = "a serverless, pay-as-you-go compute engine"。EC2 = "You choose the instance type, the number of instances, and manage the capacity."
ECS Managed Instances = "run containerized workloads on a range of Amazon EC2 instance types while offloading infrastructure management to AWS"。推奨は clusters ページの Note より: "Amazon ECS Managed Instances is the recommended choice for most new workloads"。
ECS Anywhere = "registering an external instance such as an on-premises server or virtual machine (VM), to your Amazon ECS cluster"。
"The Amazon ECS scheduler is the software that manages your applications."(スケジューラ=アプリを管理するソフトウェア)
Provisioning の公式列挙は AWS Management Console / AWS CLI / AWS SDKs / AWS CDK。

あなたが触るのは一番上の操作口(Provisioning)だけ。真ん中のスケジューラ(Controller)が宣言を受け取り、一番下の基盤(Capacity)の上に実体を置き、望んだ状態に保ち続ける。API Gateway編で見た「リクエストを受けて裏側の実体へ振り分ける制御層」と同じ、操作・制御・実行の三分割です。

⑥ 宣言は基盤から独立

タスク定義実行基盤を特定しない宣言

タスクon Fargate(サーバレス基盤)

タスクon EC2(自前EC2基盤)

"A cluster can contain a mix of tasks that are hosted on Amazon ECS Managed Instances, AWS Fargate, Amazon EC2 instances, or external instances."(1つのクラスターに Managed Instances・Fargate・EC2・外部インスタンスのタスクを混在させられる)
どの基盤に載せるかはタスク実行時の launch type または capacity provider strategy で決まり、タスク定義そのものは特定の基盤に縛られない(タスク定義側では requiresCompatibilities で「この基盤で動くか」の検証を宣言することもできる)。
Managed Instances だけは公式が「capacityProviderStrategy を指定し launchType は省略する」使い方を指定している。RunTask の launchType の Valid Values は EC2 | FARGATE | EXTERNAL | MANAGED_INSTANCES。

同じクラスターの中で、片方は Fargate、もう片方は EC2 でタスクを動かせる。これは「動かしたいものの宣言(タスク定義)」が「実際に動かす基盤(Capacity)」から独立している何よりの証拠です。設計図と実体、宣言と実行――この分離こそが、ECSの登場人物を1枚に整理する軸でした。

公式ドキュメントで詳しく ↗