混雑に合わせてサーバーの台数を自動で増減させる

手順に迷ったときや、用語の意味を確かめたいときに開きましょう。

※ リンク切れの場合は、ページタイトルで検索してください。

起動テンプレート（サーバーの設計図）をもとに、Auto Scaling グループが 2 つのアベイラビリティーゾーンへサーバーを配置します。前段のロードバランサーが、いま動いているサーバーへアクセスを振り分けます。混雑すると、最大 4 台まで自動で増えます。

以下の要件を満たす構成を作り、台数が自動で保たれる様子を確認してください。

「設計図（起動テンプレート）→ 受付役（ロードバランサー）→ 自動管理（Auto Scaling グループ）→ 増減の方針（ポリシー）」の順に積み上げ、最後に台数が自動で保たれる様子を確かめます。

1. マネジメントコンソールにサインインし、リージョンを合わせる

   ブラウザで AWS マネジメントコンソールにサインインし、画面右上のリージョンが「アジアパシフィック（東京）ap-northeast-1」になっていることを確認します。

2. セキュリティグループを 2 つ用意する

   先に通信の入口を 2 つ作っておくと、あとがスムーズです。EC2 コンソールの「セキュリティグループ」で次の 2 つを作成します。

   ロードバランサー用（例：alb-sg）	インバウンドで HTTP（80）を 0.0.0.0/0（どこからでも）から許可
   サーバー用（例：web-sg）	インバウンドで HTTP（80）を、ソース＝ロードバランサー用セキュリティグループ（alb-sg）から許可

   サーバーへは「受付役からのみ」

   サーバー用は、利用者が直接アクセスできないよう、ロードバランサー用からの通信だけを許可します。自動で増えるサーバーにも、この設計図（起動テンプレート）を通じて同じルールが適用されます。

3. 起動テンプレート（サーバーの設計図）を作る

   EC2 コンソール左メニュー「起動テンプレート」→「起動テンプレートを作成」を開きます。名前（例：web-template）を付け、次のように設定します。ユーザーデータは「高度な詳細」の中にあります。

   AMI	Amazon Linux 2023（無料利用枠の対象）
   インスタンスタイプ	無料利用枠の対象（例：t2.micro / t3.micro）
   セキュリティグループ	サーバー用（web-sg）
   ユーザーデータ	下記スクリプトを貼り付け

   ユーザーデータ（起動テンプレートに設定）

   #!/bin/bash
   dnf install -y httpd
   systemctl enable --now httpd
   # どのサーバーが応答したか分かるよう、自分のホスト名を表示する
   echo "<h1>応答したサーバー</h1><p>$(hostname -f)</p>" > /var/www/html/index.html

   起動テンプレートは「何台でも同じ」を作る素

   Auto Scaling グループは、台数を増やすときこの設計図を見て、まったく同じ構成のサーバーを起動します。サブネット（どのゾーンに置くか）は、次の Auto Scaling グループ側で指定するので、テンプレートには含めなくて構いません。

4. ターゲットグループとロードバランサーを作る

   左メニュー「ターゲットグループ」→「作成」で、タイプ「インスタンス」・HTTP:80・対象 VPC を選んで作成します（この時点ではターゲットは未登録で構いません。あとで Auto Scaling グループが自動で登録します）。続けて「ロードバランサー」→「作成」→ Application Load Balancer を選び、次のようにします。

   ターゲットグループを作成 — タイプの選択（イメージ）

   ターゲットの種類

   インスタンス

   EC2 インスタンスを宛先にする

   IP アドレス

   IP を直接指定する

   Lambda 関数

   関数を宛先にする

   ↳Auto Scaling グループで使うので「インスタンス」を選びます

   スキーム	インターネット向け（Internet-facing）
   ネットワークマッピング	VPC を選び、2 つのアベイラビリティーゾーンのパブリックサブネットにチェック
   セキュリティグループ	ロードバランサー用（alb-sg）
   リスナー	HTTP : 80 → 作成したターゲットグループへ転送

   ターゲットは「手で登録しない」

   このあと作る Auto Scaling グループにターゲットグループを結び付けると、増えたサーバーが自動で振り分け先に登録され、減ったサーバーは自動で外れます。だからここでは、ターゲットを手で登録する必要はありません。

5. Auto Scaling グループを作る

   EC2 コンソール左メニュー「Auto Scaling グループ」→「Auto Scaling グループを作成」を開き、名前（例：web-asg）を付けます。次のように進めます。

   起動テンプレート	web-template を選択
   ネットワーク	VPC を選び、2 つのアベイラビリティーゾーンのパブリックサブネットを指定
   ロードバランシング	「既存のロードバランサーにアタッチ」→ 手順 4 のターゲットグループを選択
   ヘルスチェック	Elastic Load Balancing のヘルスチェックを有効化
   容量	希望容量 2・最小 2・最大 4

   なぜ Elastic Load Balancing のヘルスチェックを有効にするの？

   これを有効にすると、「サーバーが起動している」だけでなく「ロードバランサーから見て応答できる」かどうかでも健全性を判断します。Web として実際に使える状態かを基準に、入れ替えや補充を行えるようになります。

