CDK + Auto Scaling Group で Webアプリをオートスケーリング構成にする【CPU負荷でスケールアウト体験】

はじめに

「EC2 が 1台では負荷が集中したときに対応できない」「障害で EC2 が落ちたら手動で復旧しなければならない」——これを解決するのが Auto Scaling Group（ASG） です。

この記事では、CDK Pipelines + CodeDeploy ハンズオンで構築した 単一 EC2 構成を、Auto Scaling Group + Launch Template にアップグレードします。CPU 負荷をかけて実際にスケールアウトを体験し、新しいインスタンスへ CodeDeploy が自動で WAR をデプロイする様子を確認します。

GitHub リポジトリ
  ↓ push（自動トリガー）
CodePipeline (my-cdk5-pipeline)
  ├── Source:        GitHub (CodeConnections 経由)
  ├── Build(Synth):  CodeBuild — cdk synth
  ├── Mutate:        パイプライン自己更新（セルフミューテーション）
  ├── InfraDeploy:   CloudFormation — VPC / ASG / RDS / ALB
  └── BuildAndDeployApp: ← post step
        CodeBuild: mvn package → webapp.war 生成
        CodeDeploy: ASG の全 Tomcat に一括デプロイ
                ↓
       [ALB: my-cdk5-alb]
                ↓
       ┌─────────────────────────────┐
       │  Auto Scaling Group (ASG)   │
       │  my-cdk5-asg                │
       │  ・最小 1台 / 最大 3台      │
       │  ・CPU 60% 超でスケールアウト│
       │  ├── EC2: Tomcat + WAR      │
       │  └── EC2: Tomcat + WAR（追加分）│
       └─────────────────────────────┘
                ↓
       [RDS: my-cdk5-rds-mysql]  ← MySQL 8.0

このハンズオンで体験できること：

• git push するだけで ASG の全インスタンスへ WAR が自動デプロイされる
• CPU に負荷をかけてスケールアウトを体験する
• スケールアウト後の新インスタンスへ CodeDeploy が自動で WAR をデプロイする（ライフサイクルフック）
• キーペア不要で SSM Session Manager からブラウザ経由でインスタンスに接続する

この記事は CDK Pipelines + CodeDeploy ハンズオン（cdk-webapp-pipeline） の発展記事です。
CodeDeploy・CDK Pipelines の基本を体験済みの方向けです。コード詳細は GitHub を参照してください。

-->

キーワード解説

cdk-webapp-pipeline との比較

ファイル構成と役割

cdk-asg-webapp/
├── app.py                     ← CDK アプリ エントリポイント
├── cdk.json                   ← CDK 設定（key_name/my_ip なし・asg_* 追加）
├── appspec.yml                ← CodeDeploy: WAR 配置手順とライフサイクルフック
├── scripts/
│   ├── stop_tomcat.sh
│   ├── cleanup.sh
│   └── start_tomcat.sh
├── app/                       ← Spring Boot Webアプリ（Java）
├── pipeline/
│   └── pipeline_stack.py      ← CodePipeline + post step（ASG 対応）
├── stages/
│   └── deploy_stage.py        ← Stage（WebappStack を内包）
├── stacks/
│   └── webapp_stack.py        ← インフラスタック（ASGName を CfnOutput で公開）
└── components/
    └── webapp_construct.py    ← ASG ベースの L3 Construct

詳細なコードは GitHub を参照してください。

使用するAWSサービス

注意: ALBは無料枠がありません。スケールアウト中はEC2が複数台起動するため料金も増加します。ハンズオン後は必ずリソースを削除してください。

前提条件

AWS 認証確認:

aws sts get-caller-identity

CDK Bootstrap 確認:

aws cloudformation describe-stacks ^
  --stack-name CDKToolkit ^
  --query "Stacks[0].StackStatus" ^
  --output text ^
  --region ap-northeast-1

SSH キーペアは不要です。このハンズオンでは SSM Session Manager を使って EC2 に接続するため、キーペアの作成・設定は必要ありません。

作業順序

① プロジェクトのセットアップ（Python 仮想環境）
      ↓
② GitHub との接続を作成する（CodeConnections）
      ↓
③ cdk.json を設定する
      ↓
④ コードを全て GitHub にプッシュする（重要！）
      ↓
⑤ パイプラインスタックをデプロイする（初回のみ手動）
      ↓
⑥ パイプラインの実行状況を確認する
      ↓
⑦ アプリへアクセスする
      ↓
