EC2 WebAP-RDS 構成に Auto Scaling を追加し、負荷に応じた自動スケールアウト／インを実現する
このハンズオンでは「EC2 WebAP-RDS ハンズオン」で構築した ALB + EC2 + RDS 構成に EC2 Auto Scaling を追加します。手動で管理していた WebAP サーバーを Auto Scaling グループ（ASG）に置き換え、CPU 負荷に応じて自動的にインスタンスが増減する仕組みを構築します。
| 項目 | 内容 |
|---|---|
| 対象サービス | EC2 Auto Scaling、起動テンプレート、ALB、CloudWatch |
| 主な学習内容 | AMI 作成・起動テンプレート・ASG 設定・ターゲット追跡スケーリング・負荷テスト |
| 所要時間 | 75〜90 分 |
| 難易度 | ★★★☆☆（中級者向け） |
| 前提知識 | EC2 WebAP-RDS ハンズオン修了推奨 |
| 費用目安 | 約 1〜3 USD（EC2 稼働時間・スケールアウト台数による） |
| 方式 | 説明 | このハンズオンでの扱い |
|---|---|---|
| ターゲット追跡 | CPU 使用率などのメトリクスを目標値に保つよう自動調整 | ✅ ステップ 4 で設定 |
| ステップスケーリング | メトリクスの閾値に応じてステップ単位で増減 | 参考として説明 |
| スケジュールスケーリング | 日時指定でキャパシティを事前に変更 | ✅ ステップ 6 で設定 |
| リソース | 名前 | 内容 |
|---|---|---|
| AMI | handson-webap-ami | 既存 WebAP EC2 から作成（Nginx + Node.js 設定済み） |
| 起動テンプレート | handson-lt | ASG がインスタンスを起動する際のひな形 |
| Auto Scaling グループ | handson-asg | 最小 2 / 希望 2 / 最大 6、2 AZ 分散配置 |
| スケーリングポリシー | handson-cpu-policy | CPU 使用率 50% を維持するターゲット追跡 |
| リソース | 名前 | 確認方法 |
|---|---|---|
| VPC | handson-vpc | VPC コンソール → お使いの VPC |
| プライベートサブネット（WebAP 用） | handson-subnet-private-webap-1a / 1c | VPC → サブネット |
| ALB | handson-alb | EC2 → ロードバランサー |
| ターゲットグループ | handson-tg-webap | EC2 → ターゲットグループ |
| セキュリティグループ | sg-webap | EC2 → セキュリティグループ |
| IAM インスタンスプロファイル | handson-cwl-ec2-role（または同等） | IAM → ロール |
| WebAP EC2（AMI 取得元） | handson-webap-1a | EC2 → インスタンス |
ASG が正常動作することを確認するまで、既存の handson-webap-1a と handson-webap-1c は削除しないでください。ターゲットグループへの接続をASG に切り替えるのはステップ 3 で行います。
Nginx + Node.js がセットアップ済みの EC2 インスタンスから AMI（Amazon Machine Image）を作成します。この AMI が Auto Scaling グループが新しいインスタンスを起動するためのひな形になります。
EC2 コンソール → 「インスタンス」 で handson-webap-1a を選択します。
「アクション」→「イメージとテンプレート」→「イメージを作成」 をクリックします。
「イメージを作成」をクリックします。
チェックを入れると EC2 インスタンスを停止せず AMI を作成します（稼働したままキャプチャ）。ファイルシステムの整合性は若干低下しますが、ダウンタイムが発生しないためハンズオン目的には適切です。
EC2 コンソール左メニュー → 「AMI」 を開きます。handson-webap-ami のステータスが 「利用可能」 になるまで待ちます（5〜10 分程度）。
AMI ID（ami-xxxxxxxxxxxxxxxxx）をメモしておきます。
AMI ステータスが「利用可能」になれば次のステップへ進めます。
Auto Scaling グループがインスタンスを起動する際に参照する「起動テンプレート」を作成します。インスタンスタイプ・AMI・セキュリティグループ・IAM ロールなどを定義します。
EC2 コンソール左メニュー → 「起動テンプレート」→「起動テンプレートを作成」 をクリックします。
t2.micro は旧世代です。Auto Scaling グループでは t3.micro を推奨します。t3 は t2 比でバースト性能が高く、同等コストでより高いベースライン CPU を提供します。
「起動テンプレートを作成」をクリックします。
起動テンプレート一覧に handson-lt が表示されれば成功です。
起動テンプレートを使って Auto Scaling グループを作成し、既存の ALB ターゲットグループに接続します。
EC2 コンソール左メニュー → 「Auto Scaling グループ」→「Auto Scaling グループを作成する」 をクリックします。
「次へ」をクリックします。
「次へ」をクリックします。
EC2: インスタンスが起動しているかのみ確認。アプリが応答しなくても「正常」と判定されることがある。
ELB: ALB がアプリへの HTTP リクエストで確認。アプリが異常なインスタンスを自動置換するため、本番では ELB 推奨。
「次へ」をクリックします。
「次へ」→「次へ」→「次へ」→「Auto Scaling グループを作成する」をクリックします。
ASG が管理するインスタンスが「正常」になったら（2〜3 分後）、手動で作成した既存の EC2 を ALB ターゲットグループから切り離します。
EC2 コンソール → 「ターゲットグループ」→ handson-tg-webap →「ターゲット」タブ を開き、handson-webap-1a と handson-webap-1c を選択して 「登録解除」 をクリックします。
ターゲットグループの「ヘルスチェックのステータス」が healthy になった ASG インスタンスが 2 台以上あることを確認してから既存 EC2 を切り離してください。
ターゲットグループで ASG が管理する 2 台のインスタンスだけが healthy 状態になり、ALB 経由でアプリにアクセスできれば移行完了です。
CPU 使用率 50% を目標値とするターゲット追跡スケーリングポリシーを設定します。
EC2 コンソール → 「Auto Scaling グループ」→ handson-asg→「自動スケーリング」タブ → 「ダイナミックスケーリングポリシーを作成する」 をクリックします。
「作成」をクリックします。
CPU 使用率が 50% を超えると インスタンスをスケールアウト、50% 未満が続くと スケールインします。AWS が CloudWatch アラームを 2 つ（スケールアウト用・スケールイン用）自動作成します。ウォームアップ期間中の新インスタンスは集計から除外されます。
CloudWatch コンソール → 「アラーム」 を開くと、TargetTracking-handson-asg-AlarmHigh-* と TargetTracking-handson-asg-AlarmLow-* の 2 つが自動作成されています。
Auto Scaling グループの「自動スケーリング」タブに handson-cpu-policy が表示されれば設定完了です。
stress コマンドで意図的に CPU 負荷をかけ、自動スケールアウトを確認します。
EC2 コンソール → インスタンス一覧で、ASG が起動した WebAP インスタンスを 1 台選択します（名前が handson-asg となっているもの）。「接続」→「Session Manager」→「接続」 をクリックします。
ターゲット追跡は グループ全体の平均 CPU で判断します。1 台だけに負荷をかけても 2 台平均で 50% を超えない場合があります。もう 1 台にも同様の負荷をかけてください。
CloudWatch コンソール → 「アラーム」→ TargetTracking-handson-asg-AlarmHigh-* を確認します。アラーム状態が「アラーム中」になると、数分後にインスタンスが自動追加されます。
EC2 コンソール → 「Auto Scaling グループ」→ handson-asg →「アクティビティ」タブ でスケールアウトイベントのログを確認できます。
| 確認場所 | 期待される動作 | 所要時間目安 |
|---|---|---|
| CloudWatch アラーム | AlarmHigh が「アラーム中」になる | 3〜5 分（1 分間隔メトリクスのため） |
| ASG アクティビティ | 「Launching a new EC2 instance」のログ | アラーム後 1〜2 分 |
| EC2 インスタンス | 新しいインスタンスが「実行中」になる | 1〜3 分 |
| ターゲットグループ | 新インスタンスが「healthy」になる | ヘルスチェック設定による |
Session Manager のターミナルで Ctrl+C を押して stress を停止します。CPU 使用率が 50% 未満に下がると、スケールイン保護期間（デフォルト 300 秒） 後にインスタンスが自動削除されます。
スケールアウトは素早く（CPU が高いと即応）、スケールインは保守的（冷却期間あり）に設計されています。これは短期的な負荷低下でインスタンスを削除してしまう「フラッピング」を防ぐためです。
CPU 負荷時にインスタンスが増加し、負荷を停止後に最小台数（2 台）に戻れば Auto Scaling の動作確認完了です。
業務時間開始前にインスタンスを事前に増やし、深夜に最小構成に戻す定期スケジュールを設定します。
EC2 コンソール → 「Auto Scaling グループ」→ handson-asg →「スケジュールされたアクション」タブ → 「スケジュールされたアクションを作成する」 をクリックします。
「作成」をクリックします。
「作成」をクリックします。
AWS のスケジュールスケーリングの Cron 式は UTC です。JST（UTC+9）で設定する場合は 9 時間引いた値を使ってください。0 23 * * 0-4 は UTC 23:00 = JST 翌 8:00（月〜金）を意味します。
スケジュールスケーリングとダイナミックスケーリング（ターゲット追跡）は 同時に動作 します。スケジュールで最小 4 台に設定した後、さらに CPU 負荷が上がればダイナミックスケーリングで最大 6 台まで自動拡張されます。
| 状況 | 最小 | 最大 | 動作 |
|---|---|---|---|
| 深夜（スケジュール適用後） | 2 | 6 | CPU に応じて 2〜6 台 |
| 業務時間（スケジュール適用後） | 4 | 6 | CPU に応じて 4〜6 台（最低 4 台保証） |
スケジュールされたアクション一覧に morning-scale-out と night-scale-in が表示されれば設定完了です。
EC2 インスタンス（ASG 管理分も含む）・ALB・RDS・NAT Gateway がすべて課金対象です。
handson-asg → 「削除」handson-webap-1a / handson-webap-1c → 「インスタンスの状態」→「終了」
handson-lt → 「削除」
handson-webap-ami →「アクション」→「AMI の登録解除」| 習得したスキル | 実践内容 |
|---|---|
| AMI 作成 | 既存インスタンスからゴールデン AMI を作成（再起動なし） |
| 起動テンプレート | インスタンスタイプ・AMI・SG・IAM ロールの定義 |
| Auto Scaling グループ | 2 AZ 分散・ALB 統合・ELB ヘルスチェック |
| ターゲット追跡スケーリング | CPU 50% 目標・自動スケールアウト / スケールイン |
| スケールアウトテスト | stress コマンドで CPU 負荷 → CloudWatch アラーム → ASG 動作確認 |
| スケジュールスケーリング | Cron 式（UTC）で業務時間帯の事前スケールアウト |