Amazon ECS クラスターの自動スケーリングの最適化
Amazon EC2 で Amazon ECS を実行するお客様は、クラスターの自動スケーリングを利用して Amazon EC2 Auto Scaling グループのスケーリングを管理できます。クラスターの自動スケーリングを使用すると、Auto Scaling グループを自動的にスケーリングするように Amazon ECS を設定することができ、ユーザーはタスクの実行に集中できます。Amazon ECS では、追加の操作を必要とせずに、必要に応じて Auto Scaling グループがスケールインおよびスケールアウトします。Amazon ECS キャパシティープロバイダーは、アプリケーションの需要を満たすのに十分なコンテナインスタンスを確保することで、クラスター内のインフラストラクチャを管理するために使用されます。クラスターの自動スケーリングが内部でどのように機能するかについては、「Deep Dive on Amazon ECS Cluster Auto Scaling
クラスターの自動スケーリングは、Auto Scaling グループとの CloudWatch ベースの 統合を利用して、クラスターキャパシティーを調整します。したがって、次に関連する固有のレイテンシーがあります。
-
CloudWatch メトリクスの発行
-
メトリクス
CapacityProviderReservation
が CloudWatch アラームに抵触 (高と低の両方) するまでにかかる時間 -
新しく起動した Amazon EC2 インスタンスがウォームアップするのにかかる時間 以下のアクションを実行して、クラスターの自動スケーリングの応答性を高め、デプロイを高速化できます。
キャパシティープロバイダーのステップスケーリングサイズ
Amazon ECS キャパシティープロバイダーは、アプリケーションの需要に合わせてコンテナインスタンスを拡大/縮小します。Amazon ECS が起動するインスタンスの最小数は、デフォルトでは 1 に設定されています。そのため、保留中のタスクを配置するために複数のインスタンスが必要な場合は、デプロイにさらに時間がかかることがあります。Amazon ECS API を介して minimumScalingStepSize
を増やすことで、Amazon ECS が一度にスケールインまたはスケールアウトするインスタンスの最小数を増やすことができます。maximumScalingStepSize
が小さすぎると、一度にスケールインまたはスケールアウトされるコンテナインスタンスの数が制限され、デプロイが遅くなる可能性があります。
注記
この設定は現在、CreateCapacityProvider
または UpdateCapacityProvider
API を介してのみ使用できます。
インスタンスのウォームアップ期間
インスタンスのウォームアップ期間は、新たに起動された Amazon EC2 インスタンスが Auto Scaling グループの CloudWatch メトリックスに反映されるまでの時間です。指定されたウォームアップ期間が終了すると、そのインスタンスは Auto Scaling グループの集計メトリクスにカウントされ、クラスターの自動スケーリングは、必要なインスタンス数を推定するための次の計算ループに進みます。
instanceWarmupPeriod
のデフォルト値は 300 秒です。この値を CreateCapacityProvider
または UpdateCapacityProvider
API を使用して小さい値に設定することで、スケーリングの応答性の向上させることができます。
予備のキャパシティー
キャパシティープロバイダーにタスクを配置するために使用できるコンテナインスタンスがない場合は、Amazon EC2 インスタンスをその場で起動してクラスターキャパシティーを増やし (スケールアウトし)、それらのインスタンスが起動するまで待ってからコンテナを起動する必要があります。これにより、タスクの起動レートが大幅に低下する可能性があります。ここでは 2 つのオプションがあります。
この場合、予備の Amazon EC2 キャパシティーを事前に起動してタスクを実行する準備をしておくことで、実質的なタスク起動レートを上げることができます。Target
Capacity
設定を使用して、クラスターで予備のキャパシティーを保持するかどうかを指定できます。例えば、Target Capacity
を 80 % に設定することで、クラスターに常に 20 % の予備のキャパシティーが必要であることを示します。この予備のキャパシティーにより、スタンドアロンタスクをすぐに起動できるようになり、タスクの起動がスロットリングされなくなります。このアプローチのトレードオフは、予備のクラスターキャパシティーを保持するコストが増加する可能性があることです。
検討できる代替アプローチは、キャパシティープロバイダーではなくサービスにヘッドルームを追加することです。つまり、予備のキャパシティーを起動するための Target
Capacity
設定を小さくする代わりに、ターゲット追跡スケーリングメトリクス、またはサービス自動スケーリングのステップスケーリングのしきい値を変更することで、サービス内のレプリカの数を増やすことができます。このアプローチが有用なのはワークロードの急増に対してのみであり、新しいサービスをデプロイし、初めて 0 から N タスクに移行する場合には効果がないことに注意してください。関連するスケーリングポリシーの詳細については、「Amazon Elastic Container Service デベロッパーガイド」の「ターゲット追跡スケーリングポリシー」または「ステップスケーリングポリシー」を参照してください。