Amazon ECS（Elastic Container Service）

概要

AWSが提供するフルマネージドなコンテナオーケストレーションサービス
コンテナを簡単にデプロイ・管理・スケーリングできる
代表的な起動タイプ
- EC2起動タイプ：EC2インスタンス上で動かす
- Fargate起動タイプ：サーバーレスで基盤を意識せず動かす

ECSの主要コンポーネント

1. クラスタ（Cluster）

ECSの基盤となる入れ物
タスクやサービスを実行する場所
EC2インスタンスやFargateリソースをまとめる単位

2. タスク定義（Task Definition）

タスクの設計図
記載する内容：
- 使用するDockerイメージ
- CPU・メモリの割り当て
- 環境変数
- ポート設定
- コンテナ数（1つ以上）

3. タスク（Task）

タスク定義から実際に起動したインスタンス
実際にアプリケーションが稼働する単位
1つのタスクの中に複数のコンテナを含めることも可能

4. サービス（Service）

タスクを安定稼働させる仕組み
機能：
- 指定した数のタスクを維持（オートヒーリング）
- ALB/NLBと連携してロードバランシング
- ローリング更新やブルー/グリーンデプロイ
サービスなしで単発タスク実行も可能（バッチ処理など）

5. コンテナ（Container）

実体のアプリケーション
タスク内で動くプロセス
Dockerイメージから起動
サイドカー構成（例：アプリ＋ログ収集）も可能

関係性イメージ（テキスト図解）

ECS クラスタ（Cluster）
│   ← コンテナを動かす基盤（EC2/Fargate）
│
├─ サービス（Service）
│    │   ← タスク数を維持・デプロイ管理
│    │
│    ├─ タスク（Task）
│    │    │   ← タスク定義から起動された実体
│    │    │
│    │    ├─ コンテナ（Container）
│    │    │     ← アプリ本体
│    │    └─ コンテナ（Container）
│    │          ← サイドカー（ログ収集など）
│    │
│    └─ タスク（Task）
│         └─ コンテナ（Container）
│
└─ （サービスを使わず単発で動かすタスクも可能）

クラスタ = 実行基盤（工場）
タスク定義 = 設計図（どんなアプリをどう動かすか）
タスク = 設計図から実際に動いたインスタンス（生産ライン）
サービス = タスクを管理して安定稼働させる仕組み（工場の監督）
コンテナ = アプリケーションの実体（機械）

ECSのローリングアップデート（Rolling Update）

ECS サービスに対して新しいタスク定義を適用すると、古いタスクを順次停止し、新しいタスクを起動していく
これにより「アプリを落とさずにバージョンを切り替えられる」

制御パラメータ

サービス定義時に次の2つを設定できる：

minimumHealthyPercent
- デプロイ中に「最低限維持すべき稼働中タスクの割合」
- 例: 100 → 現行タスクを止める前に必ず新タスクを立ち上げる
maximumPercent
- デプロイ中に「最大で何％までタスクを増やして良いか」
- 例: 200 → 一時的に2倍までスケールアウトして更新
例：サービスに10タスクがあるとき
- min 50%, max 200% に設定すると、更新中は 5〜20タスクの範囲で入れ替え が進む

ECSのスケーリング

ECSのスケーリングには大きく2種類あります。

1. Service Auto Scaling

タスク数を自動でスケール
トリガー例：
- CPU利用率が70%を超えたらタスクを+2
- SQSのキュー長に応じてタスク数を増減
EC2起動タイプでもFargate起動タイプでも使える
アプリケーションレベルのスケール

2. Cluster Auto Scaling（EC2起動タイプの場合）

クラスタに属するEC2インスタンス自体をスケール
Service Auto Scalingでタスク数を増やすと、インスタンスが足りなくなる場合あり
その場合、自動的にEC2インスタンスを追加起動してキャパシティを確保
インフラレベルのスケール

（Fargate起動タイプではAWSが基盤を管理するので、クラスタスケーリングを意識する必要なし）

Amazon ECS vs Amazon EKS

共通点

どちらも AWSのコンテナオーケストレーションサービス
コンテナをデプロイ・スケーリング・管理する基盤
Fargate を利用すれば両方とも「サーバレスでコンテナ実行」が可能

ECS（Elastic Container Service）

AWS独自のオーケストレーションサービス
タスク定義 / サービス / クラスタ というシンプルな概念
学習コストが低い（AWS独自用語だけ理解すればOK）
他のAWSサービス（ALB, CloudWatch, IAM, App Meshなど）とシームレス統合
Kubernetesの知識が不要

EKS（Elastic Kubernetes Service）

マネージドKubernetes（オープンソースK8s互換）
Kubernetes API がそのまま使える（kubectl / Helm / ArgoCDなど）
移植性が高く、オンプレや他クラウドのKubernetesともほぼ同じ運用が可能
ただし学習コストが高い（Pod, Deployment, Service, Ingress, Namespace... などK8sの概念が必要）
運用管理も複雑になりがち

ECS vs EKS 比較表

項目	ECS	EKS
管理モデル	AWS独自（シンプル）	標準Kubernetes
学習コスト	低い（AWS知識中心）	高い（Kubernetes知識必須）
AWS連携	ネイティブ統合が強い	追加設定が必要な場合も
移植性	低い（AWS依存）	高い（他クラウド/オンプレ可）
規模	小〜中規模向き	中〜大規模、マルチクラウド向き
起動タイプ	EC2 / Fargate	EC2 / Fargate

ポイント

ECS = AWS専用、シンプル、学習コスト低
EKS = Kubernetes標準、移植性高、複雑
どちらもFargateでサーバレス実行可能
マルチクラウドやK8s運用経験がある場合はEKSが適切