L4 ロードバランサの内部：DSR・コネクション保持

L4 ロードバランサが見ているもの

L4 ロードバランサ（LB）は、トランスポート層の情報、すなわち IP アドレスとポート番号だけを見て転送先の実サーバーを決めます。HTTP のパスや Cookie のようなアプリ層の中身は解釈しないため、TLS を終端する必要がなく、CPU 負荷が軽く遅延も小さいのが特徴です。L7 との役割分担はプロキシとロードバランサで整理しています。

ここで決定的に重要なのは、LB は「接続（コネクション）」を単位に動くという点です。1つの TCP 接続を構成するパケット群は、最初から最後まで同じ実サーバーへ届かなければなりません。途中で宛先が変われば、その実サーバーにはシーケンス番号もTCP 状態も存在しない接続のパケットが飛び込み、RST で切られて通信が壊れます。L4 LB の内部設計は、この接続の一貫性をいかに低コストで保つかという一点に集約されます。

NAT 方式：往復ともLBを通す

最も素直な実装が NAT 方式です。クライアントから来たパケットの宛先 IP（LB の VIP＝仮想 IP）を、選んだ実サーバーの IP へ書き換えて転送します。戻りパケットも LB を通り、送信元 IP を VIP へ書き戻してからクライアントへ返します。クライアントはあくまで VIP と会話しているつもりで、実サーバーの存在に気づきません。NAT そのものの仕組みはNATを参照してください。

NAT 方式の経路（往路と復路の両方が LB を通る）:
  client → [dst=VIP]           → LB
  LB     → [dst=realserver IP] → realserver   (宛先を書き換え)
  realserver → [src=realserver IP] → LB
  LB     → [src=VIP]           → client        (送信元を書き戻す)

NAT 方式の弱点は、戻りトラフィックも必ず LB を経由することです。Web の応答は一般にリクエストよりはるかに大きく、ダウンロードや動画配信では復路が支配的になります。その全量が LB を通れば、LB の帯域とパケット処理能力がボトルネックになります。さらに、実サーバーから見える送信元 IP は LB のものになり、クライアントの本来の IP はそのままでは取れません。

DSR：戻りを LB に通さない

この復路ボトルネックを外すのが**ダイレクトサーバーリターン（DSR、Direct Server Return）**です。発想は単純で、往路だけ LB を通し、復路は実サーバーからクライアントへ直接返します。応答が LB を素通りしないため、LB は往路のリクエストだけを捌けばよく、桁違いのスループットを扱えます。

実現の鍵は、宛先 IP を書き換えないことです。代表的な L2-DSR では、LB は IP ヘッダを一切変えず、宛先 MAC アドレスだけを実サーバーのものに差し替えて転送します（同一 L2 セグメントが前提）。実サーバーは宛先 IP が VIP のままのパケットを受け取るので、自分の loopback などに VIP を割り当てておき「自分宛て」として処理します。応答の送信元 IP も自然に VIP になり、クライアントから見れば VIP と会話したことになります。トンネル方式（IP-in-IP）では L2 制約を外し、ルータ越しでも DSR を成立させます。

DSR の制約は、戻りが LB を通らないためにLB が接続の終了を観測できないことです。LB は往路のパケットしか見ないので、TCP の FIN/RST による正常終了を直接は捉えられず、後述するコネクション追跡はタイムアウト主体にならざるを得ません。また、応答を加工できないため L7 的な書き換えはできず、純粋な L4 転送に用途が限られます。

コネクション追跡テーブル

NAT であれ DSR であれ、L4 LB は同一接続を同じ実サーバーへ送り続ける必要があります。これを担うのが**コネクション追跡テーブル（conntrack table）**です。キーは接続を一意に識別する5タプル、値は選択済みの実サーバーです。

conntrack エントリ:
  key   = (src IP, src port, dst IP, dst port, protocol)
  value = 選択した実サーバー, 最終観測時刻, 状態

パケットが届くと、LB はまずこの表を引きます。ヒットすれば記録済みの実サーバーへ即座に転送し、再計算しません。ミスすれば（＝新規接続）負荷分散アルゴリズムで実サーバーを選び、結果を表に書き込みます。これにより、たとえ実サーバー集合が後から変わっても、確立済みの接続は最初に選んだ宛先へ固定され続けます。表引きは O(1) のハッシュ参照で、転送のホットパスを軽く保ちます。

