ステップ４：ALB、ターゲットグループを利用したEC2インスタンスのスケーリング

今回のステップの概要とECサイトとの関連について

このステップでは、前回までに構築したECサイトを、より多くのアクセスに対応できる堅牢なシステムへと進化させます。具体的には、ALB（Application Load Balancer）を導入し、複数のEC2インスタンスでトラフィックを分散させる構成を作ります。また、マルチAZ（複数のアベイラビリティーゾーン）を活用することで、システムの可用性と耐障害性を高めます。

ECサイトにとって、この構成は「お店の支店を複数開いて、どの支店も同じサービスを提供できるようにする」ようなものです。たとえば、あるお店が混雑していたら、別のお店に案内することで、お客さんをスムーズに対応できます。また、1つのお店が何らかの理由で営業できなくなっても、他のお店が営業を続けられるので、サービスが止まることがありません。

このステップで学ぶこと

• ALB（Application Load Balancer）の作成と設定方法
• ターゲットグループの作成と設定方法
• EC2インスタンスのオートスケーリングの設定方法
• マルチAZ構成によるシステムの可用性向上
• ヘルスチェックの設定と監視方法

リソースの関わりと構成説明

ステップ4で作成するリソースは、ECサイトの拡張性と可用性を高めるものです。それぞれのリソースがECサイトにどのように関わるのかを説明します。

AMI（Amazon Machine Image）とECサイトの関わり

AMI「ec-site-web-ami」は、ECサイトの「店舗設計図」のような役割を果たします。この設計図があることで、同じ内装・設備を持つ店舗を簡単に複数作ることができます。これにより、すべての店舗（EC2インスタンス）で同じECサイトアプリケーションが動作することが保証されます。

ALB（Application Load Balancer）とECサイトの関わり

ALB「ec-site-alb」は、ECサイトの「受付案内係」のような役割を果たします。お客さん（ユーザー）が来店したとき、どの店舗（EC2インスタンス）が空いているかを確認し、最適な店舗に案内します。これにより、一部の店舗に客が集中することを防ぎ、すべての店舗で均等にサービスを提供できます。

ターゲットグループとECサイトの関わり

ターゲットグループ「ec-site-web-tg」は、ALBが案内できる「店舗リスト」のような役割を果たします。また、各店舗が正常に営業しているかを定期的にチェック（ヘルスチェック）し、問題がある店舗には客を案内しないようにします。

オートスケーリングとECサイトの関わり

オートスケーリンググループ「ECサイトASG」は、ECサイトの「店舗管理本部」のような役割を果たします。客（トラフィック）が増えたら自動的に新しい店舗（EC2インスタンス）をオープンし、客が減ったら不要な店舗を閉めることで、コストを最適化します。また、何らかの理由で店舗が閉まってしまった場合も、自動的に新しい店舗をオープンして、サービスを継続します。

実際の手順

実際の手順では、たくさんの設定値を入力することになります。 本文中に設定値が指定されていない場合は、デフォルト値のまま作業を進めてください。

1. セキュリティグループの設定

ALBのセキュリティグループを作成します。これにより、インターネットからALBにアクセスできるようになります。
EC2のセキュリティグループを修正します。これにより、ALBからEC2インスタンスにアクセスできるようになります。ALB以外はEC2インスタンスにアクセスできなくなります。

1-1. ALBセキュリティグループの作成

1. EC2ダッシュボードに移動します。
2. 左側のメニューから「セキュリティグループ」をクリックします。
3. 「セキュリティグループを作成」ボタンをクリックします：
   • セキュリティグループ名：「ec-site-alb-sg」と入力します。
   • 説明：「for ec-site ALB」と入力します。
   • VPC：「ec-site-vpc」を選択します。
   • 「インバウンドルール」の「ルールを追加」ボタンをクリックします。
     • タイプ：「HTTP」を選択します。
     • ソース：「Anywhere-IPv4」を選択します。
     • 「セキュリティグループを作成」ボタンをクリックします。
