Amazon EC2 でキャパシティプロバイダーを使用して Amazon ECS クラスターのキャパシティプロビジョニングを高速化する

Amazon EC2 で Amazon ECS を実行するお客様は、Amazon ECS Cluster Auto Scaling (CAS) を利用して Amazon EC2 Auto Scaling グループのスケーリングを管理できます。CAS を使用すると、ASG を自動的にスケールするように Amazon ECS を設定できるため、タスクの実行に集中できます。Amazon ECS により、追加の操作を必要とせずに、必要に応じて ASG をスケールインおよびスケールアウトできるようになります。Amazon ECS キャパシティープロバイダーは、アプリケーションの需要を満たすのに十分なコンテナインスタンスを確保することで、クラスター内のインフラストラクチャを管理するために使用されます。Amazon ECS CAS の仕組みについては、「Amazon ECS クラスターの Auto Scaling を深く探る」を参照してください。

CAS は、クラスターの容量を調節するにあたり、ASG との CloudWatch ベースの統合に依存するため、CloudWatch メトリクスの公開、メトリクス CapacityProviderReservation が CloudWatch アラーム (高と低の両方) に違反するまでの時間、および新しく起動された Amazon EC2 インスタンスがウォームアップするまでの時間に関連する固有のレイテンシーが存在します。以下のアクションを実行することで、CAS の応答性を高め、デプロイを高速化できます。

キャパシティープロバイダーのステップスケーリングサイズ

Amazon ECS キャパシティープロバイダーは、最終的に、アプリケーションの需要に合わせてコンテナインスタンスを拡大/縮小します。Amazon ECS が起動するインスタンスの最小数は、デフォルトでは 1 に設定されています。そのため、保留中のタスクを配置するために複数のインスタンスが必要な場合は、デプロイにさらに時間がかかることがあります。Amazon ECS API を使用して minimumScalingStepSize を増やすことで、Amazon ECS が一度にスケールインまたはスケールアウトするインスタンスの最小数を増やすことができます。maximumScalingStepSize が小さすぎると、一度にスケールインまたはスケールアウトされるコンテナインスタンスの数が制限され、デプロイが遅くなる可能性があります。

インスタンスのウォームアップ期間

インスタンスのウォームアップ期間は、新たに起動された Amazon EC2 インスタンスが Amazon EC2 Auto Scaling グループの CloudWatch メトリックスに反映されるまでの時間です。指定されたウォームアップ期間が終了すると、そのインスタンスは ASG の集計メトリクスにカウントされ、CAS は、必要なインスタンス数を推定するための次の計算ループへと進みます。

instanceWarmupPeriod のデフォルト値は 300 秒です。この値は CreateCapacityProvider API または UpdateCapacityProvider API を使用して小さい値に設定することで、スケーリングの応答性を向上させることができます。

予備のキャパシティー

キャパシティープロバイダーにタスクを配置するために使用できるコンテナインスタンスがない場合は、Amazon EC2 インスタンスをその場で起動してクラスターキャパシティーを増やし (スケールアウトし)、それらのインスタンスが起動するまで待ってからコンテナを起動する必要があります。これにより、タスクの起動レートが大幅に低下する可能性があります。ここでは 2 つのオプションがあります。

この場合、予備の Amazon EC2 キャパシティーを事前に起動してタスクを実行する準備をしておくことで、実質的なタスク起動レートを上げることができます。Target Capacity 設定を使用して、クラスターで予備のキャパシティーを保持するかどうかを指定できます。例えば、Target Capacity を 80 % に設定することで、クラスターに常に 20 % の予備のキャパシティーが必要であることを示します。この予備のキャパシティーにより、スタンドアロンタスクをすぐに起動できるようになり、タスクの起動がスロットリングされなくなります。このアプローチのトレードオフは、予備のクラスターキャパシティーを保持するコストが増加する可能性があることです。

検討できる代替アプローチは、キャパシティープロバイダーではなくサービスにヘッドルームを追加することです。つまり、予備のキャパシティーを起動するための Target Capacity 設定を小さくする代わりに、ターゲット追跡スケーリングメトリクス、またはサービス自動スケーリングのステップスケーリングのしきい値を変更することで、サービス内のレプリカの数を増やすことができます。このアプローチが有用なのはワークロードの急増に対してのみであり、新しいサービスをデプロイし、初めて 0 から N タスクに移行する場合には効果がないことに注意してください。関連するスケーリングポリシーの詳細については、「Target Tracking Scaling Policies」または「Step Scaling Policies」を参照してください。