午後では「LB」「負荷分散装置」「サーバ負荷分散装置」の名で、Web システムの増強・冗長化・クラウド移行の題材に繰り返し出てきます。 一言で言えば「1 つの宛先（仮想 IP）で受けて、裏にいる複数のサーバに配る箱」ですが、設問で問われるのは 「配った後の応答をどう戻すか」「同じ利用者を同じサーバに固定するには」「サーバが死んだとどう判断するか」という細部です。 Web サーバ 3 台の小さな構成を例に、動作の順番どおりに説明します。
Web サーバが 1 台だと、処理能力の上限がそのサーバの性能で決まり、故障すればサービスが止まります。 性能を上げる方法は 2 つあって、サーバそのものを速い機種に替えるのがスケールアップ、台数を増やすのがスケールアウトです。 スケールアウトのほうが上限がなく、1 台壊れても残りで続けられるので、Web システムではこちらが定石です（令和5年 午後Ⅱ問2 の空欄「アップ／アウト」）。
ところが台数を増やすと「利用者はどのサーバにつなげばよいか」という問題が生まれます。DNS に 3 つの IP を登録する手もありますが（5 章の DNS ラウンドロビン）、 壊れたサーバの IP も返してしまいます。そこで、利用者には 1 つの IP（仮想 IP、VIP）だけを見せ、その裏で受け取った接続を生きているサーバに配る装置を置きます。これが LB です。
利用者 PC は VIP（図1 では 203.0.113.10）宛てに TCP 接続を張ります。LB は新しい接続が来るたびに、実サーバ（リアルサーバ）の中から 1 台を選びます。選び方が分散方式です。
| 方式 | 選び方 | 向き不向き |
|---|---|---|
| ラウンドロビン | 順番に 1 台ずつ | 単純。サーバの性能が同じで、処理の重さも揃っているとき |
| 重み付けラウンドロビン | 性能の高いサーバに多く回す | 新旧サーバが混在するとき |
| 最少接続数（リーストコネクション） | 今つながっている接続が一番少ないサーバへ | 処理時間がばらつくとき。令和6年 午後Ⅰ問1 の空欄はこれ |
| 応答時間 | ヘルスチェックの応答が速いサーバへ | サーバの負荷を間接的に見たいとき |
ここで大事なのは、選ぶ単位がパケットではなく接続（セッション）だということです。1 つの TCP 接続の途中でサーバが変わると通信が壊れるので、LB は「この接続は Web2 へ」という対応表（セッション管理テーブル）を持ち、同じ接続のパケットはずっと同じサーバへ送ります。
LB は実サーバに定期的にヘルスチェックを送り、応答がなければ振分け対象から外します。何を送るかで検知できる故障が違います。
| 層 | 送るもの | 検知できること | 検知できないこと |
|---|---|---|---|
| L3 | ICMP Echo（ping） | サーバの電源断、NIC・ケーブルの故障 | OS は生きているが Web サーバのプロセスが止まっている状態 |
| L4 | TCP の SYN（80 番や 443 番へ） | ポートを開いているプロセスの有無 | プロセスはいるがエラーしか返さない状態 |
| L7 | HTTP の GET で特定 URL を取得し、ステータスや内容を見る | アプリケーションが正しく応答しているか | （最も確実。ただし負荷は大きい） |
買い物かごのように、サーバ側が利用者ごとの状態を持つアプリケーションでは、2 回目以降の接続も最初と同じサーバに届かないと状態が失われます。 これをセッション維持（パーシステンス、スティッキー）と呼び、何を手掛かりに「同じ利用者」と判断するかで 3 つの方式があります。
| 手掛かり | 仕組み | 弱点（午後で問われる所） |
|---|---|---|
| 送信元 IP アドレス | 同じ送信元 IP は同じサーバへ | プロキシや NAT の裏にいる多数の利用者が 1 つの IP に見え、負荷が偏る（令和元年 午後Ⅰ問2）。逆に携帯網では同じ利用者の IP が途中で変わる |
| 送信元 IP＋ポート番号 | 上に送信元ポートも加える | TCP コネクションが張り直されるたびにポート番号が変わる可能性があり、同じ利用者と判定できない（令和5年 午後Ⅱ問2） |
| Cookie | LB が最初の応答の Set-Cookie ヘッダに自分用の識別子を挿入し、以後の要求の Cookie ヘッダを見て振り分ける | HTTP ヘッダを読む必要があるので L7 処理が要る。HTTPS では復号しないと見えない。Cookie のセッション ID が LB のセッション管理テーブルに無いとき（LB の再起動後など）は新規として振り直す（令和5年 午後Ⅱ問2） |
| SSL/TLS セッション ID | TLS ハンドシェイクの ID で判定 | 復号せずに済むが、ブラウザが ID を頻繁に更新すると切れる |
要求を実サーバへ届けるところまでは簡単ですが、応答が LB を通って戻るかどうかで構成が分かれます。ここが午後で最も設問になる部分なので、次章で独立に説明します。
LB は要求パケットの宛先 IP を VIP から実サーバの IP に書き換えて転送します（宛先 NAT）。応答は逆に送信元 IP を実サーバから VIP に書き戻す必要があり、この書き戻しは LB しかできません。 つまり応答パケットは必ず LB を通らなければなりません。そのための方法が 2 つあります。
動画配信のように応答のデータ量が要求よりはるかに大きい場合、応答まで LB を通すと LB がボトルネックになります。そこで応答を実サーバから利用者へ直接返すのが DSR 方式です。仕組みは少し変わっています。
平成27年 午後Ⅰ問1 がこの方式そのもので、「ループバック」「VIP アドレスに対する ARP リクエストに応答しないように設定する」「GARP」が解答です。 また DSR では LB が TCP を終端しないため、SYN パケットが届いた時点で振分け先を決める必要があり、「SYN パケットにはレイヤ 7 情報が含まれていない」ので Cookie などを見た振分けはできません。
HTTPS の暗号化・復号は CPU を食うので、LB で TLS を終端し、LB と実サーバの間は平文の HTTP にする構成をよく取ります（SSL オフロード、SSL アクセラレーション）。 利点は、サーバの負荷軽減に加えて、LB が HTTP ヘッダを読めるようになるので Cookie によるセッション維持や XFF の挿入ができることです。
このとき、サーバ証明書と秘密鍵は利用者から見た TLS の相手である LB に置く必要があります。「既設 EC サーバにインストールされているサーバ証明書と秘密鍵のペアを LB に移す」（令和5年 午後Ⅱ問2）がその答えです。 同じ問題で「証明書のコモン名と URL のドメインが異なるからエラーになる」も問われており、証明書は利用者がアクセスする FQDN に対して発行されていなければなりません。
LB を 1 台にすると、今度はそれが止まれば全滅です。普通は 2 台をアクティブ・スタンバイで置き、VRRP と同じ考え方で VIP を 2 台で共有します（アクティブが死ぬとスタンバイが VIP を引き継ぎ、GARP で周囲の ARP テーブルを更新する）。 切替え時に接続を切らさないために、アクティブはセッション管理テーブルをスタンバイに同期しておきます。同期していないと、切替え後に「どの接続をどのサーバに送っていたか」が分からず、利用者は接続し直しになります。
LB は FW や IDS/IPS、プロキシのような通過型の機器の性能拡張にも使えます。FW を 2 台並べ、前後に LB を置いて振り分ける形です（平成27年 午後Ⅰ問2）。サーバ負荷分散との違いは 2 点です。
1 つのホスト名に複数の A レコードを登録し、DNS サーバが順番を入れ替えて返す最も単純な分散です（令和5年 午後Ⅱ問1 の空欄）。利点は装置が要らないこと、欠点はサーバの死活を見ていないので壊れたサーバの IP も返してしまうこと、 そしてキャッシュ DNS サーバが応答を TTL の間覚えるので、切替えが即座に効かないことです。だから移行や切替えの前には「TTL を短くしておく」が定石です（同問「キャッシュ DNS サーバがキャッシュを保持する時間を短くするため」）。
東京と大阪のように離れた拠点（サイト）にまたがる分散では、L2/L3 でパケットを振り分けるわけにいかないので、DNS の応答を使います。広域 LB は権威 DNS サーバとして動き、問合せが来るたびに ①各サイトにヘルスチェックをして生きているサイトだけを候補にし、②問合せ元に近い、または負荷の低いサイトの VIP を、③短い TTL で返します。 各サイトの中では普通のサーバ負荷分散 LB が働くので、二段構えです。令和6年 午後Ⅰ問1 は、この広域 LB 方式と CDN 方式を比較する構成でした。
もう 1 つの広域分散が BGP エニーキャストです。複数拠点から同じアドレスブロックを BGP で広告し、利用者は経路的に最も近い拠点に自然に届きます。DNS のキャッシュに左右されない利点がありますが、BGP の知識が要ります（BGP ページの AS_PATH を参照）。 同じ問題で「不正な BGP 接続」「不正な経路に含まれるアドレスブロックへのコンテンツ配信ができなくなる」と、経路ハイジャックのリスクも問われています。
世界中にキャッシュサーバ（エッジ）を持つ事業者に配信を委ねる方式です。自社の DNS で www を CDN 事業者のホスト名への CNAME にすると、利用者は CDN の DNS が選んだ最寄りのエッジにつながります。 エッジはコンテンツをキャッシュしていればそのまま返し、なければオリジン（自社のサーバ）へ取りに来ます。
| 用語 | 意味 | 午後でのポイント |
|---|---|---|
| 仮想 IP（VIP） | 利用者に見せる代表アドレス。LB が持つ | DNS に登録するのは VIP。実サーバの IP は外に出さない |
| 実サーバ（リアルサーバ） | VIP の裏で実際に処理するサーバ群 | 振分け先に追加・削除するのは運用作業（サーバ転用時に追加し忘れると使われない） |
| 分散方式 | ラウンドロビン／重み付け／最少接続数／応答時間 | 処理時間がばらつくなら最少接続数 |
| ヘルスチェック | 実サーバの死活監視。L3（ICMP）／L4（TCP）／L7（HTTP） | ping では Web プロセス停止を検知できない。サービスと同じ層で見る |
| セッション維持（パーシステンス） | 同じ利用者を同じサーバへ。送信元 IP／Cookie／TLS セッション ID | 送信元 IP は NAT で偏る。Cookie は L7 処理（復号）が要る |
| セッション管理テーブル | 「この接続はこのサーバ」の対応表 | スタンバイ LB に同期して切替え時の切断を防ぐ |
| 宛先 NAT／送信元 NAT | 宛先を VIP→実サーバに／送信元を LB の IP に書き換える | 送信元 NAT は戻りを LB に通すため。元の送信元は XFF で伝える |
| X-Forwarded-For（XFF） | LB が元の送信元 IP を書き足す HTTP ヘッダ | 2 回出題。「アクセス元 PC の IP をサーバに通知するため」 |
| インライン／ワンアーム | LB を経路上に置く／1 本足で横に置く | ワンアームは送信元 NAT か、サーバのデフォルトゲートウェイを LB にする |
| DSR | 応答を実サーバから直接返す方式 | ループバックに VIP、VIP の ARP に応答しない、L7 情報で振り分けられない |
| SSL オフロード | LB で TLS を終端 | 証明書と秘密鍵は LB に置く。コモン名は利用者がアクセスする FQDN |
| 透過型負荷分散 | FW など通過型機器の分散 | 宛先 IP は書き換えず MAC だけ。行きと帰りで同じ FW |
| スケールアップ／スケールアウト | 1 台を強化／台数を増やす | LB はスケールアウトの前提。N＋1 で故障時性能を確保 |
| DNS ラウンドロビン | 複数の A レコードを順番に返す | 死活を見ない。TTL の間キャッシュされる |
| 広域負荷分散（GSLB） | DNS 応答でサイトを選ぶ | ヘルスチェック連動、短い TTL、近接性 |
| BGP エニーキャスト | 複数拠点から同じ経路を広告 | 経路的に近い拠点へ。経路ハイジャックに注意 |
| CDN／エッジ／オリジン | 配信事業者のキャッシュ網／その末端／自社の元サーバ | CNAME で向ける。オリジンは送信元を CDN に限定。DDoS はエッジで吸収 |
| 設問の型 | 答え方 | 出た年度 |
|---|---|---|
| ping によるヘルスチェックで検知できない状態 | ICMP には応答するが HTTP サーバのプロセスが停止している状態（サービスが稼働しているか検査していない） | R6 午後Ⅰ問1、R5 午後Ⅱ問2 |
| 空欄「処理時間がばらつくときの分散方式」 | 最少接続数 | R6 午後Ⅰ問1 |
| 送信元 IP でセッション維持すると何が起きるか | プロキシ・NAT 配下の多数の利用者が同じ IP に見え、負荷が偏る | R1 午後Ⅰ問2 |
| 送信元ポート番号をセッション維持に使えない理由 | TCP コネクションが再設定されるたびにポート番号が変わる可能性があるから | R5 午後Ⅱ問2 |
| Cookie 方式の空欄・処理 | Set-Cookie で挿入、Cookie で判定。HTTP ヘッダを編集する処理（L7） | R1 午後Ⅰ問2、R5 午後Ⅱ問2 |
| 送信元 NAT の目的・副作用への対策 | 応答を LB に戻すため送信元を LB 自身の IP に変換。元の送信元は XFF ヘッダで通知する | R5 午後Ⅱ問2、R1 午後Ⅰ問2 |
| LB 導入で実サーバ側に必要な設定変更 | デフォルトゲートウェイを FW から LB に変更。証明書と秘密鍵を LB に移す | R5 午後Ⅱ問2 |
| DSR 方式の実サーバの設定 | ループバックに VIP を設定し、VIP への ARP 要求に応答しない。切替え時は GARP | H27 午後Ⅰ問1 |
| DSR で L7 振分けができない理由 | 振分けを決める SYN パケットにはレイヤ 7 情報が含まれていないから | H27 午後Ⅰ問1 |
| 透過型負荷分散で LB が書き換えるもの・条件 | 宛先 IP は書き換えられないので宛先 MAC のみ。セッション単位に 2 台の LB が同じ FW を選ぶ | H27 午後Ⅰ問2 |
| 台数を 1 台多く置く理由 | 1 台故障時にも性能（応答速度）を不足させないため | H27 午後Ⅰ問2、R5 午後Ⅱ問2 |
| DNS ラウンドロビン・TTL 短縮の理由 | キャッシュ DNS サーバが古い応答を保持する時間を短くし、切替えを早く反映させるため | R5 午後Ⅱ問1 |
| CNAME で外部サービスに向ける利点 | 事業者が IP を変更しても自社 DNS の変更作業が不要 | R1 午後Ⅰ問2 |
| CDN の DDoS 対策の利点 | 攻撃パケットを攻撃元に近いところで遮断できる | R6 午後Ⅰ問1 |
クリックで答えが開きます。
このページの用語集（17 語）から作った確認問題です。「意味 → 用語」は意味の説明（用語そのものは＿＿で伏せてある）を読んで用語を入力し、Enter で答え合わせします。 表記ゆれで × になったときは「合っていた」で直せます。「用語 → 意味」は口で説明してから答えを開いて自己採点します。結果はこのブラウザに保存され、「×だけ」で間違えた語だけを解き直せます。
作成 2026-10-28。ネットワークスペシャリスト 科目B（午後）対策。出典は平成27年秋・令和元年秋・令和5〜6年春の午後Ⅰ・Ⅱ（IPA 公開問題の解答例で確認したもの）。 関連: BGP とは（エニーキャスト・経路ハイジャック）、VRRP とは（LB 自身の冗長の考え方）、OSPF とは。