Auto Scaling のウォームアップとは ── 起動が遅いアプリでインスタンスが増えすぎるのを防ぐ
記事の「実践」を 1 項目ずつ進めるためのページです。AWS マネジメントコンソールで操作したら、右の一覧にチェックを入れてください。チェックはこのブラウザに保存されます。
前提条件
- リージョン:
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 | 同上 ※スケーリングポリシーは作らない |
> [!WARNING] > ALB と EC2 は起動している間ずっと課金されます。負荷をかけるとインスタンスが増えるため、検証が終わったら必ず削除してください。
手順 1: デフォルトのインスタンスのウォームアップを設定する
AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します。
上部の検索バーに EC2 と入力し、「EC2」を選択します。左側ナビゲーションの「Auto Scaling」→「Auto Scaling グループ」を選択し、warmup-lab-asg を開きます。
「詳細」タブの「高度な設定」で「編集」をクリックし、以下を設定します。
- 「デフォルトのインスタンスのウォームアップを有効にする」にチェックを入れ、表示された入力欄に
180秒
その他の項目はデフォルトのままにして、「更新」をクリックします。起動から 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-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 が表示されることを確認します。実際の運用では、混雑が終わる時刻に最小の台数を戻すアクションもあわせて作ります。