Docker vs Podman, ECS vs EKS vs Fargate: コンテナオーケストレーション選定

はじめに

コンテナ技術は現代のソフトウェア開発とデプロイに欠かせないものとなりました。本記事では、コンテナランタイムの選定からオーケストレーションサービスの比較まで、包括的に解説します。

身近な例えで理解するコンテナ

• コンテナ = 引越し用の段ボール箱。アプリケーションと必要なものを全て箱に詰めれば、どこに持っていっても同じように使える
• Docker = 段ボール箱の規格を作った会社。最も普及している
• Podman = 同じ規格の段ボール箱を作る別の会社。管理人（rootデーモン）がいなくても使える
• オーケストレーション = 大量の段ボール箱を効率的に管理する倉庫システム

オーケストレーションサービスの例え:

• ECS = AWSが運営する物流倉庫。AWS専用だが使いやすい
• EKS = 国際標準（Kubernetes）に準拠した物流倉庫。どのクラウドでも同じ操作方法
• Fargate = 倉庫の管理をAWSに完全委託。自分はコンテナの中身だけに集中

コンテナランタイム: Docker vs Podman

基本比較

Docker Desktopのライセンス問題

2021年にDocker社はDocker Desktopの利用規約を変更し、従業員250人以上または年間収益1000万ドル以上の企業は有料サブスクリプション（月$5〜）が必要となった。これを受けてPodmanへの移行を検討する企業が増えている。

どちらを選ぶべきか

AWSコンテナオーケストレーション: ECS vs EKS vs Fargate

サービスの関係性

+----------------------------------+
|        コンテナ実行方法          |
|                                  |
|  +----------+    +----------+    |
|  | ECS      |    | EKS      |    |
|  | (AWS独自) |    |(Kubernetes)|   |
|  +----+-----+    +----+-----+    |
|       |               |          |
|  +----v-----+    +----v-----+    |
|  |実行環境の選択              |   |
|  |                            |   |
|  | +--------+ +--------+     |   |
|  | |EC2     | |Fargate |     |   |
|  | |(自分で  | |(AWSに  |     |   |
|  | | 管理)  | | お任せ)|     |   |
|  | +--------+ +--------+     |   |
|  +----------------------------+  |
+----------------------------------+

• ECS: AWS独自のコンテナオーケストレーションサービス
• EKS: AWSが提供するマネージドKubernetes
• Fargate: ECSまたはEKSで使えるサーバーレスコンテナ実行環境

詳細比較

料金比較

※ EKSのクラスター料金（$0.10/時間=$73/月）が追加でかかることに注意。

判断フローチャート

[コンテナオーケストレーション選定]
    |
    v
[Kubernetesの知識がチームにある? or マルチクラウドが必要?]
    |
    +-- はい --> EKS
    |           |
    |           v
    |       [インフラ管理を最小化したい?]
    |           |
    |           +-- はい --> EKS on Fargate
    |           |
    |           +-- いいえ --> EKS on EC2
    |                          （GPU利用、DaemonSet、コスト最適化）
    |
    +-- いいえ
         |
         v
    [AWSに最適化された簡単な運用がしたい?]
         |
         +-- はい --> ECS
         |           |
         |           v
         |       [インフラ管理を最小化したい?]
         |           |
         |           +-- はい --> ECS on Fargate
         |           |           （最もシンプル）
         |           |
         |           +-- いいえ --> ECS on EC2
         |                          （コスト最適化、GPU利用）
         |
         +-- いいえ --> [小規模で設定を最小限にしたい?]
                          |
                          +-- はい --> App Runner
                          |           （コンテナオーケストレーション不要）
                          |
                          +-- いいえ --> ECS on Fargate

ECSの実践

タスク定義の例

ECSでは「タスク定義」でコンテナの設定を行う。

{
  "family": "web-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "123456789.dkr.ecr.ap-northeast-1.amazonaws.com/web-app:latest",
      "portMappings": [
        {
          "containerPort": 3000,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/web-app",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

ECSのアーキテクチャパターン

[ユーザー]
    |
    v
[ALB (Application Load Balancer)]
    |
    +------+------+
    |      |      |
    v      v      v
[Task1] [Task2] [Task3]   <-- ECS Service (Fargate)
    |      |      |
    v      v      v
[RDS Aurora]  [ElastiCache]

EKSの実践

Kubernetesの基本概念

Kubernetesのメリット・デメリット

メリット:

• マルチクラウド対応（AWS、GCP、Azure、オンプレミス）
• 巨大なエコシステム（Helm、Istio、ArgoCD等）
• 宣言的な設定管理
• 自動復旧、ローリングアップデート
• カスタムリソースによる拡張性

デメリット:

• 学習コストが非常に高い
• 運用が複雑
• 小規模プロジェクトにはオーバースペック
• EKSのクラスター料金が月$73かかる

ユースケース別の推奨

Webアプリケーション（小〜中規模）

推奨: ECS on Fargate

[ALB] --> [ECS/Fargate Service]
              |-- web-container (Next.js)
              +-- [RDS Aurora]

理由:

• 管理が簡単
• 自動スケーリング
• AWS統合が容易

マイクロサービスアーキテクチャ（大規模）

推奨: EKS

[Ingress Controller (ALB)]
    |
    +-- [Service A] (Namespace: frontend)
    +-- [Service B] (Namespace: backend)
    +-- [Service C] (Namespace: backend)
    +-- [Service D] (Namespace: data)

[Istio Service Mesh] -- サービス間通信の管理
[ArgoCD] -- GitOpsによるデプロイ管理

理由:

• サービスメッシュ（Istio等）でマイクロサービス間の通信を管理
• Helmでアプリケーションのパッケージ管理
• GitOpsで宣言的なデプロイ管理

バッチ処理

推奨: ECS on Fargate（タスク起動）

[EventBridge (スケジュール)] --> [ECS RunTask]
                                      |
                                      v
                                [Fargate Task]
                                      |
                                      v
                                [S3 / RDS]

理由:

• 実行時のみ課金
• スケジュール実行が簡単
• 長時間実行も可能

実際の企業での採用事例

ECS

• Duolingo: 言語学習アプリのバックエンドをECS on Fargateで運用
• Samsung: IoTプラットフォームのマイクロサービスをECSで管理

EKS

• Airbnb: 数千のマイクロサービスをKubernetes上で運用
• Spotify: GKE（Google版）を大規模に利用
• LINE: Kubernetesベースのプラットフォームで大量のサービスを管理

コンテナセキュリティのベストプラクティス

移行パスの考え方

[開発初期] App Runner or Lambda
    ↓ コンテナが必要になった
[成長期] ECS on Fargate
    ↓ より細かい制御が必要
[成熟期 - AWS専用] ECS on EC2
[成熟期 - マルチクラウド] EKS
    ↓ 大規模マイクロサービス
[エンタープライズ] EKS + サービスメッシュ

まとめ

コンテナランタイム

オーケストレーション

多くのプロジェクトではECS on Fargateから始めるのが最も合理的。Kubernetes の必要性が明確になったときにEKSに移行するアプローチを推奨する。

参考リンク

• Amazon ECS公式ドキュメント
• Amazon EKS公式ドキュメント
• Docker公式ドキュメント
• Podman公式ドキュメント
• Kubernetes公式ドキュメント