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

Amazon EC2 Auto Scaling の動的スケーリング

動的スケーリングは、トラフィックの変化に応じて Auto Scaling グループのキャパシティをスケールします。

Amazon EC2 Auto Scaling は、次のタイプの動的スケーリングポリシーをサポートしています。

ターゲット追跡スケーリングポリシーを使用し、Auto Scaling グループの容量の変化に反比例して変化するメトリクスを選択することを強くお勧めします。したがって、Auto Scaling グループのサイズを 2 倍にすると、メトリクスは 50% 減少します。これにより、メトリクスデータが比例スケーリングイベントを正確にトリガーできます。ターゲットあたりの平均CPU使用率や平均リクエスト数などのメトリクスが含まれます。

ターゲット追跡では、Auto Scaling グループはアプリケーションの実際の負荷に正比例してスケーリングされます。つまり、ターゲット追跡ポリシーは、負荷の変化に対応するキャパシティの緊急のニーズを満たすだけでなく、季節変動などにより経時的に発生する負荷の変化にも対応できます。

ターゲット追跡ポリシーでは、 CloudWatch アラームとスケーリング調整を手動で定義する必要もなくなります。Amazon EC2 Auto Scaling は、設定したターゲットに基づいてこれを自動的に処理します。

動的スケーリングポリシーが機能する方法

動的スケーリングポリシーは、特定の CloudWatch メトリクスを追跡するように Amazon EC2 Auto Scaling に指示し、関連付けられた CloudWatch アラームが にあるときに実行するアクションを定義しますALARM。アラームの状態の呼び出しに使用されるメトリクスは、Auto Scaling グループのすべてのインスタンスから取得されるメトリクスの集約です。（例えば、2 つのインスタンスを持つ Auto Scaling グループがあるとします。1 つのインスタンスは 60%、CPUもう 1 つは 40% ですCPU。 平均して 50% です）CPU。ポリシーが有効になると、Amazon EC2 Auto Scaling はアラームのしきい値を超えたときにグループの希望する容量を増減します。

動的スケーリングポリシーが呼び出されると、容量計算によってグループの最小サイズ範囲と最大サイズ範囲外の数値が生成された場合、Amazon EC2 Auto Scaling は新しい容量が最小サイズ制限と最大サイズ制限外にならないようにします。容量は、インスタンスに関して希望する容量を設定するときに選択したのと同じ単位を使用するか、容量単位を使用するか (インスタンスの重みが適用されている場合) の 2 つの方法のいずれかで測定されます。

希望するキャパシティーが最大サイズ制限に達すると、スケールアウトは停止します。需要が低下し、容量が減少すると、Amazon EC2 Auto Scaling は再びスケールアウトできます。

例外は、インスタンスの重みを使用する場合です。この場合、Amazon EC2 Auto Scaling は最大サイズ制限を超えてスケールアウトできますが、最大インスタンス重量までスケールアウトできます。その意図は、できるだけ新しい希望するキャパシティーに近づけることですが、それでもグループのために指定されている割り当て戦略を遵守することです。割り当て戦略によって、起動するインスタンスタイプを決定します。重みは、インスタンスタイプに基づいて、各インスタンスがグループの希望するキャパシティーに影響するキャパシティーユニット数を決定します。

複数の動的スケーリングポリシー

ほとんどの場合、ターゲット追跡スケーリングポリシーは、自動的にスケールアウトとスケールインするように Auto Scaling グループからインスタンスをデタッチするには、以下の手順を使用します。 グループを設定するのに十分です。ターゲット追跡スケーリングポリシーでは、希望する結果を選択したら、その結果を達成するために、必要に応じて Auto Scaling グループに対してインスタンスを追加および削除できます。

高度なスケーリング設定では、Auto Scaling グループに複数のスケーリングポリシーを設定できます。例えば、1 つ以上のターゲット追跡スケーリングポリシー、1 つ以上のステップスケーリングポリシー、またはその両方を定義できます。これにより、複数のシナリオに対応できる柔軟性が高まります。

複数の動的スケーリングポリシーがどのように連携するかを説明するために、Auto Scaling グループと Amazon SQSキューを使用して単一のEC2インスタンスにリクエストを送信するアプリケーションを検討してください。アプリケーションのパフォーマンスを最適なレベルに維持するために、Auto Scaling グループをスケールアウトするタイミングをコントロールする 2 つのポリシーがあるとします。1 つは、カスタムメトリクスを使用してキュー内のSQSメッセージ数に基づいて容量を追加および削除するターゲット追跡ポリシーです。もう 1 つのステップスケーリングポリシーは、Amazon CloudWatch CPUUtilization メトリクスを使用して、インスタンスが指定された期間に 90% の使用率を超えたときに容量を追加します。

同時に有効なポリシーが複数ある場合は、各ポリシーで、Auto Scaling グループが同時にスケールアウト (またはスケールイン) するように指定している可能性があります。例えば、SQSカスタムCPUUtilizationメトリクスがカスタムメトリクス CloudWatch アラームのしきい値をスパイクおよび超過すると同時に、メトリクスがアラームのしきい値をスパイクおよび超過する可能性があります。

このような状況が発生すると、Amazon EC2 Auto Scaling はスケールアウトとスケールインの両方に最大の容量を提供するポリシーを選択します。例えば、 のポリシーが 1 つのインスタンスCPUUtilizationを起動し、SQSキューのポリシーが 2 つのインスタンスを起動するとします。両方のポリシーのスケールアウト基準が同時に満たされた場合、Amazon EC2 Auto Scaling はSQSキューポリシーを優先します。これにより、Auto Scaling グループは 2 つのインスタンスを起動することになります。

ポリシーがスケールインに異なる基準を使用する場合でも、最大キャパシティーを提供するポリシーを優先するというアプローチが適用されます。例えば、1 つのポリシーが 3 つのインスタンスを終了し、別のポリシーがインスタンス数を 25% 減らし、スケールイン時にグループに 8 つのインスタンスがある場合、Amazon EC2 Auto Scaling はグループの最大数のインスタンスを提供するポリシーを優先します。その結果、Auto Scaling グループは 2 つのインスタンスを終了します (8 の 25% = 2)。目的は、Amazon EC2 Auto Scaling が削除するインスタンスが多すぎないようにすることです。

ただし、ターゲット追跡スケーリングポリシーをステップスケーリングポリシーとともに使用する場合、ポリシー間の競合によって望ましくない動作が生じる可能性があるため、注意することをお勧めします。例えば、ターゲット追跡ポリシーがスケールインする準備が整う前にステップスケーリングポリシーがスケールインアクティビティを開始した場合、スケールインアクティビティはブロックされません。スケールインアクティビティが完了すると、ターゲット追跡ポリシーはグループに対してスケールアウトを再び指示できます。