ロードバランサ（L4/L7）による負荷分散とSSLオフロード設計

1. 概要と本質：なぜロードバランサが可用性と性能の要なのか

現代の大規模Webシステムにおいて、単一の高性能サーバに処理を集中させる「スケールアップ（垂直統合）」には物理的・コスト的な限界があります。そのため、複数台の汎用サーバに通信トラフィックを均等配分する「スケールアウト（水平分散）」が標準アーキテクチャとなっています。

このスケールアウトを統括するのが「ロードバランサ（Load Balancer: LB / 負荷分散装置）」です。 ロードバランサは単なる通信の振り分け機にとどまりません。

• 高可用性の担保: 故障したサーバを自動検知して切り離す（ヘルスチェック）。

• セッション維持: ログイン中のユーザを同一サーバに固定誘導する（パーシステンス）。

• SSL/TLSオフロード: 暗号化・復号の膨大な暗号演算処理を肩代わりし、WebサーバのCPUリソースを解放する。

ネットワークスペシャリスト（NW）午後・科目B試験では、「L4（レイヤ4）分散とL7（レイヤ7）分散の動作モデルの相違」「DSR（Direct Server Return）の特殊なパケットフロー」「キャリアプロキシ配下で多発するIPパーシステンスの偏り」「SSLオフロード時のヘッダ付与とリダイレクトループ障害」が極めて高い頻度で問われます。 本稿では、ネットワーク設計者が直面するこれらの中核技術と障害切り分けを徹底解説します。

2. L4分散 vs L7分散のアーキテクチャ比較

ロードバランサは、パケットのどの階層までを読み取って分散判断を行うかによって、大きく「L4」と「L7」に大別されます。

図のデータを表示できません。

3. インライン構成 vs DSR（Direct Server Return）構成

ネットワークトポロジにおけるLBの配置方式は、通信スループットと障害設計に直結します。

3.1 DSR（ダイレクトサーバリターン）の仕組みと超高スループット

動画配信や大容量ファイルダウンロードサイトでは、「クライアントからの要求（リクエスト）は数KBと極小」であるのに対し、「サーバからの応答（レスポンス）は数百MB〜数GBと巨大」になります。 この戻りトラフィックをすべてLB経由にすると、LBの帯域がボトルネックになります。

図のデータを表示できません。

[!IMPORTANT] DSR設計における必須要件（NW午後試験頻出） 1. 実サーバのループバックインタフェース（`lo:0`等）にVIP（仮想IPアドレス）を設定する。 2. 実サーバは、VIP宛てのARP要求（ARP Request）に応答してはならない（ARP抑制）。 - もし実サーバがVIPへのARP応答を返すと、スイッチやルータのMACアドレステーブルが実サーバで上書きされ、LBを経由せずに直接実サーバへ通信が届いてしまい分散が破綻する。 - Linuxでは arp_ignore=1 および arp_announce=2 をカーネルパラメータに設定する。

4. パーシステンス（セッション維持）の設計と落とし穴

ECサイトの買い物かごやログインセッションのように、「一度特定のWebサーバに振り分けられたユーザは、一連の操作が完了するまで同一の実サーバへ送り続けなければならない」要件をパーシステンス（Persistence）と呼びます。

4.1 送信元IPアドレスハッシュの致命的弱点

• 方式: クライアントの送信元IPアドレスをハッシュ計算し、担当サーバを固定する。

• 落とし穴（試験頻出）:

- メガプロキシ・企業プロキシ問題: 大手企業や大学のLANでは、数千〜数万人の社員が1つのグローバルIPアドレスからプロキシ経由でWebサイトにアクセスしてくる。 - キャリアCGN問題: スマートフォンのモバイル回線では、同一キャリアの膨大な端末が共通のNAT/CGNゲートウェイIPを共有する。 - 結果: 数千人分の通信がすべて同一の「単一の実サーバ」に集中し、その1台だけがCPU 100%となってダウンし、他の実サーバは完全に暇になるという深刻な負荷偏り（不均衡）が発生する。

4.2 Cookieパーシステンス（L7推奨方式）

送信元IPアドレスに依存せず、HTTPヘッダのCookieを利用して確実にセッションを維持します。

図のデータを表示できません。

5. SSLオフロードとヘッダ付与（リダイレクトループ障害）

Webサイトの全ページHTTPS化（常時SSL）に伴い、ロードバランサでSSL/TLSを終端し、LB〜実サーバ間は平文のHTTP（80番ポート）で中継する「SSLオフロード」が広く採用されています。

図のデータを表示できません。

5.1 リダイレクトループ障害のメカニズム

SSLオフロード導入時、最も典型的な障害が「ブラウザでERR_TOO_MANY_REDIRECTS（リダイレクトループ）が発生してWebサイトが開かなくなる」トラブルです。

図のデータを表示できません。

• 解決策:

