# Amazon ECS サービスを自動的にスケールする
*オートスケーリング* は、Amazon ECS サービスで必要なタスク数を自動的に増減する機能です。Amazon ECS は アプリケーション Auto Scaling サービスを活用してこの機能を提供します。詳細については、 [ユーザーガイドの Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html) リファレンスを参照してください。
Amazon ECS はご使用のサービスの CPU とメモリの平均使用量を含む CloudWatch メトリクスを発行します。詳細については、「[Amazon ECS サービスの使用率メトリクス](service_utilization.md)」を参照してください。これらおよびその他の CloudWatch メトリクスを使用して、ピーク時に高需要に対処するためにサービスをスケールアウトし (実行するタスクを増やし)、使用率の低い期間にコストを削減するためにサービスをスケールインする (実行するタスクを減らす) ことができます。
Amazon ECS Service Auto Scaling は、以下のタイプの自動スケーリングをサポートします。
+ [ターゲットメトリクスを使用して Amazon ECS サービスをスケールする](service-autoscaling-targettracking.md) - 特定のメトリクスのターゲット値に基づいて、サービスが実行するタスク数を増減させます。これはサーモスタットが家の温度を維持する方法に似ています。温度を選択すれば、後はサーモスタットがすべてを実行します。
+ [CloudWatch アラームに基づく定義済みの増分を使用して Amazon ECS サービスをスケールする](service-autoscaling-stepscaling.md) - アラーム超過のサイズに応じて変動する一連のスケーリング調整値 (ステップ調整値) に基づいて、サービスが実行するタスク数を増減させます。
+ [スケジュールされたアクションを使用して Amazon ECS サービスをスケールする](service-autoscaling-schedulescaling.md) - 日付と時刻に基づいてサービスが実行するタスクの数を増減させます。
+ [履歴パターンを使用して予測スケーリングで Amazon ECS サービスをスケールする](predictive-auto-scaling.md) — トラフィックフローの日次または週次のパターンを検出するための過去の負荷データ分析に基づいて、サービスが実行するタスク数を増減します。
## 考慮事項
スケーリングポリシーを使用する場合は、次の考慮事項に注意してください。
+ Amazon ECSは、CloudWatch に 1 分間隔でメトリクスを送信します。クラスターとサービスが CloudWatch にメトリクスを送信するまで、メトリクスは使用できません。また、存在しないメトリクスに対して CloudWatch アラームを作成することはできません。
+ スケーリングポリシーは、クールダウン期間をサポートします。これは、以前のスケーリングアクティビティが有効になるまで待機する秒数です。
+ スケールアウトイベントでは、スケールアウトが継続的に (ただし過剰になることなく) 行われます。スケーリングポリシーを使用してサービスの自動スケーリングが正常にスケールアウトすると、クールダウン時間の計算が開始されます。スケーリングポリシーは、より大きなスケールアウトが開始されるか、クールダウン期間が終了しない限り、必要な容量を再度増加させません。このスケールアウトクールダウン期間が有効な間は、スケールアウトアクティビティを開始することで追加された容量は、次のスケールアウトアクティビティに予定される容量の一部として繰り入れられます。
+ スケールインイベントでは、アプリケーションの可用性を保護するために控えめにスケールインされます。そのため、スケールインアクティビティはクールダウン期間が終了するまでブロックされます。ただし、スケールインクールダウン期間中に別のアラームがスケールアウトアクティビティを開始した場合、アプリケーションの自動スケーリングスケールによってターゲットが即座にスケールアウトされます。この場合、スケールインクールダウン期間は停止し、完了しません。
+ サービススケジューラは常に必要数を優先しますが、サービスにアクティブなスケーリングポリシーとアラームがある限り、サービスの自動スケーリングはユーザーが手動で設定した必要数を変更できます。
+ サービスの必要タスク数が容量最小値より小さく設定された状態で、アラームがスケールアウトアクティビティを開始したとき、サービスの自動スケーリングが必要タスク数を容量最小値までスケールアップします。その後もアラームに関連付けられたスケーリングポリシーに基づいて、必要に応じてスケーリングし続けます。ただし、必要数はすでにキャパシティーの最小値より小さいため、スケールインアクティビティでは調整されません。
+ サービスの必要タスク数が容量最大値より大きく設定された状態で、アラームがスケールインアクティビティを開始したとき、Service Auto Scaling が必要タスク数を容量最大値までスケールアウトします。その後もアラームに関連付けられたスケーリングポリシーに基づいて、必要に応じてスケーリングし続けます。ただし、必要タスク数はすでに容量最大値より大きいため、スケールアウトアクティビティでは調整されません。
+ スケーリングアクティビティ中、サービスで実際に実行されているタスクの数は、必要数ではなく、サービスの自動スケーリングが開始点として使用する値です。これが想定される処理能力です。これにより、例えば、追加タスクを配置するために十分なコンテナインスタンスリソースがない場合に、満たすことができない過剰な (ランナウェイ) スケーリングを防ぐことができます。後でコンテナインスタンスのキャパシティーを使用できるようになった場合、保留中の規模の拡大や縮小が続行され、クールダウン期間後にさらに規模の拡大や縮小を続行できることができます。
+ 実行する作業がないときにタスク数をゼロにスケーリングするには、キャパシティーの最小値を 0 に設定します。ターゲット追跡スケーリングポリシーでは、実際の容量が 0 で、メトリクスがワークロードの需要があることを示している場合、サービスの自動スケーリングは 1 つのデータポイントの送信を待ってからスケールアウトします。この場合、開始点として可能な最小量だけスケールアウトしてから、実際の実行中のタスク数に基づいてスケーリングを再開します。
+ Application Auto Scaling は、Amazon ECS デプロイの進行中にスケールインプロセスをオフにします。ただし、スケールアウトプロセスは、中断しない限り、デプロイ中に引き続き発生します。この動作は、外部デプロイコントローラーを使用した Amazon ECS サービスには適用されません。詳細については、「[サービスの自動スケーリングとデプロイ](#service-auto-scaling-deployments)」を参照してください。
+ Amazon ECS タスクには、いくつかの Application Auto Scaling オプションがあります。ターゲットトラッキングは最も使いやすいモードです。これにより、CPU 平均使用率などのメトリクスの目標値を設定するだけです。次に、オートスケーラーは、その値を達成するために必要なタスクの数を自動的に管理します。ステップスケーリングを使用すると、スケーリングメトリクスの特定のしきい値と、しきい値を超えたときに追加または削除するタスクの数を定義できるため、需要の変化に迅速に対応できます。さらに重要なことは、しきい値アラームが超過する時間を最小限に抑えることで、需要の変化に非常に迅速に対応できることです。
サービスの自動スケーリングにおけるベストプラクティスの詳細については、「[Amazon ECS サービスの自動スケーリングの最適化](capacity-autoscaling-best-practice.md)」を参照してください。
## サービスの自動スケーリングとデプロイ
Application Auto Scaling は、Amazon ECS デプロイの進行中にスケールインプロセスをオフにします。ただし、スケールアウトプロセスは、中断しない限り、デプロイ中に引き続き発生します。この動作は、外部デプロイコントローラーを使用した Amazon ECS サービスには適用されません。デプロイの進行中にスケールアウトプロセスを中断する場合は、次の手順を実行します。
1. Application Auto Scaling のスケーラブルなターゲットに関連付けられたサービスのリソース ID (例: `service/default/sample-webapp`) を指定して [describe-scalable-targets](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scalable-targets.html) コマンドを呼び出します。出力を記録します。これは、次のコマンドを呼び出すときに必要になります。
1. リソース ID、名前空間、およびスケーラブルなディメンションを指定して [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) コマンドを呼び出します。`DynamicScalingInSuspended` と`DynamicScalingOutSuspended` の両方に `true` を指定します。
1. デプロイが完了したら、[register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) コマンドを呼び出してスケーリングを再開できます。
詳細については、「[Application Auto Scaling のスケーリングの中断と再開](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html)」を参照してください。
# ターゲットメトリクスを使用して Amazon ECS サービスをスケールする
ターゲット追跡スケーリングポリシーで、メトリクスを選択してターゲット値を設定します。Amazon ECS サービス自動スケーリングは、スケーリングポリシーを制御する CloudWatch アラームを作成および管理し、メトリクスとターゲット値に基づいてスケーリング調整値を計算します。スケーリングポリシーは、指定されたターゲット値、またはそれに近い値にメトリクスを維持するため、必要に応じてサービスタスクを追加または削除します。ターゲットの追跡スケーリングポリシーは、メトリクスをターゲット値近くに維持することに加えて、負荷パターンの変動によるメトリクスの変動に合わせて調整し、サービスで実行されているタスク数の急速な変動を最小化します。
ターゲット追跡ポリシーにより、CloudWatch アラームとスケーリング調整を手動で定義する必要がなくなります。Amazon ECS は、設定したターゲットに基づいてこれを自動的に処理します。
ターゲット追跡ポリシーを使用する際は、以下について検討します。
+ ターゲットの追跡スケーリングポリシーでは、指定されたメトリクスがターゲット値を超えている場合、スケールアウトする必要があると見なされます。指定されたメトリクスがターゲット値を下回っている場合、ターゲットの追跡スケーリングポリシーを使用してスケールアウトすることはできません。
+ 指定されたメトリクスに十分なデータがない場合、ターゲットの追跡スケーリングポリシーによってスケールされません。不十分なデータは低い使用率として解釈されないため、スケールインされません。
+ ターゲット値と実際のメトリクスデータポイント間にギャップが発生する場合があります。これは、Service Auto Scaling が追加または削除する容量を判断するときに、その数を切り上げまたは切り捨てることによって、常に控えめに動作するためです。これにより、不十分な容量を追加したり、必要以上に容量を削除することを防ぎます。
+ アプリケーションの可用性を高めるために、サービスのスケールアウトはメトリクスに比例して可能な限り高速に行われますが、スケールインはより緩やかです。
+ Application Auto Scaling は、Amazon ECS デプロイの進行中にスケールインプロセスをオフにします。ただし、スケールアウトプロセスは、中断しない限り、デプロイ中に引き続き発生します。この動作は、外部デプロイコントローラーを使用した Amazon ECS サービスには適用されません。詳細については、「[サービスの自動スケーリングとデプロイ](service-auto-scaling.md#service-auto-scaling-deployments)」を参照してください。
+ Amazon ECS サービスに対して複数のターゲット追跡スケーリングポリシーを設定できます。ただし、各ポリシーがそれぞれ異なるメトリクスを使用している必要があります。サービスの自動スケーリングの目的は常に可用性を優先することであるため、その動作は、スケールアウトまたはスケールインに対するターゲット追跡ポリシーの準備が整っているかどうかに応じて異なります。ターゲット追跡ポリシーのいずれかでスケールアウトする準備ができると、サービスがスケールアウトされますが、すべてのターゲット追跡ポリシー (スケールイン部分がオン) でスケールインする準備ができている場合にのみスケールインされます。
+ ターゲット追跡スケーリングポリシーのためにサービスの自動スケーリングが管理する CloudWatch アラームを編集または削除しないでください。スケーリングポリシーを削除するときに、サービスの自動スケーリングはアラームを自動的に削除します。
+ ブルー/グリーンデプロイタイプでは、ターゲット追跡スケーリングポリシーの `ALBRequestCountPerTarget` メトリクスはサポートされません。
ターゲット追跡スケーリングポリシーの詳細については、「Application Auto Scaling ユーザーガイド」の「[ターゲット追跡スケーリングポリシー](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html)」を参照してください。
# Amazon ECS サービスの自動スケーリングのターゲット追跡スケーリングポリシーを作成する
ターゲット追跡スケーリングポリシーを作成して、Amazon ECS がサービスで必要なタスク数を自動的に増減するようにします。ターゲット追跡は、ターゲットメトリクス値に基づいて機能します。
## コンソール
1. サービスの作成や更新に使用する標準の IAM アクセス権限に加えて、追加のアクセス権限が必要です。詳細については、「[Amazon ECS のサービス自動スケーリングに必要な IAM アクセス許可](auto-scaling-IAM.md)」を参照してください。
1. ポリシーに使用するメトリクスを決定します。以下のメトリクスが利用可能です。
+ **[ECSServiceAverageCPUUtilization]** — サービスが使用する平均 CPU 使用率。
+ **[ECSServiceAverageMemoryUtilization]** — サービスが使用する平均メモリ使用率。
+ **[ALBRequestCountPerTarget]** – タスクが受信する 1 分あたりの理想的な平均リクエスト数。
1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。
1. **[クラスター]** ページで、クラスターを選択します。
1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。
[サービス詳細] ページが表示されます。
1. **[タスク数を設定する]** を選択します。
1. **[Amazon ECS サービスのタスク数]** で、**[自動スケーリングを使用する]** を選択します。
**[タスク数セクション]** が表示されます。
1. **[タスクの最小数]** に、サービスの自動スケーリングで使用するタスクの下限数を入力します。必要な数がこの数を下回ることはありません。
1. **[最大]** に、サービスの自動スケーリングで使用するタスクの上限数を入力します。必要な数がこの数を超えることはありません。
1. **[保存]** を選択します。
[ポリシー] ページが表示されます。
1. **[スケーリングポリシーを作成する]** を選択します。
**[ポリシーを作成する]** ページが表示されます。
1. [**スケーリングポリシータイプ**] で [**ターゲットの追跡**] を選択します。
1. **[Policy Name]** (ポリシー名) にこのポリシーの名前を入力します。
1. **[メトリクスのタイプ]** で、オプションのリストからメトリクスを選択します。
1. **[ターゲット使用率]** には、Amazon ECS が維持するタスクの割合のターゲット値を入力します。サービスの自動スケーリングは、平均使用率が目標使用率になるまで、または指定した最大タスク数に達するまで、キャパシティをスケールアウトします。
1. **[追加設定]** で、以下を実行します。
1. **[スケールインのクールダウン期間]** に、スケールインアクティビティが完了してから別のスケールインアクティビティが開始されるまでの時間を秒単位で入力します。
1. **[スケールアウトのクールダウン期間]** には、前回のスケールアウトアクティビティが有効になるまで待機する時間を秒単位で入力します。
1. スケールアウトポリシーのみを作成するには、**[スケールインを無効にする]** を選択します。
1. **[スケーリングポリシーを作成する]** を選択します。
## AWS CLI
1. [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) コマンドを使用して、スケーラブルなターゲットとして Amazon ECS サービスを登録します。
1. [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) コマンドを使用して、スケーリングポリシーを作成します。
# CloudWatch アラームに基づく定義済みの増分を使用して Amazon ECS サービスをスケールする
ステップスケーリングポリシーを使用して、スケーリングプロセスを呼び出す CloudWatch アラームを作成および管理します。アラームに違反すると、Amazon ECS はそのアラームに関連付けられたスケーリングポリシーを開始します。ステップスケーリングポリシーは、ステップ調整と呼ばれる一連の調整を使用してタスクをスケールします。調整値の規模は、アラーム違反の大きさに応じて異なります。
+ 違反が最初のしきい値を超えた場合、Amazon ECS は最初のステップの調整を適用します。
+ 違反が 2 番目のしきい値を超えた場合、Amazon ECS は 2 番目のステップの調整を適用するというように続きます。
ターゲット追跡スケーリング ポリシーを使用して、ターゲットごとの平均 CPU 使用率や平均リクエスト数などのメトリクスに基づいてスケールすることを強くお勧めします。キャパシティーが増加すると減少し、キャパシティーが減少すると増加するメトリクスを使用すると、ターゲット追跡を使用してインスタンス数を比例的にスケールアウトしたり、タスク数を増やすことができます。これにより、Amazon ECS がアプリケーションの需要曲線に厳密に従うことが保証されます。
# Amazon ECS サービスの自動スケーリングのステップスケーリングポリシーを作成する
ステップスケーリングポリシーを作成して、Amazon ECS がサービスで必要なタスク数を自動的に増減させます。ステップスケーリングは、ステップ調整と呼ばれる、超過アラームのサイズによって異なる一連のスケーリング調整値に基づいて実行されます。
## コンソール
1. サービスの作成や更新に使用する標準の IAM アクセス権限に加えて、追加のアクセス権限が必要です。詳細については、「[Amazon ECS のサービス自動スケーリングに必要な IAM アクセス許可](auto-scaling-IAM.md)」を参照してください。
1. ポリシーに使用するメトリクスを決定します。以下のメトリクスが利用可能です。
+ **[ECSServiceAverageCPUUtilization]** — サービスが使用する平均 CPU 使用率。
+ **[ECSServiceAverageMemoryUtilization]** — サービスが使用する平均メモリ使用率。
+ **[ALBRequestCountPerTarget]** – タスクが受信する 1 分あたりの理想的な平均リクエスト数。
1. メトリクスの CloudWatch アラームを作成します。詳細については、*Amazon CloudWatch ユーザーガイド*の「[静的しきい値に基づいて CloudWatch アラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)」を参照してください。
1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。
1. **[クラスター]** ページで、クラスターを選択します。
1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。
[サービス詳細] ページが表示されます。
1. **[タスク数を設定する]** を選択します。
1. **[Amazon ECS サービスのタスク数]** で、**[自動スケーリングを使用する]** を選択します。
**[タスク数セクション]** が表示されます。
1. **[タスクの最小数]** に、サービスの自動スケーリングで使用するタスクの下限数を入力します。必要な数がこの数を下回ることはありません。
1. **[最大]** に、サービスの自動スケーリングで使用するタスクの上限数を入力します。必要な数がこの数を超えることはありません。
1. **[保存]** を選択します。
[ポリシー] ページが表示されます。
1. **[スケーリングポリシーを作成する]** を選択します。
**[ポリシーを作成する]** ページが表示されます。
1. **[スケーリングポリシータイプ]** で **[ステップスケーリング]** を選択します。
1. スケールアウトプロパティを設定します。**[タスクを追加するステップ]** で、次を実行します。
1. **[Policy Name]** (ポリシー名) にこのポリシーの名前を入力します。
1. **[CloudWatch アラーム名]** で、CloudWatch アラームを選択します。
1. **[メトリクスの集計タイプ]** で、選択したメトリクスを定義されたしきい値と比較する方法を選択します。
1. **[調整タイプ]** で、調整がタスク数の変化に基づくか、タスクの割合の変化に基づくかを選択します。
1. **[実行するアクション]** で、実行するアクションの値を入力します。
**[ステップを追加]** を選択して、追加のアクションを追加します。
1. スケールインプロパティを設定します。**[タスクを削除するステップ]** で、次を実行します。
1. **[Policy Name]** (ポリシー名) にこのポリシーの名前を入力します。
1. **[CloudWatch アラーム名]** で、CloudWatch アラームを選択します。
1. **[メトリクスの集計タイプ]** で、選択したメトリクスを定義されたしきい値と比較する方法を選択します。
1. **[調整タイプ]** で、調整がタスク数の変化に基づくか、タスクの割合の変化に基づくかを選択します。
1. **[実行するアクション]** で、実行するアクションの値を入力します。
**[ステップを追加]** を選択して、追加のアクションを追加します。
1. **[クールダウン期間]** には、前回のスケーリングアクティビティが有効になるまで待機する時間を秒単位で入力します。追加ポリシーの場合、スケールアウトアクティビティの終了後、スケーリングポリシーによってスケールインアクティビティがブロックされ、一度にスケールアウトできるタスクの数が制限されます。削除ポリシーの場合、これはスケールインアクティビティの後、別のスケールインアクティビティが開始されるまでに経過する必要がある時間です。
1. **[スケーリングポリシーを作成する]** を選択します。
## AWS CLI
1. [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) コマンドを使用して、スケーラブルなターゲットとして Amazon ECS サービスを登録します。
1. [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) コマンドを使用して、スケーリングポリシーを作成します。
# スケジュールされたアクションを使用して Amazon ECS サービスをスケールする
スケジュールされたスケーリングでは、特定の時間にタスク数を増減するスケジュールアクションを作成することで、予測可能な負荷の変化に基づいてアプリケーションの自動スケーリングを設定できます。これにより、予測可能な負荷の変化に合わせてアプリケーションを事前対応的にスケーリングできます。
これらのスケジュールされたスケーリングアクションにより、コストとパフォーマンスを最適化できます。アプリケーションには、週半ばのトラフィックのピークを処理するのに十分な数のタスクがありますが、それ以外の時間帯にタスクを過剰にプロビジョニングすることはありません。
スケジュールされたスケーリングとスケーリングポリシーを併用して、スケーリングに事前対応型アプローチと即応型アプローチの両方のメリットを得ることができます。スケジュールされたスケーリングアクションの実行後、スケーリングポリシーはタスクをさらにスケールするかどうかの判断を引き続き行うことができます。これは、アプリケーションの負荷を処理するために十分なタスク数を確保する上で役立ちます。アプリケーションは需要に合わせてスケールしますが、現行のキャパシティは、スケジュールされたアクションによって設定された最小タスク数と最大タスク数の範囲内に収まる必要があります。
スケジュールスケーリングは AWS CLI を使用して設定できます。スケジュールに基づくスケーリングの詳細については、「*Application Auto Scaling ユーザーガイド*」の「[スケジュールに基づくスケーリング](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html)」を参照してください。
# Amazon ECS サービスの自動スケーリングのスケジュールされたアクションを作成する
スケジュールされたアクションを作成して、Amazon ECS でサービスが実行するタスク数を日付と時刻に基づいて増減させます。
## コンソール
1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。
1. **[クラスター]** ページで、クラスターを選択します。
1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。
[サービス詳細] ページが表示されます。
1. **[サービスの自動スケーリング]** を選択します。
[サービスの自動スケーリング] ページが表示されます。
1. [サービスの自動スケーリング] を設定していない場合は、**[タスク数の設定]** を選択します。
**Amazon ECS サービスタスク数** のセクションが表示されます。
**Amazon ECS サービスタスク数** で、**[サービスの自動スケーリングを使用してサービスの必要なタスク数を調整する]** を選択します。
**[タスク数セクション]** が表示されます。
1. **[タスクの最小数]** に、サービスの自動スケーリングで使用するタスクの下限数を入力します。必要な数がこの数を下回ることはありません。
1. **[最大]** に、サービスの自動スケーリングで使用するタスクの上限数を入力します。必要な数がこの数を超えることはありません。
1. **[保存]** を選択します。
[ポリシー] ページが表示されます。
1. **[スケジュールされたアクション]** を選択し、**[作成]** を選択します。
**[スケジュールされたアクションを作成]** ページが表示されます。
1. **バケット名**に、一意の名前を入力します。
1. [**Time zone (タイムゾーン)**] でタイムゾーンを選択。
リストされているすべてのタイムゾーンは、IANA タイムゾーンデータベースから取得されます。詳細については、「[List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)」を参照してください。
1. **[開始時刻]** で、アクションが開始される **[日付]** と **[時刻]** を入力します。
定期的なスケジュールを選択した場合、開始時間によって、定期的なシリーズの最初のスケジュールされたアクションが実行されるタイミングが定義されます。
1. [**Recurrence (反復)**] で、使用可能なオプションの 1 つを選択します。
+ 反復スケジュールに基づいてスケールするには、Amazon ECS がスケジュールされたアクションを実行する頻度を選択します。
+ **[レート]** で始まるオプションを選択した場合、cron 式が作成されます。
+ [**Cron**] を選択した場合は、いつアクションを実行するかを Cron 式を入力します。
+ 1 回だけスケールするには、**[1 回]** を選択します。
1. **[タスク調整]** で、次の操作を行います。
+ **[最小]** で、サービスが実行する最小タスク数を入力します。
+ **[最大]** で、サービスが実行する最大タスク数を入力します。
1. **[スケジュールされたアクションの作成]** を選択してください。
## CLI
次のように AWS CLI を使用して、サービスのスケジュールされたスケーリングポリシーを設定します。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。
**例: 1 回のみスケールするには**
次の [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) コマンドを、`--start-time "YYYY-MM-DDThh:mm:ssZ"` と `--MinCapacity` および `--MaxCapacity` オプションのいずれかまたは両方と併用します。
```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
--resource-id service/my-cluster/my-service \
--scheduled-action-name my-one-time-schedule \
--start-time 2021-01-30T12:00:00 \
--scalable-target-action MinCapacity=3,MaxCapacity=10
```
**例: 定期的なスケーリングをスケジュールするには**
次の [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) コマンドを使用します。*user-input* を独自の値に置き換えます。
```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
--resource-id service/my-cluster/my-service \
--scheduled-action-name my-recurring-action \
--schedule "rate(5 hours)" \
--start-time 2021-01-30T12:00:00 \
--end-time 2021-01-31T22:00:00 \
--scalable-target-action MinCapacity=3,MaxCapacity=10
```
指定された繰り返しスケジュールは、UTC タイムゾーンに基づいて実行されます。別のタイムゾーンを指定するには、次の例のように、`--time-zone` オプションと IANA タイムゾーンの名前を含めます。
```
--time-zone "America/New_York"
```
詳細については、「[List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)」を参照してください。
# 履歴パターンを使用して予測スケーリングで Amazon ECS サービスをスケールする
予測スケーリングは、トラフィックフローからの過去の負荷データを調べて、日次または週次のパターンを分析します。次に、この分析を使用して将来のニーズを予測し、必要に応じてサービスのタスクをプロアクティブに増やします。
予測自動スケーリングは、以下の状況で最も役立ちます。
+ 周期的なトラフィック - 通常の営業時間にリソースの使用が増加し、夜間や週末にはリソースの使用が減少する。
+ オンとオフを繰り返すワークロードパターン - バッチ処理、テスト、定期的なデータ分析など。
+ 初期化に時間がかかるアプリケーション - スケールアウトイベント中のアプリケーションのパフォーマンスに影響を及ぼし、顕著なレイテンシーを引き起こす可能性がある。
アプリケーションの初期化に時間がかかり、トラフィックが規則的なパターンで増加する場合は、予測スケーリングの使用を検討する必要があります。ターゲット追跡やステップスケーリングなどの動的スケーリングポリシーを単独で使用するのではなく、予測される負荷に応じてタスク数を事前に増やすことで、より迅速にスケールできます。予測スケーリングにより、タスク数が過剰にプロビジョニングされる可能性を回避できるため、コストを削減できる場合もあります。
例えば、営業時間中の使用率が高く、夜間の使用量が少ないアプリケーションを考えてみましょう。各営業日の開始時に、予測スケーリングにより、トラフィックが最初に流入する前にタスクをスケールアウトできます。これにより、使用率の低い期間から高い使用率の期間に移行するときに、アプリケーションの高可用性とパフォーマンスを維持するのに役立ちます。トラフィックの変化に動的スケーリングが反応するのを待つ必要はありません。また、アプリケーションの負荷パターンを確認し、スケジュールされたスケーリングを使用して適切な量のタスクをスケジュールするために時間を費やす必要もありません。
予測スケーリングは、基盤となるコンピューティングキャパシティ (EC2 や Fargate など) のスケーリングとは別にサービスのタスクをスケーリングするサービスレベルの機能です。Fargate の場合、AWS はタスク要件に基づいて基盤となる容量を管理して動的にスケーリングします。EC2 キャパシティーの場合、Auto Scaling グループキャパシティープロバイダーを使用して、タスクのスケーリング要件に基づいて基盤となる EC2 インスタンスを自動的にスケーリングできます。
**Topics**
+ [予測スケーリングの概要](#predictive-auto-scaling-overview)
+ [予測スケーリングポリシーを作成する](predictive-scaling-create-policy.md)
+ [予測スケーリングポリシーの評価](predictive-scaling-graphs.md)
+ [予測を上書きする](predictive-scaling-overriding-forecast-capacity.md)
+ [カスタムメトリクスを使用する](predictive-scaling-custom-metrics.md)
## Amazon ECS における予測スケーリングの仕組み
ここでは、予測スケーリングの使用に関する考慮事項、その仕組み、制限事項について説明します。
### 予測スケーリングを使用する際の考慮事項
+ 予測スケーリングがワークロードに適していることを確認する必要があります。これを確認するには、**予測専用**モードでスケーリングポリシーを設定し、コンソールが推奨する内容を確認します。予測スケーリングの使用を開始する前に、予測とレコメンデーションを評価する必要があります。
+ 予測スケーリングが予測を開始するには、少なくとも 24 時間以上の履歴データが必要です。使用可能な履歴データが多いほど、予測がより効果的になり、2 週間分の履歴データがあると理想的です。また、Amazon ECS サービスを削除して新しいサービスを作成する場合、予測スケーリングによって新しい予測が生成されるまで 24 時間待つ必要があります。これを高速化する 1 つの方法は、カスタムメトリクスを使用して、古い Amazon ECS サービスと新しい Amazon ECS サービス全体のメトリクスを集約することです。
+ アプリケーションのすべての負荷を正確に表し、スケーリングが最も重要なアプリケーションの側面である負荷メトリクスを選択します。
+ 予測スケーリングを使用した動的スケーリングにより、アプリケーションの需要に迅速に対応でき、需要が少ないときにはスケールインし、予期しないトラフィックの増加時にはスケールアウトすることができます。複数のスケーリングポリシーがアクティブな場合、各ポリシーによって希望するタスク数が個別に決定され、希望するタスク数はそれらの最大値に設定されます。
+ ターゲット追跡やステップスケーリングなどの動的スケーリングポリシーと共に予測スケーリングを使用すると、リアルタイムパターンと履歴パターンの両方に基づいてアプリケーションをスケーリングできます。それ自体では、予測スケーリングはタスクをスケールインしません。
+ `register-scalable-target` API を呼び出すときにカスタムロールを使用すると、予測スケーリングポリシーが SLR を有効にした場合にのみ機能することを示すエラーが表示されることがあります。この場合、role-arn なしで再度 `register-scalable-target` を呼び出す必要があります。スケーラブルターゲットを登録する際に SLR を使用し、`put-scaling-policy` API を呼び出します。
### 予測スケーリングの仕組み
予測スケーリングを使用するには、モニタリングおよび分析する CloudWatch メトリクスを指定する予測スケーリングポリシーを作成します。予測スケーリングが将来の値の予測を開始するには、このメトリクスに 24 時間以上のデータが必要です。
ポリシーを作成すると、予測スケーリングは最長過去 14 日間のメトリクスデータの分析を開始し、パターンを特定します。この分析は、今後 48 時間の必要量の時間ごとの予測を生成するために使用されます。最新の CloudWatch データを使用して、6 時間ごとに予測が更新されます。新しいデータを取得すると、予測スケーリングは将来の予測の正確性を継続的に向上させます。
最初に予測スケーリングを有効にしたときは、*予測のみ*モードで実行されます。このモードでは予測を生成しますが、それらの予測に基づいて Amazon ECS サービスをスケールすることはありません。これにより、予測の正確性と適合性を評価できます。`GetPredictiveScalingForecast` API オペレーションまたは AWS マネジメントコンソールを使用して、予測データを表示します。
予測スケーリングの使用を開始する場合は、スケーリングポリシーを*予測とスケーリング*モードに切り替えます。このモードでは、次のことが発生します。
Amazon ECS サービスは、デフォルトでは、その時間の予測に基づいて各時間の開始時にスケールされます。`PutScalingPolicy` API オペレーションで `SchedulingBufferTime` プロパティを使用して、早く開始することを選択できます。これにより、新しいタスクは予測される需要よりも早く起動し、トラフィックを処理する準備が整うまでの時間を確保できます。
### 最大タスク制限
スケーリングのために Amazon ECS サービスを登録する場合、サービスごとに起動できる最大タスク数を定義します。デフォルトでは、スケーリングポリシーが設定されている場合、タスク数をその最大制限を超えて増やすことはできません。
ただし、予測が Amazon ECS サービスの最大タスク数に近づいた場合、または超えた場合に、サービスの最大タスク数を自動的に増やすことを許可できます。
**警告**
最大タスク数を自動的に増やす場合は注意してください。これにより、増加した最大タスク数がモニタリングおよび管理されていない場合、意図したよりも多くのタスクが起動される可能性があります。増加した最大タスク数は、手動で更新するまで Amazon ECS サービスの新しい通常の最大タスク数になります。最大タスク数は、自動的に元の最大タスク数まで減少しません。
### サポート対象のリージョン
+ 米国東部 (バージニア北部)
+ 米国東部 (オハイオ)
+ 米国西部 (北カリフォルニア)
+ 米国西部 (オレゴン)
+ アフリカ (ケープタウン)
+ アジアパシフィック (香港)
+ アジアパシフィック (ジャカルタ)
+ アジアパシフィック (ムンバイ)
+ アジアパシフィック (大阪)
+ アジアパシフィック (ソウル)
+ アジアパシフィック (シンガポール)
+ アジアパシフィック (シドニー)
+ アジアパシフィック (東京)
+ カナダ (中部)
+ 中国 (北京)
+ 中国 (寧夏)
+ 欧州 (フランクフルト)
+ 欧州 (アイルランド)
+ 欧州 (ロンドン)
+ 欧州 (ミラノ)
+ ヨーロッパ (パリ)
+ ヨーロッパ (ストックホルム)
+ 中東 (バーレーン)
+ 南米 (サンパウロ)
+ AWS GovCloud (米国東部)
+ AWS GovCloud (米国西部)
# Amazon ECS サービスの自動スケーリングの予測スケーリングポリシーを作成する
予測スケーリングポリシーを作成して、Amazon ECS でサービスが実行するタスク数を履歴データに基づいて増減させます。
**注記**
新しいサービスは、予測を生成する前に 24 時間以上のデータを提供する必要があります。
## コンソール
1. サービスの作成や更新に使用する標準の IAM アクセス権限に加えて、追加のアクセス権限が必要です。詳細については、「[Amazon ECS のサービス自動スケーリングに必要な IAM アクセス許可](auto-scaling-IAM.md)」を参照してください。
1. ポリシーに使用するメトリクスを決定します。以下のメトリクスが利用可能です。
+ **[ECSServiceAverageCPUUtilization]** — サービスが使用する平均 CPU 使用率。
+ **[ECSServiceAverageMemoryUtilization]** — サービスが使用する平均メモリ使用率。
+ **[ALBRequestCountPerTarget]** – タスクが受信する 1 分あたりの理想的な平均リクエスト数。
または、カスタムメトリクスを使用することもできます。次の値を定義する必要があります。
+ 負荷 - アプリケーションのすべての負荷を正確に表し、スケーリングが最も重要なアプリケーションの側面であるメトリクス。
+ スケーリングメトリクス - アプリケーションにとって理想的な使用率を予測するために最適な予測子。
1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。
1. **[クラスター]** ページで、クラスターを選択します。
1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。
[サービス詳細] ページが表示されます。
1. **[サービスの自動スケーリング]** を選択し、**[タスクの数を設定]** を選択します。
1. **[Amazon ECS サービスのタスク数]** で、**[自動スケーリングを使用する]** を選択します。
**[タスク数セクション]** が表示されます。
1. **[タスクの最小数]** に、サービスの自動スケーリングで使用するタスクの下限数を入力します。必要な数がこの数を下回ることはありません。
1. **[最大]** に、サービスの自動スケーリングで使用するタスクの上限数を入力します。必要な数がこの数を超えることはありません。
1. **[保存]** を選択します。
[ポリシー] ページが表示されます。
1. **[スケーリングポリシーを作成する]** を選択します。
**[ポリシーを作成する]** ページが表示されます。
1. **[スケーリングポリシータイプ]** で **[予測スケーリング]** を選択します。
1. **[Policy Name]** (ポリシー名) にこのポリシーの名前を入力します。
1. **[メトリクスペア]** で、オプションのリストからメトリクスを選択します。
**[Application Load Balancer request count per target]** (ターゲットあたりの Application Load Balancer リクエスト数) を選択した場合、**[Target group]** (ターゲットグループ) のターゲットグループを選択します。**[ターゲットあたりの Application Load Balancer リクエスト数]** は、Application Load Balancer ターゲットグループをサービスにアタッチしている場合にのみサポートされます。
**[カスタムメトリクスペア]** を選択した場合、**[負荷のメトリクス]** と **[スケーリングのメトリクス]** のリストから個々のメトリクスを選択します。
1. **[ターゲット使用率]** には、Amazon ECS が維持するタスクの割合のターゲット値を入力します。サービスの自動スケーリングは、平均使用率が目標使用率になるまで、または指定した最大タスク数に達するまで、キャパシティをスケールアウトします。
1. **[スケーリングポリシーを作成する]** を選択します。
## AWS CLI
次のように AWS CLI を使用して、Amazon ECS サービスの予測スケーリングポリシーを設定します。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。
指定できる CloudWatch メトリクスの詳細については、「*Amazon EC2 Auto Scaling API リファレンス*」の「[PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)」を参照してください。
### 例 1: メモリが事前定義された予測スケーリングポリシー。
以下は、メモリ設定が事前定義されたポリシーの例です。
```
cat policy.json
{
"MetricSpecifications": [
{
"TargetValue": 40,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ECSServiceMemoryUtilization"
}
}
],
"SchedulingBufferTime": 3600,
"MaxCapacityBreachBehavior": "HonorMaxCapacity",
"Mode": "ForecastOnly"
}
```
以下の例は、設定ファイルを指定し [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行して、ポリシーを作成する方法を示しています。
```
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```
成功した場合、このコマンドはポリシーの ARN を返します。
```
{
"PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
"Alarms": []
}
```
### 例 2: CPU が事前定義された予測スケーリングポリシー。
以下は、CPU 設定が事前定義されたポリシーの例です。
```
cat policy.json
{
"MetricSpecifications": [
{
"TargetValue": 0.00000004,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ECSServiceCPUUtilization"
}
}
],
"SchedulingBufferTime": 3600,
"MaxCapacityBreachBehavior": "HonorMaxCapacity",
"Mode": "ForecastOnly"
}
```
以下の例は、設定ファイルを指定し [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行して、ポリシーを作成する方法を示しています。
```
aws aas put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```
成功した場合、このコマンドはポリシーの ARN を返します。
```
{
"PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
"Alarms": []
}
```
# Amazon ECS の予測スケーリングポリシーの評価
予測スケーリングポリシーを使用してサービスをスケールする前に、Amazon ECS コンソールでポリシーの推奨事項とその他のデータを確認します。予測が正確であることがわかるまで、予測スケーリングポリシーが実際のキャパシティをスケーリングすることが好ましくないため、これは重要です。
サービスが新しい場合は、最初の予測の作成に 24 時間かかります。
AWS が予測を作成するとき、履歴データを使用します。サービスに最新の履歴データがまだ十分にない場合、予測スケーリングは現在使用可能な履歴集計から作成された集計で予測を一時的にバックフィルすることがあります。予測は、ポリシーの作成日より最大 2 週間前にバックフィルされます。
## 予測スケーリングの推奨事項の表示
分析を効果的に行うには、サービスの自動スケーリングに比較対象となる予測スケーリングポリシーが少なくとも 2 つ必要です。(ただし、単一ポリシーの結果を確認することはできます) 複数のポリシーを作成するとき、1 つのメトリクスを使用するポリシーを異なるメトリクスを使用するポリシーと比較して評価できます。異なる目標値およびメトリクスの組み合わせによる影響を評価することもできます。予測スケーリングポリシーが作成された後、Amazon ECS は、どのポリシーがグループのスケーリングに適しているかについて、すぐに評価を開始します。
**Amazon ECS コンソールで推奨事項を表示するには**
1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。
1. **[クラスター]** ページで、クラスターを選択します。
1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。
[サービス詳細] ページが表示されます。
1. **[サービスの自動スケーリング]** を選択します。
1. 予測スケーリングポリシーを選択し、**[アクション]**、**[予測スケーリング]**、**[レコメンデーションの表示]** を選択します。
ポリシーの詳細と推奨事項を表示できます。推奨事項は、予測スケーリングポリシーを使用しない場合よりも優れた性能を発揮するかどうかについて説明します。
予測スケーリングポリシーがグループに適切かどうかが不明な場合、**[可用性への影響]** 列および **[コストへの影響]** 列を確認し、適切なポリシーを選択してください。各列の情報は、ポリシーの影響について説明します。
+ **[可用性への影響]**: ポリシーを使用しない場合と比較し、ワークロードを処理するために十分なタスクをプロビジョニングすることにより、ポリシーが可用性への悪影響を回避できるかどうかについて説明します。
+ **[コストへの影響]**: ポリシーを使用しない場合と比較し、タスクを過剰にプロビジョニングしないことにより、ポリシーがコストへの悪影響を回避できるかどうかについて説明します。過剰にプロビジョニングしすぎると、サービスが十分に活用されない、またはアイドル状態になり、コストへの影響が増す一方です。
複数のポリシーがある場合、より低コストで最も可用性のメリットが高いポリシーの名前の横に **[最良予測]** タグが表示されます。可用性への影響がより重視されます。
1. (オプション) 推奨結果の必要な期間を選択するには、**[評価期間]** のドロップダウンから **[2 日]**、**[1 週間]**、または **[2 週間]** のいずれか希望する値を選択します。デフォルトでは、評価期間は過去の 2 週間です。評価期間が長いほど、推奨結果のデータポイントが増えます。ただし、需要が非常に高い時期の後など、負荷パターンが変化した場合、データポイントを追加しても結果が改善されない可能性があります。この場合、最新のデータを見ることでより焦点を絞った推奨事項を得ることができます。
**注記**
推奨事項は **[予測のみ]** モードのポリシーに対してのみ生成されます。推奨機能は、評価期間中にポリシーが **[予測のみ]** モードのときにより効果的に機能します。ポリシーを **[予測とスケーリング]** モードで開始し、後で **[予測のみ]** モードに切り替える場合、そのポリシーの結果に偏りが生じる可能性があります。これは、ポリシーが既に実際のキャパシティに関与しているためです。
## 予測スケーリングのモニタリンググラフの確認
コンソールでは、以前の日、週間、月の予測を確認し、時間の経過と共にポリシーがどの程度機能しているか視覚化できます。また、ポリシーが実際のタスク数をスケールするかどうかを決定するとき、この情報を使用して予測の精度を評価できます。
**Amazon ECS コンソールで予測スケーリングのモニタリンググラフを表示するには**
1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。
1. **[クラスター]** ページで、クラスターを選択します。
1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。
[サービス詳細] ページが表示されます。
1. **[サービスの自動スケーリング]** を選択します。
1. 予測スケーリングポリシーを選択し、**[アクション]**、**[予測スケーリング]**、**[グラフの表示]** を選択します。
1. **[モニタリング]** セクションでは、ポリシーの負荷およびキャパシティに関する過去および今後の予測を実際の値と比較できます。**[負荷]** グラフには、選択した負荷メトリクスの負荷予測および実際の値が表示されます。**[キャパシティ]** グラフには、ポリシーによって予測されたタスク数が表示されます。実際に起動されたタスク数も含まれます。縦線は履歴の値と今後の予測を区切っています。これらのグラフは、ポリシーの作成後にすぐ利用できます。
1. (オプション) グラフに表示される履歴データの量を変更するには、ページ上部の **[評価期間]** のドロップダウンから希望する値を選択します。評価期間はこのページのデータをはいかなる方法で変換することはありません。表示される履歴データの量のみを変更します。
****[負荷]** グラフのデータを比較**
各水平線は、1 時間間隔で報告される異なる一連のデータポイントを表しています。
1. **[実際に観測された負荷]** は、選択した負荷メトリクスの SUM 統計を使用し、過去の 1 時間ごとの合計負荷を表示します。
1. **[ポリシーによって予測される負荷]** は、1 時間ごとの負荷予測を表示します。この予測は過去 2 週間分の実際の負荷観測に基づいています。
****[キャパシティ]** グラフのデータの比較**
各水平線は、1 時間間隔で報告される異なる一連のデータポイントを表しています。
1. **[実際に観測されたタスク数]** には、Amazon ECS サービスの過去の実際のキャパシティが表示されます。これは、他のスケーリングポリシーや、選択した期間に有効な最小グループサイズによって異なります。
1. **[ポリシーによって予測されるキャパシティ]** には、ポリシーが **[予測とスケーリング]** モードになっているときに各時間の開始時に予想されるベースラインキャパシティが表示されます。
1. **[推定される必要タスク数]** には、スケーリングメトリクスを選択したターゲット値に維持するためのサービス内の理想的なタスク数が表示されます。
1. **[最小タスク数]** には、サービス内の最小タスク数が表示されます。
1. **[最大キャパシティ]** には、サービス内の最大タスク数が表示されます。
推定される必要キャパシティを計算するため、最初は各タスクが指定された目標値で均等に使用されていると仮定します。実際には、タスク数は均等に使用されません。ただし、使用率がタスク間で均等に分散されていると仮定することにより、必要なキャパシティの量を推定できます。次に、タスク数の要件は、予測スケーリングポリシーに使用したスケーリングメトリクスに反比例するように計算されます。つまり、タスク数が増加するにつれ、スケーリングメトリクスは同じ割合で減少します。例えば、タスク数が 2 倍になった場合、スケーリングメトリクスは半減します。
推定された必要キャパシティの計算式は、次のとおりです。
`sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)`
例えば、特定の時間の `actualServiceUnits` (`10`) および `scalingMetricValue` (`30`) を算出します。その後、予測スケーリングポリシー (`60`) で指定した `targetUtilization` を使用し、同じ時間に推定される必要キャパシティを計算します。これは `5` の値を返します。これは、スケーリングメトリクスの目標値とは正反比例し、キャパシティを維持するために必要なキャパシティの推定量は 5 であることを意味します。
**注記**
コスト削減およびアプリケーションの可用性を調整および改善するため、さまざまな手段が用意されています。
ベースラインキャパシティに予測スケーリングを使用し、追加のキャパシティに動的スケーリングを使用します。動的スケーリングは予測スケーリングとは独立して動作し、現在の使用率に基づいてスケールインおよびスケールアウトを行います。まず、Amazon ECS は、スケジュールされていないスケーリングポリシーごとに推奨されるタスク数を計算します。次に、最も多くのタスクを提供するポリシーに基づいてスケーリングします。
負荷が減少したときにスケールインできるようにするには、サービスに、スケールイン部分を有効にした動的スケーリングポリシーが常に少なくとも 1 つ必要です。
最小キャパシティおよび最大キャパシティを制限しすぎないようにすることにより、スケーリングパフォーマンスを向上させることができます。推奨されるタスク数が最小キャパシティおよび最大キャパシティの範囲に収まらないポリシーは、スケールインおよびスケールアウトができなくなります。
# CloudWatch による Amazon ECS の予測スケーリングメトリクスをモニタリングする
Amazon CloudWatch を使用して、予測スケーリング用にデータをモニタリングできます。予測スケーリングポリシーは、今後の負荷を予測するために使用されるデータを収集します。収集されたデータは、定期的に CloudWatch に自動的に保存され、ポリシーが時間の経過と共にどの程度機能しているかを視覚化するために使用できます。また、CloudWatch アラームを作成して、パフォーマンス指標が定義した制限を超えて変化したときに通知させることもできます。
## 履歴予測データの視覚化
予測スケーリングポリシーの負荷予測データは CloudWatch で表示でき、他の CloudWatch メトリクスに対する予測を 1 つのグラフで視覚化する場合に役立ちます。また、より広い時間範囲を表示することで、時間の経過に伴う傾向を確認することもできます。最大 15 か月間の履歴メトリクスにアクセスして、ポリシーの動作をより的確に把握できます。
**CloudWatch コンソールを使用して履歴予測データを表示する方法**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[Metrics]** (メトリクス)、**[All metrics]** (すべてのメトリクス) の順に選択します。
1. **[アプリケーションの自動スケーリング]** メトリクス名前空間を選択します。
1. **[予測スケーリングの負荷予測]** を選択します。
1. 検索フィールドに、予測スケーリングポリシー名または Amazon ECS サービスグループ名を入力し、Enter キーを押して結果をフィルタリングします。
1. メトリクスをグラフ表示するには、メトリクスの横にあるチェックボックスを選択します。グラフの名前を変更するには、鉛筆アイコンを選択します。時間範囲を変更するには、事前定義済みの値を選択するか、[**custom**] を選択します。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[メトリクスをグラフ化する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html)」を参照してください。
1. 統計を変更するには、[**Graphed metrics**] タブを選択します。列見出しまたは個々の値を選択し、続いて各種統計を選択します。各メトリクスの任意の統計を選択できますが、すべての統計が **[PredictiveScalingLoadForecast]** メトリクスに有用なわけではありません。例えば、**平均**、**最小**、**最大**の各統計は有用ですが、**合計**の統計は有用ではありません。
1. グラフに別のメトリクスを追加するには、**[Browse]** (参照) で **[All]** (すべて) を選択し、追加したいメトリクスを見つけて、その横にあるチェックボックスをオンにします。最大 10 個のメトリクスを追加できます。
1. (オプション) このグラフを CloudWatch ダッシュボードに追加するには、**[Actions]** (アクション)、**[Add to dashboard]** (ダッシュボードに追加) の順に選択します。
## Metric Math を使用して精度メトリクスを作成する
Metric Math により、複数の CloudWatch メトリクスをクエリし、数式を使用して、これらのメトリクスに基づく新しい時系列を作成できます。作成された時系列を CloudWatch コンソールで可視化でき、ダッシュボードに追加できます。メトリクス演算の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch メトリクスでの数式の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)」を参照してください。
Metric Math を使用して、サービス自動スケーリングが予測スケーリングのために生成するデータを各種の方法でグラフ化できます。これにより、ポリシーのパフォーマンスを経時的にモニタリングし、メトリクスの組み合わせを改善できるかどうかを把握することができます。
例えば、Metric Math 式を使用して、[平均絶対パーセント誤差](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error) (MAPE) をモニタリングできます。MAPE メトリクスは、予測値と、特定の予測期間中に観測された実際の値の差をモニタリングするのに役立ちます。MAPE の値の変化は、アプリケーションの性質が変化するにつれて、ポリシーのパフォーマンスが経時的に低下しているかどうかを示します。MAPE の増加は、予測値と実際の値の差が大きいことを示します。
**例: Metric Math 式**
このタイプのグラフを使用するには、次の例に示すような Metric Math 式を作成します。
単一のメトリクスではなく、`MetricDataQueries` 用のメトリクスデータクエリ構造の配列があります。`MetricDataQueries` の各項目は、メトリクスを取得するか、数式を実行します。最初の項目は、数式である `e1` です。指定された式は、`ReturnData` パラメータを `true` に設定し、最終的に単一の時系列を生成します。他のすべてのメトリクスで、`ReturnData` 値は `false` です。
この例では、指定された式は実際の値と予測値を入力値として使用し、新しいメトリクス (MAPE) を返します。`m1` は、実際の負荷値を含む CloudWatch メトリクスです (CPU 使用率が、`my-predictive-scaling-policy` という名前のポリシーに対して最初に指定された負荷メトリクスであると仮定)。`m2` は、予測負荷値を含む CloudWatch メトリクスです。MAPE メトリクスの計算構文は次のとおりです。
(絶対値 ((実際の値 - 予測値)/(実際の値))) の平均
### 精度メトリクスを視覚化してアラームを設定する
精度メトリクスデータを視覚化するには、CloudWatch コンソールの **[Metrics]** (メトリクス) タブをクリックします。そこからデータをグラフ化できます。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch グラフに数式を追加する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console)」を参照してください。
**[Metrics]** (メトリクス) セクションから、モニタリングしているメトリクスにアラームを設定することもできます。**[Graphed metrics]** (グラフ化したメトリクス) タブで、**[Actions]** (アクション) 列にある **[Create alarm]** (アラームを作成) アイコンをクリックします。**[Create alarm]** (アラームを作成) アイコンは小さなベルです。詳細および通知オプションについては、「*Amazon CloudWatch ユーザーガイド*」の「[メトリクス数式に基づく CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html)」と「[アラームの変更をユーザーに通知する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html)」を参照してください。
[GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) および [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) を使用して、Metric Math によって計算し、その出力に基づいてアラームを作成することもできます。
# スケジュールされたアクションを使用して Amazon ECS の予測値を上書きする
予測計算では考慮できない将来のアプリケーション要件に関する追加情報がある場合があります。例えば、予測の計算では、今後のマーケティングイベントに必要なタスクが過小評価される可能性があります。スケジュールされたアクションを使用して、将来の期間中の予測を一時的に上書きできます。スケジュールされたアクションは、繰り返し実行することも、1 回限りの需要変動がある特定の日時に実行することもできます。
例えば、予測される数よりも多いタスク数でスケジュールされたアクションを作成できます。実行時に、Amazon ECS はサービス内の最小タスク数を更新します。予測スケーリングはタスクの数に合わせて最適化するので、予測値を超える最小タスクの数でスケジュールされたアクションが尊重されます。これにより、タスクの数が予想を下回らないようになります。予測の上書きを停止するには、2 番目にスケジュールされたアクションを使用して、最小タスク数を元の設定に戻します。
次の手順では、将来の期間中の予測を上書きするステップを示します。
**Topics**
+ [ステップ 1: (オプション) 時系列データを分析する](#analyzing-time-series-data)
+ [ステップ 2: 2 つのスケジュールされたアクションを作成する](#scheduling-capacity)
**重要**
このトピックでは、予測を上書きして、予測よりも大きなキャパシティにスケールしようとしていることを前提としています。予測スケーリングポリシーの干渉なしに一時的にタスク数を減らす必要がある場合は、代わりに *予測のみ* モードを使用します。予測のみモードでは、予測スケーリングは予測を生成し続けますが、自動的にタスク数を増やすことはありません。その後、リソース使用率をモニタリングし、必要に応じてタスク数を手動で減らすことができます。
## ステップ 1: (オプション) 時系列データを分析する
まず、予測時系列データを分析します。これはオプションのステップですが、予測の詳細を理解したい場合に役立ちます。
1. **予測を取得する**
予測が作成されたら、予測の特定の期間をクエリできます。このクエリの目的は、特定の期間の時系列データの完全なビューを取得することです。
クエリには、将来の予測データを最大 2 日間含めることができます。予測スケーリングをしばらく使用している場合は、過去の予測データにアクセスすることもできます。ただし、開始時刻と終了時刻の間の最大期間は 30 日間です。
[get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI コマンドを使用して予測を取得するには、コマンドに次のパラメータを指定します。
+ `resource-id` パラメータにクラスター名を入力します。
+ ポリシーの名前を `--policy-name` パラメータに入力します。
+ 開始時刻を `--start-time` パラメータに入力して、指定した時刻以降の予測データのみが返されるようにします。
+ 終了時刻を `--end-time` パラメータに入力して、指定された時刻より前の予測データのみが返されるようにします。
```
aws application-autoscaling get-predictive-scaling-forecast \
--service-namespace ecs \
--resource-id service/MyCluster/test \
--policy-name cpu40-predictive-scaling-policy \
--scalable-dimension ecs:service:DesiredCount \
--start-time "2021-05-19T17:00:00Z" \
--end-time "2021-05-19T23:00:00Z"
```
成功すると、コマンドは次の例のようなデータを返します。
```
{
"LoadForecast": [
{
"Timestamps": [
"2021-05-19T17:00:00+00:00",
"2021-05-19T18:00:00+00:00",
"2021-05-19T19:00:00+00:00",
"2021-05-19T20:00:00+00:00",
"2021-05-19T21:00:00+00:00",
"2021-05-19T22:00:00+00:00",
"2021-05-19T23:00:00+00:00"
],
"Values": [
153.0655799339254,
128.8288551285919,
107.1179447150675,
197.3601844551528,
626.4039934516954,
596.9441277518481,
677.9675713779869
],
"MetricSpecification": {
"TargetValue": 40.0,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"
}
}
}
],
"CapacityForecast": {
"Timestamps": [
"2021-05-19T17:00:00+00:00",
"2021-05-19T18:00:00+00:00",
"2021-05-19T19:00:00+00:00",
"2021-05-19T20:00:00+00:00",
"2021-05-19T21:00:00+00:00",
"2021-05-19T22:00:00+00:00",
"2021-05-19T23:00:00+00:00"
],
"Values": [
2.0,
2.0,
2.0,
2.0,
4.0,
4.0,
4.0
]
},
"UpdateTime": "2021-05-19T01:52:50.118000+00:00"
}
```
応答には `LoadForecast` と `CapacityForecast` の 2 つの予測が含まれています。`LoadForecast` は、時間ごとの負荷予測を示します。`CapacityForecast` は、40.0 の `TargetValue` (平均 CPU 使用率 40%) を維持しながら予測された負荷を処理するために時間単位で必要なキャパシティーの予測値を示します。
1. **ターゲット期間を特定する**
1 回限りの需要変動が発生する時間または時間範囲を特定します。予測に表示される日付と時刻は UTC であることに注意してください。
## ステップ 2: 2 つのスケジュールされたアクションを作成する
次に、アプリケーションの負荷が予測を上回る特定の期間に、2 つのスケジュールされたアクションを作成します。例えば､マーケティングイベントで一時的にトラフィックがサイトに流入する場合は、1 回限りのアクションをスケジュールして、開始時に最小キャパシティーを更新できます。次に、イベント終了時に最小キャパシティーを元の設定に戻す別のアクションをスケジュールします。
1. コンソールを[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)で開きます。
1. **[クラスター]** ページで、クラスターを選択します。
1. [クラスターの詳細] ページの **[サービス]** セクションで、サービスを選択します。
[サービス詳細] ページが表示されます。
1. **[サービスの自動スケーリング]** を選択します。
[ポリシー] ページが表示されます。
1. **[スケジュールされたアクション]** を選択し、**[作成]** を選択します。
**[スケジュールアクションの作成]** ページが表示されます。
1. **バケット名**に、一意の名前を入力します。
1. [**Time zone (タイムゾーン)**] でタイムゾーンを選択。
リストされているすべてのタイムゾーンは、IANA タイムゾーンデータベースから取得されます。詳細については、「[List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)」を参照してください。
1. **[開始時刻]** で、アクションが開始される **[日付]** と **[時刻]** を入力します。
1. [繰り返し] で、[1 回] を選択してください。********
1. **[タスク調整]** の [最小] には、タスクの最大数以下の値を入力します。
1. **[スケジュールされたアクションの作成]** を選択してください。
[ポリシー] ページが表示されます。
1. イベントの終了時に、最小タスク数を元の設定に戻すように、2 番目にスケジュールされたアクションを設定します。予測スケーリングでは、**[最小]** に設定した値が予測値未満の場合のみ、タスク数をスケーリングできます。
**1 回限りのイベントに対して 2 つのスケジュールされたアクションを作成するには (AWS CLI)**
AWS CLI を使用してスケジュールされたアクションを作成するには、[put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) コマンドを使用します。
例えば、5 月 19 日の午後 5 時から 8 時間、最小キャパシティーを 3 インスタンスに維持するスケジュールを定義しましょう。以下のコマンドは、このシナリオを実装する方法を示しています。
最初の [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) コマンドは、2021 年 5 月 19 日の午後 5 時 (UTC) に指定された Auto Scaling グループの最小キャパシティーを更新するように Amazon EC2 Auto Scaling に指示します。
```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \
--auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3
```
2 番目のコマンドは、2021 年 5 月 20 日の午前 1 時 (UTC) にグループの最小キャパシティーを 1 に設定するように Amazon EC2 Auto Scaling に指示します。
```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \
--auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1
```
これらのスケジュールされたアクションを Auto Scaling グループに追加すると、Amazon EC2 Auto Scaling は次の処理を実行します。
+ 2021 年 5 月 19 日の午後 5 時 (UTC) に、最初にスケジュールされたアクションが実行されます。グループのインスタンスが 3 未満である場合、グループは 3 インスタンスにスケールアウトされます。この時刻以降の 8 時間の間、予測キャパシティーが実際のキャパシティーよりも大きい場合、または動的スケーリングポリシーが有効な場合、Amazon EC2 Auto Scaling は引き続きスケールアウトできます。
+ 2021 年 5 月 20 日の午前 1 時 (UTC) に、2 番目のスケジュールされたアクションが実行されます。これにより、イベントの終了時に最小キャパシティーが元の設定に戻ります。
### 繰り返し起こるスケジュールに基づくスケーリング
毎週同じ期間の予測を上書きするには、2 つのスケジュールされたアクションを作成し、cron 式を使用して日時のロジックを指定します。
この cron 式のフォーマットは、スペースで区切られた 5 つのフィールド ([分] [時間] [日] [月] [曜日]) で構成されます。フィールドには、特殊文字を含む任意の許容される値を含めることができます。
例えば、次の cron 式は、毎週火曜日の午前 6:30 にアクションを実行します。アスタリスクは、フィールドのすべての値を照合するワイルドカードとして使用されます。
```
30 6 * * 2
```
### 関連情報
スケジュールされたアクションを管理する方法の詳細については、「[スケジュールされたアクションを使用して Amazon ECS サービスをスケールする](service-autoscaling-schedulescaling.md)」を参照してください。
# Amazon ECS のカスタムメトリクスを使用した高度な予測スケーリングポリシー
予測スケーリングポリシーで、事前定義されたメトリクスまたはカスタムメトリクスを使用できます。カスタムメトリクスは、CPU、メモリなどの事前定義されたメトリクスが、アプリケーションの負荷を十分に記述するには不十分である場合に有用です。
カスタムメトリクスを使用して予測スケーリングポリシーを作成するときは、AWS が提供するその他の CloudWatch メトリクスを指定できます。または、自分で定義して公開するメトリクスを指定することもできます。メトリクス計算を使用して既存のメトリクスを集計し、AWS が自動的に追跡しない新しい時系列に変換することもできます。例としては、新しい合計や平均を計算してデータ内の値を結合すること (*集計*と呼ばれます) が挙げられます。結果のデータは*集計*と言います。
以下のセクションには、ポリシー用の JSON 構造を構築する方法のベストプラクティスと例が記載されています。
## 前提条件
予測スケーリングポリシーにカスタムメトリクスを追加するには、`cloudwatch:GetMetricData` 許可が必要です。
AWS が提供するメトリクスの代わりに独自のメトリクスを指定するには、まずそのメトリクスを CloudWatch に発行する必要があります。詳細については、「Amazon CloudWatch ユーザーガイド」の「[カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)」を参照してください。
独自のメトリクスを発行するときは、少なくとも 5 分間隔の頻度でデータポイントを発行するようにしてください。データポイントは、必要な期間の長さに基づいて CloudWatch から取得されます。例えば、負荷メトリクスの指定では、時間単位のメトリクスを使用してアプリケーションの負荷を測定します。CloudWatch は、発行されたメトリクスデータを使用して、各 1 時間の期間内にタイムスタンプがあるすべてのデータポイントを集計することにより、各 1 時間の期間に対して単一のデータ値を提供します。
## ベストプラクティス
次のベストプラクティスは、カスタムメトリクスをより効果的に使用するのに役立ちます。
+ 負荷メトリクス仕様で最も有用なメトリクスは、Auto Scaling グループ全体の負荷を表すメトリクスです。
+ スケーリングメトリクス仕様のスケールに最も有用なメトリクスは、タスクメトリクスごとの平均スループットまたは使用率です。
+ ターゲット使用率は、スケーリングメトリクスのタイプと一致する必要があります。例えば、CPU 使用率を使用するポリシー設定の場合、これはパーセンテージのターゲットです。
+ これらの推奨事項に従わない場合、予測される将来の時系列の値は、多くの場合、誤りになります。データが正しいことを確認するために、コンソールで予測値を表示できます。または、予測スケーリングポリシーを作成した後、[GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html) API を呼び出して返された `LoadForecast` オブジェクトを検査します。
+ 予測スケーリングがアクティブスケーリングを開始する前に予測を評価できるように、予測のみモードで予測スケーリングを設定することを強くお勧めします。
## 制限事項
+ 1 つのメトリクス指定で最大 10 個のメトリクスのデータポイントをクエリできます。
+ この制限に関しては、1 つの式は 1 つのメトリクスとしてカウントされます。
## カスタムメトリクスを使用した予測スケーリングポリシーのトラブルシューティング
カスタムメトリクスの使用中に問題が発生した場合は、次の操作を実行することをお勧めします。
+ 検索式の使用中にブルー/グリーンデプロイで問題が発生した場合は、完全一致ではなく部分一致を検索する検索式を作成してください。また、クエリが特定のアプリケーションで実行されている Auto Scaling グループのみを検索していることも確認する必要があります。検索式の構文の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch 検索式の構文](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html)」を参照してください。
+ [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) コマンドは、スケーリングポリシーの作成時に式を検証します。ただし、このコマンドでは、検出されたエラーの正確な原因を特定できない可能性があります。問題を解決するには、[get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html) コマンドへのリクエストからの応答で受け取ったエラーをトラブルシューティングします。CloudWatch コンソールから式をトラブルシューティングすることもできます。
+ `MetricDataQueries` で SUM() のような数学関数を使用せずに、独自の SEARCH() 関数を指定する場合、`ReturnData` に `false` を指定する必要があります。これは、検索式が複数の時系列を返す可能性がある一方、数式に基づくメトリクス指定は 1 つの時系列しか返すことができないためです。
+ 検索式に含まれるすべてのメトリクスは、同じ解像度である必要があります。
# Amazon ECS を使用した予測スケーリングカスタムメトリクス用の JSON の構築
以下のセクションには、CloudWatch からのデータをクエリするための予測スケーリングを設定する方法の例が記載されています。このオプションの設定には 2 つの異なる手法あり、予測スケーリングポリシーの JSON を構築するために使用する形式は、選択される手法の影響を受けます。メトリクス計算を使用する場合は、実行されるメトリクス計算に基づいて JSON の形式がさらに多様化します。
1. AWS が提供するその他の CloudWatch メトリクス、またはユーザーが CloudWatch に発行するメトリクスから直接データを取得するポリシーを作成するには、「[AWS CLI を使用したカスタム負荷メトリクスとスケーリングメトリクスを用いた予測スケーリングポリシーの例](#predictive-scaling-custom-metrics-example1)」を参照してください。
## AWS CLI を使用したカスタム負荷メトリクスとスケーリングメトリクスを用いた予測スケーリングポリシーの例
AWS CLI でカスタムロードメトリクスとスケーリングメトリクスを使用する予測スケーリングポリシーを作成するには、`config.json` という名前の JSON ファイルに `--predictive-scaling-configuration` の引数を保存します。
カスタムメトリクスの追加は、以下の例にある置き換え可能な値を独自のメトリクスとターゲット使用率に置き換えることによって開始します。
```
{
"MetricSpecifications": [
{
"TargetValue": 50,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Id": "scaling_metric",
"MetricStat": {
"Metric": {
"MetricName": "MyUtilizationMetric",
"Namespace": "MyNameSpace",
"Dimensions": [
{
"Name": "MyOptionalMetricDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}
]
},
"Stat": "Average"
}
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_metric",
"MetricStat": {
"Metric": {
"MetricName": "MyLoadMetric",
"Namespace": "MyNameSpace",
"Dimensions": [
{
"Name": "MyOptionalMetricDimensionName",
"Value": "MyOptionalMetricDimensionValue"
}
]
},
"Stat": "Sum"
}
}
]
}
}
]
}
```
詳細については、「*Amazon EC2 Auto Scaling API Reference*」の「[MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html)」を参照してください。
**注記**
以下は、CloudWatch メトリクスのメトリクス名、名前空間、ディメンション、および統計を見つけるために役立つ追加のリソースです。
AWS のサービスで使用可能なメトリクスの詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)」を参照してください。
CloudWatch メトリクスの正確なメトリクス名、名前空間、ディメンション (該当する場合) を AWS CLI で取得するには、「[list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html)」を参照してください。
このポリシーを作成するには、以下の例にあるように、JSON ファイルを入力として使用して [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行します。
```
aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
```
成功した場合、このコマンドはポリシーの Amazon リソースネーム (ARN) を返します。
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy",
"Alarms": []
}
```
# Metric Math 式を使用する
以下のセクションでは、ポリシー内の予測スケーリングポリシーで Metric Math を使用する方法について説明します。
## Metric Math について
既存のメトリクスデータの集計だけを行いたい場合は、CloudWatch Metric Math により、別のメトリクスを CloudWatch に発行する手間とコストを節約できます。AWS が提供するメトリクスはすべて使用できます。また、アプリケーションの一部として定義したメトリクスを使用することもできます。
詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[Amazon CloudWatch メトリクス数学の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)」を参照してください。
予測スケーリングポリシーで Metric Math の数式を使用する場合は、次の点を考慮してください。
+ Metric Math 演算では、メトリクスのメトリクス名、名前空間、ディメンションのキーと値のペアの一意の組み合わせのデータポイントを使用します。
+ 任意の算術演算子 (\$1 - \$1 / ^)、統計関数 (AVG や SUM など)、または CloudWatch がサポートするその他の関数を使用できます。
+ 数式の関係式では、メトリクスと他の数式の結果の両方を使用できます。
+ Metric Math の数式は、さまざまな集計で構成できます。ただし、最終的な集計結果として、`Average` をスケーリングメトリクスに使用し、`Sum` を負荷メトリクスに使用するのがベストプラクティスです。
+ メトリクスの指定で使用される数式はすべて、最終的に単一の時系列を返す必要があります。
Metric Math を使用するには、次の操作を実行します。
+ 1 つまたは複数の CloudWatch メトリクスを選択します。次に、数式を作成します。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[Amazon CloudWatch メトリクス数学の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)」を参照してください。
+ CloudWatch コンソールまたは CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API を使用して、Metric Math の数式が有効であることを確認します。
## メトリクス計算を使用してメトリクスを組み合わせる予測スケーリングポリシーの例 (AWS CLI)
場合によっては、メトリクスを直接指定するのではなく、まず何らかの方法でそのデータを処理する必要がある場合があります。例えば、Amazon SQS キューから作業を取り出すアプリケーションがあり、キュー内の項目数を予測スケーリングの基準として使用したいとします。キューにあるメッセージの数だけでは、必要なインスタンスの数は定義されません。インスタンスごとのバックログを計算するために使用できるメトリクスを作成するには、さらに多くの作業が必要です。
このシナリオの予測スケーリングポリシー例を次に示します。Amazon SQS `ApproximateNumberOfMessagesVisible` メトリクス (キューから取得可能なメッセージの数) に基づくスケーリングメトリクスおよび負荷メトリクスを指定します。Amazon EC2 Auto Scaling `GroupInServiceInstances` メトリクスと、スケーリングメトリクスのインスタンスごとのバックログを計算するための数式も使用します。
```
aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
--policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
--service-namespace ecs \
--resource-id service/MyCluster/test \
"MetricSpecifications": [
{
"TargetValue": 100,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Label": "Get the queue size (the number of messages waiting to be processed)",
"Id": "queue_size",
"MetricStat": {
"Metric": {
"MetricName": "ApproximateNumberOfMessagesVisible",
"Namespace": "AWS/SQS",
"Dimensions": [
{
"Name": "QueueName",
"Value": "my-queue"
}
]
},
"Stat": "Sum"
},
"ReturnData": false
},
{
"Label": "Get the group size (the number of running instances)",
"Id": "running_capacity",
"MetricStat": {
"Metric": {
"MetricName": "GroupInServiceInstances",
"Namespace": "AWS/AutoScaling",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Stat": "Sum"
},
"ReturnData": false
},
{
"Label": "Calculate the backlog per instance",
"Id": "scaling_metric",
"Expression": "queue_size / running_capacity",
"ReturnData": true
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_metric",
"MetricStat": {
"Metric": {
"MetricName": "ApproximateNumberOfMessagesVisible",
"Namespace": "AWS/SQS",
"Dimensions": [
{
"Name": "QueueName",
"Value": "my-queue"
}
],
},
"Stat": "Sum"
},
"ReturnData": true
}
]
}
}
]
}
```
この例では、ポリシーの ARN が返されます。
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy",
"Alarms": []
}
```