Amazon ECS / Fargate講座

この講座では、AWSのコンテナオーケストレーションサービスであるECSとFargateについて学びます。

• コンテナオーケストレーションの必要性
• Amazon ECSの概要と特徴
• ECSの構成要素（クラスター・タスク定義・サービス）
• EC2起動タイプとFargate起動タイプの違い
• AWS Fargateのメリット

1. Amazon ECSとは

1.1 コンテナオーケストレーションの必要性

AWSのEC2などのサーバにDockerをインストールし、DockerコマンドやDocker Composeによりコンテナを起動すれば、コンテナのアプリケーションをデプロイすることはできます。

しかし、この構成には以下のような問題点があり、本番環境でコンテナのメリットを十分に活かすことができません。

EC2自体の管理が必要

まず、Dockerを動かすためのEC2インスタンス自体を管理しなければなりません。OSのパッチ適用やセキュリティアップデート、ディスク容量の監視、インスタンスの障害対応など、サーバ運用の負担がそのまま残ります。コンテナによりアプリケーションのデプロイは容易になっても、その外側のインフラの運用負荷は軽減されません。

スケーリングや障害復旧が手動になる

アクセスの増加に応じてコンテナを増やしたり、異常終了したコンテナを再起動したりする作業を手動で行う必要があります。トラフィックの変動にリアルタイムで対応することが難しく、障害発生時にはサービスが停止し続けるリスクがあります。また、複数サーバにコンテナを分散配置する場合、どのサーバにどのコンテナを配置するかの管理も煩雑になります。

ダウンタイムなしのデプロイが難しい

アプリケーションを更新する際、既存のコンテナを停止してから新しいコンテナを起動する必要があるため、デプロイ時にサービスの中断が発生します。ローリングデプロイやBlue/Greenデプロイといった高度なデプロイ戦略を、ロードバランサーとの連携も含めて手動で実現するのは非常に手間がかかります。

以上のような課題を解決するために必要となるのが、コンテナオーケストレーションです。

1.2 Amazon ECSとは

Amazon ECS（Elastic Container Service）は、AWSが提供するコンテナオーケストレーションサービスです。前述したスケーリング・障害復旧・デプロイといった課題を、AWSの仕組みの中で自動的に解決してくれます。

代表的なコンテナオーケストレーションツールとしてはKubernetesが広く知られていますが、Kubernetesは学習コストや運用の複雑さが課題となることがあります。ECSはAWSに特化することでよりシンプルな構成となっており、AWSを利用しているプロジェクトであれば導入しやすいのが特徴です。

ECSの主な特徴を以下にまとめます。

フルマネージドである

コンテナのスケーリングや配置、障害時の復旧といった管理の仕組みをAWSが提供・運用します。ユーザはこれらの仕組みを自前で構築する必要がなく、アプリケーションの開発・運用に集中できます。

AWSサービスとの統合がしやすい

ECSは、ECR（コンテナイメージの管理）、ALB（ロードバランシング）、CloudWatch（監視・ログ）、IAM（権限管理）など、AWSの各種サービスと深く統合されています。これらを組み合わせることで、効率的なコンテナ環境を容易に構築できます。

Kubernetesと比べて学習コスト・運用難易度が低い

Kubernetesは非常に高機能ですが、その分構成要素や概念が多く、学習や運用のハードルが高くなりがちです。ECSはAWSに特化したシンプルな設計のため、覚えるべき概念が少なく、AWSの知識があれば比較的短期間で導入・運用を始めることができます。

2. ECSの構成要素

続いて、ECSを構成する要素をみていきたいと思います。

ECSの構成要素の階層関係を以下に示します。

graph TB
  subgraph Cluster["クラスター"]
    subgraph Service["サービス"]
      subgraph Task1["タスク"]
        C1[コンテナ]
      end
      subgraph Task2["タスク"]
        C2[コンテナ]
      end
    end
  end
  TD[タスク定義] -. "テンプレート" .-> Task1
  TD -. "テンプレート" .-> Task2

2.1 クラスター

クラスターは、ECSの論理的なグループ単位です。タスクやサービスは、必ずいずれかのクラスターに属します。

環境ごと（開発、ステージング、本番など）にクラスターを分けたり、アプリケーションごとにクラスターを分けたりする運用が一般的です。

ちょっとイメージがつきにくいかもしれませんが、簡単に言えば「この後説明するタスクやサービスをまとめて管理するための一つの箱のようなもの」と考えていただければ大丈夫です。

