Auto Scaling設計 — ターゲット追跡と予測スケーリング

Auto Scalingは「入れれば勝手に伸縮する」ものではありません。指標選び、ウォームアップ、スケールインの安全設計を外すと、遅延・コスト・障害のいずれかを踏みます。EC2とECSの実務ポイントを整理します。

Auto Scalingは、EC2でもECS/Fargateでも「導入した瞬間に効く」機能ではありません。効かせるかどうかは、スケール指標の選び方、ウォームアップ時間の設定、そしてスケールインをどこまで安全に倒すかという設計判断で決まります。本記事では、EC2 Auto Scaling・ECSサービスAuto Scaling（Application Auto Scaling）を対象に、ターゲット追跡／ステップ／スケジュール／予測の使い分けから、スパイク対応とコストまでを、実務の落とし穴込みで整理します。

01まず全体像 — 3つのAuto Scalingを混同しない

AWSで「Auto Scaling」と呼ばれるものは実は複数あり、設定面もAPIも別です。ここを混同すると設計会議が噛み合いません。

• Amazon EC2 Auto Scaling：Auto Scalingグループ（ASG）のEC2インスタンス台数を伸縮させます。予測スケーリングが使えるのはこれです。
• Application Auto Scaling：ECSサービスのタスク数、Aurora Replica、DynamoDBのキャパシティなど、EC2以外のリソースを対象にした汎用スケーラです。ECSサービスAuto Scalingはこの上で動きます。
• AWS Auto Scaling（統合ダッシュボード）：複数リソースをまとめて計画するフロントエンド。実体は上の2つに委譲されます。

本記事では実務で触る機会が多いEC2 Auto ScalingとECSサービスAuto Scalingを中心に扱います。ECSの起動タイプ選定はFargate対EC2起動タイプ、EC2のインスタンスタイプ選びはEC2インスタンスタイプ選定も併せてご覧ください。

02ターゲット追跡が第一候補である理由

AWSは明確に、平均CPU使用率やターゲットあたりリクエスト数といった指標に対してはターゲット追跡スケーリングを推奨しています。ターゲット追跡では、指標と目標値を決めるだけで、AWS側がCloudWatchアラームを自動生成・管理し、必要台数を逆算して増減します。運用負荷が低く、需要曲線に追従しやすいのが利点です。

EC2でよく使う定義済み指標はASGAverageCPUUtilization、ALB配下ならALBRequestCountPerTarget。ECSサービスではECSServiceAverageCPUUtilization、ECSServiceAverageMemoryUtilization、ALBRequestCountPerTargetが定番です。

03指標選定 — ここを外すと全部崩れる

Auto Scaling設計の本丸は指標選定です。AWSのECS運用ベストプラクティスは、スケール指標が満たすべき2条件を明快に示しています。

• 需要と相関する：リソースを固定して需要が変われば、指標値も動くこと。
• 容量に比例する：需要一定でタスク（インスタンス）を倍にすれば、指標値がおおむね半分になること。

この2条件を満たさない指標でスケールすると、増やしても指標が下がらず暴走する、あるいは下がりすぎて振動する、といった破綻が起きます。特にメモリベースのスケーリングは要注意です。AWSは、JVM（Java 8 update 191以降）が利用可能なメモリいっぱいにヒープを確保するため、メモリ使用率がスループットやコンカレンシーと相関しないケースが多いと明記しており、Javaや.NET・Rubyなどのランタイムではメモリベースのスケーリングを推奨していません。CPUバウンドならCPU使用率、そうでなければ負荷試験に基づき平均スループットか平均コンカレンシーで、というのが公式の指針です。

指標は机上で決めず、ステージング環境の負荷試験で決めるのが公式の推奨です。負荷を段階的に上げ、SLOを割るまでの各指標の振る舞いを観測し、飽和リソースと比例性を確認してから採用します。監視の土台づくりはCloudWatch監視の第一歩も参照してください。

04ウォームアップとクールダウン — 振動を止める要

スケールアウト直後のインスタンスは、起動・アプリ初期化・JITウォームアップなどで一時的にCPUが跳ねたり、逆にまだトラフィックを受けていなかったりします。これを集計に含めると、Auto Scalingが誤った判断をして台数が振動します。

