AWS 認定資格 ラボ
コンピューティング ・

ECS タスク定義とサービスの違いを完全解説（リビジョン管理・ローリングデプロイ・希望数）

Amazon ECS のタスク定義（Task Definition）とサービス（Service）の役割と違いを、リビジョン管理・ローリングデプロイ・希望数の維持・ALB 連携・スケジューラの内部動作まで体系的に解説。設計時に迷いやすい「タスク単独実行 vs サービス化」の判断軸も整理する。

#AWS #ECS #コンテナ #タスク定義 #サービス #コンピューティング

ECS で迷う第一歩は「タスク定義」と「サービス」の役割分担。タスク定義は設計図、サービスは“常に N 個動かす”運用係。両者は別物として理解すると、デプロイ・スケール・障害復旧の設計が一気にクリアになる。

1. 概要（端的に）

Amazon ECS では、コンテナを動かすために 4 つの概念（クラスター・タスク定義・タスク・サービス）を組み合わせる。このうち タスク定義（Task Definition）と サービス（Service）は責務がはっきり分かれている。

  • タスク定義 — 「どんなコンテナを、どんな設定で動かすか」を JSON で宣言する設計図。リビジョン番号で世代管理される。
  • サービス — そのタスク定義を「常に N 個動かし続ける」スケジューラ。ALB と連動し、ローリングデプロイや障害時の自動再起動も担う。

タスク定義は静的な定義、サービスは実行時の運用主体、と覚えると間違えにくい。

2. それぞれの責務（What）

2-1. タスク定義（Task Definition）が決めること

  • Docker イメージ URI（ECR / Docker Hub 等）
  • vCPU / メモリの割り当て
  • ポートマッピング、ボリュームマウント
  • 環境変数 / Secrets Manager / Parameter Store 連携
  • タスクロール（コンテナから AWS API を叩くときの IAM）
  • タスク実行ロール（ECR pull・ログ書き込みなど ECS 自身の権限）
  • ネットワークモード（awsvpc / bridge / host / none）
  • ログドライバ（awslogs / firelens / splunk 等）
  • 起動タイプ（EC2 / Fargate）の互換性宣言
  • サイドカー含む複数コンテナ定義

タスク定義は変更不可（immutable）。設定を変えると family:revision（例 web:42）の新リビジョンが生まれる。

2-2. サービス（Service）が決めること

  • どの タスク定義リビジョン を使うか（web:42 など）
  • 希望数（desired count） ＝ いつも動いていてほしいタスク数
  • デプロイメントコントローラ（ECS rolling / CodeDeploy Blue-Green / EXTERNAL）
  • デプロイ設定（minimumHealthyPercent / maximumPercent / サーキットブレーカー）
  • ロードバランサー（ALB / NLB）と ターゲットグループ への登録
  • ヘルスチェック猶予時間（healthCheckGracePeriodSeconds）
  • スケジューリング戦略（REPLICA / DAEMON）
  • Service Auto Scaling（Application Auto Scaling との連携）
  • Service Discovery（Cloud Map）・Service Connect

サービスは動的な運用主体で、タスクの起動・置き換え・ヘルスチェック・LB 登録を継続的に担う。

3. 4 階層モデルの中での位置付け

ECS の構成は次の 4 階層で理解する。

クラスター（Cluster）        … 論理的な実行環境のグループ
   └─ サービス（Service）     … タスクを「常に N 個」維持するスケジューラ
        ├─ タスク定義参照     … 「どのリビジョン」を動かすか指定
        └─ タスク（Task）     … 実体としての実行単位（コンテナの集合）

タスク定義はクラスター/サービスとは独立したリージョン単位の資産で、複数のサービスから同じ定義を参照できる。

4. タスク定義 vs サービスの比較（早見表）

