AWS ECS 詳細解説：アーキテクチャとデプロイメントオプション

: AWS ECS とは何ですか？

このページを共有

Yifat Perry

2021-08-30

Kubernetes と Amazon ECS の比較は、完全に公平とは言えません。なぜなら Amazon ECS は、コンテナーオーケストレーションのプラットフォーム と、これを運用しハードウェアリソースを提供する マネージドサービス の 2 要素を 1 つの製品に統合しているのに対し、Kubernetes はそのうち オーケストレーション部分のみ を提供しているからです。

現在、多くの企業が Kubernetes の複雑さを軽減し、より迅速に本番稼働できるようにする マネージド Kubernetes サービス を採用しています。代表例として Amazon Elastic Kubernetes Service (EKS)、Azure Kubernetes Service (AKS)、Google Kubernetes Engine (GKE) があります。これらのサービスは Kubernetes に管理レイヤーを追加し、Amazon ECS と直接比較できるようにしています。

Kubernetes の利点

サーバーレス型インフラストラクチャ

Kubernetes コンテナーは VM に直接アクセスすることなく実行できます。また、AWS Fargate や Azure Container Instances と統合された、真のサーバーレス Kubernetes ソリューションも存在します。

統合されたセキュリティ

Kubernetes は独自のプライベートネットワークを構築し、隔離された安全なネットワークリソースを提供します。

ベンダーロックインの回避

Amazon ECS と異なり、Kubernetes はプラットフォームに依存せず、あらゆるクラウドベンダーやオンプレミス環境で動作可能です。Kubernetes ワークロードは可搬性が高く、ハイブリッドクラウドやマルチクラウド戦略をサポートします。

オープンソース

Kubernetes は大規模なオープンソースコミュニティに支えられ、豊富なツールやプラグインのエコシステム、強力なサポート、そして積極的な開発ロードマップを備えています。

実運用での実績

Kubernetes は、あらゆるコンテナーオーケストレーションプラットフォームの中で最も豊富な本番運用経験を持ち、ほぼすべてのスケールで堅牢かつ信頼性の高い実績を示しています。

ECS の利点とユースケース

ECS は、多様なユースケースにおいてコンテナーを簡単に活用できるようにします。

シンプルなウェブサイトのホスティングから、分散型マイクロサービスアーキテクチャの管理まで幅広く利用可能です。ECS はコンテナー管理を大幅に簡素化しますが、プロセス全体を完全に自動化するわけではありません。そのため、必要に応じてフローを細かく調整・カスタマイズする柔軟性も保持できます。

Amazon ECS の主な利点

シンプルで容易なデプロイ

ECS が Kubernetes クラスターのインフラ構築と管理を引き受け、利用者の負担を軽減します。

スケジューリング機能

サービス、アプリケーション、バッチ処理を計画的に実行できます。

マネージド可用性

ECS がアプリケーションの可用性を維持し、ニーズに応じてスケールアップ／ダウンを行い、キャパシティ要件を満たします。

ネイティブ統合

AWS ELB、Amazon VPC、IAM、AWS EBS など多彩な機能とシームレスに統合。

既存ツールとの統合

シンプルな API を提供し、CI/CD パイプラインや既存ツールと容易に連携可能です。

さらに詳しくは以下のガイドをご参照ください：

AWS ECS vs. Kubernetes
AWS ECS vs. EKS

Amazon ECS アーキテクチャ

次の図は、AWS Fargate 上で実行されているコンテナを備えた Amazon ECS を示しています。次のセクションでは、表示されている主要なコンポーネントについて説明します。

Amazon ECS architecture with VPC, container registry, Fargate tasks, and elastic network interfaces across availability zones.

出典: AWS

コンテナとイメージ

Amazon ECS にアプリケーションをデプロイするためには、アプリケーションの各コンポーネントをコンテナ上で実行できるように設計する必要があります。コンテナは、イメージと呼ばれる読み取り専用のテンプレートから生成されます。

イメージは通常、Dockerfile から作成されます。Dockerfile は、コンテナ内で稼働させる全てのコンポーネントを定義したシンプルなテキストファイルです。イメージの作成後、それらはコンテナレジストリに保存され、その後クラスター内にダウンロードされて実行可能となります。

AWS ECS タスク定義

Amazon ECS 上でアプリケーションを実行するためには、まずタスク定義（Task Definition）を作成する必要があります。

タスク定義とは、JSON 形式のテキストファイルであり、最大 10 個までのコンテナを記述し、それらを組み合わせてアプリケーション全体を構成します。

タスク定義では、コンテナ化されたアプリケーションに関するさまざまなパラメータを指定できます。例えば次のような内容です：

実行するコンテナ
開放するポート
使用するデータボリューム
利用する Docker ネットワークモード
割り当てる IAM ロール

基本的に、Docker コマンドを使用してコマンドラインから実行できるほとんどの設定は、ECS のタスク定義に含めることが可能です。

利用可能なすべてのパラメータについては、公式ドキュメントをご参照ください。

AWS ECS タスクとスケジューリング

タスクとは、クラスター内で稼働しているタスク定義のインスタンスを指します。

アプリケーション用のタスク定義を Amazon ECS 上で作成した後、クラスター内で実行するタスクの数を指定できます。

Amazon ECS のタスクスケジューラは、クラスター内でタスクを配置する役割を担います。主な戦略は次の 2 つです：

REPLICA 戦略 – クラスター内で指定された数のタスクを起動し、その数を常に維持します。個々のタスクが停止した場合には、自動的に置き換えられます。
DAEMON 戦略 – 関連する条件を満たすすべてのアクティブなコンテナインスタンス上に、それぞれ 1 つのタスクを起動します。

Amazon ECS architecture showing service definition and Fargate tasks with elastic network interfaces.

