2 台のサーバーへアクセスを振り分ける

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

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

ブラウザからのアクセスは、まず Application Load Balancer が受け取ります。ロードバランサーは「ターゲットグループ」に登録された 2 台の EC2 へ、アクセスを順番に振り分けます。2 台は別々のアベイラビリティーゾーンのパブリックサブネットに置きます。

以下の要件を満たす構成を作り、ブラウザで振り分けを確認してください。

「2 台のサーバー → 振り分けの設定 → 受付役のロードバランサー」の順に組み立てます。登場人物が多いので、いま何を作っているかを意識しながら進めましょう。

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

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

2. 2 台の Web サーバーを用意する（2 つの方式から選べます）

   同じ内容の Web サーバーを 2 台、別々のアベイラビリティーゾーンに用意します。やり方は次の 方式 A（ユーザーデータ）か 方式 B（AMI）のどちらかを選んでください。どちらでも、最終的に web-1・web-2 が別ゾーンにある状態になれば、以降の手順は共通です。

   方式 A

   ユーザーデータで 2 台を直接セットアップする

   起動のたびにスクリプトで Apache を入れる方法。手軽で、ページの中身を変えたいときに直しやすいのが利点です。

   1. web-1 を起動：EC2 コンソールで「インスタンスを起動」。名前 web-1、AMI は Amazon Linux 2023、タイプは無料利用枠の対象。サブネットをひとつ選び（例：アベイラビリティーゾーン a）、パブリック IP の自動割り当てを有効にします。「高度な詳細」→「ユーザーデータ」に次を貼り付けて起動します。
      ユーザーデータ（web-1・web-2 共通）

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

   2. web-2 を別ゾーンに起動：もう一度「インスタンスを起動」し、名前 web-2 で同じ AMI・タイプ・ユーザーデータを設定します。ポイントは、サブネットを web-1 とは違うアベイラビリティーゾーン（例：ゾーン c）にすること。セキュリティグループは web-1 と同じサーバー用のものを選びます。
      ※ 起動ウィザードで台数を 2 にすると両方が同じゾーンに入ってしまうため、ゾーンを分けたい今回はあえて 1 台ずつ起動します。

   — または —

   方式 B

   AMI に焼いてから 2 台を複製する

   Apache を焼き込んだ自分専用 AMI を 1 つ作り、そこから 2 台を起動する方法。起動が速く、何台でもまったく同じ土台で立てられます。台数が多いほど有利になります。

   1. ベースを 1 台起動：名前 web-base で Amazon Linux 2023・無料利用枠タイプのインスタンスを起動します。ユーザーデータには Apache の導入までを書きます（ページはまだ作りません）。
      ユーザーデータ（web-base ＝土台づくり）

      #!/bin/bash
      dnf install -y httpd
      systemctl enable --now httpd

   2. AMI を作成：web-base を選び、「アクション」→「イメージとテンプレート」→「イメージを作成」。イメージ名 web-ami で作成し、「AMI」一覧で状態が 利用可能（available） になるまで待ちます（作成後、web-base は使わないので終了してかまいません）。
   3. AMI から 2 台を別ゾーンに起動：「AMI」で web-ami を選び「AMI からインスタンスを起動」。web-1 をゾーン a、web-2 をゾーン c に（1 台ずつ）起動します。Apache は焼き込み済みなので、各起動時のユーザーデータはページを作る 1 行だけにします。
      ユーザーデータ（web-1・web-2 ＝ページ生成だけ）

      #!/bin/bash
      echo "<h1>応答したサーバー</h1><p>$(hostname -f)</p>" > /var/www/html/index.html

   これが「組み合わせ」の考え方

   変わりにくい土台（Apache）は AMI に焼き、起動ごとに変わる部分（ホスト名のページ）だけ ユーザーデータで入れています。実務でもよく使う、両者の良いとこ取りの形です。

   セキュリティグループはここで 2 つ目を意識

   どちらの方式でも、web-1・web-2 に付けるサーバー用セキュリティグループは、あとでロードバランサーからの通信だけを許可する形にします。いったんは作成（または選択）しておき、ルールの調整はこのあとの「サーバー用セキュリティグループを整える」手順で行うと迷いません。

3. ターゲットグループを作り、2 台を登録する

   EC2 コンソール左メニュー「ロードバランシング」→「ターゲットグループ」→「ターゲットグループの作成」を開きます。ターゲットタイプは「インスタンス」、プロトコルは HTTP : 80、VPC は EC2 を置いたものを選びます。次の画面で web-1 と web-2 を選び、「保留中として以下を含める」で登録してから作成します。

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

   ターゲットの種類

   インスタンス

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

   IP アドレス

   IP を直接指定する

   Lambda 関数

   関数を宛先にする

   ↳EC2 インスタンスを登録するので「インスタンス」を選びます

   ターゲットグループは「振り分け先の名簿」

   ロードバランサーは、この名簿に載っているサーバーへアクセスを配ります。ヘルスチェック（既定ではパス /）に応答できたサーバーだけが healthy として扱われ、振り分け対象になります。

4. Application Load Balancer を作成する

   左メニュー「ロードバランサー」→「ロードバランサーの作成」で、Application Load Balancer を選びます。次のように設定します。

   スキーム	インターネット向け（Internet-facing）
   ネットワークマッピング	EC2 を置いた VPC を選び、2 つのアベイラビリティーゾーン（web-1・web-2 を置いたゾーン）のパブリックサブネットにチェック
   セキュリティグループ	ロードバランサー用（HTTP 80 を 0.0.0.0/0 から許可）を指定
   リスナー	HTTP : 80 → 先ほど作成したターゲットグループへ転送

   ロードバランサーも複数ゾーンに置く

   ロードバランサー自身も、指定した複数のゾーンにまたがって動きます。だからこそ、片方のゾーンに問題が起きても受付を続けられます。サーバーと同じゾーンを選んでおきましょう。

