はじめに
Web サイトや業務システムの「遅い」「つながらない」を防ぐうえで、ロードバランサー（LB: 負荷分散装置）は基盤となる存在です。クライアントからのアクセスを複数のサーバーへ振り分けることで負荷を分散し、1 台のサーバーが停止してもサービスを継続できる可用性（Availability）を担保します。
導入時に最初に迷いやすいのが、ネットワークへの接続構成（配置デザイン）です。「既存のネットワークを変えずに導入したいのか」「セキュリティを重視して通信を分離したいのか」によって、選ぶべき構成は変わります。
- ワンアーム構成（One-Arm）: 既存環境に後付けで導入しやすい構成の仕組みと、SNAT が前提となる理由
- ツーアーム構成（Two-Arm）: ネットワークの境界として機能する構成の仕組みと、クライアント IP を透過できる利点
- DSR 構成（Direct Server Return）: 戻り通信が LB を経由しない第 3 の構成と、その制約
- 3 構成の比較とクラウドマネージド LB（AWS ALB／NLB 等）との位置づけ、自社環境に合った選び方
結論を先に整理すると、後付け導入を優先するならワンアーム、セキュリティ境界の確立を優先するならツーアーム、戻り通信の帯域を抑えたいなら DSR が候補になります。いずれが優れているという話ではなく、既存環境への影響・クライアント IP の見え方・冗長化の要件で選び分けるのが実務上の判断軸です。
ワンアーム構成（One-Arm Design）
ワンアーム構成は、その名のとおり LB がネットワークに対して 1 本のインターフェース（片腕）だけで接続される構成です。物理的には、L2/L3 スイッチにサーバーと同じようにぶら下がる形になります。
特徴: 既存ネットワークへの後付け導入
最大の特徴は、既存のネットワーク構成をほとんど変更せずに導入できる点です。ルータやスイッチの物理配線、サーバーのデフォルトゲートウェイ設定を変更することなく、LB を追加するだけで負荷分散を始められます。
通信の仕組み: SNAT が前提となる理由
ワンアーム構成で重要になるのが、SNAT（Source Network Address Translation: 送信元アドレス変換）です。これがないと、行きと帰りで経路が分かれる非対称通信が発生し、通信が成立しません。
行き（Client → Server）の通信は LB に届き、LB はサーバーへ転送します。問題は帰り（Server → Client）です。もし SNAT を行わない場合、サーバーは送信元 IP をクライアントの実 IP と認識し、LB を通さずに直接デフォルトゲートウェイ（ルータ）経由でクライアントへ返信します。その結果、クライアントは「LB に送ったのに、別の相手から返事が来た」と判断し、パケットを破棄します（通信断）。
これを防ぐため、LB はサーバーへ転送する際、送信元 IP を自分（LB）の IP アドレスに書き換えます（SNAT）これにより、サーバーからの返信は必ず LB に戻り、正しい経路で通信が成立します。
クライアント IP が見えなくなる問題と対策
SNAT の副作用として、Web サーバーのアクセスログにはすべてのアクセス元が LB の IP アドレスとして記録されます。これではアクセス元の分析ができません。代表的な対策は次の 3 つです。
- X-Forwarded-For（XFF）
-
LB が HTTP ヘッダーに本来のクライアント IP を付与してサーバーへ伝える方式です。HTTP/HTTPS（L7）で広く使われる事実上の標準です。
- Forwarded ヘッダー（RFC 7239）
-
XFF を標準化した後継ヘッダーで、
for/proto/host/byを 1 つのヘッダーに集約できます。XFF が事実上の標準であるのに対し、こちらは IETF 標準として位置づけられています。 - PROXY protocol
-
HTTP に依存しない L4（TCP）レベルの方式で、接続の先頭にクライアント IP・ポート情報を付与します。HTTP 以外のプロトコルを負荷分散する場合の選択肢になります。
参考: HAProxy Documentation (Add a Forwarded header)
“supersedes the non-standard X-Forwarded-For header and its variants”
（非標準の X-Forwarded-For ヘッダーおよびその派生を置き換えるもの）
https://www.haproxy.com/documentation/haproxy-configuration-tutorials/proxying-essentials/client-ip-preservation/add-forwarded-header/
F5 BIG-IP を利用している場合の X-Forwarded-For 設定手順については、詳細を関連記事『BIG-IP の X-Forwarded-For 設定｜SNAT 環境でクライアント IP を通知』で解説しています。
また、IP アドレスの変換はログだけでなくセッション維持（パーシステンス）の設定にも影響します。パーシステンスの仕組みと選び方については、関連記事『BIG-IP のセッションパーシステンスの設定手順｜Cookie と Source IP の違い』もあわせて参照してください。
メリットとデメリット
| 区分 | 内容 |
|---|---|
| メリット | ・導入が容易: 既存ネットワーク（IP 設計や配線）への影響が最小限 ・柔軟性: 必要なサーバーだけを LB 配下に置くといった構成変更が簡単 |
| デメリット | ・ログ問題: サーバー側で実 IP を確認するには X-Forwarded-For 等の追加設定が必要 ・帯域: 行きの通信も帰りの通信も同じインターフェース（VLAN）を通るため、帯域消費が 2 倍になりやすい |
ツーアーム構成（Two-Arm / Inline Design）
ツーアーム構成（インライン構成）は、LB が 2 つの異なるネットワークセグメントの間に挟まるように接続される構成です。LB が外部ネットワーク（Internet 側）と内部ネットワーク（Server 側）をつなぎます。
特徴: ネットワークの境界として配置
この構成の特徴は、すべての通信が必ず LB を通過する点です。ワンアームのように横から追加するのではなく、クライアントとサーバーの通信経路上に直列で配置されます。これにより、許可されていない通信を遮断できるため、ファイアウォールのようなセキュリティ境界の役割も兼ねられます。
参考: CCDE – Load Balancer Designs (Daniels Networking Blog)
“all traffic to and from the servers will pass through the SLB device”
（サーバーへの行き帰りすべての通信が、ロードバランサー装置を通過する）
https://lostintransit.se/2015/10/26/ccde-load-balancer-designs/
通信の仕組み: デフォルトゲートウェイとしての役割
ツーアーム構成では、サーバー側のデフォルトゲートウェイ（DGW）を LB の内部側 IP アドレスに向けるのが一般的です。
行き（Client → Server）では、LB はクライアントの通信を受け取り、そのままサーバーへ転送します（ここで SNAT は不要です）。帰り（Server → Client）では、サーバーは返信パケットを自身の DGW である LB に送ります。LB は帰りのパケットも確実に受け取れるため、正しい通信としてクライアントへ返信できます。
つまり、SNAT なしで通信が成立するため、サーバー側でクライアントの実 IP アドレスをそのまま確認できるのが利点です（X-Forwarded-For 等の設定が不要）
メリットとデメリット
| 区分 | 内容 |
|---|---|
| メリット | ・透過性: SNAT 不要でクライアント IP を維持できるため、ログ分析やアクセス制御が容易 ・セキュリティ: サーバーを外部から直接アクセスできないセグメント（DMZ 等）に隔離できる |
| デメリット | ・影響範囲が大きい: LB が停止すると配下のサーバー群への通信が遮断される ・サーバー設定変更: 既存サーバーの DGW を変更する必要があり、導入時の停止や影響確認が大掛かりになる |
LB が単一障害点（SPOF）になりやすいため、ツーアーム構成では冗長化（HA 構成）を推奨します。
DSR 構成（Direct Server Return / F5 では N-Path）
ワンアーム・ツーアームと並ぶ第 3 の代表構成が DSR（Direct Server Return）です。F5 では N-Path、製品によっては Direct Routing（DR）とも呼ばれます。ワンアームと同様に LB のインターフェースを 1 本だけ使いますが、戻り通信が LB を経由せず、サーバーからクライアントへ直接返る点が大きく異なります。
仕組みと向いているケース
行きの通信（Client → Server）は LB が受け取り、宛先 MAC アドレスを書き換えてサーバーへ転送します。帰りの通信は LB を通らず、ルータ経由でクライアントへ直接戻ります。リクエストは小さく応答が大きいワークロード（例: 受信が小さく、応答が数倍の帯域を生むケース）では、戻り通信が LB を通らないことで、LB がボトルネックになりにくいという利点があります。これはワンアーム構成の「帯域消費が 2 倍になりやすい」課題への有効な対策になります。
なお、DSR でも LB はサーバーへのヘルスチェックは継続できます。
参考: NetScaler Documentation (Direct server return mode)
“the appliance can continue to perform health checks on services”
（DSR モードでも、装置はサービスへのヘルスチェックを継続できる）
https://docs.netscaler.com/en-us/citrix-adc/current-release/load-balancing/load-balancing-dsrmode.html
制約事項とハマりポイント
DSR には導入前に押さえておきたい前提条件があります。
- サーバー側のループバックに VIP（仮想 IP）を設定し、その VIP に対する ARP 応答を無効化する必要があります。 これを行わないと、クライアントの要求が LB を迂回してしまいます。
- LB はパケットの宛先 MAC を書き換えるだけのため、L4 より上位の処理（ポート書き換え、SSL 終端、コンテンツベースのルーティング等）は行えません。
- 戻り通信が LB を通らないため、SNAT は使わず、クライアント IP はサーバー側でそのまま確認できます。
メリットとデメリット
| 区分 | 内容 |
|---|---|
| メリット | ・性能: 戻り通信が LB を迂回するため、応答が大きいトラフィックで LB の負荷を抑えやすい ・透過性: クライアント IP を維持できる |
| デメリット | ・設定が複雑: 各サーバーでループバック VIP 設定と ARP 無効化が必要 ・機能制限: L7 の処理（SSL 終端、コンテンツベースのルーティング等）には対応しにくい |
比較と選び方: どの構成を採用すべきか
それぞれの特徴を踏まえ、比較表と選定の考え方を整理します。
構成比較テーブル
| 項目 | ワンアーム（One-Arm） | ツーアーム（Two-Arm） | DSR（Direct Server Return） |
|---|---|---|---|
| 物理接続 | L2 スイッチ等に 1 本で接続 | 外部と内部の間に直列接続 | L2 スイッチ等に 1 本で接続 |
| 既存環境への影響 | 小（IP 設計変更なし） | 大（DGW 変更など設計見直し） | 中（サーバーにループバック VIP・ARP 設定） |
| 戻り通信の経路 | 行きと帰りで経路が異なる（非対称） | 行きも帰りも LB を通過（対称） | 戻りは LB を経由せず直接返る |
| SNAT（IP 変換） | 必要（戻り通信の誘導のため） | 不要（透過的に通信可能） | 不要（戻りが LB を通らない） |
| クライアント IP | サーバー側で見えない（XFF 等が必要） | そのまま見える | そのまま見える |
| L7 処理（SSL 終端等） | 対応しやすい | 対応しやすい | 対応しにくい |
| 主な用途 | 既存システムの拡張、クラウド環境 | 新規構築、DMZ セグメント設計 | 応答帯域が大きい高負荷システム |
既存環境への後付けなら「ワンアーム」
すでに稼働しているシステムに後付けで導入する場合や、ネットワーク構成を大きく変えたくない場合は、ワンアーム構成がおすすめです。サーバーの DGW や IP アドレスを変更する必要がなく、ダウンタイムや移行リスクを抑えられます。Web サーバー側でアクセスログ分析が必要な場合は、X-Forwarded-For（または Forwarded ヘッダー）の設定とログフォーマットの変更をあわせて行うことを推奨します。
セキュリティ境界を作るなら「ツーアーム」
新規システム構築時や、Web サーバーを直接インターネットに公開したくない場合は、ツーアーム構成が適しています。LB がファイアウォールのように振る舞い、許可されていない通信を遮断できます。SNAT 不要でクライアント IP が見えるため、サーバー側の設定もシンプルになります。LB が SPOF になりやすいため、冗長化（HA 構成）を前提に設計することをおすすめします。
応答帯域がボトルネックになるなら「DSR」
大量のデータを返すストリーミングやダウンロード系など、応答トラフィックが大きいワークロードでは、戻り通信が LB を迂回する DSR が選択肢になります。ただしサーバー側のループバック VIP 設定や ARP 無効化が必要で、L7 処理には対応しにくいため、要件が L4 の範囲で収まるかを事前に確認することをおすすめします。
クラウドマネージド LB との位置づけ
オンプレミスの構成設計の考え方は、クラウドのマネージド LB を選ぶ際にもそのまま応用できます。AWS を例にとると、Application Load Balancer（ALB）は L7 のリバースプロキシとして動作し、クライアント IP はそのままでは透過されず X-Forwarded-For で伝達します。これはワンアーム＋ SNAT の挙動に近いものです。一方 Network Load Balancer（NLB）は L4 で動作し、クライアントの送信元 IP を既定で透過できます。これはツーアームや DSR の透過性に近い考え方です。
参考: AWS（ALB と NLB の PrivateLink 連携）
“ALB is a managed layer 7 proxy that provides advanced request-based routing”
（ALB は高度なリクエストベースのルーティングを提供する、マネージドな L7 プロキシ）
https://aws.amazon.com/about-aws/whats-new/2021/09/application-load-balancer-aws-privatelink-static-ip-addresses-network-load-balancer/
つまり「L7 でリッチな機能を使うか（ALB／ワンアーム的）」「L4 で透過性と性能を優先するか（NLB／ツーアーム・DSR 的）」という選定軸は、オンプレでもクラウドでも共通しています。
まとめ
ロードバランサーの配置は、単なる配線の違いではなく、運用設計に関わる選択です。後付け導入のしやすさ、クライアント IP の見え方、戻り通信の帯域、冗長化の要件によって、適した構成は変わります。以下に要点を整理します。
- ワンアームは既存ネットワークを変えずに後付け導入しやすい構成
- ワンアームでは戻り通信を誘導するため SNAT が前提となる
- SNAT でクライアント IP が隠れるため XFF や Forwarded での通知が必要
- ツーアームは全通信が LB を通過しセキュリティ境界を兼ねられる構成
- ツーアームは SNAT 不要で IP を透過できる一方 SPOF になりやすい
- DSR は戻り通信が LB を迂回し応答帯域のボトルネックを避けやすい構成
- クラウドでも ALB は L7、NLB は L4 透過と選定軸は共通する
以上、最後までお読みいただきありがとうございました。
