アクセスが増えたらサーバを増やして分散する——その要となるのがロードバランサ（LB）です。L4とL7の違いを中心に解説します。
ロードバランサの役割
複数のサーバへリクエストを振り分け、負荷を分散します。1台に集中させず、全体で捌く。さらに、落ちたサーバを自動で振り分け対象から外す（ヘルスチェック）ことで、可用性も上げます。
L4ロードバランサ（トランスポート層）
IPアドレスとポート番号を見て振り分けます。中身（HTTPの内容など）は見ません。
- 速い・軽い（ヘッダだけ見る）
- プロトコル非依存（HTTP以外もいける）
- 中身で振り分けられない
「とにかく速く、TCP/UDPレベルで分ける」のがL4です。
L7ロードバランサ（アプリケーション層）
HTTPの中身まで見て振り分けます。
- URLパスで振り分け（
/apiはAPIサーバ、/imgは画像サーバ） - Cookieでセッションを固定（同じ人を同じサーバへ）
- SSL終端（LBでHTTPSを解いて、内部はHTTP）
賢く振り分けられる代わりに、中身を解釈する分だけ処理は重くなります。
振り分けアルゴリズム
- ラウンドロビン: 順番に均等配分（基本）
- 最小コネクション: 今つながっている数が少ないサーバへ
- 重み付け: 性能の高いサーバへ多めに
ヘルスチェックが命
LBは各サーバへ定期的に「生きてる？」と確認し、応答がなければ振り分け対象から外します。この設定が甘いと、落ちたサーバへ振り続けてエラーになります。「TCPが開くか」だけでなく、「特定URLが200を返すか」まで見ると、より確実です。
セッション維持（スティッキー）
ショッピングカートのように、同じ利用者を同じサーバに固定したい場合、Cookieや送信元IPで固定します（セッションアフィニティ）。ただし固定しすぎると分散が偏るので、セッション情報を外部（Redis等）に持たせて、そもそも固定不要にする設計も有力です。
まとめ
- L4 … IP/ポートで速く分ける
- L7 … 中身を見て賢く分ける（URL・Cookie・SSL終端）
要件次第で使い分け、あるいは併用します。ヘルスチェックとセッション維持まで含めて設計できると、可用性の高いWeb基盤が組めます。