EC2 Auto Scalingではデフォルトインスタンスウォームアップを設定します。これは、インスタンスがInServiceになってから、集計指標にデータを寄与し始めるまでの待機時間です。これを設定しておくと、暖機中の個別インスタンスの一時的な高負荷でスケール判断が歪むのを防げます。AWSはこの設定を強く推奨しており、設定するとステップ／ターゲット追跡のウォームアップ時間として一元的に使われます（旧来のクールダウンに代わる推奨機構）。

• ウォームアップ：新規インスタンスが指標に寄与するまでの猶予。長すぎるとスケール反応が鈍く、短すぎると振動。起動〜ヘルスチェック通過〜実トラフィック処理までの実測時間を基準に決めます。
• クールダウン（簡易スケーリング）：1回のスケール後に次のスケールを抑制する時間。ターゲット追跡ではウォームアップに置き換わる考え方が基本です。

05スケールインの安全設計 — 事故はだいたい縮小時に起きる

スケールアウトの失敗は「遅い・高い」で済みますが、スケールインの失敗は処理中のリクエストを切る・ジョブを殺すという実害につながります。ここは臆病に設計します。

• コネクションドレイン（登録解除の遅延）：ALB/NLBのターゲットグループでderegistration_delayを適切に設定し、処理中のリクエストを流し切ってから落とします。
• インスタンススケールイン保護：長時間ジョブを持つインスタンスなど、落とされると困る個体を保護します。バッチ処理系で特に有効です。
• 終了ポリシー：デフォルトのDefaultポリシーは、(1)最も多くの（スケールイン保護されていない）インスタンスを持つAZ、(2)古い構成のインスタンス（まず起動設定、次に現行と異なる起動テンプレート、最後に現行起動テンプレートの最古バージョン）、(3)次の課金時間に最も近いインスタンス、の順で選ぶとされています。ローリング更新の意図と合っているか確認します。
• ECSのタスク保護：ECSでは処理中タスクを守るUpdateTaskProtection API、FargateではstopTimeoutとSIGTERMハンドリングでグレースフルシャットダウンを実装します。

スケールインは「速く」ではなく「安全に、ゆっくり」が原則です。ターゲット追跡は増強を速く・縮小を保守的に振る舞うよう設計されていますが、アプリ側のシャットダウン処理が甘いと台無しになります。

06予測スケーリング — 効く条件を見極める

予測スケーリング（EC2 Auto Scaling専用）は、過去の指標から需要を予測し、需要が立ち上がる前に先回りで増強する機能です。周期性のあるワークロード、たとえば「平日朝に負荷が立ち上がる」「毎週末にアクセスが増える」といった曜日・時間帯に固有の繰り返しパターンを持つ場合に効果を発揮します。

公式ドキュメントベースで押さえるべき要点は次の通りです（数値・仕様はバージョン依存のため公式で最新を確認してください）。

• 予測を始めるには対象指標に最低24時間のデータが必要。ただし精度は2週間のデータが揃ってからが本領です。
• 直近14日分を分析し、今後48時間の毎時キャパシティ予測を生成、6時間ごとに更新します。
• 有効化直後はforecast only（予測のみ）モードで動き、実際のスケールはしません。コンソールの推奨と予測精度を確認してからforecast and scaleに切り替えます。
• 予測はスケールアウトのみ。予測に基づく縮小はしないため、不要キャパシティの回収には別途動的スケーリング（ターゲット追跡など）の併用が必要です。
• SchedulingBufferTime（コンソールのPre-launch instances）で予測時刻より前倒しに起動でき、起動〜ready猶予を確保できます。この前倒し運用にはデフォルトインスタンスウォームアップの併用が推奨されます。
• 複数ポリシー併用時は、各ポリシーが独立に必要台数を算出し、その最大値が採用されます。

07スパイク対応 — 予測できない急変にどう備えるか

予測やスケジュールが効くのは「読める」需要です。読めない急変には、ターゲット追跡だけでは起動時間ぶんの遅れが必ず出ます。実務での備え方は次の通りです。