4. 「セキュリティグループ (sg-xxxxxxxxxxxxxxxxx | ec-site-alb-sg) が正常に作成されました」と表示されることを確認します。

1-2. EC2セキュリティグループの修正

1. 左側のメニューから「セキュリティグループ」をクリックします。
2. 「ec-site-web-sg」を選択します。
3. 「インバウンドルール」タブを選択します。
4. 「インバウンドのルールを編集」ボタンをクリックします。
5. 「削除」ボタンをクリックします。(これによりすべてのIPアドレスからEC2インスタンスにアクセスできるルールを削除します。)
6. 「ルールを追加」ボタンをクリックします。
   • タイプ：「HTTP」を選択します。
   • ソース：「カスタム」を選択します。右隣の空欄には「ec-site-alb-sg」を選択します。(これによりEC2インスタンスにアクセスできるのはALBだけとなります。)
   • 「ルールを保存」ボタンをクリックします。
7. 「インバウンドセキュリティグループのルールが、セキュリティグループで正常に変更されました」と表示されることを確認します。

2. AMI（Amazon Machine Image）の作成

まず、現在動作しているEC2インスタンスから、AMI（システムのスナップショット）を作成します。これにより、同じ設定の新しいインスタンスを簡単に作成できるようになります。

2-1. EC2ダッシュボードにアクセス

1. AWSマネジメントコンソールにログインします。
2. 画面上部の検索バーに「EC2」と入力し、表示される「EC2」をクリックします。
3. EC2ダッシュボードが表示されます。

2-2. AMIの作成前の準備

1. 左側のメニューから「インスタンス」をクリックします。
2. ステップ1で作成したEC2インスタンス「ec-site-web」を選択し、「接続」ボタンをクリックします。
3. 「接続方法」画面で「Session Manager」タブを選択します。
4. 「接続」ボタンをクリックします。
5. 新しいブラウザタブが開き、EC2インスタンスのターミナルセッションが表示されます。
6. 接続に成功すると、Amazon Linux 2023のウェルカムメッセージが表示されます。
7. 以下コマンドを実行しpm2プロセスや既存のソースコードを削除しましょう：

# 特権管理者で作業します
sudo su
# 作業ディレクトリに移動
cd /root/ecommerce-app-v1
# PM2タスク削除
pm2 delete all
# EC2インスタンス起動時のPM2自動起動設定を削除
pm2 unstartup
# PM2ログを削除
pm2 flush
 
#
cd /root/
# 既存ソースコードの削除
rm -rf /root/ecommerce-app-v* /root/ecommerce-app-v*.zip __MACOSX
 
# ファイルが残っていないことを確認（total 0 と表示されればOK）
ll /root
# 80ポートがどのプロセスからも使われていないことを確認（何も表示されなければOK）
netstat -tulpn | grep :80

2-3. AMIの作成

1. 左側のメニューから「インスタンス」をクリックします。
2. ステップ1で作成したEC2インスタンス「ec-site-web」を選択します。
3. 「アクション」→「イメージとテンプレート」→「イメージの作成」をクリックします。
4. 「イメージの作成」：
   • イメージ名：「ec-site-web-ami」と入力します。
   • イメージの説明：「lets hosting ec site」と入力します。
   • 他の設定はデフォルトのままにします。
5. 「イメージの作成」ボタンをクリックします。
6. 「AMIが正常に作成されました」というメッセージが表示されます。

2-4. AMIの状態確認

1. 左側のメニューから「AMI」をクリックします。
2. 作成したAMI「ec-site-web-ami」のステータスが「利用可能」になるまで待ちます（数分かかることがあります）。

3. 起動テンプレートの作成

オートスケーリングで使用する起動テンプレートを作成します。

3-1. 起動テンプレートの作成

1. 左側のメニューから「起動テンプレート」をクリックします。

2. 「起動テンプレートを作成」ボタンをクリックします。