2.2 タスク定義

タスク定義は、コンテナの実行設定を定義するテンプレートです。Dockerのdocker runコマンドに指定する内容を、JSON形式で記述したものと考えることができます。

タスク定義には以下のような内容が設定できます。

なお、コンテナイメージの保管先としては、AWSのコンテナレジストリサービスであるECR（Elastic Container Registry）を使用するのが一般的です。ECRにプッシュしたイメージのURIをタスク定義に指定することで、ECSがそのイメージを取得してコンテナを起動します。タスク定義の項目の詳細はCreating an Amazon ECS task definition using the console（AWS公式ドキュメント）に記載があります。

2.3 タスク

タスクは、先程説明したタスク定義をもとに実際に起動された実行単位です。タスク定義が「設計図」であるのに対し、タスクは「設計図から作られた、実際に動いているコンテナ」を表します。

1つのタスクには、1つ以上のコンテナを含めることができます。一つのタスクに一つのコンテナだけを紐づけることが多いですが、一つのタスクで複数のコンテナを起動させることもできます。

2.4 サービス

サービスは、実際にタスクを実行する単位です。クラスターの中に作成され、サービスの中に、指定した数のタスクが起動されます。

具体的には、クラスターの中にサービスを作成し、サービスに「どのタスク定義でタスクを起動するか」「何個のタスクを同時に実行するか」といった定義を行います。

サービスの主な機能として、以下があります。

2.5 まとめ

最後に、ここまでの内容を表で整理しておきます。

3. AWS Fargateとは

3.1 ECSの起動タイプ

ECSには、コンテナをどの環境で実行するかを決める「起動タイプ」という設定があり、「EC2起動タイプ」と「Fargate起動タイプ」の2つから選択できます。

EC2起動タイプは、ECSによるコンテナの管理は行いつつも、コンテナが動作するサーバとしてEC2インスタンスを利用する方式です。そのため、EC2自体の管理（OSのパッチ適用やキャパシティの管理など）は引き続き必要になります。

一方、Fargate起動タイプは、コンテナが動作するサーバの管理をAWSに任せる「サーバレス」の方式です。Fargateを利用することで、開発者はコンテナイメージを用意し、先程説明したクラスターやサービスなどの設定を行うだけで、コンテナのアプリケーションをデプロイできます。

きめ細かいサーバの設定が必要な場合はEC2起動タイプが適していますが、多くのケースではFargateで十分に対応できるため、まずはFargateを検討するのがおすすめです。

3.2 Fargateのメリット

AWS Fargateを使用することで、以下のメリットが得られます。

運用負荷の軽減

EC2インスタンスの管理（OSのパッチ適用、セキュリティ更新、キャパシティプランニングなど）が不要になります。インフラ運用に時間を取られることなく、アプリケーション開発に集中できます。

セキュリティの向上

各タスクは独立した環境で実行されるため、タスク間のセキュリティ境界が明確です。また、ホストOSへのアクセスが不要なため、攻撃対象領域が縮小されます。

スケーラビリティ

タスクの起動が高速なため、負荷に応じた迅速なスケーリングが可能です。EC2起動タイプのように、インスタンスの起動を待つ必要がありません。

3.3 Fargateの料金体系

Fargateは、タスクに割り当てたCPUとメモリの量、および実行時間に基づいて課金されます。

• vCPU: 1時間あたりの単価 × 使用時間
• メモリ: 1GBあたりの単価 × 使用時間

タスクが実行されていない時間は課金されないため、一時的に起動して処理を行う「バッチ処理」などとも相性が良いです。

3.4 EC2起動タイプとFargateの比較

プロジェクトの要件に応じて、適切な起動タイプを選択することが重要です。初めてECSを使用する場合や、運用負荷を最小限にしたい場合は、Fargateがおすすめです。

4. ECS/Fargateの主要な設定項目

4.1 ネットワークモード

Fargateでは、awsvpcネットワークモードが使用されます。各タスクに専用のENI（Elastic Network Interface）とプライベートIPアドレスが割り当てられます。

つまり「ECS/Fargateで起動したタスクは、EC2と同じようにVPCやサブネット内で動作しますよ」という形です。

4.2 セキュリティグループ

ECS/Fargateで起動するタスクにも、EC2と同様にセキュリティグループが設定できます。そのため、インバウンドやアウトバウンドの通信をきめ細かく制御できます。

4.3 IAMロール（タスクロール・タスク実行ロール）

