ベストプラクティス - タスクの起動を高速化する

Amazon ECS がタスクを起動するのにかかる時間を短縮するために、いくつかの改善点があります。

Amazon ECS タスク起動ワークフロー

Amazon ECS がタスクをプロビジョニングする方法を理解することは、タスクの起動を高速化するための最適化に関する推論に役立ちます。Amazon ECS タスク (スタンドアロンタスクまたは Amazon ECS サービス) を起動すると、タスクが作成され、正常に起動されるPROVISIONING前に RUNNING状態になります (詳細については、「Amazon ECS デベロッパーガイド」の「タスクのライフサイクル」を参照してください）。PROVISIONING 状態では、Amazon ECS がタスクを配置するためのコンピューティング性能を見つける必要があるため、タスクもコンテナも存在しません。

Amazon ECS は、起動タイプまたはキャパシティプロバイダーの設定に基づいて、タスクに適したコンピューティング性能を選択します。起動タイプは、 の AWS Fargate (Fargate) および Amazon EC2 AWS、および Amazon ECS Anywhere で使用されるEXTERNALタイプです。キャパシティープロバイダーとキャパシティープロバイダー戦略は、Fargate 起動タイプと Amazon EC2 起動タイプの両方で使用できます。Fargate を使用すると、クラスター容量のプロビジョニング、設定、スケーリングについて心配する必要はありません。Fargate は、お客様のタスクに必要なすべてのインフラストラクチャ管理を行います。Amazon EC2 を使用する Amazon ECS の場合、Amazon EC2 インスタンスをクラスターに登録してクラスター容量を管理するか、Amazon ECS Cluster Auto Scaling (CAS) を使用してコンピューティング容量管理を簡素化できます。CAS はクラスター容量を動的にスケーリングするため、実行中のタスクだけに集中できます。Amazon ECS は、タスク定義で指定した要件 (CPU やメモリなど)、および配置の制約事項と戦略に基づいて、タスクを配置する場所を決定します。タスク配置の詳細については、「Amazon ECS タスク配置」を参照してください。

タスクを配置する容量を見つけた後、Amazon ECS はタスクに必要なアタッチメント (Elastic Network Interface (ENIs) など) を awsvpc モードでプロビジョニングし、Amazon ECS コンテナエージェントを使用してコンテナイメージをプルし、コンテナを起動します。これらがすべて完了し、関連するコンテナが起動すると、Amazon ECS はタスクを RUNNING状態に移行します。

Amazon ECS Service Scheduler ワークフロー

Amazon ECS は、サービスの状態を管理するためのサービススケジューラを提供します。サービススケジューラは、指定したスケジューリング戦略が確実に実行され、失敗したタスクが再スケジュールされるようにします。例えば、基盤となるインフラストラクチャに障害が発生した場合、サービススケジューラはタスクを再スケジュールできます。サービススケジューラの主な責任は、アプリケーションが常に必要な数のタスクを実行していることを確認することです。これは、サービス設定で指定した必要数、またはサービスの自動スケーリング を使用している場合は、アプリケーションの負荷に基づいて自動スケーリングされたタスク数に基づきます。サービススケジューラは、非同期ワークフローを使用してタスクをバッチで起動します。サービススケジューラがどのように機能するかを理解するために、大量のトラフィックを受信する大規模なウェブ API 用の Amazon ECS サービスを作成するとします。このサービスは多くのウェブトラフィックを処理し、サービスの適切な必要数は 1,000 タスクであると判断すると予想されます。このサービスをデプロイすると、Amazon ECS サービススケジューラは 1,000 個のタスクをすべて一度に起動するわけではありません。代わりに、ワークフローサイクルの実行を開始して、現在の状態 (0 タスク) を目的の状態 (1,000 タスク) に戻し、各ワークフローサイクルで新しいタスクのバッチを起動します。サービススケジューラは、サービスごとに 1 分あたり最大 500 個のタスクを Fargate、Amazon EC2、および External 起動タイプにプロビジョニングできます。Amazon ECS で許可されるレートとクォータの詳細については、「Amazon ECS サービスクォータ」を参照してください。

Amazon ECS タスク起動ワークフローを理解したので、この知識の一部を使用してタスク起動を高速化する方法について説明します。

タスクの起動を高速化するための推奨事項

前のセクションで説明したように、タスク起動のトリガー (Amazon ECS APIsまたはサービススケジューラ経由) からコンテナが正常に起動するまでにかかる時間は、Amazon ECS、設定、およびコンテナ自体のさまざまな要因の影響を受けます。タスク起動をスピードアップするために、以下の推奨事項を考慮してください。

• コンテナイメージと binpack インスタンスをキャッシュします。

  Amazon EC2 で Amazon ECS を実行している場合は、以前に使用したコンテナイメージをキャッシュするように Amazon ECS コンテナエージェントを設定して、その後の起動でイメージのプル時間を短縮できます。コンテナインスタンスでタスク密度が高い場合、キャッシュの効果はさらに大きくなります。これは、binpackプレイスメント戦略 を使用して設定できます。コンテナイメージのキャッシュは、通常はコンテナイメージのサイズが大きい Windows ベースのワークロード (数十 GB) に特に役立ちます。binpack 配置戦略を使用する場合は、Elastic Network Interface (ENI) トランキングを使用して、各コンテナインスタンスにawsvpcネットワークモードでより多くのタスクを配置することを検討することもできます。ENI トランキングを使用すると、awsvpc モードで実行できるタスク数が増加します。たとえば、同時に 2 つのタスクしか実行できない c5.large インスタンスの場合、ENI トランキングでは最大 10 のタスクを実行できます。

• 最適なネットワークモード を選択します。

  awsvpc ネットワークモードが理想的なインスタンスは多数ありますが、このネットワークモードは本質的にタスク起動のレイテンシーを増加させる可能性があります。 awsvpc モードの各タスクについて、Amazon ECS ワークフローは Amazon EC2 APIs を呼び出して ENI をプロビジョニングしてアタッチする必要があります。これにより、タスク起動に数秒のオーバーヘッドが追加されます。対照的に、awsvpc ネットワークモードを使用する主な利点は、各タスクにトラフィックを許可または拒否するセキュリティグループがあることです。つまり、タスクとサービス間の通信をよりきめ細かく制御できる柔軟性が増します。デプロイ速度のメリットが awsvpc モードのメリットを上回る場合は、 bridge モードを使用してタスクの起動を高速化することを検討してください。各ネットワークモードの相対的な利点の詳細については、AWSVPC モード「」および「」を参照してくださいブリッジモード。

• タスクの起動ライフサイクルを追跡して、最適化の機会を見つけます。

  多くの場合、アプリケーションの起動にかかる時間を把握することは困難です。アプリケーションの起動時に、コンテナイメージの起動、起動スクリプトの実行、その他の設定を行うと、驚くほど時間がかかることがあります。ECS エージェントメタデータエンドポイントを使用してメトリクスを投稿し、アプリケーションがトラフィックを処理する準備ができたときContainerStartTimeまでのアプリケーションの起動時間を追跡できます。このデータにより、アプリケーションが起動時間全体にどのような影響を与えているかを把握し、アプリケーション固有の不要なオーバーヘッドを減らし、コンテナイメージを最適化できる領域を見つけることができます。

• 最適なインスタンスタイプを選択します (Amazon EC2 で Amazon ECS を使用する場合）。

  正しいインスタンスタイプの選択は、タスクで設定したリソース予約 (CPU、メモリ、ENI、GPU など) に基づいているため、インスタンスのサイズを設定するときに、1 つのインスタンスに配置することができるタスクの数を計算できます。適切に配置されたタスクの簡単な例として、m5.large インスタンスで 0.5 vCPU と 2GB のメモリ予約を必要とする 4 つのタスクをホストします (2 vCPU と 8 GB のメモリをサポート）。このタスク定義の予約は、インスタンスのリソースを最大限に活用します。

• Amazon ECS サービススケジューラを使用して、 サービスを同時に起動します。

  前のセクションで説明したように、サービススケジューラは非同期ワークフローを使用して複数のサービスのタスクを同時に起動できます。したがって、多数のタスクを持つ大規模なサービスではなく、より少ないタスクを持つ小規模なサービスとしてアプリケーションを設計することで、デプロイ速度を向上させることができます。例えば、1,000 個のタスクを持つ単一のサービスを持つ代わりに、それぞれ 100 個のタスクを持つ 10 個のサービスを持つと、サービススケジューラはすべてのサービスのタスクプロビジョニングを並行して開始するため、デプロイ速度が大幅に向上します。