3. 「起動テンプレートの作成」：

   • 起動テンプレート名と説明：
     • 起動テンプレート名：「ec-site-launch-template」と入力します。
     • バージョンの説明：「ec-site-launch-template-1」と入力します。
     • 「Auto Scalingガイダンスを提供する」にチェックを入れます。
   • アプリケーションとOSイメージ：
     • 「自分のAMI」タブの「自己所有」を選択します。
     • Amazon マシンイメージ (AMI)で先ほど作成した「ec-site-web-ami」を選択します。
   • インスタンスタイプ：
     • 「t3.small」を選択します。
   • キーペア：
     • 「キーペアなしで続行」を選択します。
     • （注：Systems Managerセッションマネージャーを使用するため、SSHキーペアは不要です）
   • ネットワーク設定：
     • セキュリティグループ：「ec-site-web-sg」「ec2-rds-1」を選択します。
   • ストレージ：
     • デフォルト設定のままにします。
   • リソースタグ：
     • 「新しいタグを追加」をクリックします。
     • キー：「Name」と入力します。
     • 値：「ec-site-AutoScaling-Instance」と入力します。
   • 高度な詳細：
     • IAMインスタンスプロファイル：ステップ1で作成した「ec-site-web-SSMRole」を選択します。
     • （注：このロールにより、Systems Managerセッションマネージャーを使用してインスタンスに接続できます）
     • User Data（ユーザーデータ）によるWebアプリ自動デプロイ設定

       • Auto Scalingで起動するEC2インスタンスが、常に最新のWebアプリケーションをS3から取得し、pm2で自動起動するには「ユーザーデータ（User Data）」の設定が必要です。

       • 「起動テンプレートの作成」画面の「高度な詳細」セクションにある「ユーザーデータ」欄に、以下のスクリプトを貼り付けてください。

       • arn:aws:secretsmanager:us-east-1:xxxxxxx:secret:xxxxの部分は、ステップ3でメモしたSecrets ManagerのARNに置き換えてください。

         #!/bin/bash
           
         # 起動テンプレート時点ではPATHも環境変数も何も設定されていないので設定する
         export HOME=/root
               
         cd /root
          
         # 1. S3から最新ソース取得＆展開
         aws s3 cp s3://tenarai-blueprint-sample-code-983911888049-us-east-1/ec-site-tenarai-sample/ecommerce-app-v1.zip ./ecommerce-app-v1.zip
         unzip -o ecommerce-app-v1.zip
          
         # 2. ステップ3で メモしたSecrets ManagerのARNを.envファイルに記録します
         cd /root/ecommerce-app-v1
         echo 'AURORA_SECRET_ARN=arn:aws:secretsmanager:us-east-1:xxxxxxx:secret:xxxx' > /root/ecommerce-app-v1/.env
          
         # 3. 依存パッケージインストール
         /root/.local/share/pnpm/pnpm install
         /root/.local/share/pnpm/pnpm build
          
         # 4. pm2でアプリ起動
         /root/.local/share/pnpm/pm2 start
         /root/.local/share/pnpm/pm2 save
         /root/.local/share/pnpm/pm2 startup

4. 「起動テンプレートを作成」ボタンをクリックします。

4. オートスケーリンググループの作成

オートスケーリンググループを作成して、トラフィックに応じて自動的にEC2インスタンスの数を調整できるようにします。

4-1. オートスケーリンググループの作成

1. 左側のメニューから「Auto Scalingグループ」をクリックします。
2. 「Auto Scalingグループの作成」ボタンをクリックします。
3. 「起動テンプレートまたは設定を選択」：
   • Auto Scalingグループ名：「ec-site-asg」と入力します。
   • 起動テンプレート：先ほど作成した「ec-site-launch-template」を選択します。
   • バージョン：「Latest (*)」を選択します。
     • 注意：Defaultではありません
4. 「次へ」ボタンをクリックします。
5. 「インスタンス起動オプションを選択」：
   • VPC：ステップ0で作成した「ec-site-vpc」を選択します。
     • アベイラビリティーゾーンとサブネット：
       • 「ec-site-private-us-east-1a」と「ec-site-private-us-east-1c」を選択します。