• 下限台数（MinSize）で頭金を積む：常時ゼロ近くまで縮小せず、想定スパイクの初速を吸収できる台数を最低確保します。コストと引き換えの保険です。
• ステップスケーリングで急変に段階対応：閾値の乖離幅に応じて増分を変えられるため、大きく振れたときに一気に増やせます。ターゲット追跡＋ステップの併用も可能です。
• スケジュールスケーリングで既知イベントを先回り：セール開始・TVCM放映・月次バッチなど時刻が読めるものは、スケジュールで下限を事前に引き上げます。
• ウォームプール／起動高速化：EC2ウォームプールで事前起動済みインスタンスを待機させる、あるいはコンテナ/AMIを軽量化して起動を縮める。スパイク追従の実効速度は起動時間で決まります。
• Fargateの制約を織り込む：Fargateはインスタンス管理不要な反面、タスク起動に一定時間がかかります。瞬間的スパイクが読めるなら、EC2キャパシティプロバイダやスケジュール事前増強を組み合わせます。

ECSのクラスターキャパシティ（EC2起動タイプでのインスタンス側）は、キャパシティプロバイダとManaged Scalingで別途スケールする二層構造になります。タスクだけ増やしても載せる先のEC2が無ければ意味がないため、この二層の整合を必ず確認してください。

08コスト最適化 — スケール設計はそのままコスト設計

Auto Scalingは「必要なときだけ払う」ための仕組みですが、設計次第で逆にコストを膨らませます。判断軸を整理します。

• ターゲット値の置き方：CPU 40%を狙えば余裕はあるが常時多め、70%を狙えばコスト効率は上がるがスパイク耐性は下がる。SLOと相談して決めます。
• スケールインの積極度：安全のためゆっくり縮小するほどコストは残ります。ドレインとタスク保護を固めた上で、縮小を過度に遅らせない設計が理想です。
• 下限台数のベースはSavings Plans/RIへ：常時稼働する下限ぶんはコミットメント割引で、スパイクの上振れぶんはオンデマンドやSpotで、と層を分けます。
• Spot活用：ステートレスなWeb/ワーカー層はSpotとの相性が良く、Mixed Instancesやキャパシティプロバイダで按分できます。ただし中断耐性のあるアプリ設計が前提です。
• 予測の最大容量自動引き上げに注意：MaxCapacityBreachBehaviorで上限自動引き上げを許すと、意図せず台数が増え、しかも上限は自動で戻りません。コスト事故になりやすいので監視必須です。

スケール設計はコスト設計そのものです。指標・ターゲット値・下限台数・割引適用の4点を、SLOとコスト目標の両にらみで決めるのがEMWの基本方針です。実運用の監視・アラート設計は監視・アラート設計と併せて固めてください。

—まとめ

Auto Scaling設計の勘所を整理します。

• まずターゲット追跡を第一候補に。指標は机上でなく負荷試験で「需要相関」「容量比例」を確認して選ぶ。メモリベースはJava/GC系で特に危険。
• デフォルトインスタンスウォームアップを必ず設定し、暖機中の一時負荷で判断が歪むのを防ぐ。実測ベースで時間を決める。
• スケールインは臆病に。ドレイン・スケールイン保護・タスク保護・グレースフルシャットダウンで、縮小時の事故を防ぐ。
• 予測スケーリングは周期性が前提。forecast onlyで検証してから本番へ。縮小には動的スケーリングの併用が必要。
• 読めないスパイクは下限台数・ステップ・起動高速化で、読めるイベントはスケジュール・予測で先回り。
• スケール設計はコスト設計。ターゲット値・下限台数・割引適用をSLOと両にらみで決める。

「入れれば伸縮する」ではなく、指標選定・ウォームアップ・スケールインの安全という3点を詰めきることが、遅延もコストも障害も出さないAuto Scaling設計の核心です。

—参考(一次情報)

• Target tracking scaling policies for Amazon EC2 Auto Scaling（AWS公式ドキュメント）
• How predictive scaling works — Amazon EC2 Auto Scaling（AWS公式ドキュメント）
• Set the default instance warmup for an Auto Scaling group（AWS公式ドキュメント）
• Configure instance termination policies for Amazon EC2 Auto Scaling（AWS公式ドキュメント）
• Optimizing Amazon ECS service auto scaling（AWS公式ドキュメント）
• Automatically scale your Amazon ECS service（AWS公式ドキュメント）