ロードバランサ (L4 / L7)｜基礎を学ぶ

ロードバランサ (L4 / L7)

このレッスンで分かること

ロードバランサは複数バックエンドの前段で負荷分散・可用性向上・スケール柔軟性を提供します

L4 (TCP/UDP) はシンプル高速、L7 (HTTP) は URL/ヘッダー/Cookie で賢く振り分け

ヘルスチェックとスティッキーセッション設計が運用の肝。セッションは外部 KV に逃がすのが定石

ロードバランサとは

L4 と L7 ロードバランサの違いと使い分けを理解します。本レッスンでは、ロードバランサの基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

L4 vs L7 ロードバランサ早見表

観点	L4 (NLB 系)	L7 (ALB 系)
見るレイヤー	TCP/UDP, IP, ポート	HTTP の URL, ヘッダー, Cookie
スループット	非常に高い	高い (中身を見るので L4 より低い)
TLS 終端	透過 (バックエンドで終端)	LB で終端することが多い
パスベースルーティング	不可	可能
WAF や認証統合	不可	可能
代表サービス	AWS NLB, HAProxy TCP, LVS	AWS ALB, Nginx, Envoy, Cloudflare LB
典型用途	DB 前段、低レイテンシ要件	Web/API 前段、マイクロサービス

このレッスンで学ぶこと

複数のサーバーにトラフィックを振り分けるロードバランサ (LB) の仕組みと、L4 / L7 という重要な区別を学びます。

ロードバランサの役割

ロードバランサは、複数のバックエンドサーバーの前段に立ち、リクエストを振り分ける装置です。目的は次の 3 つです。

負荷分散 — 1 台に集中せず、複数台で処理を分け合う
可用性向上 — 1 台が落ちても、他のサーバーが受け付ける
スケール柔軟性 — サーバーを増減してもクライアント側は気にしない

クラウドでは AWS ELB (ALB/NLB)、GCP Cloud Load Balancing、Cloudflare Load Balancing などがマネージドサービスとして提供されています。

L4 ロードバランサ

L4 ロードバランサは、トランスポート層 (TCP/UDP) で動きます。

振り分けの判断 — 送信元 IP、ポート番号
中身は見ない — HTTP のリクエストパスやヘッダーは解析しない
高速 — 単純な分配なのでスループットが高い
TLS 終端しない — 暗号化されたまま透過させることが多い

代表例は AWS NLB (Network Load Balancer)、HAProxy の TCP モード、LVS など。

L7 ロードバランサ

L7 ロードバランサは、アプリケーション層 (HTTP) で動きます。

振り分けの判断 — URL パス、ホスト名、ヘッダー、Cookie
TLS 終端する — LB で復号して、バックエンドへは平文 (または再暗号化) で送る
機能豊富 — 認証、レート制限、リダイレクト、A/B テストなど
やや重い — 中身を見るぶん、L4 より処理コストが高い

代表例は AWS ALB (Application Load Balancer)、Nginx、Envoy、Traefik、Cloudflare Load Balancer など。

この章のポイント

マイクロサービスとサービスメッシュ

Envoy や Istio のようなサービスメッシュは、各マイクロサービスの脇にサイドカーとして L7 プロキシを置き、サービス間通信を細かく制御します。これも L7 ロードバランサの拡張形と捉えられます。

振り分けアルゴリズム

LB は内部でいくつかの振り分けアルゴリズムを使い分けます。

ラウンドロビン — 順番に振り分ける。最も単純。
重み付きラウンドロビン — サーバー性能に応じて重みを変える
最小接続数 — 接続数が一番少ないサーバーへ
最小応答時間 — 応答が最速のサーバーへ
IP ハッシュ — 同じ送信元 IP は常に同じサーバーへ (セッション維持)
コンシステントハッシュ — リクエストキーから一貫したサーバーを選ぶ (キャッシュ用)

セッション維持が必要なアプリは IP ハッシュ、ステートレスなアプリはラウンドロビンや最小接続が定番です。

ヘルスチェック

LB は各バックエンドサーバーに定期的にヘルスチェックを送り、応答がないサーバーを振り分け対象から外します。

TCP ヘルスチェック — ポートに接続できるかだけ確認
HTTP ヘルスチェック — 特定パス (例 /healthz) で 200 を返すか確認

アプリ側は /healthz エンドポイントを用意し、DB 接続や外部 API への到達性を含む簡易チェックを返すのが定番です。

スティッキーセッション

セッション情報を特定のサーバーのメモリに持つアプリでは、同じユーザーを必ず同じサーバーに振り分けたい場合があります。これがスティッキーセッションです。

LB は Cookie や送信元 IP で「このユーザーはこのサーバー」と固定します。ただし、スティッキーにすると LB の意味が薄れ、サーバー再起動でセッションが消える問題もあるので、可能ならセッションを外部 KV (Redis など) に置く方が良い設計です。

この章のポイント

「ステートレスアプリ + 外部セッション」が定番

現代の Web アプリは、Web サーバー自体をステートレスに保ち、セッションは Redis / DynamoDB に置きます。これによりロードバランサはスティッキーを使わずに済み、サーバーを自由に増減できます。

DSR (Direct Server Return)

L4 の高度な構成として、応答パケットを LB を経由せず直接クライアントに返す DSR があります。LB の負荷が劇的に下がりますが、設定が複雑なので大規模で慎重に使われます。

まとめ

このレッスンの要点は、L4 と L7 の使い分け / 振り分けアルゴリズム / ヘルスチェック設計 の 3 点です。実務でこれらを切り分けて説明できるようになると、設計レビューや障害対応の精度が一段上がります。

理解度チェック

Q. URL パスごとに別のマイクロサービスへ振り分けたい。選ぶべきロードバランサは？

L4 (NLB) で十分
L7 (ALB) が必要
DNS ラウンドロビンで OK
ファイアウォールで対応

答えを見る

正解は 2。パス情報は HTTP リクエストの中身なので、L7 ロードバランサが必要です。L4 は IP + ポートまでしか見えないので、URL パスでの振り分けはできません。

出典 (References)

最終更新: 2026-05-28

よくある質問

Q. このトピックは実務でどう役立ちますか？

A. DB のクエリ最適化、API 設計、データ構造の選択など、設計判断の根拠になります。表面的にライブラリを使うだけでなく「なぜそれが速いのか」を理解できると、性能問題を未然に防げます。コーディング面接でも頻出のテーマです。

Q. 計算量はどう求めれば良いですか？

A. ループのネストごとに掛け算する、再帰なら漸化式から解く、というのが基本です。Big-O 表記は定数倍と低次の項を無視するため、n の指数（n²、n log n など）に注目してください。最悪・平均・最良の 3 つを意識すると説得力が増します。

Q. 覚えるべき定番アルゴリズムは何ですか？

A. 二分探索、クイックソート/マージソート、BFS/DFS、ダイクストラ、DP の基本問題（フィボナッチ・ナップサック）が必修です。これらを「白紙から書ける」状態にすると、応用問題が一気に解けるようになります。

次のレッスン

次は プロキシとリバースプロキシ で、L4 と L7 ロードバランサの違いと使い分けを理解しますを学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

ロードバランサの要点を自分の言葉で説明できる
このレッスンの最小コード (または操作手順) を見ずに書ける
練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. ロードバランサとは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン