概要
EC2 Auto Scaling は、負荷が上がるとインスタンスを足してくれます。ところが、アプリケーションの初期化に時間がかかると、足したインスタンスが「起動はしたが、まだリクエストを処理できない」時間が生まれます。この間のメトリクスをそのまま判断に使うと、必要以上にインスタンスを増やしたり、増やしたはずなのに応答が追いつかなかったりします。
この空白の時間を Auto Scaling に教えるのが インスタンスのウォームアップ です。グループに「デフォルトのインスタンスのウォームアップ」を設定すると、ウォームアップ中のインスタンスはメトリクスの集計から外れ、一方で追加済みの容量としては数えられるため、同じ負荷に対して何度もスケールアウトすることがなくなります。
また、毎日決まった時刻に混むことが分かっているなら、負荷が上がってから増やすのではなく、スケジュールされたスケーリング や 予測スケーリング で先回りして増やす選択肢もあります。
この記事では、Auto Scaling のスケーリング方法の違いと、ウォームアップの仕組みを整理します。実践では、応答できるまで 1 分以上かかる Web サーバーにウォームアップとステップスケーリングを設定し、負荷をかけても、ウォームアップの間は台数が増えないことを確かめたうえで、正午前に台数を増やすスケジュールを設定します。
クラウドおさる当番の猿を増やしても、着替えて持ち場に着くまでは戦力にならないでござる。その「着替え中」をどう数えるかが、今日のウォームアップの話でござるよ。
この記事のメリット
- ターゲット追跡・ステップ・シンプル・スケジュール・予測の各スケーリングの違いと使いどころが分かる
- デフォルトのインスタンスのウォームアップの役割と、ウォームアップ中のインスタンスの扱いを説明できるようになる
- 起動に時間がかかるアプリケーションで、過剰なスケールアウトを防ぐ設定ができるようになる
- 決まった時刻の混雑に、スケジュールや予測で先回りする方法が分かる
- 「起動の遅さ」の対策になるものと、ならないものを区別できるようになる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
起動から応答までの「空白の時間」
Auto Scaling が起動したインスタンスは、InService になった時点でグループの一員になります。しかし、アプリケーションの初期化（パッケージの導入、設定の読み込み、キャッシュの準備など）が終わるまでは、リクエストを処理できません。
この間のインスタンスのメトリクスは、実際の負荷を表していません。初期化処理で CPU が一時的に跳ね上がることもあれば、まだリクエストを受けていないので CPU がほぼ 0% のこともあります。どちらにしても、グループ全体の平均に混ぜると判断がぶれます。
| 状態 | 起こりがちなこと |
|---|---|
| 初期化中のインスタンスの高い CPU を平均に混ぜる | まだ負荷が高いと判断して、さらにスケールアウトする（過剰なスケールアウト） |
| 初期化中のインスタンスの低い CPU を平均に混ぜる | 負荷が下がったと判断して、スケールインしてしまう |
| 足したインスタンスを容量として数えない | 同じ負荷に対して何度もスケールアウトする |
スケーリングの方法
EC2 Auto Scaling には、負荷に応じて増減する「動的スケーリング」と、時刻や予測に基づいて先回りする方法があります。
| 方法 | いつ動くか | 向いているケース |
|---|---|---|
| ターゲット追跡スケーリング | メトリクスを目標値（例: 平均 CPU 50%）に保つように自動で増減する。CloudWatch アラームは Auto Scaling が作成・管理する | ほとんどのケース。AWS が最初に勧めている方法 |
| ステップスケーリング | 自分で作った CloudWatch アラームの超過幅に応じて、段階的に増減する | 超過幅ごとの増減数を細かく決めたいとき |
| シンプルスケーリング | アラームで 1 段だけ増減し、各スケーリングアクティビティの間にクールダウン期間を置く | 1 段の増減で足りるとき。段階を分けたいならステップスケーリング |
| スケジュールされたスケーリング | 指定した日時に、希望・最小・最大の台数を設定する | 混む時刻が決まっているとき |
| 予測スケーリング | 過去の負荷から日・週の周期を学習し、予測に合わせて先に増やす | 周期的な負荷、初期化に時間がかかるアプリ |
インスタンスのウォームアップ
デフォルトのインスタンスのウォームアップ は、インスタンスが InService になってから、そのメトリクスをグループの集計に使い始めるまでの待ち時間です。Auto Scaling グループ単位で設定します。
| 項目 | 内容 |
|---|---|
| 設定する場所 | Auto Scaling グループ（作成時の「追加設定」、または既存グループの「詳細」タブ →「高度な設定」） |
| 値 | 0〜3600 秒。分からなければ 300 秒から始めて調整する |
| 既定 | 有効になっていない。ターゲット追跡・ステップスケーリングを使うなら、有効にすることが強く推奨されている |
| ポリシーとの関係 | ターゲット追跡・ステップスケーリングのポリシーでウォームアップを指定しなければ、グループの値が使われる |
ウォームアップ中のインスタンスは、次のように扱われます。
- メトリクスの集計には入らない: ウォームアップが終わるまで、グループの集約メトリクスに数えない
- 容量には入る: 次にスケールアウトするとき、ウォームアップ中のインスタンスはグループの容量の一部として数える。そのため、同じステップの範囲にとどまるアラームの超過が続いても、スケーリングアクティビティは 1 回で済む
- スケールインは止まる: 新しいインスタンスのウォームアップが終わるまで、動的スケーリングによるスケールインはブロックされる
- 追加のスケールアウトは条件付き: ウォームアップ中は、ウォームアップしていないインスタンスのメトリクスがしきい値を超えている場合にだけスケールアウトする
クラウドおさる着替え中の当番は、見張り台の人数には数えるけれど、疲れ具合の平均には入れないのでござる。だから「まだ足りぬ」と何度も呼び足すことがなくなるのでござるな。
決まった時刻に混むなら先回りする
ウォームアップは「増やしたあとの判断」を正しくする仕組みです。初期化に時間がかかるアプリケーションでは、混み始めてから増やすと、増えたインスタンスが応答できるまでの間はどうしても遅くなります。混む時刻が分かっているなら、先に増やしておくほうが確実です。
| 項目 | スケジュールされたスケーリング | 予測スケーリング |
|---|---|---|
| 何を決めるか | 日時と、そのときの希望・最小・最大の台数 | 予測に使うメトリクスと目標値 |
| 繰り返し | cron 式で指定。タイムゾーンの既定は UTC で、Asia/Tokyo などを指定できる | 過去最長 14 日のデータから日・週のパターンを見つける |
| 準備 | なし | 予測を始めるには 24 時間以上のデータが必要（2 週間あると効果的） |
| 動き方 | 指定時刻に台数を設定する | 48 時間先までの時間ごとの予測を 6 時間ごとに更新し、その時間の始めに台数を増やす。「起動前のインスタンス」で開始を早められる |
| 注意 | 1 グループに 125 個まで。同じ開始時刻のアクションは作れない | 最初は「予測のみ」モードで、予測を確かめてから「予測とスケーリング」に切り替える |
予測スケーリングでも、予測された需要の前に新しいインスタンスを用意できるよう、デフォルトのインスタンスのウォームアップを有効にすることが強く推奨されています。
クラウドおさるスケジュールの時刻は、タイムゾーンを選ばないと UTC で動くのでござる。「正午に増やす」つもりが日本時間の 21 時に増えた、では猿山の昼バナナ配りに間に合わないでござるぞ。
起動の遅さへの対策にならないもの
負荷対策の仕組みは多くありますが、「起動から応答までに時間がかかる」問題を直接解決するものは限られます。
| 仕組み | 何をするか | 起動の遅さに効くか |
|---|---|---|
| ALB のターゲットグループのスロースタート | 正常になったばかりのターゲットに送るリクエストを、指定した期間で徐々に増やす | 増えたあとの負荷のかけ方を穏やかにするだけで、いつ増やすかの判断は変わらない |
| ElastiCache・CloudFront | 読み込みやコンテンツの配信を肩代わりして、サーバーの負荷を下げる | 負荷そのものを減らす対策で、スケーリングの判断のぶれは解決しない |
| ウォームアップ | 初期化中のインスタンスを、メトリクスに数えず容量には数える | 効く。過剰なスケールアウトを防ぐ |
| スケジュール・予測スケーリング | 混む前にインスタンスを増やしておく | 効く。混雑の時点で初期化を終えておける |
実践
応答できるまで 1 分以上かかる Web サーバーの Auto Scaling グループに、デフォルトのインスタンスのウォームアップとステップスケーリングを設定します。負荷をかけて、追加したインスタンスがウォームアップしている間は次のインスタンスが起動されないこと、台数が足りるとアラームが収まることを確かめます。最後に、正午前に台数を増やすスケジュールされたアクションを作ります。
前提条件
- リージョン:
ap-northeast-1（東京） - EC2・Auto Scaling・CloudWatch・Systems Manager の操作権限を持つ IAM ユーザーまたはロールでコンソールにログイン済みであること
以下のリソースが作成済みであることを前提とします。Auto Scaling グループには、まだスケーリングポリシーもウォームアップも設定されていません。
まだ用意していない場合は、「作り方の参考」の記事の手順で作れます。リソース名は、この記事の名前に読み替えてください。
| リソース種別 | リソース名 | 内容 | 作り方の参考 |
|---|---|---|---|
| VPC・パブリックサブネット | warmup-lab-vpc / warmup-lab-public-1a / warmup-lab-public-1c | 2 つの AZ のパブリックサブネット。インターネットゲートウェイへのルートあり | EC2 Auto Scaling で落ちても自動で戻る Web サーバーを作る |
| Application Load Balancer | warmup-lab-alb | インターネット向け。ターゲットグループ warmup-lab-tg に転送 | 同上 |
| 起動テンプレート | warmup-lab-web-template | Amazon Linux 2023・t3.micro。起動後 60 秒待ってから Web サーバー（httpd）を起動する。負荷をかける stress-ng を導入済み。詳細モニタリングが有効。Session Manager で接続できるインスタンスプロファイル付き | 同上 ※ユーザーデータと詳細モニタリング、インスタンスプロファイルを足す |
| Auto Scaling グループ | warmup-lab-asg | 2 つのパブリックサブネット。最小 1・希望 1・最大 4。ヘルスチェックは ELB。起動したインスタンスには Name タグ warmup-lab-web が付く | 同上 ※スケーリングポリシーは作らない |
ALB と EC2 は起動している間ずっと課金されます。負荷をかけるとインスタンスが増えるため、検証が終わったら必ず削除してください。
手順 1: デフォルトのインスタンスのウォームアップを設定する
AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
上部の検索バーに EC2 と入力し、「EC2」を選択します。左側ナビゲーションの「Auto Scaling」→「Auto Scaling グループ」を選択し、warmup-lab-asg を開きます。
「詳細」タブの「高度な設定」で「編集」をクリックし、以下を設定します。
- 「デフォルトのインスタンスのウォームアップを有効にする」にチェックを入れ、表示された入力欄に
180秒
その他の項目はデフォルトのままにして、「更新」をクリックします。ユーザーデータで 60 秒待ってから httpd を起動するので、OS の起動を含めると Web サーバーの応答までに約 2 分かかります。そのため、余裕を見て 180 秒にしています。
手順 2: CPU 使用率のアラームを作る
上部の検索バーに CloudWatch と入力し、「CloudWatch」を選択します。左側ナビゲーションの「アラーム」→「すべてのアラーム」を選択し、「アラームの作成」をクリックします。
「メトリクスの選択」をクリックし、「EC2」→「Auto Scaling グループ別」を選択します。検索欄に warmup-lab-asg と入力し、候補の AutoScalingGroupName = warmup-lab-asg を選んで絞り込みます（名前が似た別のグループも一覧に出るためです）。warmup-lab-asg の CPUUtilization にチェックを入れ、「メトリクスの選択」をクリックします。続けて以下を設定します。
- 統計:
平均値（デフォルト） - 期間:
1 分（デフォルトは 5 分） - しきい値の種類:
静的 CPUUtilizationが…:以上、60
「次へ」をクリックし、「通知」は「削除」で外します。「次へ」をクリックすると「アクションが設定されていません」と確認されるので、「アクションなしで続行」をクリックします（スケーリングのアクションは、手順 3 のポリシーからこのアラームに結び付けます）。アラーム名に warmup-lab-cpu-high と入力します。「次へ」をクリックし、内容を確認して「アラームの作成」をクリックします。
手順 3: ステップスケーリングポリシーを作る
EC2 コンソールの「Auto Scaling グループ」に戻り、warmup-lab-asg の「自動スケーリング」タブを開きます。「動的スケーリングポリシー」で「動的スケーリングポリシーを作成する」をクリックし、以下を設定します。
- ポリシータイプ:
ステップスケーリング（デフォルトはターゲット追跡スケーリング） - スケーリングポリシー名:
warmup-lab-step-out - CloudWatch アラーム:
warmup-lab-cpu-high - アクションを実行:
追加、1、容量ユニット（60 <= CPUUtilization < +無限大の 1 段だけ。60 はアラームのしきい値から自動で入ります） - インスタンスのウォームアップ: 空欄のまま（グループのデフォルトのインスタンスのウォームアップ
180が薄く表示されます）
「作成」をクリックします。
手順 4: 負荷をかけて、ウォームアップの間は台数が増えないことを確かめる
左側ナビゲーションの「インスタンス」→「インスタンス」を選択し、warmup-lab-asg が起動したインスタンス（名前 warmup-lab-web）を選択して「接続」をクリックします。「SSM セッションマネージャー」が選ばれていることを確認して「接続」をクリックし、次のコマンドで CPU に 15 分間の負荷をかけます。Session Manager の作業ディレクトリには書き込めないため、--temp-path /tmp を付けます。
stress-ng --cpu 0 --timeout 15m --temp-path /tmp
数分すると、アラーム warmup-lab-cpu-high が アラーム状態 になり、Auto Scaling グループに 1 台追加されます。
最初のインスタンスは負荷をかけ続けているので、アラームは アラーム状態 のままです。それでも、追加したインスタンスはウォームアップ中も容量として数えられるため、その間は次のインスタンスは起動されません。
ウォームアップの 180 秒が過ぎると、追加したインスタンスのメトリクスが集計に入ります。そのときアラームがまだ アラーム状態 なら、もう 1 台追加されます。今回は、集計に入った直後のデータポイントがまだ 60% 以上だったため、1 台目の追加から 4 分後に 2 台目が追加されました。その後、平均の CPU 使用率は 50% ほどに下がり、アラームは OK に戻りました。
warmup-lab-asg の「アクティビティ」タブで、インスタンスの起動の間隔が、ウォームアップの 180 秒より長く空いていることを確認します。
CloudWatch の「アラーム」で warmup-lab-cpu-high を開き、グラフで確認します。
クラウドおさるアラームが鳴りっぱなしでも、当番の着替えが終わるまでは次の当番を呼ばなかったでござる。着替え中の当番も人数に数えているから、慌てて呼び足さないのでござるな。
手順 5: 正午前に台数を増やすスケジュールを作る
毎日正午に混むことが分かっている前提で、11:50 に台数を増やしておくスケジュールを作ります。
warmup-lab-asg の「自動スケーリング」タブの「予定されたアクション」で「予定されたアクションを作成する」をクリックし、以下を設定します。
- 名前:
warmup-lab-before-noon - 希望する容量:
2、最小:2、最大:4 - 反復:
Cron（デフォルトは一度）を選び、表示された入力欄に50 11 * * * - タイムゾーン:
Asia/Tokyo（デフォルトはEtc/UTC。検索欄に入力して選びます） - 開始日: 明日の日付（
YYYY/MM/DDの形式）。開始時刻はデフォルトの00:00のまま
「作成」をクリックし、「予定されたアクション」の一覧に warmup-lab-before-noon が表示されることを確認します。実際の運用では、混雑が終わる時刻に最小の台数を戻すアクションもあわせて作ります。
クラウドおさる「起動に時間がかかる」と言われたらウォームアップ、「毎日決まった時刻に混む」と言われたらスケジュールか予測でござる。スロースタートやキャッシュは負荷の受け方を変えるだけで、いつ増やすかの判断は変えない、と見分けられるかが肝でござるな。
まとめ
| 要件 | 選ぶもの |
|---|---|
| メトリクスを目標値に保ちたい（ほとんどのケース） | ターゲット追跡スケーリング |
| 超過幅ごとに増やす台数を決めたい | ステップスケーリング |
| 起動から応答まで時間がかかり、過剰にスケールアウトする | デフォルトのインスタンスのウォームアップを有効にする |
| 混む時刻が決まっている | スケジュールされたスケーリング（タイムゾーンを指定） |
| 日・週の周期で負荷が変わる | 予測スケーリング（予測のみモードで確かめてから適用） |
- ウォームアップ中のインスタンスは、メトリクスの集計には入らず、容量には入る。そのため同じ範囲のアラーム超過が続いてもスケールアウトは 1 回で済み、スケールインもウォームアップが終わるまで止まる
- デフォルトのインスタンスのウォームアップは既定で無効。0〜3600 秒で、分からなければ 300 秒から調整する。ポリシー側で指定しなければグループの値が使われる
- スケジュールされたアクションのタイムゾーンの既定は UTC。1 グループに 125 個まで
- 予測スケーリングは 24 時間以上のデータで予測を始め、48 時間先までの予測を 6 時間ごとに更新する
参照先
- Auto Scaling グループに対するインスタンスのデフォルトウォームアップを設定する – Amazon EC2 Auto Scaling
- グループに対するインスタンスのデフォルトウォームアップを有効にする – Amazon EC2 Auto Scaling
- Amazon EC2 Auto Scaling のステップおよび簡易スケーリングポリシー – Amazon EC2 Auto Scaling
- スケールアウト用のステップスケーリングポリシーを作成する – Amazon EC2 Auto Scaling
- Amazon EC2 Auto Scaling のターゲットトラッキングスケーリングポリシー – Amazon EC2 Auto Scaling
- Amazon EC2 Auto Scaling のスケジュールされたスケーリング – Amazon EC2 Auto Scaling
- スケジュールされたアクションの作成 – Amazon EC2 Auto Scaling
- 予測スケーリングの仕組み – Amazon EC2 Auto Scaling
- Application Load Balancer のターゲットグループ属性を編集する – Elastic Load Balancing