6. 「次へ」ボタンをクリックします。
7. ステップ３でロードバランサーとターゲットグループを作成します：
   • ロードバランシング：
     • 「新しいロードバランサーにアタッチする」を選択します。
       • 「ロードバランサーのタイプ」：「Application Load Balancer」
       • 「ロードバランサーの名前」：「ec-site-alb」
       • 「ロードバランサーのスキーム」：「Internet-facing」
         • 「Internal」はインターネットに公開しないVPC内部で利用するためのものです。
       • 「アベイラビリティーゾーンとサブネット」：「パブリック」
         • ドロップダウンリストをクリックし、パブリックを選択してください。
       • 「リスナーとルーティング」の「デフォルトルーティング (転送先)」：「ターゲットグループを作成する」
       • 「新しいターゲットグループ名」：「ec-site-web-tg」
8. 「次へ」ボタンをクリックします。
9. 「グループサイズとスケーリングポリシーを設定」：
   • グループサイズ：
     • 希望するキャパシティー：「1」と入力します。
     • 最小キャパシティー：「1」と入力します。
     • 最大キャパシティー：「4」と入力します。
   • スケーリングポリシーはなしを選択します。
10. 「次へ」ボタンをクリックします。
11. 「通知を追加」画面では、デフォルト設定のままで「次へ」ボタンをクリックします。
12. 「タグを追加」画面では、デフォルト設定のままで「次へ」ボタンをクリックします。
13. 「確認」画面で内容を確認し、「Auto Scalingグループの作成」ボタンをクリックします。

4-2. ALBセキュリティグループの修正

1. 左側のメニューから「ロードバランサー」をクリックします。
2. 「ec-site-alb」を選択します。
3. 「セキュリティ」タブを選択します。
4. 「編集」ボタンをクリックします。
   • 「ec-site-web-sg」と「ec2-rds-1」を削除します。(削除するには×印をクリックします。)
   • 「セキュリティグループ」のドロップダウンリストから「ec-site-alb-sg」を選択します。
   • 「変更内容の保存」ボタンをクリックします。
5. 「セキュリティグループが正常に変更されました。」と表示されることを確認します。

4-3. オートスケーリンググループの確認

1. 作成したオートスケーリンググループ「ec-site-asg」が表示されます。

2. 「インスタンス管理」タブをクリックし、インスタンスが起動していることを確認します（2つのインスタンスが起動するまで数分かかることがあります）。

3. ALBを確認します。左側のメニューから「ロードバランサー」をクリックします。

• ここでDNS名（例：http://ec-site-alb-123456789.us-east-1.elb.amazonaws.com）をメモしておきます。 

4. ターゲットグループを確認します。左側のメニューから「ターゲットグループ」をクリックします。

4-4. スケーリングポリシーの作成

1. 作成したAutoScalingGroup「ec-site-asg」の詳細画面を開き、「オートスケーリングタブ」を開きます。

2. 「動的スケーリングポリシーを作成する」を押し、以下設定を入力します。

   • ポリシータイプ： ターゲット追跡スケーリング
   • スケーリングポリシー名： RequestCountPolicy
   • メトリクスタイプ： ターゲットごとの Application Load Balancer リクエスト数
   • ターゲットグループ： ec-site-web-tg
   • ターゲット値： 25

3. 「作成」を押し、スケーリングポリシーを作成すると以下のような項目が表示されます。

4-5. ALB経由で負荷をかけてスケールアウトを確認する

オートスケーリングが正しく動作するかを確認するため、ローカルPCからALBのDNS名に対して負荷テストツール（例：abコマンド）を使ってリクエストを大量に送り、インスタンス数が自動で増える（スケールアウト）ことを確認します。

まずはALBとターゲットグループ経由でWebサイトが見れるか確認しましょう。

1. ステップ6-3でメモしたALBのDNS名（例：http://ec-site-alb-123456789.us-east-1.elb.amazonaws.com）をブラウザで確認しましょう。 

   • 前回のステップと同じ画面が表示されれば成功です。
   • メトリクスでが変化することも確認できます。（メトリクスの反映には５分ほどかかります。）

