# 履歴パターンを使用して予測スケーリングで Amazon ECS サービスをスケールする
<a name="predictive-auto-scaling"></a>

予測スケーリングは、トラフィックフローからの過去の負荷データを調べて、日次または週次のパターンを分析します。次に、この分析を使用して将来のニーズを予測し、必要に応じてサービスのタスクをプロアクティブに増やします。

予測自動スケーリングは、以下の状況で最も役立ちます。
+ 周期的なトラフィック - 通常の営業時間にリソースの使用が増加し、夜間や週末にはリソースの使用が減少する。
+ オンとオフを繰り返すワークロードパターン - バッチ処理、テスト、定期的なデータ分析など。
+ 初期化に時間がかかるアプリケーション - スケールアウトイベント中のアプリケーションのパフォーマンスに影響を及ぼし、顕著なレイテンシーを引き起こす可能性がある。

アプリケーションの初期化に時間がかかり、トラフィックが規則的なパターンで増加する場合は、予測スケーリングの使用を検討する必要があります。ターゲット追跡やステップスケーリングなどの動的スケーリングポリシーを単独で使用するのではなく、予測される負荷に応じてタスク数を事前に増やすことで、より迅速にスケールできます。予測スケーリングにより、タスク数が過剰にプロビジョニングされる可能性を回避できるため、コストを削減できる場合もあります。

例えば、営業時間中の使用率が高く、夜間の使用量が少ないアプリケーションを考えてみましょう。各営業日の開始時に、予測スケーリングにより、トラフィックが最初に流入する前にタスクをスケールアウトできます。これにより、使用率の低い期間から高い使用率の期間に移行するときに、アプリケーションの高可用性とパフォーマンスを維持するのに役立ちます。トラフィックの変化に動的スケーリングが反応するのを待つ必要はありません。また、アプリケーションの負荷パターンを確認し、スケジュールされたスケーリングを使用して適切な量のタスクをスケジュールするために時間を費やす必要もありません。

予測スケーリングは、基盤となるコンピューティングキャパシティ (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 における予測スケーリングの仕組み
<a name="predictive-auto-scaling-overview"></a>

ここでは、予測スケーリングの使用に関する考慮事項、その仕組み、制限事項について説明します。

### 予測スケーリングを使用する際の考慮事項
<a name="predictive-auto-scaling-considerations"></a>
+ 予測スケーリングがワークロードに適していることを確認する必要があります。これを確認するには、**予測専用**モードでスケーリングポリシーを設定し、コンソールが推奨する内容を確認します。予測スケーリングの使用を開始する前に、予測とレコメンデーションを評価する必要があります。
+ 予測スケーリングが予測を開始するには、少なくとも 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 を呼び出します。

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

予測スケーリングを使用するには、モニタリングおよび分析する CloudWatch メトリクスを指定する予測スケーリングポリシーを作成します。予測スケーリングが将来の値の予測を開始するには、このメトリクスに 24 時間以上のデータが必要です。

ポリシーを作成すると、予測スケーリングは最長過去 14 日間のメトリクスデータの分析を開始し、パターンを特定します。この分析は、今後 48 時間の必要量の時間ごとの予測を生成するために使用されます。最新の CloudWatch データを使用して、6 時間ごとに予測が更新されます。新しいデータを取得すると、予測スケーリングは将来の予測の正確性を継続的に向上させます。

最初に予測スケーリングを有効にしたときは、*予測のみ*モードで実行されます。このモードでは予測を生成しますが、それらの予測に基づいて Amazon ECS サービスをスケールすることはありません。これにより、予測の正確性と適合性を評価できます。`GetPredictiveScalingForecast` API オペレーションまたは AWS マネジメントコンソールを使用して、予測データを表示します。

予測スケーリングの使用を開始する場合は、スケーリングポリシーを*予測とスケーリング*モードに切り替えます。このモードでは、次のことが発生します。

Amazon ECS サービスは、デフォルトでは、その時間の予測に基づいて各時間の開始時にスケールされます。`PutScalingPolicy` API オペレーションで `SchedulingBufferTime` プロパティを使用して、早く開始することを選択できます。これにより、新しいタスクは予測される需要よりも早く起動し、トラフィックを処理する準備が整うまでの時間を確保できます。

### 最大タスク制限
<a name="predictive-scaling-maximum-tasks-limit"></a>

スケーリングのために Amazon ECS サービスを登録する場合、サービスごとに起動できる最大タスク数を定義します。デフォルトでは、スケーリングポリシーが設定されている場合、タスク数をその最大制限を超えて増やすことはできません。

ただし、予測が Amazon ECS サービスの最大タスク数に近づいた場合、または超えた場合に、サービスの最大タスク数を自動的に増やすことを許可できます。

**警告**  
最大タスク数を自動的に増やす場合は注意してください。これにより、増加した最大タスク数がモニタリングおよび管理されていない場合、意図したよりも多くのタスクが起動される可能性があります。増加した最大タスク数は、手動で更新するまで Amazon ECS サービスの新しい通常の最大タスク数になります。最大タスク数は、自動的に元の最大タスク数まで減少しません。

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