今も重要な OSI レイヤーの区別
ロードバランシングの概念は単純です。入ってくるリクエストを複数のサービスインスタンスに分散させ、単一のサーバーが過負荷にならず、アプリケーションが可用な状態を保つようにします。興味深いのは、その分散判断をどのように下すかです。最も影響が大きい分かれ目が Layer 4 と Layer 7 の間にあります。
Layer 4 ロードバランシングは OSI モデルのトランスポート層 — TCP と UDP で動作します。ロードバランサーは接続の送信元 IP、宛先 IP、ポートしか見ません。これらヘッダーフィールドに基づいて分散判断を下し、ペイロードを検査せずバイトを通過させます。アプリケーションプロトコルは HTTP、MySQL、Kafka、独自のバイナリプロトコルのいずれでも構いません — ロードバランサーは知りもしないし気にもしません。
Layer 7 ロードバランシングはアプリケーション層 — HTTP、HTTPS、gRPC、WebSocket で動作します。ロードバランサーは各リクエストを解析し、URL パス、ヘッダー、Cookie、メソッドを読み、その内容に基づいてルーティング判断を下します。通過時にリクエストを変換することもできます: 圧縮、ヘッダー書き換え、TLS 終端、キャッシュ。
Layer 7 は Layer 4 より強力で、Layer 4 より高価です。両者の選択は、アプリケーションプロトコルが HTTP 形状かどうか、また追加機能が接続あたりのコストに見合うかどうかにかかっています。
Layer 4 が正解になるとき
L4 が正解となるシナリオは一つの性質を共有します。すなわち、アプリケーション内容の解析が不要か、予算に収まらないかです。
HTTP 以外のプロトコルがこのカテゴリの最も明確な例です。データベース(MySQL、PostgreSQL)、メッセージキュー(Kafka、RabbitMQ)、メール(SMTP)、独自 TCP サービスでは、ロードバランサーはアプリケーション内容を理解する必要がありません — ポートと接続レートによる分散で十分機能します。
純粋なパフォーマンス要件も L4 を指します。L4 の接続あたりオーバーヘッドはアプリケーション解析がないため最小です。マイクロ秒が問題になる大容量 TCP サービス — レイテンシに敏感な取引プラットフォーム、リアルタイムゲームのバックエンド、類似のワークロード — では L4 が適切なツールです。
エンドツーエンド暗号化もまた L4 のケースです。TLS をロードバランサーではなくアプリケーションで終端しなければならない — 規制上の要請、マルチテナント分離、顧客管理鍵 — 場合、L4 は TLS を透過的に通します。ロードバランサーは平文を一度も見ません。
最後に、単純な分散ロジックで十分であれば、L4 はより少ない運用オーバーヘッドで動きます。ラウンドロビン、送信元 IP ハッシュ、最小接続が十分で URL ベースのルーティングが要らないなら、L4 は軽量で扱いやすい選択です。
Layer 7 が正解になるとき
L7 を特徴づけるのは、アプリケーション内容に基づいてルーティングと変換の判断を下せる能力です。この能力がなければ最新の Web アプリケーションのほとんどは機能しません。
URL ベースのルーティングが最も一般的なケースです。異なるパスを異なるサービスクラスタへ送る — /api/v1/users をあるクラスタへ、/api/v1/orders を別のクラスタへ、/static/* を CDN へ — ことは L4 では不可能です。L4 はパスを見ないからです。
ヘッダーや Cookie に基づくルーティングも L7 を要求します。A/B テスト、バージョンピン留め(X-Service-Version: 2.5 が特定の配置にルーティング)、アプリケーションセッション ID によるセッションアフィニティ、ヘッダーによる顧客別ルーティング — これらはすべてアプリケーション内容の読み取りを必要とします。
TLS 終端も L7 の仕事です。SSL オフロードはロードバランサーで TLS を終端し、サービスを暗号処理から解放します。証明書管理を集約でき、WAF 検査が可能になります。WAF は攻撃を見るために平文を必要としますが、L7 がなければそれは起きません。
アプリケーション対応機能 — 圧縮、キャッシュ、リクエスト書き換え、内容ベースのヘルスチェック(サービスは接続を受けるだけでなく /health で 200 を返す)、レガシーサービスのための HTTP/2 から HTTP/1.1 へのダウングレード — もすべて L7 を必要とします。
アプリケーションレベルの可観測性も同じ論理に従います。エンドポイントあたりレイテンシ、URL ごとのエラー率、スロークエリ検出 — これらはリクエストを見る必要があり、接続では足りません。L7 はこのデータを露出させ、L4 は接続レベルしか見ません。
中心となる論点はこうです。アプリケーション内容に基づいて判断するなら L7 は必須。接続レベルでのみ判断するなら L4 で足ります。
直接比較
| 項目 | Layer 4 | Layer 7 |
|---|---|---|
| OSI 層 | トランスポート(TCP/UDP) | アプリケーション(HTTP、HTTPS、gRPC、WebSocket) |
| ルーティング入力 | 送信元 IP、宛先 IP、ポート | URL、ヘッダー、Cookie、メソッド、ボディ |
| TLS の扱い | パススルー | 終端またはパススルー |
| 接続あたりオーバーヘッド | 最小 | 高い(解析が必要) |
| 分散アルゴリズム | ラウンドロビン、送信元 IP ハッシュ、最小接続 | L4 のすべて、加えてコンテンツベースルーティング、URL 単位の重み付け |
| WAF 連携 | 不可(内容が見えない) | ネイティブ |
| 可観測性 | 接続レベル | リクエストレベル |
| 典型的なユースケース | データベースプロキシ、ゲーム、RTMP、SMTP | Web アプリ、API、マイクロサービス |
最新の配置は両方を使う
判断はインフラ全体で「L4 か L7 か」となることはまれです。アプリケーション単位、ときにはリスナー単位で行われます。
典型的なエンタープライズパターンは両モードを組み合わせます。ユーザーからの HTTPS トラフィックにはエッジで L7。プロトコルが TCP ネイティブでレイテンシ予算が厳しい内部の東西トラフィックには L4。東西トラフィックが gRPC のような HTTP 上 RPC で走る箇所では再び L7。
アーキテクチャ上の問いは、単一のロードバランサー配置で両モードを扱えるか、それとも組織が L4 と L7 の別製品を運用すべきかです。別製品アプローチは歴史的に一般的でした。L4 はカーネルバイパスネットワークを、L7 はリッチな HTTP 解析を望み、実装要件が異なっていたためです。最新の ADC はその差を埋め、同一の機器がリスナーごとの設定で両モードを扱います。
両者を統合する運用上の利点はどの統合とも同じです。デプロイすべき製品が一つ、可観測性面が一つ、運用ランブックの集合が一つ、アップグレードパスが一つ。以前は別ベンダーの L4 と L7 製品を運用していた組織にとって、単一の ADC への統合はしばしば最大の運用簡素化となります。
TR7 ロードバランサーは両モードをどう扱うか
TR7 のロードバランサー(LB)はリスナーごとの設定により、同一機器で L4 と L7 の両モードを担います。単一の配置で次のリスナーを並べてホストできます: 443 で WAF と SSL アクセラレーションを伴う HTTPS Web トラフィックを扱う L7 リスナー。5432 で送信元 IP アフィニティで PostgreSQL 接続を扱う L4 リスナー。8080 で mTLS による内部 gRPC サービスを扱うもう一つの L7 リスナー。すべて一緒に構成され、可観測性とアップグレードのライフサイクルを共有します。
ハードウェアアクセラレーションは両モードに適用されます。L4 接続はカーネルバイパスのパケット処理を活用し、L7 接続はオフロードされた TLS 終端と HTTP/2 / HTTP/3 の解析を活用します。同じ物理機器で何千もの L4 TCP サービスと何千もの L7 HTTPS セッションを同時に運ぶことができます。制限はハードウェアのエンベロープであり、モードごとのライセンスや機能ゲートではありません。
2026 年にベンダーを選ぶ組織にとって、「この LB は L4 と L7 を両方サポートしますか?」という質問はもはや差別化要因ではなく、ほとんどがサポートします。差別化要因は運用の物語(製品が一つか二つか)、可観測性の物語(統合か分割か)、そしてモダナイゼーションの物語(HTTP/3、TLS 1.3、ポスト量子暗号への対応)です。TR7 はこれら三つの軸を中心に位置づけられ、L4 と L7 の能力はその入力です。
単一プラットフォームに L4 + L7
TR7 ロードバランサーは同一機器で L4 と L7 を担い、両方にハードウェアアクセラレーションを提供します。可観測性面は一つ、アップグレードパスは一つ、両モードがリスナー単位で利用可能です。
TR7 ロードバランサーを見る