ECS タスク定義とサービスの違い
評価項目
タスク定義（Task Definition）
サービス（Service）
役割 コンテナの設計図 タスクを N 個維持する運用係
状態 静的（immutable） 動的（タスクを起動・停止・置換）
バージョン管理 リビジョン番号（family:revision） デプロイ単位（service revision）
主な設定 イメージ・CPU/メモリ・IAM ロール・ネットワークモード 希望数・LB 連携・デプロイ戦略・Auto Scaling
ライフサイクル 登録／非アクティブ化のみ 作成→更新→削除を継続的に運用
ロードバランサー 指定不可 ターゲットグループに登録
自動復旧 なし（単発実行） タスク死亡時に自動再起動
スケーリング 対象外 Service Auto Scaling で増減
対応 API RegisterTaskDefinition CreateService / UpdateService
タスク定義＝設計図、サービス＝運用主体。この役割分担を崩さない設計が大原則。

5. リビジョン管理の仕組み

タスク定義は「変更」ではなく「新リビジョンの登録」で更新する。

web:1   ← 初回登録
web:2   ← イメージタグ更新
web:3   ← メモリを 512 → 1024 に変更
web:4   ← 環境変数追加

サービスはこのリビジョンを明示的に指すことでデプロイを開始する。UpdateService で taskDefinition を web:3 → web:4 に切り替えるとローリングデプロイが走る。

古いリビジョンの扱い

  • リビジョンは永続的に残る（明示的に DeregisterTaskDefinition するまで ACTIVE）
  • 非アクティブ化しても、現在動作中のサービスからの参照は引き続き有効
  • 大量に溜まると一覧が見づらくなるので、定期的に古いリビジョンを INACTIVE 化する運用が一般的

6. サービスのデプロイ戦略

サービスは「タスクをどう入れ替えるか」を deploymentController で選ぶ。

6-1. ECS（ローリング）— デフォルト

minimumHealthyPercent と maximumPercent の範囲内で、古いタスクを少しずつ新しいリビジョンへ置き換える。

設定既定値意味
minimumHealthyPercent100デプロイ中も希望数の 最低この割合は稼働させる
maximumPercent200一時的に希望数の最大この割合まで増やしてよい

希望数 4・min 100%・max 200% の場合：新タスクを最大 4 個まで先に起動 → ヘルスチェック OK → 古いタスク順次停止、という増減パターンになる。

6-2. CODE_DEPLOY（Blue/Green）

CodeDeploy が新しいタスクグループ（Green）を別ターゲットグループに用意し、テスト・トラフィックシフトを段階的に行う。瞬時切替・カナリア・線形リリースが選べる。

6-3. EXTERNAL

サードパーティのデプロイツールに任せる。Argo Rollouts や独自パイプラインを使う場合に選ぶ。

ECS デプロイ戦略の使い分け
評価項目
ECS ローリング 推奨
CODE_DEPLOY (Blue/Green)
EXTERNAL
切替方式 段階置換 トラフィックシフト 外部委任
実装難易度 低 中 高
カナリア 不可 可（線形・段階） 実装次第
コスト 通常コスト Green 側で一時 2 倍 実装次第
自動ロールバック サーキットブレーカー CloudWatch アラーム連携 実装次第
主なユース 一般的な Web/API 厳密な検証フローが必要 独自オーケストレーション
まずは ECS ローリング＋サーキットブレーカーで始め、要件に応じて Blue/Green に拡張するのが定石。

7. 希望数（desired count）と自己修復

サービスは 希望数 を「契約値」として扱い、現在数とのギャップを埋め続ける。

  • タスクがクラッシュ → 自動で新タスクを起動
  • AZ 障害で EC2 が失われた → 別 AZ にタスクを再配置
  • ALB ヘルスチェック失敗が続く → 不健全タスクを置換

この自己修復こそ「サービス化」の最大価値。単発のタスク実行（RunTask）では得られない。

サービス Auto Scaling