出典: AWS

AWS ECS クラスター

Amazon ECS クラスターとは、1 つ以上のタスクで構成されるサービスを論理的にグルーピングしたものです。Amazon ECS を初めて利用する際には、デフォルトクラスターが自動的に作成されます。

アカウント内で追加のクラスターを作成することで、さまざまなワークロードやプロジェクトに対してリソースを分離して管理することが可能です。

クラスターリソースを実行する方法は 2 通りあります：

EC2 インスタンス上で実行
Amazon Fargate を利用して実行

これら 2 つのオプションの詳細については、次のセクションで説明します。

コンテナエージェント

コンテナエージェントは、Amazon ECS クラスター内の各コンテナインスタンス上で稼働します。

エージェントは、現在実行中のタスクやリソース使用状況に関する情報を Amazon ECS に送信します。

ECS はこのエージェントを利用して、必要に応じてタスクの起動や停止を行うことができます。

Amazon ECS workflow diagram illustrating container registry integration and task scheduling.

出典: AWS

AWS ECS のデプロイメントオプション：EC2 と Fargate

ECS は Elastic Compute Cloud (EC2) インスタンスを利用してコンテナを実行できます。これらの EC2 インスタンスは Amazon EC2 サービスの一部として提供され、定義済みの ECS クラスターに登録されます。これにより、ECS はこれらのインスタンス上でコンテナをデプロイすることが可能となります。

また、既存の VPC（Virtual Private Cloud）内で ECS クラスターを稼働させることで、その VPC 内にある既存の AWS リソースへのアクセスを実現できます。

ECS コンテナを実行する代替手段として Amazon Fargate があります。Fargate を利用することで、EC2 インスタンスのプロビジョニング、設定、および管理を行う必要がなくなり、これらの作業は AWS によって処理されます。

Fargate ではサーバー管理は不要ですが、タスク定義はステートレス（stateless）でなければなりません。現在のところ、Elastic Block Storage (EBS) のような永続的なストレージボリュームをタスク定義で指定したコンテナに直接アタッチすることはできません。

そのため、Fargate で永続ストレージを利用する場合は、Amazon S3 や Relational Database Service (RDS) といった外部ストレージサービスを利用する必要があります。

ECS を EC2 と組み合わせて利用すべきケース：

インフラ全体が AWS 上で稼働している場合
すでに VPC とサブネットを定義している場合
EC2 インスタンスのデプロイや管理に関する既存のプロセスがある場合
アプリケーションが直接接続された永続ストレージを必要とする場合

ECS を Fargate と組み合わせて利用すべきケース：

まだ既存の VPC がない場合
リソースが一部 AWS 上で稼働し、一部は他のクラウド環境に存在する場合
アプリケーションがステートレスである、または直接接続されたストレージボリュームを必要としない場合

AWS ECS 質疑応答（Q&A）

Amazon ECS と AWS Elastic Beanstalk の違いは何ですか？

Amazon ECS は、コンテナ管理を簡素化する機能を提供しつつ、プロセスを柔軟に調整できるように設計されています。

一方、AWS Elastic Beanstalk はインフラ全体を自動的に管理するため、コードにのみ集中したい場合に適しています。

AWS Elastic Beanstalk は、アプリケーションやサービスを容易にデプロイおよびスケーリングできるクラウドサービスです。Beanstalk は ELB、EC2、Auto Scaling、RDS などのサービスを自動的に管理し、デプロイやモニタリングも実行します。

Beanstalk を利用する際にユーザーが指定する必要があるのは、以下の項目です：

デプロイするコンテナイメージ
必要なストレージおよび CPU リソース
コンテナ間の連携方法
利用するポートマッピング

これらの情報を定義すれば、Beanstalk が自動的に以下を実行します：

ECS クラスターのプロビジョニング
オートスケーリングとモニタリング
ロードバランシング
クラスター内でのコンテナ実行

Amazon ECS と AWS Lambda の違いは何ですか？

Amazon ECS は、コンテナおよびクラスターの管理を簡素化する機能を提供しますが、完全に自動化されているわけではありません。

ユーザーはデプロイメントプロセスを理解し、リソースを継続的に設定およびスケーリングする必要があります。

ECS を利用することで、サーバー環境への直接的な可視性と、セットアップを最適化するために必要な情報を得ることができます。

一方、AWS Lambda はイベント駆動型のタスクをプログラムでき、計算リソースのインフラは自動的に管理されます。

Lambda はサーバーレスアーキテクチャを定義しており、ユーザーによる構成や運用は不要で、必要なのは特定のイベントに応答するコードを記述することだけです。

イベントの例としては、データの変更やウェブサイト上でのクリック操作などがあります。

Lambda はそれらのイベントに応じて、ユーザーが定義したアクションを自動的に実行します。

Cloud Volumes ONTAP を活用したコンテナストレージの最適化

NetApp Cloud Volumes ONTAP は、エンタープライズレベルの先進的なストレージ管理ソリューションです。

AWS、Azure、Google Cloud 上で、安全で実績のあるストレージサービスを提供します。

Cloud Volumes ONTAP は最大 368TB の容量をサポートし、ファイルサービス、データベース、DevOps、その他のエンタープライズワークロードなど、多様なユースケースに対応しています。

主な機能には以下が含まれます：

高可用性
データセキュリティ
ストレージ効率化
Kubernetes との統合
その他多数の機能

特に、Cloud Volumes ONTAP はコンテナ化されたワークロード向けの Persistent Volume のプロビジョニングおよび管理 の要件をサポートしています。

Cloud Volumes ONTAP がコンテナ化アプリケーションの課題をどのように解決するかについては、**「Kubernetes Workloads における Cloud Volumes ONTAP の事例」**をご参照ください。