タスク定義の表でも触れましたが、ECSでは2種類のIAMロールを設定します。混同しやすいポイントなので、改めて整理しておきます。

タスク実行ロールは、ECSの仕組み側が使うロールです。ECRからコンテナイメージを取得したり、CloudWatch Logsにログを書き込んだりする際に必要になります。ほぼすべてのタスクで設定が必要です。AWS公式のAmazon ECS task execution IAM roleでも「The task execution role grants the Amazon ECS container and Fargate agents permission to make AWS API calls on your behalf.」と説明されており、ECRからのイメージ取得やCloudWatch Logsへのログ送信といった「ECS本体が代行して実行する処理」のために必要なロールであることが分かります。

タスクロールは、コンテナ内で動くアプリケーションが使うロールです。例えば、アプリケーションからS3にファイルをアップロードしたり、DynamoDBにデータを書き込んだりする場合に、必要な権限をこのロールに付与します。AWSサービスにアクセスしないアプリケーションであれば、設定は不要です。

4.4 ログ設定

ECS/Fargateでは、コンテナのログをCloudWatch Logsに出力するのが一般的です。タスク定義でログドライバーとしてawslogsを指定すれば、自動でCloudWatch Logsにログが出力されるようになります。具体的な設定例はSend Amazon ECS logs to CloudWatch（AWS公式ドキュメント）に記載があります。

4.5 ロードバランサーとの接続

ALBとECSサービスの連携構成を以下に示します。

flowchart LR
  Internet[インターネット] --> ALB[ALB]
  ALB --> Task1[タスク AZ-a]
  ALB --> Task2[タスク AZ-c]
  ECR[Amazon ECR] -- "イメージをpull" --> Task1
  ECR -- "イメージをpull" --> Task2

  subgraph ECS["ECS サービス"]
    Task1
    Task2
  end

ECSのサービスは、ALB（Application Load Balancer）やNLB（Network Load Balancer）と連携させることができます。ロードバランサーを設定すると、外部からのリクエストが複数のタスクに自動で振り分けられるようになります。

タスクが増減した場合もロードバランサーが自動的に振り分け先を更新してくれるため、手動で設定を変更する必要はありません。

4.6 オートスケーリング

ECSのサービスには、オートスケーリングを設定できます。CPU使用率やリクエスト数などの指標に基づいて、タスクの数を自動的に増減させることが可能です。

例えば「CPU使用率が70%を超えたらタスクを追加し、30%を下回ったら減らす」といったルールを設定しておけば、アクセスの増減に合わせてタスク数が自動で調整されます。スケーリング方式の種類や設定方法はAutomatically scale your Amazon ECS service（AWS公式ドキュメント）に記載があります。

5. 主なユースケース

ECS/Fargateは、さまざまなコンテナワークロードに対応できます。以下に代表的なユースケースを紹介します。

5.1 Webアプリケーションのホスティング

ALB（Application Load Balancer）と組み合わせて、Webアプリケーションをホスティングする構成が最も一般的です。複数のタスクにトラフィックを分散し、タスクの異常を検知して自動的に置き換えることで、高可用性を実現できます。Auto Scalingを設定すれば、アクセス数の増減に応じてタスク数を自動調整できます。

5.2 マイクロサービスアーキテクチャ

複数のマイクロサービスをそれぞれ独立したECSサービスとして運用できます。サービスごとに個別にデプロイ・スケーリングができるため、チームごとに独立した開発・リリースサイクルを実現できます。サービス間の通信には、AWS App MeshやCloud Mapを活用できます。

5.3 バッチ処理・定期実行タスク

EventBridge（旧CloudWatch Events）と連携して、定期的なバッチ処理を実行できます。Fargateを使用すれば、処理が実行されている時間だけ課金されるため、常時稼働するEC2インスタンスと比較してコストを削減できます。

6. 設計のポイント

ECS/Fargateを運用する際の主要な検討項目を以下にまとめます。

7. まとめ

この講座では、Amazon ECSとAWS Fargateについて学びました。

• Amazon ECSは、AWSのフルマネージドコンテナオーケストレーションサービス
• クラスター、タスク定義、タスク、サービスが主な構成要素
• AWS Fargateは、サーバレスでコンテナを実行できる起動タイプ
• Fargateを使用すると、サーバ管理が不要になり運用負荷が軽減される
• 次の講座では、実際にECS/Fargateを使ってコンテナをデプロイする方法を学ぶ