Application Auto Scaling と統合し、希望数を動的に変える。

  • Target Tracking — CPU・メモリ使用率を一定に保つように増減
  • Step Scaling — CloudWatch アラームをトリガに段階増減
  • Scheduled Scaling — 業務時間帯のみ希望数を上げる

希望数の上限（max capacity）を必ず設定し、暴走スケールでコストが破裂する事故を防ぐ。

8. タスク単独実行 vs サービス化の判断軸

ECS にはサービスを使わず、タスクを単独で起動するパターンもある（RunTask / StartTask / EventBridge スケジュール）。

判断軸：

用途推奨
常時受付の Web/APIサービス（ALB 連携）
常駐ワーカー（SQS ポーリング等）サービス（希望数=並列度）
毎晩 03:00 のレポート生成単発タスク + EventBridge
データ移行・1 回限りの集計単発タスク（RunTask）
各 EC2 ホストに 1 個（log shipper）サービス（DAEMON スケジューリング戦略）

9. よくある設計ミス

  • :latest タグ運用で「何が動いているか」が不明になる — リビジョンと Docker タグを 1:1 で対応させる。
  • サービスを作らず RunTask で常駐させようとする — 落ちたら止まる。常駐ものは必ずサービス化。
  • minimumHealthyPercent=100 のまま希望数 1 — ローリング時に新旧 2 個立てる必要があり、希望数 1 では実質置換不能。希望数 1 のサービスは min を 0、max を 200 にする。
  • タスクロールと実行ロールの混同 — タスクロール＝アプリの権限、実行ロール＝ECR pull や CloudWatch Logs への書き込み権限。混ぜると「ECR から pull できない」「アプリだけ動かない」が混在し原因切り分けが難しくなる。
  • 古いリビジョンを残しすぎる — 数百個溜まると一覧操作が辛い。CI で N 世代より古いものを INACTIVE 化するクリーンアップを組む。

10. ベストプラクティス

  • タスク定義は IaC で管理（CloudFormation / CDK / Terraform）。手動編集はせず PR レビューを通す。
  • イメージタグは不変（commit SHA・ビルド番号） にし、:latest は使わない。
  • サーキットブレーカー＋自動ロールバックを必ず ON。失敗デプロイで本番が止まらない設計。
  • タスクヘルスチェックと ALB ヘルスチェックを両方設計。コンテナ単位とエンドポイント単位で別観点。
  • Service Auto Scaling の上限を必ず設定。コスト暴走の保険。
  • タスクロールに最小権限。*:* で済ませない。
  • CodeDeploy Blue/Green は本番系のクリティカルサービスから順次採用。最初から全サービスに導入すると運用負荷が跳ねる。
  • タスク定義のリビジョンを CI 出力に含める — 監査・障害調査のときに「何番のリビジョンが本番だったか」が即わかる。

11. 関連用語

  • ECS — タスク定義とサービスを束ねる本体サービス
  • Fargate — サービスから指定するサーバーレス実行基盤
  • ECR — タスク定義が参照する Docker イメージのレジストリ
  • ALB — サービスが連携するロードバランサー
  • IAM Role — タスクロール／タスク実行ロールの基礎
  • CloudWatch Logs — ログドライバ awslogs の出力先
  • CodeDeploy — Blue/Green デプロイの制御主体
  • EventBridge — 単発タスクの定期実行トリガ

12. 関連サイト

AWS 公式

参考記事

🎓 試験での出題傾向

試験重要度主な出題パターン
CLF中タスク定義／サービス／クラスターの位置付け
SAA高サービス Auto Scaling、ALB 連携、AZ 障害時の挙動
DVA高タスク定義リビジョン、ローリング vs Blue/Green、IAM ロール設計
SOA中minimumHealthyPercent／maximumPercent、サーキットブレーカー、ロールバック

特に DVA では「タスク定義を更新したが本番に反映されない理由」を問う出題が定番。UpdateService でサービス側のリビジョンを切り替えることを確実に押さえておく。SAA では「Web/API は常駐、バッチは単発」の使い分けが頻出。