Nginxはロードバランサーなのになぜロードバランサーがさらに必要なのか

概要¶

「Nginxは何千もの接続を処理できるのに、なぜさらにロードバランサーが必要なのか？」という面接の定番質問。NginxはLB機能を持つが、それ自体が単一サーバーである。上位のロードバランサーはスケーラビリティ・可用性・フェイルオーバーの問題を解決する。

詳細¶

誤解されやすいポイント¶

「NginxはロードバランサーだからLBは不要では？」← よくある誤解

→ Nginxはリバースプロキシ兼LBとして機能するが、
  それ自体は"1台のサーバー"に過ぎない

Nginxだけの構成が抱える問題¶

クライアント → Nginx（単一インスタンス）→ バックエンドサーバー群

問題点：
  ① Nginxが落ちたらすべてのトラフィックが止まる（SPOF）
  ② Nginx自体がボトルネックになる（スケールアップに限界）
  ③ Nginxのメンテナンスやデプロイ時にダウンタイムが発生

理想的な構成（多層ロードバランシング）¶

                  インターネット
                       ↓
          ┌─────────────────────┐
          │  Azure LB / AWS ALB  │  ← L4/L7 クラウドLB
          │  （ヘルスチェック付き）│
          └──────┬──────┬────────┘
                 ↓      ↓
           [Nginx 1]  [Nginx 2]   ← 複数Nginxインスタンス
                 ↓      ↓
          ┌──────────────────────┐
          │  バックエンドサーバー群  │
          └──────────────────────┘

上位ロードバランサーが解決すること¶

課題	上位LBによる解決策
Nginx障害	ヘルスチェックで自動フェイルオーバー
トラフィック急増	Nginxインスタンスを水平スケール
ゼロダウンタイムデプロイ	1インスタンスずつ切り離して更新
地理的分散	リージョン別にトラフィックを振り分け
DDoS対策	エッジで吸収してNginxへの到達を防ぐ

要約¶

Nginx = 「何千もの接続を捌けるLB機能付きプロキシ」
        ただし、それ自体は1台のサーバー

上位LB = Nginxの「可用性」「スケーラビリティ」「フェイルオーバー」
         を担保するための仕組み

→ 「Nginxを使っているからLBは不要」ではなく
  「Nginxの前にもLBが必要」という発想になる

なぜ重要か / いつ使うか¶

インフラ設計・面接で「LBアーキテクチャ」を説明するとき
SPOF（単一障害点）を排除した高可用性設計を議論するとき
「なぜALB/NLBとNginxを両方使っているのか」をチームに説明するとき