このドキュメントは疑問に思っていた点をAIエージェントとの対話を通じて整理したメモです。L4とL7ロードバランシングの違い、TLS終端とルーティング基準、LogstashとElasticsearchの手前での選択ポイントを整理します。

L4 vs L7ロードバランシング完全まとめ

#

1. L4 vs L7ロードバランシングの基本概念

#

L4ロードバランシング（Transport Layer）

#

L4ロードバランシングはTCP/UDPのようなトランスポート層の基準で接続を分散する。代表的にIP、Port、プロトコル、接続単位の情報をもとに対象サーバーを選ぶ。

メリット

• アプリケーションのリクエスト内容を直接解析しないため、処理経路がシンプルだ
• TCP/UDPベースの様々なトラフィックに適用しやすい
• シンプルな分散、静的IP、大量の接続処理といった要件に向いている

デメリット

• URL、ヘッダー、クッキー、gRPCメソッドのようなアプリケーション情報ベースのルーティングはできない
• 細かいリクエスト単位のポリシーはL7より制限的だ

参考：TLS終端はL7で一般的だが、AWS NLBのようなL4系でもTLS listenerとしてサポートする製品がある。そのため「L4なら必ずTLS終端不可」と断定するのは誤りになる場合がある。

L7ロードバランシング（Application Layer）

#

L7ロードバランシングはアプリケーション層のリクエストを解析して分散する。Webトラフィック基準ではURL、ヘッダー、クッキー、メソッド、クエリ文字列などを基準にルーティングできる。

メリット

• URLパス、ホスト、ヘッダー、クエリ文字列ベースのルーティングが可能
• クッキーベースのsticky sessionを実装可能
• TLS終端とHTTP/gRPCレベルのポリシー適用がしやすい
• カナリアデプロイ、A/Bテスト、認証、リダイレクトのような高度な制御に有利だ

デメリット

• リクエストを解析する必要があるため、L4よりも一般的に処理経路が複雑だ
• 製品が理解するアプリケーションプロトコルに依存する
• 機能が増えるほど設定と障害ポイントが増える

参考：多くのL7製品はHTTP/HTTPS中心だが、製品によってはHTTP/2、gRPC、WebSocketもサポートする。そのため「L7 = 通常のHTTPのみ」と見るのも過度な単純化だ。

一目で比較

#

2. いつL4を、いつL7を使うべきか？

#

核心原則

#

L4は接続をどこに送るかを決めることに強く、L7はリクエストの内容を見てどのように分けるかを決めることに強い。

L7も複数のサーバーにトラフィックを分散できる。違いはリクエストの内容を読む機能が実際に必要かどうかにある。

シンプルな分散 → L4が自然な理由

#

状況：同じSpringサーバー3台にトラフィックを分散

#

クライアント → [ロードバランサー] → Server A
                                  → Server B
                                  → Server C

3台のサーバーが全く同じ役割をしており、リクエストごとに別のポリシーが不要なら、URLやヘッダーを読む必要はない。

• L4：接続単位で分散 → 通常よりシンプルで軽い
• L7：HTTPリクエストを解析してから分散 → 機能は多いが必要ない場合も多い

つまりこの場合は**「L7ができないから」ではなく「L4で十分だから」**L4がより自然な選択になる。

MSA環境 → L7が必要な理由

#

状況：ショッピングモールのMSA

#

/api/users     → User Service（ポート8081）
/api/orders    → Order Service（ポート8082）
/api/products  → Product Service（ポート8083）

1つの進入点からパスごとに異なるサービスへ送るためにはリクエストの内容を読む必要がある。

クライアントがGET /api/ordersをリクエスト

L4：接続情報だけ見るのでURLパス自体は判断基準にならない ❌
L7：/api/ordersパスを読んでOrder Serviceへルーティング ✅

この構造ではL7プロキシ、API Gateway、Ingress Controllerのようなリクエスト認識型（L7）の構成が必要だ。

カナリアデプロイも区別して見る必要がある

#

/api/ordersのリクエストのうち
  → 特定のヘッダーがあればv2へ
  → それ以外はv1へ

このようにヘッダー、クッキー、パス、メソッドを基準にトラフィックを分けるカナリア/A-Bルーティングにはl7が必要だ。

一方でシンプルな重み付けベースの分散は一部のL4製品もサポートする。例えばAWS Network Load Balancerは複数のtarget groupにweightを設定できる。
正確に言えば**「精密なリクエストベースのカナリア」はL7の領域であり、「シンプルな比率分割」は製品によってL4でも可能な場合がある。**

まとめ

#

3. ELKスタックでなぜL4ロードバランシングを使うのか？

#

ELKのデータフロー

#

アプリケーションサーバー群
    ↓ （ログ転送）
[Logstashクラスター - 3台]  ← ここの手前にLBを置ける
    ↓
Elasticsearch
    ↓
Kibana

Logstashの手前にロードバランサーを置く理由は、入力トラフィックを複数のLogstashインスタンスに分散するためだ。

核心は「Logstashの入力プロトコル」だ

#

Logstash自体はHTTP専用の製品ではない。どのinput pluginを使うかによって、手前で扱うプロトコルが変わる。

• Beats input：LogstashがBeats frameworkの接続を受ける
• FilebeatのLogstash output：lumberjack protocolを使いTCPの上で動作する
• UDP input：UDPでイベントを受け取る
• HTTP input：HTTP(S)リクエストをイベントとして受け取る

つまり**「Logstashの手前は必ずL4」でも「必ずL7」**でもない。
実際に使う入力がBeats/TCP/UDP系であればL4が自然で、HTTP inputを使えばL7も可能だ。