2. メトリクスを確認します。

3. AWSコンソールからCloudShell開きます。

4. CloudShellの環境からリクエストを送り負荷をかけてみましょう：

# 送信数: 4000件
# 期間: 4分（240秒, 間隔 0.12秒 ≒ 8.3RPS）
for i in {1..4000}; do curl -sS http://ec-site-alb-1509604451.us-east-1.elb.amazonaws.com/ >/dev/null 2>&1 & sleep 0.12; done; wait

※負荷テストは短時間で行い、不要なコストや他の利用者への影響が出ないよう注意してください。

5. 先ほどと同じように「ec-site-asg」や「ec-site-alb」のメトリクスを確認しリクエストが実際に届いているかどうか確認しましょう。

4-6. CloudWatchでアラームを確認

CloudWatchのアラームも確認しましょう。このアラームを利用してEC2のAutoScalingの判定をしています。AlarmHighがスケールアウトのアラーム、AlarmLowがスケールインのアラームです。

1. 画面上部の検索バーに「CloudWatch」と入力し、表示される「CloudWatch」をクリックします。
2. CloudWatchダッシュボードが表示されます。
3. 左側のメニューから「すべてのアラーム」をクリックします。

4-7. Auto Scaling グループでインスタンス数の増減の履歴を確認

AutoScalingGroupのアクティビティタブではインスタンス数の増減の履歴を確認できます。

1. EC2ダッシュボードに戻ります。
2. 左側のメニューから「Auto Scaling グループ」をクリックします。
3. 「アクティビティ」タブをクリックします。

5. 不必要なインスタンスの停止

1. EC2メニューから「インスタンス」をクリックします。
2. ステップ1で作成したEC2インスタンス「ec-site-web」を選択
3. アクションを開き、「インスタンスを停止」を押してEC2インスタンスを停止します

このステップで何をしたのか

このステップでは、ECサイトの可用性と拡張性を高めるために、ALB（Application Load Balancer）を導入し、複数のEC2インスタンスでトラフィックを分散させる構成を構築しました。また、オートスケーリンググループを設定して、アクセス数に応じて自動的にサーバー数を増減できるようにしました。

ECサイトでどのような影響があるのか

この構成により、ECサイトは多くのアクセスがあっても安定したサービスを提供できるようになりました。たとえば、セール時などのアクセス集中時でも、自動的にサーバーが増えて対応できます。また、サーバーに障害が発生しても、別のサーバーが自動的に引き継ぐため、サービスが停止することなく継続できます。これは、お店が混雑時に自動的に店舗数を増やし、災害時でも別の場所で営業を続けられる体制を整えたことに相当します。

実践チェック：画面キャプチャで証明しよう

下記のチェック項目について、実際にAWSマネジメントコンソールで設定ができていることを確認し、各項目ごとに該当画面のスクリーンショットを撮影して提出してください。

• EC2インスタンスからAMI「ec-site-web-ami」が正常に作成されている
• ターゲットグループ「ec-site-web-tg」が正常に作成されている
• ALB「ec-site-alb」が正常に作成され、ステータスが「アクティブ」になっている
• EC2セキュリティグループ「ec-site-web-sg」が更新され、ALBからのトラフィックのみを許可している
• 起動テンプレート「ec-site-launch-template」が正常に作成され、IAMロール「EC2SSMRole」が設定されている
• オートスケーリンググループ「ec-site-asg」が正常に作成され、2つのインスタンスが起動している
• ALBのDNS名にアクセスすると、ECサイトが正常に表示される
• 商品の注文処理が正常に行われ、データベースに注文情報が保存される

構成図による理解度チェック

ステップ3の構成図を元に、このステップで追加・変更したリソースを反映させ、より実践的な構成図を完成させましょう。

なぜ構成図を更新するのか？

