振り分ける仕組みを、自分の手で組み立てる

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

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

中央のプロキシ用 EC2 が利用者からのアクセスを受け止め、背後の 2 台のバックエンド EC2 へ順番に振り分けます（ラウンドロビン）。

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

「セキュリティグループ → バックエンド 2 台 → プロキキシ用 EC2 → nginx の設定 → 動作確認」の順に組み立てます。

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

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

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

   EC2 コンソールの「セキュリティグループ」から、次の 2 つを作成します。先にプロキシ用セキュリティグループを空の状態で作っておき、あとからバックエンド用のルールで参照すると迷いません。

   プロキシ用セキュリティグループ	インバウンド：HTTP（80）を 0.0.0.0/0（インターネット）から許可、SSH（22）を「マイ IP」から許可
   バックエンド用セキュリティグループ	インバウンド：HTTP（80）をソースにプロキシ用セキュリティグループを指定して許可（SSH も必要であれば「マイ IP」から許可しておくと、後片づけ時のログイン確認に使えます）

   なぜプロキシ経由だけに絞るのか

   バックエンドへの直接アクセスを閉じておくことで、利用者が必ずプロキシを通る経路にそろいます。振り分けや自動切り離しが効くのも、この経路が 1 本にそろっているからです。

3. バックエンド用 EC2 を 2 台起動する

   EC2 コンソールで「インスタンスを起動」を 2 回行い、Amazon Linux 2023・無料利用枠タイプで、名前タグを自由に決めて（例：web-1 ／ web-2）起動します。セキュリティグループは手順 2 のバックエンド用を選びます。「高度な詳細」→「ユーザーデータ」に次の内容を貼り付けます。

   ユーザーデータ（web-1・web-2 共通）

   #!/bin/bash
   dnf install -y httpd
   echo "<h1>Hello from $(hostname)</h1>" > /var/www/html/index.html
   systemctl enable httpd
   systemctl start httpd

   1 行ずつ確認しましょう。

   dnf install -y httpd	Amazon Linux 2023 のパッケージ管理コマンド dnf で、Web サーバーソフトの httpd（Apache）を確認なしで導入します。
   echo "..." > /var/www/html/index.html	その時点のホスト名（$(hostname)）を埋め込んだ簡単なページを、Web サーバーの公開フォルダに作成します。これにより、どちらのサーバーが応答したか見分けられます。
   systemctl enable httpd	インスタンスを再起動しても httpd が自動的に立ち上がるよう設定します。
   systemctl start httpd	httpd を今すぐ起動します。

   プライベート IP アドレスを控えておく

   起動後、各インスタンスの詳細画面でプライベート IP アドレスを確認し、メモしておきましょう。あとで nginx の設定に使います。

4. プロキシ用 EC2 を 1 台起動する

   同じように「インスタンスを起動」から、Amazon Linux 2023・無料利用枠タイプで 1 台起動します。セキュリティグループは手順 2 のプロキシ用を選びます。パブリック IP の自動割り当てを有効にしておきます。

5. プロキシ EC2 に SSH でログインし、nginx を導入する

   ローカルの PowerShell から、Windows 標準の OpenSSH を使ってプロキシ EC2 に接続します。

   PowerShell

   PS> ssh -i "C:\Users\you\Downloads\your-key.pem" ec2-user@<プロキシEC2のパブリックIP>

   ログインできたら、nginx を導入します。

   プロキシEC2内（SSH接続後）

   $ sudo dnf install -y nginx

   秘密鍵ファイルのアクセス権限

   Windows 標準の OpenSSH では、.pem ファイルのアクセス権限が緩すぎると接続を拒否されることがあります。エラーが出た場合は、鍵ファイルのプロパティから自分以外のアクセス権を外してみましょう。

6. nginx の設定ファイルを作成する

   プロキシ EC2 内で、設定ファイル（例：/etc/nginx/conf.d/proxy.conf）を作成します。手順 3 で控えた 2 台のプライベート IP アドレスを使います。

   /etc/nginx/conf.d/proxy.conf

   upstream backend_pool {
       server <web-1のプライベートIP>:80 max_fails=2 fail_timeout=10s;
       server <web-2のプライベートIP>:80 max_fails=2 fail_timeout=10s;
   }
   
   server {
       listen 80;
       location / {
           proxy_pass http://backend_pool;
           proxy_next_upstream error timeout http_502 http_503 http_504;
       }
   }

   1 行ずつ確認しましょう。

   upstream backend_pool { ... }	振り分け先のグループに backend_pool という名前を付けて定義します。
   server <IP>:80 max_fails=2 fail_timeout=10s;	振り分け先のサーバーを 1 台ずつ記載します。max_fails=2 は「連続 2 回失敗したら」、fail_timeout=10s は「10 秒間は振り分け先から外す」という意味です。値は自由に決められますが、悩む場合はこの例の値から始めるとよいでしょう。
   listen 80;	プロキシ自身が HTTP（80 番ポート）でアクセスを受け付けることを示します。
   proxy_pass http://backend_pool;	受け付けたアクセスを、先ほど定義した backend_pool へ転送します。ここで台数や振り分け方式を意識せず書けるのが upstream の利点です。
   proxy_next_upstream error timeout http_502 http_503 http_504;	転送先からエラーやタイムアウトが返ってきた場合に、別の振り分け先へ自動的に再試行する条件を指定します。

   IP アドレスは自由に決まる値です

   プライベート IP アドレスは、自分の VPC・サブネットの設定によって変わります。手順 3 で確認した値をそのまま使ってください。

