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

# 予測スケーリングの仕組み
<a name="predictive-scaling-policy-overview"></a>

このトピックでは、予測スケーリングの仕組みと、予測スケーリングポリシーを作成するときに考慮すべき点について説明します。

**Topics**
+ [仕組み](#how-predictive-scaling-works)
+ [最大キャパシティの制限](#predictive-scaling-maximum-capacity-limit)
+ [考慮事項](#predictive-scaling-considerations)
+ [サポート対象のリージョン](#predictive-scaling-regions)

## 仕組み
<a name="how-predictive-scaling-works"></a>

予測スケーリングを使用するには、モニタリングおよび分析する 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)」を参照してください。

## 最大キャパシティの制限
<a name="predictive-scaling-maximum-capacity-limit"></a>

Auto Scaling グループには、グループに対して起動できる EC2 インスタンスの最大数を制限する最大キャパシティ設定があります。デフォルトでは、スケーリングポリシーが設定されている場合、最大キャパシティを超えてキャパシティを増やすことはできません。

それ以外の方法として、予測キャパシティが Auto Scaling グループの最大キャパシティに近づいた場合や、それを超えた場合に、グループの最大キャパシティを自動的に増やすことができます。この動作を有効にするには、`PutScalingPolicy` API オペレーションの `MaxCapacityBreachBehavior` および `MaxCapacityBuffer` プロパティ、または AWS マネジメントコンソールの **[最大キャパシティーの動作]** 設定を使用します。

**警告**  
最大キャパシティを自動的に増やす場合は注意してください。これにより、増加した最大キャパシティがモニタリングおよび管理されていない場合、意図したよりも多くのインスタンスが起動される可能性があります。その後、増加した最大キャパシティは、手動で更新するまで Auto Scaling グループの新しい通常の最大キャパシティになります。最大キャパシティは、自動的に元の最大キャパシティまで減少しません。

## 考慮事項
<a name="predictive-scaling-considerations"></a>
+ 予測スケーリングがワークロードに適しているかどうかを確認します。ワークロードは、曜日または時刻に固有の定期的な負荷パターンを示す場合に、予測スケーリングに適しています。これを確認するには、*予測のみ*モードで予測スケーリングポリシーを設定し、コンソールの推奨事項を参照してください。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 インスタンスタイプの方が大幅に高いネットワークスループットを提供します。

## サポート対象のリージョン
<a name="predictive-scaling-regions"></a>
+ 米国東部 (バージニア北部)
+ 米国東部 (オハイオ)
+ 米国西部 (北カリフォルニア)
+ 米国西部 (オレゴン)
+ アフリカ (ケープタウン)
+ アジアパシフィック (香港)
+ アジアパシフィック (ハイデラバード)
+ アジアパシフィック (ジャカルタ)
+ アジアパシフィック (メルボルン)
+ アジアパシフィック (ムンバイ)
+ アジアパシフィック (大阪)
+ アジアパシフィック (ソウル)
+ アジアパシフィック (シンガポール)
+ アジアパシフィック (シドニー)
+ アジアパシフィック (東京)
+ カナダ (中部)
+ カナダ西部 (カルガリー)
+ 中国 (北京)
+ 中国 (寧夏)
+ 欧州 (フランクフルト)
+ 欧州 (アイルランド)
+ 欧州 (ロンドン)
+ 欧州 (ミラノ)
+ 欧州 (パリ)
+ 欧州 (スペイン)
+ 欧州 (ストックホルム)
+ 欧州 (チューリッヒ)
+ イスラエル (テルアビブ)
+ 中東 (バーレーン)
+ 中東 (アラブ首長国連邦)
+ 南米 (サンパウロ)
+ AWS GovCloud (米国東部)
+ AWS GovCloud (米国西部)