Auto Scalingポリシー｜基礎を学ぶ

このレッスンでできるようになること

需要の変わり方を読んで、目標追跡・ステップ・スケジュール・予測のどのスケーリング方式を選ぶか、そして間に合わないときに何を足すかを判断できるようになります。

まず要件を読む

あるメディア企業が、Auto Scaling グループの後ろで記事配信サーバーを動かしています。平日の昼はゆるやかに混み、毎週月曜の朝 9 時にメールマガジンを配信した直後だけアクセスが跳ね上がります。現在は CPU 使用率が上がってから台数を増やしているのですが、増えたインスタンスが応答できるようになる頃には山が過ぎており、その間ユーザーがエラー画面を見ています。運用チームを増やさずに直したい、という相談です。

ここには2つの別々の問題が混ざっています。ゆるやかな増減への追従と、時刻が読めているスパイクへの先回りです。SAA では、この2つを別のポリシーで解くと気づけるかが問われます。

4つの方式の線引き

方式	何を指示するか	向いている場面
目標追跡スケーリング	「平均 CPU を 50 パーセントに保て」のように目標値だけ	負荷がなめらかに増減する。まず既定で選ぶ
ステップスケーリング	しきい値の帯ごとに増やす台数を指定	超過の度合いで増やす量を変えたい
シンプルスケーリング	1つのアラームで一定数を増減	古い方式。新規設計では選ばない
スケジュールされたアクション	日時を指定して最小台数を上げ下げ	増える時刻が決まっている
予測スケーリング	過去のパターンから先回りして台数を用意	曜日や時間帯で繰り返す山がある

目標追跡とステップは、どちらもメトリクスを見てから動きます。つまり山が来てから起動が始まる方式です。起動に時間がかかるアプリでは、この遅れがそのまま障害時間になります。

スケジュールと予測は、山が来る前に台数を用意する方式です。冒頭の月曜 9 時のように時刻が確定しているならスケジュール、曜日や時間帯で繰り返すが厳密な時刻までは決まっていないなら予測が合います。

そして予測スケーリングは単独では使いません。過去にない山が来たときに追従できないからです。予測で土台を用意し、目標追跡で残りの揺れを吸収する、という組み合わせが基本形です。

立ち上がりが遅いときに足すもの

台数を増やす判断が正しくても、インスタンスが使い物になるまで数分かかるなら間に合いません。次を検討します。

ウォームアップの設定 — 起動直後のインスタンスのメトリクスを集計から除き、増やしすぎと減らしすぎを防ぐ
ウォームプール — あらかじめ初期化済みのインスタンスを停止状態で待たせ、必要になったら起動するだけにする
ライフサイクルフック — 起動完了前の準備や、終了前のログ退避のために状態を保留する
ヘルスチェックタイプを ELB にする — EC2 としては生きているがアプリが応答しない、という状態を検知して入れ替える

要件語から構成への対応

要件の言い回し	選ぶもの
使用率を一定に保ちたい / 運用の手間を最小に	目標追跡スケーリング
超過の度合いによって増やす台数を変えたい	ステップスケーリング
毎日 9 時から / 決まった時刻に必ず増える	スケジュールされたアクション
曜日ごとの傾向がある / 事前に用意しておきたい	予測スケーリング(目標追跡と併用)
起動に時間がかかり、スパイクに間に合わない	ウォームプール
プロセスは生きているが応答しないインスタンスがある	ヘルスチェックタイプを ELB に

よくある引っ掛け

その1 「しきい値を下げる」だけの選択肢。 CPU 60 パーセントで増やしていたのを 40 パーセントに下げれば早く動き出しますが、起動時間そのものは縮まないうえ、平常時も台数が増えてコストが上がります。原因が起動の遅さなら、ウォームプールや予測が正解です。

その2 最大台数を常に高くしておく選択肢。 最大値は上限であって台数ではないので、これを上げても山の直前に台数は増えません。先回りさせたいならスケジュールで最小台数を上げます。

まとめ

迷ったらまず目標追跡。運用の手間が最も少ない
時刻が確定しているならスケジュール、繰り返す傾向があるなら予測
予測スケーリングは目標追跡と組み合わせて使う
起動が遅くて間に合わない問題は、ポリシーではなくウォームプールで解く
アプリの生死を見たいならヘルスチェックタイプを ELB にする