7. 構文チェックをして、nginx を起動する

   設定ファイルを保存したら、構文に誤りがないか確認します。

   プロキシEC2内（SSH接続後）

   $ sudo nginx -t
   # syntax is ok / test is successful と表示されれば問題ありません
   $ sudo systemctl enable nginx
   $ sudo systemctl start nginx
   # 既に起動している場合は次で設定を反映します
   $ sudo systemctl reload nginx

8. 動作確認をする

   プロキシ EC2 のパブリック IP アドレスにブラウザでアクセスし（http://<プロキシEC2のパブリックIP>）、ホスト名が表示されることを確認します。再読み込みを繰り返して、表示が web-1 と web-2 の間で切り替わることを確認しましょう。

   続けて、片方のバックエンドに SSH でログインし、httpd を停止します。

   バックエンドEC2内（SSH接続後）

   $ sudo systemctl stop httpd

   その後、プロキシのパブリック IP に何度かアクセスを繰り返し、停止したサーバーが振り分け先から外れていく様子を観察しましょう。

   外れるまで少しアクセスが必要

   max_fails=2 の設定では、停止後すぐにではなく、2 回失敗した時点で振り分け先から外れます。最初の数回は失敗（つながらない、もしくは遅い）応答が混ざることがあります。

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

要件の再確認ではなく、画面のどこを見れば達成を確認できるかをまとめました。ブラウザと SSH 接続先のターミナルで、次を順に確かめましょう。

• プロキシのパブリック IP にブラウザでアクセスすると、ホスト名を表示するページが表示される。
• 複数回アクセス（再読み込み）すると、表示されるホスト名が web-1 と web-2 の間で切り替わる。
• プロキシ EC2 内で sudo nginx -t を実行してもエラーが出ない。
• 片方のバックエンドで httpd を停止すると、数回の失敗のあと、そちらのホスト名が表示されなくなる（振り分け先から外れる）。
• 停止した httpd を再開すると、しばらくしてそのホスト名が再び表示されるようになる（振り分け先に戻る）。

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

1. 実際のロードバランサーは、リクエストが来なくてもバックエンドの状態を定期的に確認しに行きます（アクティブヘルスチェック）。今回の nginx の設定は、リクエストが失敗したときに初めて気づく仕組みでした。この違いは、どんな場面で問題になりそうでしょうか。
   ヒント

   「リクエストが来てから気づく」方式では、最初にそのサーバーへ振り分けられた利用者が、必ず一度は失敗した応答を受け取ってしまいます。アクセスの頻度が低い時間帯や、サーバーが落ちた直後にアクセスが集中する場面を想像してみましょう。
2. プロキシ自体（このEC2）が落ちたら、システム全体はどうなるでしょうか。
   ヒント

   バックエンドが 2 台とも正常でも、その手前にいる窓口が 1 つしかなければ、その窓口が止まった時点で利用者は誰もアクセスできなくなります。「振り分ける役」自体を複数台にする、または冗長化する方法がないか考えてみましょう。
3. バックエンドを 3 台、4 台と増やしたら、設定ファイルのどこを変更する必要がありそうでしょうか。
   ヒント

   upstream backend_pool { ... } の中に並んでいる server 行を見てみましょう。台数が増えるたびに、この設定ファイルを自分で編集して反映し直す必要がある、という点が今回の方式の特徴です。

3 台の EC2 とセキュリティグループを、依存関係につまずかない順番で削除します。

1. プロキシ用 EC2 を削除する：EC2 コンソールの「インスタンス」でプロキシ用のインスタンスを選び、「インスタンスを終了（Terminate）」を実行します。
2. バックエンド用 EC2 を 2 台削除する：同様に web-1・web-2 を選び、「インスタンスを終了（Terminate）」を実行します。
3. セキュリティグループを削除する：今回作成したプロキシ用・バックエンド用の 2 つのセキュリティグループを、インスタンスを終了したあとに削除します。