⑧ Auto Scaling を体験する（CPU 負荷 → スケールアウト → 自動デプロイ）
      ↓
⑨ CI/CD を体験する（アプリ変更を push で自動反映）
      ↓
⑩ リソース削除

① プロジェクトのセットアップ

cd C:\my-aws\aws-learning-projects\cdk-asg-webapp

python -m venv .venv

.venv\Scripts\activate

pip install -r requirements.txt

プロンプトの先頭に (.venv) が表示されれば仮想環境が有効になっています。

重要: CDK コマンドはすべてこの仮想環境が有効な状態で実行する必要があります。
ターミナルを開き直した際は必ず最初に以下を実行してください。

cd C:\my-aws\aws-learning-projects\cdk-asg-webapp
.venv\Scripts\activate

② GitHub との接続を作成する（CodeConnections）

cdk-webapp-pipeline を実施済みの場合: 同じリポジトリ aws-learning-projects を扱うため、
既存の接続（my-github-connection）をそのまま再利用できます。
② はスキップして、ARN の確認（②-4）から始めてください。

CodePipeline が GitHub リポジトリを監視するために、GitHub との接続（CodeConnections） を作成します。

重要: AWS コンソールと GitHub の操作は同じブラウザで行ってください。

接続を作成する

1. AWS コンソール検索（Alt+S）で CodePipeline と入力 → CodePipeline を開く
2. 左サイドバー → 「設定」 → 「接続」
3. リージョンが 東京（ap-northeast-1） になっていることを確認する
4. 「接続を作成」をクリック
5. プロバイダー: GitHub を選択
6. 接続名: my-github-connection（任意）
7. 「GitHub に接続する」をクリック

GitHub App をインストールする

8. 「Authorize」をクリック → AWS コンソールの「GitHub 接続設定」画面に自動で戻る
9. 「新しいアプリをインストールする」をクリック
10. 「Only select repositories」 を選択 → aws-learning-projects を追加
11. 「Install & Authorize」をクリック（メール認証コードが求められる場合は入力）
12. AWS コンソールに自動でリダイレクトされる → 「接続」ボタンをクリック

接続 ARN を確認する

接続一覧から接続の ARN をコピーします。

arn:aws:codeconnections:ap-northeast-1:123456789012:connection/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

ステータスが 「利用可能」 になっていることを確認してから次に進んでください。

控えておく情報: 接続 ARN（arn:aws:codeconnections:...）

③ cdk.json の設定

cdk.json の context セクションを自分の環境に合わせて編集します。

{
  "context": {
    "employee_id": "my",
    "db_password": "Handson1234!",
    "tomcat_version": "10.1.28",
    "asg_min_capacity": 1,
    "asg_max_capacity": 3,
    "asg_desired_capacity": 1,
    "github_owner": "your-github-username",
    "github_repo": "aws-learning-projects",
    "github_branch": "main",
    "connection_arn": "arn:aws:codeconnections:ap-northeast-1:..."
  }
}

key_name・my_ip は不要です。SSH の代わりに SSM Session Manager を使うため、キーペアやSSH許可IPの設定は必要ありません。

④ コードを GitHub にプッシュする（重要！）

cdk deploy の前に必ずプロジェクト全体を push してください。
パイプラインが cdk synth・Maven ビルドを実行する際、GitHub から取得したコードを使うためです。

cd C:\my-aws\aws-learning-projects

git add cdk-asg-webapp/
git commit -m "feat: cdk-asg-webapp ハンズオンを追加"
git push origin main

⑤ パイプラインスタックのデプロイ（初回のみ）

cd C:\my-aws\aws-learning-projects\cdk-asg-webapp

.venv\Scripts\activate

cdk synth

cdk deploy my-AsgPipelineStack

「Do you wish to deploy these changes?」に y を入力します。

所要時間: パイプラインスタック自体のデプロイは 3〜5 分。その後パイプラインが自動起動します。

デプロイ完了後、CodePipeline が自動起動します:

RDS の起動に時間がかかるため、InfraDeploy は 10〜20 分かかることがあります。

⑥ パイプラインの実行状況を確認する

1. AWS コンソール → CodePipeline を開く
2. my-cdk5-pipeline を選択
3. 各ステージが 「成功」 になるまで待つ

CloudFormation スタックの命名規則

{StageName}-{StackName}

my-AsgPipelineStack（パイプライン）と my-Deploy-WebappStack（インフラ）の 2つが別スタックとして CloudFormation に表示されます。

CloudFormation Outputs の確認