このテーブルは無限には保持できないため、各エントリにアイドルタイムアウトを持たせ、一定時間パケットが来ない接続を回収します。TCP では FIN/RST を観測したら短いタイムアウトへ落とし、確立中の接続は長めに保つ、という状態依存の管理が一般的です。DSR では復路（と多くの場合 FIN/RST）が見えないため、この見極めが効かず、アイドルタイムアウトのみで判断します。

なぜテーブルだけでは足りないのか

conntrack テーブルは強力ですが、1台の LB の中だけで完結する記憶です。現実の大規模 LB は、可用性とスケールのために複数台を並べ、その手前でECMPやAnycastを使ってトラフィックを各 LB へ分散します。ここで二つの問題が起きます。

一つはLB 群の構成変化です。ECMP は経路（＝LB）が増減すると単純なハッシュではフローの割り当てが大きくずれ、確立済み接続のパケットが、その接続のエントリを持たない別の LB へ届きます。届いた LB はテーブルがミスし、新規接続として別の実サーバーを選ぶかもしれません。結果、接続が壊れます。

もう一つは実サーバー集合の変化です。index = hash(5タプル) mod N のような単純剰余では、実サーバー数 N が変わると、ほとんどの接続の割り当て先がずれてしまいます。conntrack でヒットしている既存接続は守られますが、何らかの理由でエントリを失った接続（LB の切り替えやテーブル満杯による追い出し）は、再計算で別サーバーへ飛び、壊れます。

つまり、テーブルがミスしたときのフォールバックとしての実サーバー選択自体が、構成変化に対して安定でなければなりません。ここで一貫性ハッシュが効いてきます。

Maglev と一貫性ハッシュによる接続維持

一貫性ハッシュ（consistent hashing）は、実サーバーの増減で再割り当てされる接続を全体の約 1/N に限定し、影響を受けない接続の宛先を不変に保つ手法です。これにより、conntrack テーブルがミスしても、複数の LB がそれぞれ独立に同じ実サーバーを選べるようになります。テーブルの内容を LB 間で同期しなくても、同じ5タプルなら同じ宛先に落ちるからです。

Google が公表した Maglev は、これをパケット処理速度に耐える形で実装したものです。各 LB は実サーバー集合から決定的に lookup テーブル（固定長の配列で、各スロットが1つの実サーバーを指す）を構築します。転送時は5タプルをハッシュしてスロット番号を引くだけで実サーバーが決まり、ホットパスは単純な配列参照になります。

Maglev の転送（テーブルがミスした場合のフォールバック選択）:
  slot   = hash(5タプル) mod テーブル長
  server = lookup[slot]
  # lookup テーブルは実サーバー集合から決定的に生成されるため、
  # 同じ集合を持つ全 LB が同じ slot から同じ server を導く

Maglev の lookup テーブル生成は、各実サーバーに固有の順列（preference list）を割り当て、ラウンドロビンでスロットを奪い合わせることで、(1) 各サーバーがほぼ均等なスロット数を得る均等性と、(2) サーバーが1台抜けても他のスロット割り当てがほとんど動かない最小撹乱性を両立させます。1台障害時に再割り当てされるスロットは、原則その障害サーバーが持っていた分にほぼ限られます。

まとめ

L4 ロードバランサの内部は、接続の一貫性を低コストで保つという制約から設計が導かれます。NAT 方式は往復とも LB を通して対称性を担保しますが復路がボトルネックになり、DSR は戻りを実サーバーから直接返すことでこの制約を外す代わりに、VIP の loopback 割当・ARP 抑制と、LB が接続終了を観測できないという代償を負います。同一接続を同じ実サーバーへ固定する記憶はコネクション追跡テーブルが担い、テーブルがミスする瞬間に宛先がブレないよう Maglev のような一貫性ハッシュを併用します。NAT と DSR の経路差、conntrack の役割、そして一貫性ハッシュが「テーブル同期なしの宛先一致」をどう実現するかを、それぞれが何を解いているかとセットで押さえることが、L4 LB を正しく設計・運用する鍵になります。