6. スケーリングポリシー（増減の方針）を設定する

   Auto Scaling グループの作成中、または作成後の「自動スケーリング」タブで、「ターゲット追跡スケーリングポリシー」を追加します。指標に「平均 CPU 使用率」、目標値に 50（%）を設定します。

   「目標値を保つ」という考え方

   ターゲット追跡は、エアコンの温度設定に似ています。「平均 CPU を 50% に保つ」と決めておくと、混雑して 50% を超え続ければ台数を増やし、下回って余裕が出れば（最小の範囲で）減らします。細かいしきい値を自分で組まなくてよいのが利点です。

   ※ 実際にこのポリシーで増えるには、CPU の高い状態が続く必要があります。今回は次のステップの「自己修復」で自動増減の動きを確認し、ポリシーは本番向けの設定として用意しておく位置づけです。

7. 動作確認 ①：2 台が動き、振り分けされることを見る

   Auto Scaling グループの「インスタンス管理」に 2 台が現れ、ライフサイクルが InService になるのを待ちます。ターゲットグループの「ターゲット」タブで2 台が healthy になったら、ロードバランサーの「DNS 名」を http://<DNS 名> でブラウザに開き、再読み込みでホスト名が切り替わることを確認します。

   ここまでで「自動で 2 台そろう」状態

   注目すべきは、インスタンスを 1 台ずつ手で起動していないことです。Auto Scaling グループに「希望 2」と伝えただけで、設計図どおりの 2 台が自動でそろっています。

8. 動作確認 ②：1 台を終了して「自己修復」を見る

   「インスタンス」一覧から、グループ内のサーバーを1 台選んで終了（Terminate）します。すると Auto Scaling グループは台数が希望を下回ったことを検知し、自動で新しい 1 台を立ち上げて 2 台に戻します。グループの「アクティビティ」タブに、終了と新規起動の履歴が記録されます。数分待つと、新しいサーバーも healthy になり振り分けに加わります。

   （任意）増える様子も見たい場合

   Auto Scaling グループの希望容量を一時的に 3 や 4 に変更すると、その台数まで自動で増えます（最大 4 の範囲内）。増えたサーバーがロードバランサーの振り分けに加わるのを確認したら、料金のため希望容量を 2 に戻しておきましょう。確認が終わったら、必ず後片づけまで進めてください。

初学者がよく引っかかる箇所を先回りでまとめました。答えそのものは載せていませんが、「どこを見直せばよいか」の手がかりとして使ってください。

要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。EC2 コンソールとブラウザを開いて、次を順に確かめましょう。

• 「起動テンプレート」一覧に web-template がある。
• 「Auto Scaling グループ」に web-asg があり、希望 2・最小 2・最大 4 になっている。
• web-asg の「インスタンス管理」に 2 台あり、ライフサイクルが InService になっている。
• 「ターゲットグループ」で 2 台が healthy になっている。
• ロードバランサーの http://<DNS 名> を開くと、再読み込みでホスト名が入れ替わる。
• web-asg の「自動スケーリング」に、平均 CPU 使用率のターゲット追跡ポリシーが設定されている。
• 1 台を終了すると、「アクティビティ」に終了と新規起動の履歴が残り、自動で 2 台に戻る。

手を動かすことに加えて、次の問いに自分の言葉で答えられるようにしておくと、理解がより深まります。

1. 容量を「希望・最小・最大」の 3 つに分けて指定しました。最小と最大を分けて持つことには、それぞれどんな意味があるでしょうか。両方を同じ値にした場合との違いも考えてみましょう。
   ヒント

   最小は「これ以上は減らさない下限」、最大は「これ以上は増やさない上限」です。下限は可用性（最低限の台数を保つ）、上限は暴走を防いでコストの上限を決める役割と考えると、分けて持つ理由が見えてきます。
2. 1 台を終了しても自動で補充されました。この「自己修復」は、台数を固定で運用する場合と比べて、可用性の面でどんな価値があるでしょうか。
   ヒント

   固定運用では、1 台壊れると人が気づいて対応するまで台数が欠けたままです。自己修復があると、夜間でも自動で台数が戻ります。「気づく → 直す」を人がやるか、仕組みがやるか、という観点で比べてみましょう。
3. ターゲット追跡で「平均 CPU 使用率 50%」を目標にしました。これを 30% や 70% に変えると、サービスの余裕と料金の関係はどう変わるでしょうか。
   ヒント

   目標値を低くすると、早めに台数を増やすので余裕は出ますが、台数が多くなりがちで料金は上がります。高くすると、ぎりぎりまで台数を増やさないので安く済む反面、急な混雑への余裕は減ります。安全と料金のトレードオフとして考えてみましょう。

片づけの順番がとくに大事です。先に Auto Scaling グループを削除しないと、サーバーを終了しても自動で補充されて消えません。次の順で進めましょう。

1. Auto Scaling グループを削除する：「Auto Scaling グループ」で web-asg を選び削除します。これに伴い、配下の EC2 インスタンスも自動で終了します（手で 1 台ずつ消す必要はありません）。
2. ロードバランサーを削除する：「ロードバランサー」で対象を選び削除します。これで時間課金が止まります。
3. ターゲットグループを削除する：ロードバランサーを消したあとに削除します。
4. 起動テンプレートを削除する（任意）：「起動テンプレート」から web-template を削除できます。
5. セキュリティグループを削除する（任意）：web-sg・alb-sg は、上記をすべて消したあとに削除できます（他で使っていないことを確認してから）。