- LBが実サーバへリクエストを転送する際、`X-Forwarded-Proto: https` というHTTPヘッダを付加する。 - Webサーバ（Nginx / Apache / アプリ）は、自身がHTTPでパケットを受信しても、このヘッダを見て「クライアントとは元々HTTPSで暗号化通信が行われていた」と認識し、HTTPSへの不要なリダイレクトを抑止する。 - 同時に、ログ解析やアクセス制限のためにクライアント本来のIPアドレスを伝える `X-Forwarded-For` ヘッダも付与する。

6. 午後・科目B形式 実戦演習

【問題シナリオ】

大手アパレルECサイトを運営するM社は、年商拡大に伴うアクセス急増に対応するため、ロードバランサを刷新した。 M社システムは、L7ロードバランサ（LB-1）の配下に4台のWeb/APサーバ（Web-01〜04）を配置し、HTTPSアクセスのSSL終端をLB-1で実施する設計とした。

図のデータを表示できません。

セール開始日の正午、特定のキャリア（携帯電話事業者）の回線からアクセスした多数の利用者が「カートに商品が入らない」「画面の読み込みがタイムアウトする」という苦情が相次いだ。 運用管理者が各サーバのCPU使用率を確認したところ、以下の状況であった。

• Web-01: CPU使用率 100%（ロードアベレージ急上昇、応答遅延多発）

• Web-02: CPU使用率 8%

• Web-03: CPU使用率 7%

• Web-04: CPU使用率 9%

LB-1のパーシステンス設定を確認したところ、「送信元IPアドレスハッシュ（Source IP Persistence）」が適用されていた。

【設問1】

携帯キャリア網を経由してアクセスした多数の利用者において、Web-01だけに負荷が極端に偏り、サービス遅延が発生した技術的理由について、携帯キャリアのネットワーク仕様およびLB-1の動作に着目して35字以内で述べよ。

解答への思考プロセス

• 障害原因の分析:

- 携帯キャリア網配下の多数のスマートフォンは、キャリア側のCGN（キャリアグレードNAT）や大規模プロキシを経由してインターネットへ抜ける。 - 外部のWebサーバ（LB-1）から見ると、数千〜数万人もの異なる端末の送信元IPアドレスが、キャリアが保有する同一の数個のグローバルIPアドレスに見える。 - LB-1は「送信元IPアドレス」に基づいてハッシュ計算しサーバを固定するため、同一キャリアの全端末が特定の1台（Web-01）に集中転送された。

• 設問要求の確認:

- 「携帯キャリアのネットワーク仕様」＝同一のゲートウェイIP（NAT）を共有 - 「LB-1の動作」＝送信元IPが同一のため同一サーバに振り分けた - 35字以内でまとめる。

• 文章作成:

- キャリアのNATにより送信元IPが同一となり同一サーバに集中したため。（35字）

模範解答

キャリアのNATにより送信元IPが同一となり特定サーバに集中したため。（35字）

減点・失点分析

• ×「Web-01のスペックが他の3台より低かったため。」（構成上の問題ではなくLBのアルゴリズム問題。0点）

• △「キャリア網からのアクセス数が多すぎたため。」（なぜWeb-01だけに偏ったのか「同一IP共有とLBのIPハッシュ動作」の説明がないため不十分）

【設問2】

M社が、Webサーバの負荷を4台に均等に分散しつつ、各利用者のショッピングカート等のセッションを確実に維持するために、LB-1で変更すべきパーシステンス方式を、利用するプロトコル要素を明記して30字以内で述べよ。

解答への思考プロセス

• 解決策の選定:

- 送信元IPアドレスに依存する方式を廃止する。 - Webアプリケーションのセッション維持において、IPアドレスの制約を受けない標準方式は 「Cookieパーシステンス（Cookie挿入方式）」。 - L7ロードバランサがHTTPレスポンスに専用のCookieを付与し、クライアントからの次回リクエストに含まれるCookie値を見てサーバを決定する。

• 字数制限（30字以内）への整形:

- 「HTTPのCookieを利用したパーシステンス方式に変更する。」（29字）

模範解答

HTTPのCookieを利用したパーシステンス方式に変更する。（29字）

減点・失点分析

• ×「ラウンドロビン方式に変更する。」（負荷は均等になるが、セッション維持ができなくなりカートが消えるため不適）

• △「L4ロードバランサに変更する。」（L4ではCookieを解読できないため要件を満たせない）

7. まとめと次ステップ

ロードバランサは、単なるトラフィック分配器ではなく、Webシステムのボトルネックを解消する重要コンポーネントです。

• L4は高速パケット転送、L7はリバースプロキシによる高度な制御とSSLオフロード。

• DSR構成では実サーバのループバックVIP設定とARP応答無効化が必須。

• セッション維持はプロキシやNATの影響を受けない Cookieパーシステンス を採用する。

• SSLオフロード時は X-Forwarded-Proto によるリダイレクトループ防止を徹底する。

次稿 NWP-08（HTTP/2・HTTP/3プロトコル仕様とWeb高速化アーキテクチャ） では、長年使われてきたHTTP/1.1のHead-of-Lineブロッキングの壁を打ち破り、TCPからUDP（QUIC）へと進化した次世代Webトランスポート技術を徹底解剖します。