aws cloudformation describe-stacks ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1 ^
  --query "Stacks[0].Outputs"

控えておく情報: ALBEndpoint、RDSEndpoint

⑦ アプリへアクセスする

BuildAndDeployApp ステージが完了したら、ALB 経由でアプリにアクセスします。

http://<ALBEndpoint>/webapp/

http://<ALBEndpoint>/（ルートパス）では Tomcat のデフォルト画面が表示されます。/webapp/ が必要です。

ALB の DNS 名を CLI で確認する場合:

aws cloudformation describe-stacks ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1 ^
  --query "Stacks[0].Outputs[?OutputKey=='ALBEndpoint'].OutputValue" ^
  --output text

ASG インスタンスを確認する

AWS コンソール → EC2 → Auto Scaling グループ → my-cdk5-asg

• インスタンス タブを開く
• 1台の EC2 が InService になっていることを確認する

⑧ Auto Scaling を体験する

ASG のスケールアウト・スケールインを実際に体験します。CPU 使用率が 60% を超えると自動でインスタンスが追加されます。

現在の ASG 状態を確認する

aws autoscaling describe-auto-scaling-groups ^
  --auto-scaling-group-names my-cdk5-asg ^
  --region ap-northeast-1 ^
  --query "AutoScalingGroups[0].{Desired:DesiredCapacity,Min:MinSize,Max:MaxSize,Instances:Instances[*].{Id:InstanceId,State:LifecycleState}}"

出力例（初期状態: 1台が InService）:

{
    "Desired": 1,
    "Min": 1,
    "Max": 3,
    "Instances": [{ "Id": "i-0abc123...", "State": "InService" }]
}

SSM Session Manager でインスタンスに接続する

キーペアは不要です。AWS コンソールから直接ブラウザでターミナルを開けます。

1. EC2 → インスタンス → 対象インスタンスを選択
2. 「接続」ボタンをクリック
3. 「Session Manager」タブ → 「接続」をクリック

ブラウザでターミナルが開きます。

CLI から接続する場合:

rem インスタンス ID を取得
aws autoscaling describe-auto-scaling-groups ^
  --auto-scaling-group-names my-cdk5-asg ^
  --region ap-northeast-1 ^
  --query "AutoScalingGroups[0].Instances[0].InstanceId" ^
  --output text

rem 接続（Session Manager Plugin が必要）
aws ssm start-session ^
  --target i-0abc123def456789 ^
  --region ap-northeast-1

CPU 負荷をかける（スケールアウトをトリガーする）

インスタンスに接続したターミナルで実行します:

cd /tmp && stress-ng --cpu 2 --timeout 300s &
echo "CPU stress started (PID: $!)"

スケールアウトを監視する

1. AWS コンソール → CloudWatch → メトリクス → EC2 → Auto Scaling グループ別
2. my-cdk5-asg の CPUUtilization を確認
3. CPU が 60% を超えると、約 1〜3 分後にスケールアウトが始まる

ASG のインスタンス数を 10秒ごとに確認:

:loop
aws autoscaling describe-auto-scaling-groups ^
  --auto-scaling-group-names my-cdk5-asg ^
  --region ap-northeast-1 ^
  --query "AutoScalingGroups[0].Instances[*].{Id:InstanceId,State:LifecycleState}" ^
  --output table
timeout /t 10
goto loop

しばらく待つと 2台目のインスタンスが起動し InService になります。

スケールアウト後の CodeDeploy 自動デプロイを確認する

新しいインスタンスが起動すると、CodeDeploy が自動的に最新の WAR をデプロイします。

AWS コンソール → CodeDeploy → my-cdk5-deploy-app
→ デプロイグループ → デプロイ履歴

新しいデプロイが自動で実行されていることを確認します。パイプラインを手動実行しなくても、ライフサイクルフックにより新インスタンスへ最新 WAR が自動デプロイされます。

スケールインを確認する

CPU 負荷が終了（300秒後）すると CPU 使用率が下がり、スケールインが始まります。

ターゲット追跡ポリシーのデフォルトのスケールイン保護時間は 300秒。
負荷終了後、約 5〜10 分でインスタンス数が 1台に戻ります。

途中で手動停止する場合:

pkill stress-ng

⑨ CI/CD を体験する（アプリ変更を push で自動反映）

アプリのコードを変更して push するだけで、ASG の全インスタンスへ自動デプロイされることを確認します。

アプリの HTML を変更する

app/src/main/resources/templates/index.html を開き、以下の行を変更します:

変更前:

<h1>Spring Boot + RDS Item Manager</h1>