• 可用性の理解: ALBやAuto Scaling、マルチAZといった、システムの可用性・耐障害性を高めるための仕組みがどのように連携するのかを把握します。
• スケーラビリティの理解: アクセス負荷に応じてサーバーが自動で増減する様子を図で表現することで、スケーラブルな設計を体感します。
• セキュリティ構成の進化: インターネットからのアクセスをALBに集約し、EC2インスタンスをプライベートサブネットに配置する構成のセキュリティ的な利点を理解します。

構成図の書き方（変更・追記）

ステップ3で作成した構成図をベースに、以下の点を変更・追記してみましょう。

1. EC2インスタンスの移動: パブリックサブネットにあったEC2インスタンスを、プライベートサブネットに移動します。
2. ALBの追加: パブリックサブネットにALBを描きます。
3. Auto Scaling Groupの追加: 2つのプライベートサブネットにまたがる形で、EC2インスタンスを囲むAuto Scaling Groupを描きます。
4. ターゲットグループ: ALBとEC2インスタンスの間にターゲットグループを配置します。
5. 通信経路の変更:
   • インターネットからの通信は、まずALBに到達します。
   • ALBは、プライベートサブネット内のEC2インスタンスにトラフィックを転送します。
   • EC2からDBへの通信経路はこれまで通りです。
6. セキュリティグループの更新:
   • ALB用のSG（インターネットからHTTPを許可）と、EC2用のSG（ALBからHTTPを許可）の関係性がわかるように描きます。

💡 ヒント: この構成図は、モダンなWebアプリケーションの基本的な形です。どのリソースがどのネットワーク領域にあり、どのように通信を制御しているかを意識して描くことが重要です。

理解度チェック：なぜ？を考えてみよう

AWSの各リソースや設計には、必ず“理由”や“目的”があります。 下記の「なぜ？」という問いに自分なりの言葉で答えてみましょう。 仕組みや設計意図を自分で説明できることが、真の理解につながります。 ぜひ、単なる暗記ではなく「なぜそうなっているのか？」を意識して考えてみてください。

Q. EC2インスタンス（Webサーバーやアプリサーバーなど）を、インターネットから直接アクセスできない「プライベートサブネット」に置くのはなぜでしょうか？ （ヒント：もしEC2がインターネットから見える場所にあったら、どんなリスクがあるでしょう？）

Q. ALB（Application Load Balancer）は、なぜインターネットからアクセスできる「パブリックサブネット」に置くのでしょうか？ （ヒント：ALBの役割や、外部からのアクセスについて考えてみましょう）

Q. Auto Scaling（オートスケーリング）は、なぜ必要なのでしょうか？ （ヒント：利用者が増えたり減ったりしたとき、サーバーの数を自動で調整する仕組みがあると、どんな良いことがあるでしょう？）

今回のステップで利用したAWSサービス名一覧

• EC2 (Elastic Compute Cloud)：仮想サーバーを提供するサービス
• AMI (Amazon Machine Image)：EC2インスタンスのテンプレートとなるイメージ
• ALB (Application Load Balancer)：HTTPトラフィックを複数のターゲットに分散させるロードバランサー
• ターゲットグループ：ALBがトラフィックを転送する先のEC2インスタンスをグループ化したもの
• Auto Scaling：トラフィックに応じて自動的にEC2インスタンスの数を調整するサービス
• 起動テンプレート：Auto Scalingで使用するEC2インスタンスの設定テンプレート
• Aurora PostgreSQL：高性能なマネージドリレーショナルデータベースサービス
• マルチAZ (Multiple Availability Zones)：複数のアベイラビリティーゾーンにリソースを配置して可用性を高める構成
• VPC (Virtual Private Cloud)：AWS上に構築する仮想ネットワーク
• セキュリティグループ：トラフィックの許可ルールを定義し、EC2やAuroraやALBなどのAWSリソースへの通信を制御する仮想ファイアウォール
• Systems Manager：AWSリソースを安全に管理するためのサービス
• Session Manager：SSHポートを開放せずにEC2インスタンスに接続するためのツール
• IAM (Identity and Access Management)：AWSリソースへのアクセス権限を管理するサービス