Amazon ECS の一般的ユースケース - Amazon Elastic Container Service
マイクロサービスバッチジョブ

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

Amazon ECS の一般的ユースケース

このトピックでは、マイクロサービスとバッチジョブという、Amazon ECS の 2 つの一般的ユースケースのガイダンスを提供します。アプリケーションを Amazon ECS で実行するために役立つ考慮事項と外部リソース、および各ソリューションの一般的な特徴について説明します。

マイクロサービス

マイクロサービスは、複雑なアプリケーションを小型で独立したサービスに分解する、ソフトウェアアーキテクチャ手法により構築されています。コンテナは小さな分離型サービスを実行するのに最適で、次の利点があります:

  • コンテナは、イミュータブルなイメージを使い、すべての依存関係を持った、サービスのモデル化を容易にします。

  • コンテナではあらゆるアプリケーションやプログラミング言語を使用できます。

  • コンテナのイメージはバージョニングされたアーティファクトであるため、コンテナのイメージから元のソースを追跡できます。

  • ローカルでコンテナのテストを行い、同じアーティファクトをスケールしてデプロイできます。

次のセクションでは、Amazon ECS 上で実行するマイクロサービスアーキテクチャの設計時に考慮する必要がある点や課題について説明します。GitHub のマイクロサービスリファレンスアーキテクチャを参照することもできます。詳細については、「Amazon ECS、AWS CloudFormation、および Application Load Balancer でマイクロサービスをデプロイする」を参照してください。

Auto Scaling

マイクロサービスアーキテクチャのアプリケーション負荷は時間の経過によって変化する場合があります。応答性に優れたアプリケーションでは、実際の負荷または予想される負荷に応じて、スケールアウトやスケールインを行うことができます。Amazon ECS では、クラスターで実行されるサービスだけでなく、実際のクラスター自体もスケールすることが可能なツールがいくつかあります。

たとえば、Amazon ECS はクラスターとサービスの CloudWatch メトリクスを提供します。詳細については、「Amazon ECS CloudWatch のメトリクス」を参照してください。クラスターおよびサービスのメモリおよび CPU の使用率をモニタリングできます。次に、リソースが不足した場合に、クラスターを自動的にスケールアウトできるように、CloudWatch アラームをトリガーするためにそれらのメトリクスを使用します。それらのリソースが不要になったときにスケールを戻します。詳細については、「チュートリアル: CloudWatch アラームを使用したコンテナインスタンスのスケーリング」を参照してください。

クラスターサイズのスケーリングに加え、オプションで、サービスの Auto Scaling を使用して CloudWatch アラームに応じて必要数を調整するように Amazon ECS サービスを設定できます。サービスの Auto Scaling は Amazon ECS がサポートされているすべてのリージョンで使用できます。詳細については、「サービスの Auto Scaling」を参照してください。

サービス検出

サービス検出は、多くの分散システムとサービス指向アーキテクチャ の、主要なコンポーネントです。あるインフラストラクチャ上でマイクロサービスのコンポーネントが作成されたり、終了されると、サービス検出によって自動的に検出されます。サービスを検出可能にするために使用できる、いくつかの方法があります。次のリソースは、いくつかの例を示しています。

認証とシークレット管理

アプリケーション用のデータベース認証情報などのシークレット管理には、常に困難な課題が伴います。「タスクのパラメータストアと IAM ロールを使用して Amazon ECS アプリケーションのシークレットを管理する」の投稿では、Amazon ECS のタスクの IAM ロール機能と AWS Systems Manager パラメータストアを統合する方法を中心に説明しています。パラメータストアは、データベース文字列などのプレーンテキストデータから、AWS Key Management Service により暗号化されたパスワードのような機密情報まで、設定データを管理する一元化されたストアを提供します。

ログ記録

ログ情報を CloudWatch Logs に送信するように、コンテナインスタンスを設定できます。これにより、1 つの便利な場所でコンテナインスタンスからのさまざまなログを表示できます。Amazon ECS-optimized AMI で起動されたコンテナインスタンスで CloudWatch Logs を使い始めるための詳細については、「コンテナインスタンスでの CloudWatch Logs の使用」を参照してください。

タスクのコンテナを設定して CloudWatch Logs にログ情報を送信できます。こうすることで、コンテナからの異なるログを 1 か所で便利に表示できます。また、コンテナログがコンテナインスタンスのディスク容量を占めることも防止できます。タスク定義で awslogs ログドライバーを使い始めるための詳細については、「awslogs ログドライバーを使用する」を参照してください。

継続的な統合と継続的なデプロイ

継続的な統合と継続的なデプロイ (CICD) は、Docker コンテナに基づくマイクロサービスアーキテクチャでの一般的なプロセスです。パイプラインを作成して次のアクションを取ることができます:

  • ソースコードリポジトリの変更をモニタリングする

  • そのソースから新しい Docker イメージを構築する

  • Amazon ECR や Docker Hub などのイメージリポジトリにイメージをプッシュする

  • Amazon ECS サービスを更新して、アプリケーションで新しいイメージを使用する

次のリソースでは、別のやり方でこれを行う方法について説明しています。

バッチジョブ

Docker コンテナは、バッチジョブのワークロードに特に適しています。バッチジョブは多くの場合、存在期間が短く、大量に並列化されています。バッチ処理アプリケーションを Docker イメージにパッケージ化して、Amazon ECS タスク内など、任意の場所にデプロイすることができます。バッチジョブのワークロードを実行する場合には、次のリソースを検討します。

  • AWS Batch: フルマネージド型のバッチ処理では、処理の規模を問わず、AWS Batch の使用を検討する必要があります。AWS Batch を使用することで、開発者、科学者、およびエンジニアは、数十万件のバッチコンピューティングジョブを AWS で効率的に実行できます。AWS Batch は、送信されたバッチジョブの量と特定のリソース要件に基づいて、最適な量と種類のコンピューティングリソース (CPU やメモリ最適化インスタンスなど) を動的にプロビジョニングします。詳細については、AWS Batch に関する製品の詳細ページを参照してください。

  • 「Amazon ECS リファレンスアーキテクチャ: バッチ処理」: このリファレンスアーキテクチャは、AWS CloudFormation、Amazon S3、Amazon SQS、および CloudWatch アラームを使用して、Amazon ECS でバッチ処理を行う方法を説明しています。