変更後:

<h1>Spring Boot + RDS Item Manager (ASG)</h1>

コミット＆プッシュ

cd C:\my-aws\aws-learning-projects
git add cdk-asg-webapp/app/src/main/resources/templates/index.html
git commit -m "feat: update webapp UI for ASG"
git push

パイプラインの自動起動を確認する

1. AWS コンソール → CodePipeline → my-cdk5-pipeline
2. push 後、数十秒以内にパイプラインが自動起動することを確認
3. BuildAndDeployApp ステージが完了したらブラウザで /webapp/ を更新する

「(ASG)」が付いた見出しが表示されれば、ASG 構成での CI/CD が正常に動作しています。

注意: InfraDeploy ステージはインフラに変更がない場合は「変更なし」でスキップされます。

⑩ リソース削除

課金を止めるために、ハンズオン完了後は必ず削除します。

ASG を含むスタックを削除すると、全インスタンスが自動終了されます。

削除順序が重要です。インフラスタック（my-Deploy-WebappStack）を先に削除してから、パイプラインスタック（my-AsgPipelineStack）を削除します。

1. インフラスタックを削除する

aws cloudformation delete-stack ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1

aws cloudformation wait stack-delete-complete ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1

echo WebappStack 削除完了

RDS の削除に 10〜15 分かかります。wait コマンドが完了するまでそのまま待ってください。

2. パイプラインスタックを削除する

aws cloudformation delete-stack ^
  --stack-name my-AsgPipelineStack ^
  --region ap-northeast-1

aws cloudformation wait stack-delete-complete ^
  --stack-name my-AsgPipelineStack ^
  --region ap-northeast-1

echo AsgPipelineStack 削除完了

3. SSM パラメータを削除する

aws ssm delete-parameter ^
  --name "/my/cdk5/db-password" ^
  --region ap-northeast-1

4. 仮想環境の終了

deactivate

5. GitHub との接続を削除する（オプション）

次のハンズオンでも使う場合はそのままでよいです。

CodePipeline → 設定 → 接続 → my-github-connection → 「削除」

削除確認

aws cloudformation list-stacks ^
  --region ap-northeast-1 ^
  --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE ^
  --query "StackSummaries[?contains(StackName, 'my-')].StackName"

空のリスト [] が返れば削除完了です。

削除されるリソース一覧

Auto Scaling のポイント解説

ASG ライフサイクルフックで新インスタンスへ自動デプロイ

CDK で codedeploy.ServerDeploymentGroup(auto_scaling_groups=[self.asg]) と指定すると、CodeDeploy が ASG にライフサイクルフックを自動設定します。

スケールアウト発生
  ↓
ASG: 新しいインスタンスを Launch Template から起動
  ↓
EC2 UserData: Java・Tomcat・CodeDeploy エージェントをインストール
  ↓
ライフサイクルフック: CodeDeploy が最新 WAR を自動デプロイ
  ↓
ALB ターゲットグループに追加（InService）

これにより、スケールアウト後の新インスタンスでもユーザーは何もしなくて済みます。

cdk-webapp-pipeline → cdk-asg-webapp の変化

cdk-webapp-pipeline               cdk-asg-webapp
─────────────────────────         ─────────────────────────
EC2 Instance（固定 1台）           Auto Scaling Group（1〜3台）
  ↓                                 ↓
SSH（キーペア必要）                 SSM Session Manager（キーペア不要）
  ↓                                 ↓
CodeDeploy: 名前タグで指定          CodeDeploy: ASG を直接指定
  ↓                                 ↓
スケールアウト不可                  CPU 60% 超で自動スケールアウト
  ↓                                 ↓
新インスタンスに WAR なし          ライフサイクルフックで自動 WAR デプロイ

トラブルシューティング

CodeDeploy 失敗時のログ確認:

AWS コンソール → CodeDeploy → my-cdk5-deploy-app → デプロイグループ → デプロイ履歴 → 失敗したデプロイ → 「ログの表示」

まとめ

ASG を導入することで「単一障害点の排除・自動スケーリング・スケールアウト時の自動デプロイ」を一度に体験できました。

コンソールで3層構成を視覚的に学びたい場合は AWSコンソール版ハンズオン、CDK の基本は CDK版ハンズオン（cdk-alb-ec2-rds）、カスタム Construct は CDK カスタム Construct ハンズオン、インフラ CI/CD は CDK Pipelines ハンズオン、アプリ CI/CD は CDK + CodeDeploy ハンズオン を参照してください。