5. サーバー用セキュリティグループを「ロードバランサーからのみ許可」に整える

   web-1・web-2 に付けたサーバー用セキュリティグループのインバウンドルールを開き、HTTP（80）のソースを、ロードバランサー用セキュリティグループに設定します（ソース欄でセキュリティグループを指定できます）。

   なぜ直接アクセスを閉じるの？

   利用者には必ずロードバランサーを通ってほしいので、サーバーへの直接アクセスは閉じておきます。「サーバーの入口は、受付役からの通信だけ開ける」と、経路が 1 本にそろい、振り分けや見張りも効くようになります。

6. ターゲットが healthy になるのを待つ

   「ターゲットグループ」の「ターゲット」タブを開き、web-1・web-2 の状態を確認します。最初は initial ですが、しばらくするとhealthy に変わります（数分かかることがあります）。

   healthy にならないときは

   多くは「サーバー用セキュリティグループがロードバランサーからの 80 番を許可していない」か「Apache がまだ起動していない」のどちらかです。サーバー用セキュリティグループのルールと、起動からの経過時間を見直しましょう。

7. ロードバランサーの DNS 名にアクセスして振り分けを確認する

   「ロードバランサー」の詳細画面で「DNS 名」（例：my-alb-1234567890.ap-northeast-1.elb.amazonaws.com）をコピーし、ブラウザで http://<DNS 名> を開きます。再読み込みを何回か繰り返すと、表示されるホスト名が web-1 と web-2 の間で切り替わり、振り分けが効いていることが分かります。

   仕上げ：1 台止めると何が起きる？

   片方のインスタンスを停止してみましょう。しばらくするとそのサーバーが unhealthy になり振り分けから外れますが、ブラウザでは生きているほうが応答し続けて表示が途切れません。これが複数台にする狙いです（確認後、料金のため停止したままにせず、後片づけまで進めてください）。

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

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

• 「インスタンス」一覧に web-1・web-2 があり、それぞれ異なるアベイラビリティーゾーンに配置されている（一覧の「アベイラビリティーゾーン」列で確認）。
• 「ターゲットグループ」の「ターゲット」タブで、2 台とも状態が healthy になっている。
• 「ロードバランサー」の状態が アクティブ（Active） で、「DNS 名」が表示されている。
• サーバー用セキュリティグループのインバウンドに、HTTP（80）のソースがロードバランサー用セキュリティグループになっている行がある。
• ブラウザで http://<DNS 名> を開き、再読み込みで web-1 と web-2 のホスト名が入れ替わって表示される。
• （仕上げ）1 台を停止すると、しばらくしてそのターゲットが unhealthy になり、ブラウザでは残った 1 台が応答し続ける。

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

1. 2 台を別々のアベイラビリティーゾーンに置きました。もし 2 台とも同じゾーンに置いていたら、どんなときに困るでしょうか。ゾーンを分けたことの意味を考えてみましょう。
   ヒント

   アベイラビリティーゾーンは電源やネットワークが独立した区画です。あるゾーン全体に問題が起きた場面を想像すると、「同じゾーンに 2 台」と「別ゾーンに 1 台ずつ」で結果がどう変わるかが見えてきます。
2. サーバー用セキュリティグループで、HTTP（80）のソースを「ロードバランサー用セキュリティグループ」に絞りました。もしここを 0.0.0.0/0（どこからでも可）にしてしまうと、どんな問題が考えられるでしょうか。
   ヒント

   サーバーに直接アクセスできてしまうと、ロードバランサーを通さない経路ができます。振り分けや見張り（ヘルスチェック）を通らないアクセスが生まれること、入口が広がることの両面から考えてみましょう。
3. 今回はアクセスが増えても 2 台のままです。もし利用者がさらに増えたら、どんな手を打てるでしょうか。「手動で台数を足す」以外に、AWS で自動的に台数を増減させる仕組みがないか調べてみましょう。
   ヒント

   混雑に合わせてサーバーの台数を自動で増やしたり減らしたりする仕組み（オートスケーリング）があります。ロードバランサーと組み合わせると何がうれしいか、という観点で調べてみると、今回の構成の発展形が見えてきます。

登場人物が多いぶん、消す順番に気をつけます。ロードバランサーは起動している間ずっと料金が発生するため、使い終わったら必ず片づけましょう。次の順で進めると、依存関係でつまずきにくくなります。

1. ロードバランサーを削除する：「ロードバランサー」で対象を選び、「アクション」→「削除」。これで時間課金が止まります。
2. ターゲットグループを削除する：「ターゲットグループ」で対象を選び削除します（ロードバランサーを消したあとに行います）。
3. EC2 インスタンスを終了する：「インスタンス」で web-1・web-2 を選び、「インスタンスを終了（Terminate）」。状態が「終了済み」になれば料金が止まります。
4. セキュリティグループを削除する（任意）：今回作った 2 つのセキュリティグループは、ロードバランサーとインスタンスを消したあとに削除できます（他で使っていないことを確認してから）。
5. （方式 B を選んだ場合）AMI とスナップショットを片づける：作成した web-ami を「AMI」で登録解除し、続けて「スナップショット」から対応するスナップショットを削除します。登録解除だけではスナップショットが残り、ストレージ料金がかかり続けます。web-base を残していれば、これも終了します。