なぜL4がよく合うのか？

#

ログ収集経路では以下の条件が多いからだ。

• 入力がBeats、TCP、UDP、syslogのようにHTTPではない場合が多い
• 複数のLogstashインスタンスが同じ役割をするため、パスベースのルーティングが不要な場合が多い
• シンプルな分散が目的なら、リクエスト内容をわざわざ解析する必要が少ない

Filebeat → LB → Logstash A
              → Logstash B
              → Logstash C

この構造では**「どのLogstashがこのログを処理してもよいか？」が核心であり、ほとんどの場合そうだ。
そのためHTTPの機能よりTCP/UDPレベルの分散**の方が重要な場合が多い。

L7にしてはいけないのか？

#

いけないわけではない。 Logstashにはhttp input pluginがあるため、HTTPでイベントを受ける構成であればL7も使える。

ただしこの場合も確認すべき質問はシンプルだ。

• 入力は本当にHTTPか？
• URL/ヘッダーベースのルーティングが必要か？
• 複数のLogstashインスタンスが同じ役割なら、L7の機能が実質的に必要か？

結論：Logstashの手前の選択は「ELKだから」ではなく「入力プロトコルとルーティングの要件が何か」で決めるのが正しい。

4. Elasticsearchのシャード構成とロードバランシング

#

重要な概念の区分

#

シャードのルーティングと外部のロードバランサーは別のレイヤーの話だ。

外部のロードバランサーがシャードを直接分散させるわけではない。
Elasticsearchクラスターは各ノードがクラスターの状態を共有し、適切なノードにリクエストを転送できる。

ESの内部シャードルーティングのメカニズム

#

クライアント
    ↓ HTTPリクエスト
[Node 1] ← coordinatingの役割
    ↓
  ┌─────────────────┐
  ↓                 ↓
[Node 2]          [Node 3]
Shard 0, 1        Shard 2, 3

クライアントのリクエストを受けたノードはクラスターの状態をもとに、適切なシャードがあるノードにリクエストを転送し、レスポンスをまとめて返すことができる。
Elasticのドキュメントでもcoordinating-only nodeをスマートなロードバランサーのように動作すると説明している。

つまり、外部LBが行うことは通常**「最初の進入ノードを選ぶこと」であり、「シャードを直接分けること」**ではない。

ではESの手前に置くロードバランサーは何をするのか？

#

ノードレベルの分散だ。

クライアント群
    ↓
[外部LB] → Node 1
          → Node 2
          → Node 3
              ↓
        （以降のシャード単位の調整はES内部で処理）

どのノードに最初に入っても、その後のシャード単位の分散とreduceはElasticsearchクラスターが処理する。

ESの手前でなぜL4がよく言及されるのか？

#

理由1：外部LBと内部transportポートは区別する必要がある

#

Elasticsearchは HTTPインターフェースとtransportインターフェースを別々に持つ。

9200台 → HTTP client communication
9300台 → node-to-node transport TCP

ここで重要な点は、9300台のtransportポートが存在するからといって、外部クライアント用LBが必ず9300も扱わなければならないわけではないということだ。
通常クライアントの進入点はHTTP（9200台）であり、9300台はクラスター内部の通信用と見る。

つまり**「9300があるから外部ESの手前は必ずL4」**と言うのは過剰だ。

理由2：URLベースのルーティングが通常必要ない

#

GET /my-index/_search
POST /my-index/_doc

Elasticsearch APIはパスが異なっても、一般的な複数ノードクラスターの手前では特定のURLを特定のノードに送らなければならない場合が多くない。

つまり外部LBの観点では通常：

• どのhealthyなノードに最初に送るかだけを決めればよく
• 以降のシャードの配置と内部転送はElasticsearchが処理する

このためリクエスト内容を読むL7の機能が必ずしも必要でない場合が多い。

理由3：シンプルなノード分散だけを望むならL4で十分だ

#

外部で必要なものが：

• 静的な進入点
• 複数のESノードへの基本的な分散
• TCP/TLSレベルのシンプルな転送

程度であれば、L4が自然な選択になる。

ESでL7を使ってはいけないのか？

#

可能だ。 9200台のHTTP APIの手前にはL7を置けるし、実際にAWS ALBのようなHTTP/HTTPSベースのL7ロードバランサーで構成することもできる。

ただしこの場合も質問は同じだ。

• path/headerベースのポリシーが必要か？
• 認証/リダイレクト/WAFのようなHTTP機能が必要か？
• シンプルなノード分散以上の要件があるか？

なければL4で十分かもしれず、あればL7が意味を持つ。

5. 最終まとめ

#

選択基準の一文まとめ

#

L7の方がより多くのリクエスト情報を理解するが、その情報が必要でなければL4がより単純な選択になる。

全ケースのまとめ

#

参考資料

#

• AWS - Application Load Balancer
• AWS Docs - Listeners for your Application Load Balancers
• AWS Docs - Condition types for listener rules
• AWS Docs - Action types for listener rules
• AWS Docs - Target groups for your Application Load Balancers
• AWS Docs - What is a Network Load Balancer?
• AWS Docs - Listeners for your Network Load Balancers
• AWS Docs - Health checks for Network Load Balancer target groups
• AWS Docs - Target groups for your Network Load Balancers
• Elastic Docs - Beats input plugin
• Elastic Docs - Udp input plugin
• Elastic Docs - Http input plugin
• Elastic Docs - Configure the Logstash output (Filebeat)
• Elastic Docs - Networking settings
• Elastic Docs - Node roles
• Elastic Docs - Search shard routing
• NGINX Docs - HTTP Load Balancing
• NGINX Docs - TCP and UDP Load Balancing