Amazon Elastic Container Service
開発者ガイド (API バージョン 2014-11-13)

アプリケーションのアーキテクチャ

Amazon ECS でアプリケーションを設計する方法は複数の要因に応じて変化しますが、主な違いをもたらしているのは、使用している起動タイプです。設計プロセスでは、起動タイプごとに用意された以下のガイダンスを参考にしてください。

Fargate 起動タイプを使用する場合

タスクで Fargate 起動タイプを使用してアプリケーションを設計する場合、複数のコンテナを同じタスク定義に配置するか、複数のコンテナを複数のタスク定義に個別にデプロイするか、というのが主な問題となります。

以下の場合は、複数のコンテナを同じタスク定義に配置する必要があります。

  • コンテナが同じライフサイクルを共有している (同時に起動および終了する必要がある).

  • 実行基盤となるホストが同じになるようにコンテナを実行する (つまり、あるコンテナが、localhost ポート上の別のコンテナを参照する) 必要がある。

  • コンテナにリソースを共有させる必要がある.

  • コンテナでデータボリュームを共有している。

上記以外の場合は、個別のタスク定義でコンテナを定義することで、コンテナを個別にスケーリング、プロビジョニング、プロビジョニング解除できるようになります。

EC2 起動タイプを使用する場合

EC2 起動タイプを使用してタスク定義とサービスをモデル化する方法を検討するときは、同じインスタンスでどのプロセスを一緒に実行する必要があるか、各コンポーネントをどのようにスケーリングするかを検討します。

たとえば、以下のコンポーネントで構成されるアプリケーションがあるとします。

  • ウェブページに情報を表示するフロントエンドサービス

  • フロントエンドサービスに API を提供するバックエンドサービス

  • データストア

開発環境では、Docker ホストで 3 つのコンテナをすべて一緒に実行することがよくあります。同じアプローチを実稼働環境に使用したくなりますが、このアプローチにはいくつかの欠点があります。

  • 1 つのコンポーネントの変更は 3 つのコンポーネントすべてに影響を与え、想定したよりも変更が広範囲になる可能性がある.

  • 各コンポーネントを比例的にスケーリングする必要があるため、スケーリングがより難しくなる.

  • タスク定義に 10 個のコンテナ定義しかなく、アプリケーションスタックに今すぐまたは今後に追加のコンテナ定義が必要になる可能性がある.

  • タスク定義内のすべてのコンテナは、同じコンテナインスタンスに配置する必要があるため、その最大サイズによってインスタンスの選択肢が制限されることがある.

代わりに、用途が共通するコンテナをコンポーネントにグループ化し、それらのコンポーネントを複数のタスク定義に分ける必要があります。この例では、3 つのタスク定義でそれぞれ 1 つのコンテナを指定しています。以下の例のクラスターでは、3 つのコンテナインスタンスのうち、3 つをフロントエンドサービスコンテナに、2 つをバックエンドサービスコンテナに、1 つをデータストアサービスコンテナに登録しています。


                アプリケーションアーキテクチャの例

一緒に実行する必要のあるリンクされたコンテナなど、関連するコンテナをタスク定義にグループ化できます。たとえば、ログストリーミングコンテナをフロントエンドサービスに追加して、同じタスク定義に含めることができます。

タスク定義を作成したら、それらの定義からサービスを作成して、使用可能なタスクの必要数を維持できます。詳細については、「サービスの作成」を参照してください。サービスでは、コンテナを Elastic Load Balancing ロードバランサーに関連付けることができます。詳細については、「サービスロードバランシング」を参照してください。アプリケーションの要件が変更されたら、サービスを更新してタスクの必要数を増減したり、より新しいバージョンのコンテナをタスクにデプロイしたりできます。詳細については、「サービスの更新」を参照してください。