翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon EC2 Auto Scaling の予測スケーリング
予測スケーリングは、負荷の履歴データを分析して、トラフィックフローの日ごとまたは週ごとのパターンを検出することで機能します。この情報を使用して将来のキャパシティのニーズを予測し、Amazon EC2 Auto Scaling が予想される負荷に合わせて Auto Scaling グループのキャパシティをプロアクティブに増やすことができるようにします。
予測スケーリングは、次のような状況に適しています。
+ 通常の営業時間にはリソースの使用率が高く、夜間や週末はリソースの使用率が低いといったサイクルがあるトラフィック
+ バッチ処理、テスト、定期的なデータ分析など、オンとオフを繰り返すワークロードパターン
+ 初期化に時間がかかり、スケールアウトイベント中のアプリケーションのパフォーマンスにレイテンシーが顕著な影響を与えるアプリケーション
一般に、トラフィックが増加する規則的なパターンがあり、アプリケーションの初期化に長い時間がかかる場合は、予測スケーリングの使用を検討する必要があります。反応的な性質を持つ動的スケーリングのみを使用する場合と比較して、予測スケーリングを使用すると、予測される負荷に先立ってキャパシティーを起動することで、より迅速にスケーリングできます。予測スケーリングでは、キャパシティを過剰にプロビジョニングする必要がないので、EC2 課金の費用を節約できる可能性もあります。
例えば、営業時間中の使用率が高く、夜間の使用量が少ないアプリケーションを考えてみましょう。各営業日の開始時に、予測スケーリングにより、トラフィックが最初に流入する前にキャパシティーを追加できます。これにより、使用率の低い期間から高い使用率の期間に移行するときに、アプリケーションの高可用性とパフォーマンスを維持するのに役立ちます。トラフィックの変化に動的スケーリングが反応するのを待つ必要はありません。また、アプリケーションの負荷パターンを確認し、スケジュールされたスケーリングを使用して適切なキャパシティーをスケジュールしようと時間を費やす必要はありません。
**Topics**
+ [予測スケーリングの仕組み](predictive-scaling-policy-overview.md)
+ [予測スケーリングポリシーを作成する](predictive-scaling-create-policy.md)
+ [予測スケーリングポリシーの評価](predictive-scaling-graphs.md)
+ [予測を上書きする](predictive-scaling-overriding-forecast-capacity.md)
+ [カスタムメトリクスを使用する](predictive-scaling-customized-metric-specification.md)
# 予測スケーリングの仕組み
このトピックでは、予測スケーリングの仕組みと、予測スケーリングポリシーを作成するときに考慮すべき点について説明します。
**Topics**
+ [仕組み](#how-predictive-scaling-works)
+ [最大キャパシティの制限](#predictive-scaling-maximum-capacity-limit)
+ [考慮事項](#predictive-scaling-considerations)
+ [サポート対象のリージョン](#predictive-scaling-regions)
## 仕組み
予測スケーリングを使用するには、モニタリングおよび分析する CloudWatch メトリクスを指定する予測スケーリングポリシーを作成します。予測スケーリングが将来の値の予測を開始するには、このメトリクスに 24 時間以上のデータが必要です。
ポリシーを作成すると、予測スケーリングは最長過去 14 日間のメトリクスデータの分析を開始し、パターンを特定します。この分析を使用して、今後 48 時間のキャパシティ必要量の時間ごとの予測を生成します。予測は、最新の CloudWatch データを使用して 6 時間ごとに更新されます。新しいデータを取得すると、予測スケーリングは将来の予測の正確性を継続的に向上させることができます。
最初に予測スケーリングを有効にしたときは、*予測のみ*モードで実行されます。このモードでは、キャパシティ予測が生成されますが、実際には、それらの予測に基づいて Auto Scaling グループをスケールすることはありません。これにより、予測の正確性と適合性を評価できます。`GetPredictiveScalingForecast` API オペレーションまたは AWS マネジメントコンソールを使用して、予測データを表示できます。
予測データを確認し、そのデータに基づいてスケーリングを開始することを決定したら、スケーリングポリシーを*予測とスケーリング*のモードに切り替えます。このモードでは、次のようになります。
+ 予測で負荷の増加が予想される場合、Amazon EC2 Auto Scaling はスケールアウトによってキャパシティを増やします。
+ 予測で負荷の減少が予想される場合、キャパシティを削除するためのスケールインは行いません。不要になったキャパシティを削除する場合は、動的スケーリングポリシーを作成する必要があります。
デフォルトでは、Amazon EC2 Auto Scaling は、1 時間ごとの予測に基づいて、その時間の開始時に Auto Scaling グループをスケールします。必要に応じて、`PutScalingPolicy` API オペレーションの `SchedulingBufferTime` プロパティ、または AWS マネジメントコンソールの **[起動前のインスタンス]** 設定を使用して、より早い開始時刻を指定できます。これにより、Amazon EC2 Auto Scaling は予測された需要よりも先に新しいインスタンスを起動し、インスタンスが立ち上がってトラフィックを処理する準備が整うまでの時間を確保します。
予測された需要より前に新しいインスタンスを起動できるように、Auto Scaling グループの*デフォルトのインスタンスウォームアップ*を有効にすることを強くお勧めします。これは、スケールアウトアクティビティの後で、動的スケーリングポリシーがキャパシティを減らす必要があることを示している場合でも、Amazon EC2 Auto Scaling がスケールインしない期間を指定します。これにより、新しく起動したインスタンスが、スケールインオペレーションの対象となる前に、増加したトラフィックの処理を開始するのに十分な時間を確保できます。詳細については、「[Auto Scaling グループに対するインスタンスのデフォルトウォームアップを設定する](ec2-auto-scaling-default-instance-warmup.md)」を参照してください。
## 最大キャパシティの制限
Auto Scaling グループには、グループに対して起動できる EC2 インスタンスの最大数を制限する最大キャパシティ設定があります。デフォルトでは、スケーリングポリシーが設定されている場合、最大キャパシティを超えてキャパシティを増やすことはできません。
それ以外の方法として、予測キャパシティが Auto Scaling グループの最大キャパシティに近づいた場合や、それを超えた場合に、グループの最大キャパシティを自動的に増やすことができます。この動作を有効にするには、`PutScalingPolicy` API オペレーションの `MaxCapacityBreachBehavior` および `MaxCapacityBuffer` プロパティ、または AWS マネジメントコンソールの **[最大キャパシティーの動作]** 設定を使用します。
**警告**
最大キャパシティを自動的に増やす場合は注意してください。これにより、増加した最大キャパシティがモニタリングおよび管理されていない場合、意図したよりも多くのインスタンスが起動される可能性があります。その後、増加した最大キャパシティは、手動で更新するまで Auto Scaling グループの新しい通常の最大キャパシティになります。最大キャパシティは、自動的に元の最大キャパシティまで減少しません。
## 考慮事項
+ 予測スケーリングがワークロードに適しているかどうかを確認します。ワークロードは、曜日または時刻に固有の定期的な負荷パターンを示す場合に、予測スケーリングに適しています。これを確認するには、*予測のみ*モードで予測スケーリングポリシーを設定し、コンソールの推奨事項を参照してください。Amazon EC2 Auto Scaling は、潜在的なポリシーのパフォーマンスに関する観察内容に基づいた推奨事項を提供します。予測スケーリングがアプリケーションをアクティブにスケーリングできるようにする前に、予測および推奨事項を評価します。
+ 予測スケーリングでは、予測を開始するには 24 時間以上の履歴データが必要です。ただし、履歴データが 2 週間あれば予測がより効果的です。新しい Auto Scaling グループを作成し、古いグループを削除してアプリケーションを更新する場合、予測スケーリングが再び予測の生成を開始するには、新しい Auto Scaling グループに 24 時間の履歴負荷データが必要です。カスタムメトリクスを使用して新旧の Auto Scaling グループ全体のメトリクスを集計できます。そうでない場合、より正確な予測を得るために数日かかる場合があります。
+ アプリケーションのすべての負荷を正確に表し、スケーリングが最も重要なアプリケーションの側面である負荷メトリクスを選択します。
+ 動的スケーリングを予測スケーリングと組み合わせて使用すると、アプリケーションの需要曲線に忠実に従って、トラフィックが少ない時間帯にスケールインし、トラフィックが予想を上回る場合はスケールアウトできます。複数のスケーリングポリシーがアクティブな場合、各ポリシーによって希望するキャパシティーが個別に決定され、希望するキャパシティーはそれらの最大値に設定されます。例えば、ターゲット追跡スケーリングポリシーでターゲット使用率を維持するために 10 インスタンスが必要で、予測スケーリングポリシーでターゲット使用率を維持するために 8 つのインスタンスが必要である場合、グループの希望するキャパシティーは 10 に設定されます。動的スケーリングを初めて使用する場合は、ターゲット追跡スケーリングポリシーを使用することをお勧めします。詳細については、「[Amazon EC2 Auto Scaling の動的スケーリング](as-scale-based-on-demand.md)」を参照してください。
+ 予測スケーリングの中核的な前提は、Auto Scaling グループが同種構成であり、すべてのインスタンスの容量が同じであるということです。これがグループに当てはまらない場合、予測された容量が正確ではない可能性が生じます。このため、[混合型のインスタンスグループ](ec2-auto-scaling-mixed-instances-groups.md)向けに予測スケーリングポリシーを作成するときは注意が必要です。キャパシティが同じではない異なるタイプのインスタンスがプロビジョニングされる可能性があるからです。以下は、予測された容量が不正確になる場合の例です。
+ 予測スケーリングポリシーが CPU 使用率に基づいているのに、各 Auto Scaling インスタンスの vCPU の数がインスタンスタイプに応じて異なる。
+ 予測スケーリングポリシーがネットワークインまたはネットワークアウトに基づいているのに、各 Auto Scaling インスタンスのネットワーク帯域幅のスループットがインスタンスタイプに応じて異なる。例えば、M5 と M5n インスタンスタイプは類似していますが、M5n インスタンスタイプの方が大幅に高いネットワークスループットを提供します。
## サポート対象のリージョン
+ 米国東部 (バージニア北部)
+ 米国東部 (オハイオ)
+ 米国西部 (北カリフォルニア)
+ 米国西部 (オレゴン)
+ アフリカ (ケープタウン)
+ アジアパシフィック (香港)
+ アジアパシフィック (ハイデラバード)
+ アジアパシフィック (ジャカルタ)
+ アジアパシフィック (メルボルン)
+ アジアパシフィック (ムンバイ)
+ アジアパシフィック (大阪)
+ アジアパシフィック (ソウル)
+ アジアパシフィック (シンガポール)
+ アジアパシフィック (シドニー)
+ アジアパシフィック (東京)
+ カナダ (中部)
+ カナダ西部 (カルガリー)
+ 中国 (北京)
+ 中国 (寧夏)
+ 欧州 (フランクフルト)
+ 欧州 (アイルランド)
+ 欧州 (ロンドン)
+ 欧州 (ミラノ)
+ 欧州 (パリ)
+ 欧州 (スペイン)
+ 欧州 (ストックホルム)
+ 欧州 (チューリッヒ)
+ イスラエル (テルアビブ)
+ 中東 (バーレーン)
+ 中東 (アラブ首長国連邦)
+ 南米 (サンパウロ)
+ AWS GovCloud (米国東部)
+ AWS GovCloud (米国西部)
# Auto Scaling グループの予測スケーリングポリシーを作成する
次の手順は、 AWS マネジメントコンソール または を使用して予測スケーリングポリシーを作成するのに役立ちます AWS CLI。
Auto Scaling グループが新しい場合に Amazon EC2 Auto Scaling がグループの予測を生成するには、そのグループが少なくとも 24 時間分のデータを提供する必要があります。
**Topics**
+ [予測スケーリングポリシーを作成する (コンソール)](#predictive-scaling-policy-console)
+ [予測スケーリングポリシーの作成 (AWS CLI)](#predictive-scaling-policy-aws-cli)
## 予測スケーリングポリシーを作成する (コンソール)
予測スケーリングポリシーを初めて作成する場合は、コンソールを使用して*予測のみ*モードで複数の予測スケーリングポリシーを作成することをお勧めします。これにより、異なるメトリクスおよび目標値の潜在的な影響をテストできます。Auto Scaling グループごとに複数の予測スケーリングポリシーを作成できますが、アクティブなスケーリングに使用できるポリシーは 1 つだけです。
### コンソールで予測スケーリングポリシーを作成する (事前定義されたメトリクス)
事前定義されたメトリクス (CPU、ネットワーク I/O、またはターゲットあたりの Application Load Balancer リクエスト数) を使用して予測スケーリングポリシーを作成するには、以下の手順を実行します。予測スケーリングポリシーを作成する最も簡単な方法は、事前定義されたメトリクスを使用することです。その代わりにカスタムメトリクスを使用する場合は、「[コンソールで予測スケーリングポリシーを作成する (カスタムメトリクス)](#create-a-predictive-scaling-policy-in-the-console-custom-metrics)」を参照してください。
**予測スケーリングポリシーを作成する**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
ページの下部に分割されたペインが開きます。
1. **[Automatic scaling]** (自動スケーリング) タブの **[Scaling policies]** (スケーリングポリシー) で、**[Create predictive scaling policy]** (予測スケーリングポリシーの作成) を選択します。
1. ポリシーの名前を入力します。
1. Amazon EC2 Auto Scaling にすぐにスケーリングを開始させるには、**[Scale based on forecast]** (予測に基づくスケーリング) をオンにします。
ポリシーを*予測のみ*モードにしておくには、**[Scale based on forecast]** (予測に基づくスケーリング) をオフのままにします。
1. **[Metrics]** (メトリクス) で、オプションのリストからメトリクスを選択します。オプションには、**[CPU]**、**[Network In]** (ネットワーク入力)、**[Network Out]** (ネットワーク出力)、**[Application Load Balancer request count]** (Application Load Balancer リクエスト数)、および **[Custom metric pair]** (カスタムメトリクスペア) が含まれます。
**[Application Load Balancer request count per target]** (ターゲットあたりの Application Load Balancer リクエスト数) を選択した場合、**[Target group]** (ターゲットグループ) のターゲットグループを選択します。**[Application Load Balancer request count per target]** (ターゲットあたりの Application Load Balancer リクエスト数) は、Application Load Balancer ターゲットグループを Auto Scaling グループにアタッチしている場合にのみサポートされます。
**[Custom metric pair]** (カスタムメトリクスペア) を選択した場合、**[Load metric]** (負荷のメトリクス) と **[Scaling metric]** (スケーリングのメトリクス) のドロップダウンリストから個々のメトリクスを選択します。
1. **[Target utilization]** (ターゲット使用率) に、Amazon EC2 Auto Scaling が維持する必要があるターゲット値を入力します。Amazon EC2 Auto Scaling は、平均使用率がターゲット使用率になるまで、または指定したインスタンスの最大数に達するまで、キャパシティーをスケールアウトします。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/predictive-scaling-create-policy.html)
1. (オプション) **[起動前のインスタンス]** で、予測によって負荷の増加が必要とされる際、どれくらい前にインスタンスを起動しておくかを選択します。
1. (オプション) **[Max capacity behavior]** (最大容量の動作) で、予測されたキャパシティーが定義された最大値を超える場合に、Amazon EC2 Auto Scaling がグループの最大容量を超えてスケールアウトできるようにするかどうかを選択します。この設定をオンにすると、トラフィックが最高になると予測される期間中にスケールアウトが実行されます。
1. (オプション) **[Buffer maximum capacity above the forecasted capacity]** (予測キャパシティーを超える最大キャパシティーのバッファ) で、予測キャパシティーが最大キャパシティーに近づいたか、それを超えたときに使用する追加キャパシティーを選択します。この値は予測キャパシティーに対する割合 (%) として指定されます。たとえば、バッファが 10 の場合、バッファは 10% です。従って、予測キャパシティーが 50 で最大キャパシティーが 40 の場合、有効な最大キャパシティーは 55 です。
これを 0 に設定すると、Amazon EC2 Auto Scaling は最大キャパシティーを超えてスケールすることはできても、予測キャパシティーまでとなり、それを超えることはできません。
1. **[Create predictive scaling policy]** (予測スケーリングポリシーを作成) を選択します。
### コンソールで予測スケーリングポリシーを作成する (カスタムメトリクス)
カスタムメトリクスを使用して予測スケーリングポリシーを作成するには、以下の手順を実行します。カスタムメトリクスには、CloudWatch が提供するその他メトリクス、またはユーザーが CloudWatch に発行するメトリクスを含めることができます。CPU、ネットワーク I/O、またはターゲットあたりの Application Load Balancer リクエスト数を使用するには、「[コンソールで予測スケーリングポリシーを作成する (事前定義されたメトリクス)](#create-a-predictive-scaling-policy-in-the-console)」を参照してください。
カスタムメトリクスを使用して予測スケーリングポリシーを作成するには、以下を実行する必要があります。
+ Amazon EC2 Auto Scaling が CloudWatch のメトリクスとやり取りできるようにする未処理のクエリを提供する必要があります。詳細については、「[カスタムメトリクスを使用した高度な予測スケーリングポリシー](predictive-scaling-customized-metric-specification.md)」を参照してください。Amazon EC2 Auto Scaling が CloudWatch からメトリクスデータを抽出できることを確実にするため、各クエリがデータポイントを返していることを確認します。これは、CloudWatch コンソール、または CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API 操作を使用して確認します。
**注記**
Amazon EC2 Auto Scaling コンソールの JSON エディタには、サンプル JSON ペイロードが提供されています。これらの例では、 が提供する他の CloudWatch メトリクス、 AWS または以前に CloudWatch に公開したメトリクスを追加するために必要なキーと値のペアのリファレンスを提供します。これらを開始点として使用してから、必要に応じてカスタマイズすることができます。
+ メトリクス計算を使用する場合は、独自のシナリオに適した JSON を手動で構築する必要があります。詳細については、「[Metric Math 式を使用する](using-math-expression-examples.md)」を参照してください。ポリシーでメトリクス計算を使用する前に、メトリクス数式に基づくメトリクスクエリが有効であり、単一の時系列を返すことを確認してください。これは、CloudWatch コンソール、または CloudWatch [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) API 操作を使用して確認します。
誤ったデータ (間違った Auto Scaling グループ名など) を提供することによってクエリでエラーが発生した場合、予測にはデータがありません。カスタムメトリクス問題のトラブルシューティングについては、「[予測スケーリングポリシーでのカスタムメトリクスに関する考慮事項](custom-metrics-troubleshooting.md)」を参照してください。
**予測スケーリングポリシーを作成する**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
ページの下部に分割されたペインが開きます。
1. **[Automatic scaling]** (自動スケーリング) タブの **[Scaling policies]** (スケーリングポリシー) で、**[Create predictive scaling policy]** (予測スケーリングポリシーの作成) を選択します。
1. ポリシーの名前を入力します。
1. Amazon EC2 Auto Scaling にすぐにスケーリングを開始させるには、**[Scale based on forecast]** (予測に基づくスケーリング) をオンにします。
ポリシーを*予測のみ*モードにしておくには、**[Scale based on forecast]** (予測に基づくスケーリング) をオフのままにします。
1. **[Metrics]** (メトリクス) では、**[Custom metric pair]** (カスタムメトリクスのペア) を選択します。
1. **[Load metric]** (ロードメトリクス) では、**[Custom CloudWatch metric]** (カスタム CloudWatch メトリクス) を選択してカスタムメトリクスを使用します。ポリシーのロードメトリクス定義が含まれる JSON ペイロードを構築し、それを JSON エディタボックスに貼り付けて、ボックス内にすでに入力されているペイロードを置き換えます。
1. **[Scaling metric]** (スケーリングメトリクス) では、**[Custom CloudWatch metric]** (カスタム CloudWatch メトリクス) を選択してカスタムメトリクスを使用します。ポリシーのスケーリングメトリクス定義が含まれる JSON ペイロードを構築し、それを JSON エディタボックスに貼り付けて、ボックス内にすでに入力されているペイロードを置き換えます。
1. (オプション) カスタム容量メトリクスを追加するには、**[Add custom capacity metric]** (カスタム容量メトリクスを追加する) のチェックボックスをオンにします。ポリシーの容量メトリクス定義が含まれる JSON ペイロードを構築し、それを JSON エディタボックスに貼り付けて、ボックス内にすでに入力されているペイロードを置き換えます。
このオプションを有効にする必要があるのは、容量メトリクスデータが複数の Auto Scaling グループにまたがる場合に容量の新しい時系列を作成するためのみです。この場合は、メトリクス計算を使用してデータを単一の時系列に集計する必要があります。
1. **[Target utilization]** (ターゲット使用率) に、Amazon EC2 Auto Scaling が維持する必要があるターゲット値を入力します。Amazon EC2 Auto Scaling は、平均使用率がターゲット使用率になるまで、または指定したインスタンスの最大数に達するまで、キャパシティーをスケールアウトします。
1. (オプション) **[起動前のインスタンス]** で、予測によって負荷の増加が必要とされる際、どれくらい前にインスタンスを起動しておくかを選択します。
1. (オプション) **[Max capacity behavior]** (最大容量の動作) で、予測されたキャパシティーが定義された最大値を超える場合に、Amazon EC2 Auto Scaling がグループの最大容量を超えてスケールアウトできるようにするかどうかを選択します。この設定をオンにすると、トラフィックが最高になると予測される期間中にスケールアウトが実行されます。
1. (オプション) **[Buffer maximum capacity above the forecasted capacity]** (予測キャパシティーを超える最大キャパシティーのバッファ) で、予測キャパシティーが最大キャパシティーに近づいたか、それを超えたときに使用する追加キャパシティーを選択します。この値は予測キャパシティーに対する割合 (%) として指定されます。たとえば、バッファが 10 の場合、バッファは 10% です。従って、予測キャパシティーが 50 で最大キャパシティーが 40 の場合、有効な最大キャパシティーは 55 です。
これを 0 に設定すると、Amazon EC2 Auto Scaling は最大キャパシティーを超えてスケールすることはできても、予測キャパシティーまでとなり、それを超えることはできません。
1. **[Create predictive scaling policy]** (予測スケーリングポリシーを作成) を選択します。
## 予測スケーリングポリシーの作成 (AWS CLI)
AWS CLI 次のように を使用して、Auto Scaling グループの予測スケーリングポリシーを設定します。各*ユーザー入力プレースホルダー*を独自の情報に置き換えます。
指定できる CloudWatch メトリクスの詳細については、「*Amazon EC2 Auto Scaling API リファレンス*」の「[PredictiveScalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html)」を参照してください。
### 例 1: 予測を作成するが、スケーリングしない予測スケーリングポリシー
次のポリシー例では、予測スケーリングに CPU 使用率メトリクスを使用し、ターゲット使用率が `40` である完全なポリシー設定を示しています。使用するモードを明示的に指定しない限り、デフォルトで `ForecastOnly` モードが使用されます。この設定を `config.json` という名前のファイルに保存してください。
```
{
"MetricSpecifications": [
{
"TargetValue": 40,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"
}
}
]
}
```
コマンドラインからこのポリシーを作成するには、以下の例にあるように、設定ファイルが指定された [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行します。
```
aws autoscaling put-scaling-policy --policy-name cpu40-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/cpu40-predictive-scaling-policy",
"Alarms": []
}
```
### 例 2: 予測とスケーリングを行う予測スケーリングポリシー
Amazon EC2 Auto Scaling の予測およびスケーリングを許可するポリシーには、`Mode` プロパティを `ForecastAndScale` の値で追加します。次の例は、Application Load Balancer リクエスト数メトリクスを使用するポリシー設定を示しています。ターゲット使用率は `1000` で、予測スケーリングは `ForecastAndScale` モードに設定されています。
```
{
"MetricSpecifications": [
{
"TargetValue": 1000,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ALBRequestCount",
"ResourceLabel": "app/my-alb/778d41231b141a0f/targetgroup/my-alb-target-group/943f017f100becff"
}
}
],
"Mode": "ForecastAndScale"
}
```
このポリシーを作成するには、次の例に示すように、設定ファイルを指定して [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行します。
```
aws autoscaling put-scaling-policy --policy-name alb1000-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:19556d63-7914-4997-8c81-d27ca5241386:autoScalingGroupName/my-asg:policyName/alb1000-predictive-scaling-policy",
"Alarms": []
}
```
### 例 3: 最大キャパシティーを超えてスケーリングできる予測スケーリングポリシー
次の例は、通常よりも高い負荷を処理する必要がある場合に、グループの最大サイズ制限を超えてスケーリングできるポリシーを作成する方法を示しています。デフォルトでは、Amazon EC2 Auto Scaling は、定義した最大キャパシティーを超えて EC2 のキャパシティーをスケーリングしません。しかし、パフォーマンスや可用性の問題を回避するために、キャパシティーを少し増やしてスケーリングすると便利な場合があります。
キャパシティーがグループの最大サイズに達している、または非常に近いと予測されるときに、Amazon EC2 Auto Scaling が追加のキャパシティーをプロビジョニングする余地を提供するには、次の例に示すように、`MaxCapacityBreachBehavior` および `MaxCapacityBuffer` プロパティを指定します。`MaxCapacityBreachBehavior` に値 `IncreaseMaxCapacity` を指定する必要があります。グループに含めることができるインスタンスの最大数は、`MaxCapacityBuffer` の値によって異なります。
```
{
"MetricSpecifications": [
{
"TargetValue": 70,
"PredefinedMetricPairSpecification": {
"PredefinedMetricType": "ASGCPUUtilization"
}
}
],
"MaxCapacityBreachBehavior": "IncreaseMaxCapacity",
"MaxCapacityBuffer": 10
}
```
この例では、10% のバッファ (`"MaxCapacityBuffer": 10`) を使用するようにポリシーが設定されています。したがって、予測キャパシティーが 50、最大キャパシティーが 40 の場合、有効な最大キャパシティーは 55 です。キャパシティーを最大キャパシティーを超えてスケーリングし、予測キャパシティーに等しくするが、予測キャパシティーを超えないようにするポリシーでは、バッファは 0 です (`"MaxCapacityBuffer": 0`)。
このポリシーを作成するには、次の例に示すように、設定ファイルを指定して [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行します。
```
aws autoscaling put-scaling-policy --policy-name cpu70-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:d02ef525-8651-4314-bf14-888331ebd04f:autoScalingGroupName/my-asg:policyName/cpu70-predictive-scaling-policy",
"Alarms": []
}
```
# 予測スケーリングポリシーの評価
予測スケーリングポリシーを使用して Auto Scaling グループをスケーリングする前に、Amazon EC2 Auto Scaling コンソールでポリシーの推奨事項やその他のデータを確認します。予測が正確であることがわかるまで、予測スケーリングポリシーが実際のキャパシティをスケーリングすることが好ましくないため、これは重要です。
Auto Scaling グループが新しい場合、Amazon EC2 Auto Scaling が最初の予測を作成するために 24 時間かかります。
Amazon EC2 Auto Scaling が予測を作成するとき、履歴データを使用します。Auto Scaling グループにまだ最新の履歴データがない場合、Amazon EC2 Auto Scaling は現在利用可能な履歴集計から作成された集計で予測を一時的にバックフィルすることがあります。予測は、ポリシーの作成日より最大 2 週間前にバックフィルされます。
**Topics**
+ [推奨事項の表示](#view-predictive-scaling-recommendations)
+ [モニタリンググラフの確認](#review-predictive-scaling-monitoring-graphs)
+ [CloudWatch によるメトリクスのモニタリング](monitor-predictive-scaling-cloudwatch.md)
## 予測スケーリングの推奨事項の表示
分析を効果的に行うには、Amazon EC2 Auto Scaling に比較対象となる予測スケーリングポリシーが少なくとも 2 つ必要です。(ただし、単一ポリシーの結果を確認することはできます) 複数のポリシーを作成するとき、1 つのメトリクスを使用するポリシーを異なるメトリクスを使用するポリシーと比較して評価できます。異なる目標値およびメトリクスの組み合わせによる影響を評価することもできます。予測スケーリングポリシーが作成された後、Amazon EC2 Auto Scaling は、どのポリシーがグループのスケーリングに適しているかについて、すぐに評価を開始します。
**Amazon EC2 Auto Scaling コンソールで推奨事項を表示するには**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
ページの下部にスプリットペインが開きます。
1. **[予測スケーリングポリシー]** の **[Auto Scaling]** タブで、ポリシーの詳細および推奨事項を表示できます。推奨事項は、予測スケーリングポリシーを使用しない場合よりも優れた性能を発揮するかどうかについて説明します。
予測スケーリングポリシーがグループに適切かどうかが不明な場合、**[可用性への影響]** 列および **[コストへの影響]** 列を確認し、適切なポリシーを選択してください。各列の情報は、ポリシーの影響について説明します。
+ **[可用性への影響]**: ポリシーを使用しない場合と比較し、ワークロードを処理するために十分なインスタンスをプロビジョニングすることにより、ポリシーが可用性への悪影響を回避できるかどうかについて説明します。
+ **[コストへの影響]**: ポリシーを使用しない場合と比較し、インスタンスをオーバープロビジョニングしないことにより、ポリシーがコストへの悪影響を回避できるかどうかについて説明します。過度にオーバープロビジョニングすることにより、インスタンスが十分に活用されない、あるいはアイドル状態になり、コストへの影響が増す一方です。
複数のポリシーがある場合、より低コストで最も可用性のメリットが高いポリシーの名前の横に **[最良予測]** タグが表示されます。可用性への影響がより重視されます。
1. (オプション) 推奨結果の必要な期間を選択するには、**[評価期間]** のドロップダウンから **[2 日]**、**[1 週間]**、**[2 週間]**、**[4 週間]**、**[6 週間]**、**[8 週間]** のいずれから希望する値を選択します。デフォルトでは、評価期間は過去の 2 週間です。評価期間が長いほど、推奨結果のデータポイントが増えます。ただし、需要が非常に高い時期の後など、負荷パターンが変化した場合、データポイントを追加しても結果が改善されない可能性があります。この場合、最新のデータを見ることでより焦点を絞った推奨事項を得ることができます。
**注記**
推奨事項は **[予測のみ]** モードのポリシーに対してのみ生成されます。推奨機能は、評価期間中にポリシーが **[予測のみ]** モードのときにより効果的に機能します。ポリシーを **[予測とスケーリング]** モードで開始し、後で **[予測のみ]** モードに切り替える場合、そのポリシーの結果に偏りが生じる可能性があります。これは、ポリシーが既に実際のキャパシティに関与しているためです。
## 予測スケーリングのモニタリンググラフの確認
Amazon EC2 Auto Scaling コンソールでは、以前の日、週間、月の予測を確認し、時間の経過とともにポリシーがどの程度機能しているか視覚化できます。ポリシーが実際のキャパシティをスケーリングするかどうかを決定するとき、この情報を使用して予測の精度を評価できます。
**Amazon EC2 Auto Scaling コンソールで予測スケーリングのモニタリンググラフを表示するには**
1. **[予測スケーリングポリシー]** リストからポリシーを選択します。
1. **[モニタリング]** セクションでは、ポリシーの負荷およびキャパシティに関する過去および今後の予測を実際の値と比較できます。**[負荷]** グラフには、選択した負荷メトリクスの負荷予測および実際の値が表示されます。**[キャパシティ]** グラフには、ポリシーによって予測されたインスタンスの数が表示されます。実際に起動されたインスタンスの数も含まれます。縦線は履歴の値と今後の予測を区切っています。これらのグラフは、ポリシーの作成後にすぐ利用できます。
1. (オプション) グラフに表示される履歴データの量を変更するには、ページ上部の **[評価期間]** のドロップダウンから希望する値を選択します。評価期間はこのページのデータをはいかなる方法で変換することはありません。表示される履歴データの量のみを変更します。
次の画像は、予測が複数回適用された場合の **[負荷]** グラフおよび **[キャパシティ]** グラフを表示しています。予測スケーリングは、履歴の負荷データに基づいて負荷を予測します。アプリケーションが生成する負荷は、Auto Scaling グループの各インスタンスの CPU 使用率、ネットワークの入出力、受信したリクエスト、カスタムメトリクスのいずれかの合計として表されます。予測スケーリングは、負荷予測およびスケーリングメトリクスで達成したい目標の使用率に基き、今後のキャパシティのニーズを計算します。
![\[予測スケーリンググラフ\]](http://docs.aws.amazon.com/ja_jp/autoscaling/ec2/userguide/images/predictive-scaling-graphs.png)
****[負荷]** グラフのデータを比較**
各水平線は、1 時間間隔で報告される異なる一連のデータポイントを表しています。
1. **[実際に観測された負荷]** は、選択した負荷メトリクスの SUM 統計を使用し、過去の 1 時間ごとの合計負荷を表示します。
1. **[ポリシーによって予測される負荷]** は、1 時間ごとの負荷予測を表示します。この予測は過去 2 週間分の実際の負荷観測に基づいています。
****[キャパシティ]** グラフのデータの比較**
各水平線は、1 時間間隔で報告される異なる一連のデータポイントを表しています。
1. [GroupTotalInstances](ec2-auto-scaling-metrics.md#as-group-metrics) メトリクスが有効になっている場合、**[実際に観測されたキャパシティ]** は Auto Scaling グループの過去の実際のキャパシティを示します。このキャパシティは、他のスケーリングポリシーと、選択した期間中の最小グループサイズによって異なります。
1. **[ポリシーによって予測されるキャパシティ]** には、ポリシーが **[予測とスケーリング]** モードになっているときに各時間の開始時に予想されるベースラインキャパシティが表示されます。
1. **[推定必要容量は]** には、スケーリング指標を選択した目標値に維持するための理想的な容量を表示します。
1. **[最小容量]** には、Auto Scaling グループの最小容量を表示します。
1. **[最大容量]** には、Auto Scaling グループの最大容量を表示します。
推定される必要キャパシティを計算するため、最初は各インスタンスが指定された目標値で均等に使用されていると仮定します。実際には、インスタンスは均等に使用されません。ただし、使用率がインスタンス間で均等に分散されていると仮定することにより、必要なキャパシティの量を推定できます。次に、キャパシティ要件は、予測スケーリングポリシーに使用したスケーリングメトリクスに反比例するように計算されます。つまり、キャパシティが増加するにつれ、スケーリングメトリクスは同じ割合で減少します。例えば、キャパシティが 2 倍になった場合、スケーリングメトリクスは半減します。
推定された必要キャパシティの計算式は、次のとおりです。
`sum of (actualCapacityUnits*scalingMetricValue)/(targetUtilization)`
例えば、特定の時間の `actualCapacityUnits` (`10`) および `scalingMetricValue` (`30`) を算出します。その後、予測スケーリングポリシー (`60`) で指定した `targetUtilization` を使用し、同じ時間に推定される必要キャパシティを計算します。これは `5` の値を返します。これは、スケーリングメトリクスの目標値とは正反比例し、キャパシティを維持するために必要なキャパシティの推定量は 5 であることを意味します。
**注記**
コスト削減およびアプリケーションの可用性を調整および改善するため、さまざまな手段が用意されています。
ベースラインキャパシティに予測スケーリングを使用し、追加のキャパシティに動的スケーリングを使用します。動的スケーリングは予測スケーリングとは独立して動作し、現在の使用率に基づいてスケールインおよびスケールアウトを行います。まず、Amazon EC2 Auto Scaling は、動的スケーリングポリシーごとに推奨されるインスタンスの数を計算します。次に、最も多くのインスタンスを提供するポリシーに基づいてスケーリングします。
負荷が減少したときにスケールインを実行できるようにするには、Auto Scaling グループには、スケールイン部分を有効にした動的スケーリングポリシーが常に少なくとも 1 つ必要です。
最小キャパシティおよび最大キャパシティを制限しすぎないようにすることにより、スケーリングパフォーマンスを向上させることができます。推奨されるインスタンスの数が最小キャパシティおよび最大キャパシティの範囲に収まらないポリシーは、スケールインおよびスケールアウトができなくなります。
# CloudWatch による予測スケーリングメトリクスのモニタリング
必要に応じて、Amazon EC2 Auto Scaling コンソールではなく Amazon CloudWatch から予測スケーリングのモニタリングデータにアクセスすることもできます。予測スケーリングポリシーを作成すると、ポリシーは、今後の負荷とキャパシティを予測するために使用するデータを収集します。このデータは収集後、定期的かつ自動的に CloudWatch に保存されます。その後、CloudWatch を使用して、経時的なポリシーのパフォーマンスを視覚化できます。また、CloudWatch アラームを作成して、パフォーマンス指標が CloudWatch で定義した制限を超えて変化したときに通知させることもできます。
**Topics**
+ [履歴予測データの視覚化](#visualize-historical-forecast-data)
+ [Metric Math を使用して精度メトリクスを作成する](#create-accuracy-metrics)
## 履歴予測データの視覚化
CloudWatch では、予測スケーリングポリシーの負荷とキャパシティ予測データを表示できます。これは、他の CloudWatch メトリクスに対する予測を 1 つのグラフで視覚化する場合に便利です。また、経時的な傾向を確認するために、より長い期間を表示することもできます。最大 15 か月間の履歴メトリクスにアクセスして、ポリシーの動作をより的確に把握できます。
詳細については、「[予測スケーリングのメトリクスとディメンション](ec2-auto-scaling-metrics.md#predictive-scaling-metrics)」を参照してください。
**CloudWatch コンソールを使用して履歴予測データを表示する方法**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで、**[Metrics]** (メトリクス)、**[All metrics]** (すべてのメトリクス) の順に選択します。
1. **[Auto Scaling]** メトリクス名前空間を選択します。
1. 以下のオプションのいずれかを選択して、負荷予測またはキャパシティ予測メトリクスのいずれかを表示します。
+ **予測スケーリングの負荷予測**
+ **予測スケーリングのキャパシティ予測**
1. 検索フィールドに、予測スケーリングポリシー名または Auto Scaling グループ名を入力し、Enter キーを押して結果をフィルタリングします。
1. メトリクスをグラフ表示するには、メトリクスの横にあるチェックボックスを選択します。グラフの名前を変更するには、鉛筆アイコンを選択します。時間範囲を変更するには、事前定義済みの値を選択するか、[**custom**] を選択します。詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[メトリクスをグラフ化する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html)」を参照してください。
1. 統計を変更するには、[**Graphed metrics**] タブを選択します。列見出しまたは個々の値を選択し、続いて各種統計を選択します。各メトリクスの任意の統計を選択できますが、すべての統計が **PredictiveScalingLoadForecast** および **PredictiveScalingCapacityForecast** メトリクスに有用なわけではありません。例えば、**平均**、**最小**、**最大**統計は有用ですが、**合計**統計は有用ではありません。
1. グラフに別のメトリクスを追加するには、**[Browse]** (参照) で **[All]** (すべて) を選択し、追加したいメトリクスを見つけて、その横にあるチェックボックスをオンにします。最大 10 個のメトリクスを追加できます。
例えば、CPU 使用率の実際の値をグラフに追加するには、**[EC2]** 名前空間、**[By Auto Scaling Group]** (Auto Scaling グループ別) の順に選択します。次に、**[CPUUtilization]** メトリクス、および対象とする Auto Scaling グループのチェックボックスをオンにします。
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 を使用して、Amazon EC2 Auto Scaling が予測スケーリングのために生成するデータを各種の方法でグラフ化できます。これにより、ポリシーのパフォーマンスを経時的にモニタリングし、メトリクスの組み合わせを改善できるかどうかを把握することができます。
例えば、Metric Math 式を使用して、[平均絶対パーセント誤差](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error) (MAPE) をモニタリングできます。MAPE メトリクスは、予測値と、特定の予測期間中に観測された実際の値の差をモニタリングするのに役立ちます。MAPE の値の変化は、アプリケーションの性質が変化するにつれて、ポリシーのパフォーマンスが経時的に低下しているかどうかを示します。MAPE の増加は、予測値と実際の値の差が大きいことを示します。
**例: Metric Math 式**
このタイプのグラフを使用するには、次の例に示すような Metric Math 式を作成します。
```
{
"MetricDataQueries": [
{
"Expression": "TIME_SERIES(AVG(ABS(m1-m2)/m1))",
"Id": "e1",
"Period": 3600,
"Label": "MeanAbsolutePercentageError",
"ReturnData": true
},
{
"Id": "m1",
"Label": "ActualLoadValues",
"MetricStat": {
"Metric": {
"Namespace": "AWS/EC2",
"MetricName": "CPUUtilization",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
}
]
},
"Period": 3600,
"Stat": "Sum"
},
"ReturnData": false
},
{
"Id": "m2",
"Label": "ForecastedLoadValues",
"MetricStat": {
"Metric": {
"Namespace": "AWS/AutoScaling",
"MetricName": "PredictiveScalingLoadForecast",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": "my-asg"
},
{
"Name": "PolicyName",
"Value": "my-predictive-scaling-policy"
},
{
"Name": "PairIndex",
"Value": "0"
}
]
},
"Period": 3600,
"Stat": "Average"
},
"ReturnData": false
}
]
}
```
単一のメトリクスではなく、`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 によって計算し、その出力に基づいてアラームを作成することもできます。
# 予定されたアクションを使用して予測値を上書きする
予測計算では考慮できない将来のアプリケーション要件に関する追加情報がある場合があります。例えば、予測の計算では、今後のマーケティングイベントに必要なキャパシティーが過小評価される可能性があります。スケジュールされたアクションを使用して、将来の期間中の予測を一時的に上書きできます。スケジュールされたアクションは、繰り返し実行することも、1 回限りの需要変動がある特定の日時に実行することもできます。
例えば、予測されるキャパシティーを超える最小キャパシティーでスケジュールされたアクションを作成できます。実行中に、Amazon EC2 Auto Scaling は Auto Scaling グループの最小キャパシティーを更新します。予測スケーリングはキャパシティーを最適化するので、予測値を超える最小キャパシティーでスケジュールされたアクションが適用されます。これにより、キャパシティーが想定より少なくなるのを防ぎます。予測の上書きを停止するには、2 番目のスケジュールされたアクションを使用して、最小キャパシティーを元の設定に戻します。
次の手順では、将来の期間中の予測を上書きするステップを示します。
**Topics**
+ [ステップ 1: (オプション) 時系列データを分析する](#analyzing-time-series-data)
+ [ステップ 2: 2 つのスケジュールされたアクションを作成する](#scheduling-capacity)
**重要**
このトピックでは、予測を上書きして、予測よりも大きなキャパシティにスケールしようとしていることを前提としています。予測スケーリングポリシーの干渉なしに一時的にキャパシティを減らす必要がある場合は、代わりに*予測のみ*モードを使用します。予測のみモードでは、予測スケーリングは予測を生成し続けますが、自動的にキャパシティを増やすことはありません。その後、リソース使用率をモニタリングし、必要に応じてグループのサイズを手動で減らすことができます。手動スケーリングの詳細については、「[Amazon EC2 Auto Scaling の手動スケーリング](ec2-auto-scaling-scaling-manually.md)」を参照してください。
## ステップ 1: (オプション) 時系列データを分析する
まず、予測時系列データを分析します。これはオプションのステップですが、予測の詳細を理解したい場合に役立ちます。
1. **予測を取得する**
予測が作成されたら、予測の特定の期間をクエリできます。このクエリの目的は、特定の期間の時系列データの完全なビューを取得することです。
クエリには、将来の予測データを最大 2 日間含めることができます。予測スケーリングをしばらく使用している場合は、過去の予測データにアクセスすることもできます。ただし、開始時刻と終了時刻の間の最大期間は 30 日間です。
[get-predictive-scaling-forecast](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/get-predictive-scaling-forecast.html) AWS CLI コマンドを使用して予測を取得するには、 コマンドで次のパラメータを指定します。
+ Auto Scaling グループの名前を `--auto-scaling-group-name` パラメータに入力します。
+ ポリシーの名前を `--policy-name` パラメータに入力します。
+ 開始時刻を `--start-time` パラメータに入力して、指定した時刻以降の予測データのみが返されるようにします。
+ 終了時刻を `--end-time` パラメータに入力して、指定された時刻より前の予測データのみが返されるようにします。
```
aws autoscaling get-predictive-scaling-forecast --auto-scaling-group-name my-asg \
--policy-name cpu40-predictive-scaling-policy \
--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 回限りのイベントに対して 2 つのスケジュールされたアクションを作成するには (コンソール)**
1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/) でAmazon EC2 コンソールを開き、ナビゲーションペインで [**Auto Scaling グループ**] を選択します。
1. Auto Scaling グループの横にあるチェックボックスを選択します。
ページの下部にスプリットペインが開きます。
1. [**Automatic scaling (自動スケーリング)**] タブの [**Scheduled actions (スケジュールされたアクション)**] で、[**Create scheduled action (スケジュールされたアクションの作成)**] を選択します。
1. 次のスケジュールされたアクション設定を入力します。
1. スケジュールされたアクションに [**Name (名前)**] を入力します。
1. **[Min]** (最小) に、Auto Scaling グループの新しい最小キャパシティーを入力します。**[Min]** (最小) は、グループの最大サイズ以下である必要があります。**[Min]** (最小) の新しい値が、グループの最大サイズよりも大きい場合、**[Max]** (最大) を更新する必要があります。
1. [繰り返し] で、[1 回] を選択してください。********
1. [**Time zone (タイムゾーン)**] でタイムゾーンを選択。タイムゾーンが選択されていない場合は、デフォルトでは、`ETC/UTC` が使用されます。
1. **[Specific start time]** (特定の開始時刻) を定義します。
1. **[作成]** を選択します。
コンソールに Auto Scaling グループのスケジュールされたアクションが表示されます。
1. イベントの終了時に、最小キャパシティーを元の設定に戻すように、2 番目のスケジュールされたアクションを設定します。予測スケーリングでは、**[Min]** (最小) に設定した値が予測値未満の場合のみ、キャパシティーをスケーリングできます。
**1 回限りのイベントに対して 2 つのスケジュールされたアクションを作成するには (AWS CLI)**
を使用してスケジュールされたアクション AWS CLI を作成するには、[put-scheduled-update-group-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scheduled-update-group-action.html) コマンドを使用します。
例えば、5 月 19 日の午後 5 時から 8 時間、最小キャパシティーを 3 インスタンスに維持するスケジュールを定義しましょう。以下のコマンドは、このシナリオを実装する方法を示しています。
最初の [put-scheduled-update-group-action](https://awscli.amazonaws.com/v2/documentation/api/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 EC2 Auto Scaling のスケジュールされたスケーリング](ec2-auto-scaling-scheduled-scaling.md)」を参照してください。
# カスタムメトリクスを使用した高度な予測スケーリングポリシー
予測スケーリングポリシーでは、事前定義されたメトリクスまたはカスタムメトリクスを使用できます。カスタムメトリクスは、事前定義されたメトリクス (CPU、ネットワーク I/O、および Application Load Balancer のリクエスト数) ではアプリケーションの負荷が十分に反映できない場合に役立ちます。
カスタムメトリクスを使用して予測スケーリングポリシーを作成するときは、 が提供する他の CloudWatch メトリクスを指定するか AWS、自分で定義して公開するメトリクスを指定できます。また、Metric Math を使用して既存のメトリクスを集計し、自動的に追跡 AWS されない新しい時系列に変換することもできます。新しい合計や平均の計算など、データの値を組み合わせることを、*集計する*と言います。結果のデータは*集計*と言います。
以下のセクションには、ポリシー用の JSON 構造を構築する方法のベストプラクティスと例が記載されています。
**Topics**
+ [ベストプラクティス](#custom-metrics-best-practices)
+ [前提条件](#custom-metrics-prerequisites)
+ [カスタムメトリクス用の JSON の構築](construct-json-custom-metrics.md)
+ [予測スケーリングポリシーでのカスタムメトリクスに関する考慮事項](custom-metrics-troubleshooting.md)
+ [制限事項](#custom-metrics-limitations)
## ベストプラクティス
次のベストプラクティスは、カスタムメトリクスをより効果的に使用するのに役立ちます。
+ 負荷メトリクスの指定では、グループのキャパシティーに関係なく Auto Scaling グループ全体の負荷を表すメトリクスが最も有用です。
+ スケーリングメトリクスの指定では、インスタンスあたりの平均スループットまたは使用率のメトリクスでスケールするのが最も有用です。
+ スケーリングメトリクスは、キャパシティーに反比例する必要があります。つまり、Auto Scaling グループのインスタンス数が増加すると、スケーリングメトリクスはほぼ同じ割合で減少するようにします。予測スケーリングが期待どおりに動作するようにするには、負荷メトリクスとスケーリングメトリクスに強い相関がある必要もあります。
+ ターゲット使用率は、スケーリングメトリクスのタイプと一致する必要があります。CPU 使用率を使用するポリシー設定の場合、これはパーセンテージのターゲットです。リクエスト数やメッセージ数など、スループットを使用するポリシー設定の場合、これは任意の 1 分間のインスタンスあたりのリクエスト数やメッセージ数のターゲットです。
+ これらの推奨事項に従わない場合、予測される将来の時系列の値は、多くの場合、誤りになります。データが正しいことを確認するために、Amazon EC2 Auto Scaling コンソールで予測値を表示できます。または、予測スケーリングポリシーを作成した後、[GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_GetPredictiveScalingForecast.html) API を呼び出して返された `LoadForecast` および `CapacityForecast` オブジェクトを検査します。
+ 予測スケーリングがキャパシティーのアクティブスケーリングを開始する前に予測を評価できるように、予測のみモードで予測スケーリングを設定することを強くお勧めします。
## 前提条件
予測スケーリングポリシーにカスタムメトリクスを追加するには、`cloudwatch:GetMetricData` 許可が必要です。
AWS が提供するメトリクスの代わりに独自のメトリクスを指定するには、まずメトリクスを CloudWatch に発行する必要があります。詳細については、「Amazon CloudWatch ユーザーガイド」の「[カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)」を参照してください。
独自のメトリクスを発行するときは、少なくとも 5 分間隔の頻度でデータポイントを発行するようにしてください。Amazon EC2 Auto Scaling は、必要な期間の長さに基づいて CloudWatch からデータポイントを取得します。例えば、負荷メトリクスの指定では、時間単位のメトリクスを使用してアプリケーションの負荷を測定します。CloudWatch は、発行されたメトリクスデータを使用して、各 1 時間の期間内にタイムスタンプがあるすべてのデータポイントを集計することにより、各 1 時間の期間に対して単一のデータ値を提供します。
# カスタムメトリクス用の JSON の構築
以下のセクションには、CloudWatch からのデータをクエリするための予測スケーリングを設定する方法の例が記載されています。このオプションの設定には 2 つの異なる手法あり、予測スケーリングポリシーの JSON を構築するために使用する形式は、選択される手法の影響を受けます。メトリクス計算を使用する場合は、実行されるメトリクス計算に基づいて JSON の形式がさらに多様化します。
1. が提供する他の CloudWatch メトリクス AWS または CloudWatch に発行するメトリクスから直接データを取得するポリシーを作成するには、「」を参照してください[カスタムロードメトリクスとスケーリングメトリクスを使用する予測スケーリングポリシーの例 (AWS CLI)](#custom-metrics-ex1)。
1. 複数の CloudWatch メトリクスをクエリし、数式を使用してこれらのメトリクスに基づく新しい時系列を作成できるポリシーを作成するには、「[Metric Math 式を使用する](using-math-expression-examples.md)」を参照してください。
## カスタムロードメトリクスとスケーリングメトリクスを使用する予測スケーリングポリシーの例 (AWS CLI)
でカスタムロードおよびスケーリングメトリクスを使用して予測スケーリングポリシーを作成するには AWS CLI、 の引数を という名前`--predictive-scaling-configuration`の JSON ファイルに保存します`config.json`。
カスタムメトリクスの追加は、以下の例にある置き換え可能な値を独自のメトリクスとターゲット使用率に置き換えることによって開始します。
```
{
"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 [AWS CloudWatch ユーザーガイド」の「CloudWatch メトリクスを発行するサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html)」を参照してください。 *Amazon CloudWatch *
を使用して CloudWatch メトリクスの正確なメトリクス名、名前空間、ディメンション (該当する場合) を取得するには AWS CLI、[「list-metrics](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/list-metrics.html)」を参照してください。
このポリシーを作成するには、以下の例にあるように、JSON ファイルを入力として使用して [put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) コマンドを実行します。
```
aws 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 式を使用する
以下のセクションには、ポリシーでメトリクス計算を使用する方法を説明する予測スケーリングポリシーの情報と例が記載されています。
**Topics**
+ [Metric Math について](#custom-metrics-metric-math)
+ [メトリクス計算を使用してメトリクスを組み合わせる予測スケーリングポリシーの例 (AWS CLI)](#custom-metrics-ex2)
+ [ブルー/グリーンデプロイシナリオで使用する予測スケーリングのポリシーの例 (AWS CLI)](#custom-metrics-ex3)
## Metric Math について
既存のメトリクスデータの集計だけを行いたい場合は、CloudWatch Metric Math により、別のメトリクスを CloudWatch に発行する手間とコストを節約できます。 AWS が提供する任意のメトリクスを使用できます。また、アプリケーションの一部として定義したメトリクスを使用することもできます。例えば、インスタンスごとに Amazon SQS キューバックログを計算したい場合があります。これを行うには、キューから取得可能なメッセージのおおよその数を取得し、その数を Auto Scaling グループの実行中のキャパシティーで割ります。
詳細については、「*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 に基づくスケーリングポリシー](as-using-sqs-queue.md)」を参照してください。
このシナリオの予測スケーリングポリシー例を次に示します。Amazon SQS `ApproximateNumberOfMessagesVisible` メトリクス (キューから取得可能なメッセージの数) に基づくスケーリングメトリクスおよび負荷メトリクスを指定します。Amazon EC2 Auto Scaling `GroupInServiceInstances` メトリクスと、スケーリングメトリクスのインスタンスごとのバックログを計算するための数式も使用します。
```
aws autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
{
"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": []
}
```
## ブルー/グリーンデプロイシナリオで使用する予測スケーリングのポリシーの例 (AWS CLI)
検索式には、複数の Auto Scaling グループからメトリクスをクエリし、それらに対して数式を実行できる高度なオプションが用意されています。これは、Blue/Green デプロイで特に有用です。
**注記**
*Blue/Green デプロイ* とは、同一の Auto Scaling グループを 2 つ別々に作成するデプロイ方法です。本番トラフィックを受信するグループは 1 つだけです。ユーザートラフィックは、最初は以前の (「青」の) Auto Scaling グループに送信され、新しいグループ (「緑」) はアプリケーションまたはサービスの新しいバージョンのテストと評価に使用されます。新しいデプロイがテストされ、合格すると、ユーザートラフィックは緑の Auto Scaling グループに送信されるようになります。デプロイが成功したら、青のグループを削除できます。
Blue/Green デプロイの一部として新しい Auto Scaling グループが作成されると、メトリクスの指定を変更する必要なく、各グループのメトリクス履歴を自動的に予測スケーリングポリシーに含めることができます。詳細については、 AWS コンピューティングブログの[「ブルー/グリーンデプロイでの EC2 Auto Scaling 予測スケーリングポリシーの使用](https://aws.amazon.com/blogs/compute/retaining-metrics-across-blue-green-deployment-for-predictive-scaling/)」を参照してください。
次のポリシー例で、これをどのように実行できるかを示します。この例では、ポリシーで、Amazon EC2 が出力する `CPUUtilization` メトリクスを使用します。Amazon EC2 Auto Scaling `GroupInServiceInstances` メトリクスとインスタンスごとのスケーリングメトリクスの値を計算するための数式を使用します。また、キャパシティーメトリック仕様を指定して、`GroupInServiceInstances` メトリクスを取得します。
検索式は、指定した検索条件に基づいて、複数の Auto Scaling グループ内のインスタンスの `CPUUtilization` を検索します。後で同じ検索条件に一致する新しい Auto Scaling グループを作成すると、新しい Auto Scaling グループのインスタンスの `CPUUtilization` が、自動的に含まれます。
```
aws autoscaling put-scaling-policy --policy-name my-blue-green-predictive-scaling-policy \
--auto-scaling-group-name my-asg --policy-type PredictiveScaling \
--predictive-scaling-configuration file://config.json
{
"MetricSpecifications": [
{
"TargetValue": 25,
"CustomizedScalingMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_sum",
"Expression": "SUM(SEARCH('{AWS/EC2,AutoScalingGroupName} MetricName=\"CPUUtilization\" ASG-myapp', 'Sum', 300))",
"ReturnData": false
},
{
"Id": "capacity_sum",
"Expression": "SUM(SEARCH('{AWS/AutoScaling,AutoScalingGroupName} MetricName=\"GroupInServiceInstances\" ASG-myapp', 'Average', 300))",
"ReturnData": false
},
{
"Id": "weighted_average",
"Expression": "load_sum / capacity_sum",
"ReturnData": true
}
]
},
"CustomizedLoadMetricSpecification": {
"MetricDataQueries": [
{
"Id": "load_sum",
"Expression": "SUM(SEARCH('{AWS/EC2,AutoScalingGroupName} MetricName=\"CPUUtilization\" ASG-myapp', 'Sum', 3600))"
}
]
},
"CustomizedCapacityMetricSpecification": {
"MetricDataQueries": [
{
"Id": "capacity_sum",
"Expression": "SUM(SEARCH('{AWS/AutoScaling,AutoScalingGroupName} MetricName=\"GroupInServiceInstances\" ASG-myapp', 'Average', 300))"
}
]
}
}
]
}
```
この例では、ポリシーの ARN が返されます。
```
{
"PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-blue-green-predictive-scaling-policy",
"Alarms": []
}
```
# 予測スケーリングポリシーでのカスタムメトリクスに関する考慮事項
カスタムメトリクスの使用中に問題が発生した場合は、次の操作を実行することをお勧めします。
+ エラーメッセージが表示された場合は、メッセージを読み、可能な場合は報告されている問題を解決します。
+ Blue/Green デプロイシナリオで検索式を使用しようとしているときに問題が発生した場合は、まず、完全一致ではなく部分一致を検索する検索式の作成方法を理解していることを確認してください。また、クエリが、特定のアプリケーションを実行している Auto Scaling グループのみを見つけることを確認します。検索式の構文の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch 検索式の構文](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html)」を参照してください。
+ 事前に式を検証しなかった場合は、[put-scaling-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-scaling-policy.html) コマンドは、スケーリングポリシーの作成時にそれを検証します。ただし、このコマンドでは、検出されたエラーの正確な原因を特定できない可能性があります。問題を解決するには、[get-metric-data](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/get-metric-data.html) コマンドへのリクエストからの応答で受け取ったエラーをトラブルシューティングします。CloudWatch コンソールから式をトラブルシューティングすることもできます。
+ コンソールで **[Load]** (負荷) と ** [Capacity] ** (キャパシティー) のグラフを表示すると、**[Capacity]** (キャパシティー) グラフにはデータがまったく表示されない場合があります。グラフに完全なデータが含まれるようにするには、Auto Scaling グループのグループメトリクスを常に有効にしてください。詳細については、「[Auto Scaling グループのメトリクスを有効にする (コンソール)](ec2-auto-scaling-metrics.md#as-enable-group-metrics)」を参照してください。
+ キャパシティーメトリクスの指定は、有効期間にわたって異なる Auto Scaling グループで実行されるアプリケーションがある場合にのみ、Blue/Green デプロイで役立ちます。このカスタムメトリクスでは、複数の Auto Scaling グループの総キャパシティーを指定できます。予測スケーリングは、これを使用して、履歴データをコンソールの **[Capacity]** (キャパシティー) グラフに表示します。
+ `MetricDataQueries` で SUM() のような数学関数を使用せずに、独自の SEARCH() 関数を指定する場合、`ReturnData` に `false` を指定する必要があります。これは、検索式が複数の時系列を返す可能性がある一方、数式に基づくメトリクス指定は 1 つの時系列しか返すことができないためです。
+ 検索式に含まれるすべてのメトリクスは、同じ解像度である必要があります。
## 制限事項
+ 1 つのメトリクス指定で最大 10 個のメトリクスのデータポイントをクエリできます。
+ この制限に関しては、1 つの式は 1 つのメトリクスとしてカウントされます。