変更要約: 初版
3.4負荷分散とコンテンツ配信
L4/L7ロードバランサの違いとラウンドロビン/最小コネクション/重み付けなどの負荷分散方式、ヘルスチェックによる障害サーバの自動切り離し、セッション維持（スティッキーセッション）、リバースプロキシとCDNによるコンテンツ配信の最適化、NTPによる時刻同期を、要件に応じたL4/L7選択の判断とともに学びます。
負荷分散は「複数のサーバに処理を分散して1台あたりの負荷を下げ、可用性を高める」ための基盤技術ですが、実務では「どの層（L4かL7か）で分散すべきか」「どの分散方式が要件に合うか」という設計判断が問われます。この節ではロードバランサの仕組みと、CDN・リバースプロキシによるコンテンツ配信の最適化まで、判断に必要な知識を体系的に扱います。
3.4.1L4ロードバランサとL7ロードバランサ
- L4ロードバランサ＝トランスポート層（TCP/UDPのIPアドレス・ポート番号）の情報だけを見て振り分ける方式。パケットの中身（アプリケーションデータ）を解析しないため処理が高速で低遅延、大量のコネクションを高いスループットでさばくのに向く。
- L7ロードバランサ＝アプリケーション層（HTTPヘッダ・URL・cookie等）の内容まで解析して振り分ける方式。URLパスによる振り分け（/api は API サーバ群へ、/static は静的コンテンツサーバへ等）やcookieを見たセッション維持など、内容に応じた高度な制御ができる一方、解析の分だけL4より処理負荷が高く遅延が増える。
3.4.2負荷分散方式とヘルスチェック
- ラウンドロビン＝リクエストを順番に各サーバへ均等に割り振る最も単純な方式。サーバ性能が均一な場合に有効だが、処理時間の長いリクエストが偏ると特定サーバに負荷が滞留しやすい。
- 最小コネクション＝その時点で処理中のコネクション数が最も少ないサーバへ優先的に割り振る方式。リクエストごとの処理時間にばらつきがある場合、ラウンドロビンより実際の負荷に即した分散ができる。
- 重み付け（ウェイテッド）＝サーバの処理能力（スペック差）に応じて重みを設定し、能力の高いサーバに多くのリクエストを振り分ける方式。ラウンドロビンや最小コネクションと組み合わせて使う（重み付けラウンドロビン等）。
- ヘルスチェック＝ロードバランサが定期的に各サーバへ疎通確認（ping、TCP接続確認、HTTP応答確認等）を行い、応答がないサーバを振り分け対象から自動的に除外する機能。障害サーバへのリクエスト集中を防ぎ可用性を保つ。
3.4.3セッション維持・リバースプロキシ・CDN・NTP
- セッション維持（スティッキーセッション）＝同じクライアントからのリクエストを常に同じサーバへ振り分ける機能。サーバ側でセッション情報をローカルに保持する構成（ログインカートの状態等）で必要になるが、特定サーバへの負荷偏在を招きやすいトレードオフがある。
- リバースプロキシ＝クライアントからのリクエストを受け、内部の複数サーバへ中継する装置。CDN（Content Delivery Network）＝静的コンテンツ（画像・動画・JS/CSS等）を利用者に地理的に近いエッジサーバにキャッシュし、オリジンサーバの負荷とレイテンシを削減する仕組み。
- NTP（Network Time Protocol）＝ネットワーク機器・サーバの時刻をNTPサーバと同期するプロトコル。ログの時系列突合、証明書の有効期限判定、分散システムでの整合性確保などに時刻同期は不可欠。
「L4=トランスポート層のみ見る高速方式」「L7=アプリケーション層まで見る高度だが低速な方式」「ヘルスチェック=障害サーバの自動切り離し」「セッション維持=同一サーバ固定だが負荷偏在のトレードオフ」が最頻出です。URLパス振り分けやcookie参照はL7でのみ可能な点を押さえましょう。
あるECサイトの基盤担当者が、現在の構成（L4ロードバランサでラウンドロビン分散）を見直すよう依頼を受けたとします。要件は「/api配下のAPIリクエストは高性能なAPIサーバ群へ、/imagesなどの静的コンテンツは別の軽量サーバ群へ振り分けたい」というものです。URLパスに基づく振り分けはHTTPヘッダの内容を解析する必要があるため、L4では実現できず、L7ロードバランサへの切り替えが必須と判断できます。次に、ログイン中のユーザーのカート情報をアプリケーションサーバのメモリ上に保持する設計になっている場合、リクエストのたびに異なるサーバへ振り分けられるとカート情報が見つからずエラーになるため、セッション維持（スティッキーセッション）をL7ロードバランサのcookie参照機能で実現する必要があります。ただし、特定のヘビーユーザーのセッションが1台のサーバに固定され続けると負荷が偏るため、将来的にはセッション情報を外部のRedis等の共有ストアに移し、どのサーバに振り分けられても状態を参照できる「ステートレス化」を検討するのがより望ましい設計です。さらに、画像や動画などの静的コンテンツについては、オリジンサーバへの都度アクセスを避けるためCDNを導入して地理的に近いエッジサーバにキャッシュさせ、オリジンの負荷とユーザー体感速度の両方を改善します。最後に、複数サーバのログを時系列で正確に突合してこの負荷分散の効果を分析するには、全サーバの時刻をNTPで同期しておくことが前提になります。このように、負荷分散の設計は「振り分け基準に何を使うか（L4かL7か）」から始まり、セッション管理・コンテンツ配信・時刻同期まで一貫した判断が求められます。
| 観点 | L4ロードバランサ | L7ロードバランサ |
|---|---|---|
| 参照する情報 | IPアドレス・ポート番号 | HTTPヘッダ・URL・cookie等 |
| 処理速度 | 高速・低遅延 | L4より低速・高負荷 |
| URLパス振り分け | 不可 | 可能 |
| cookieベースのセッション維持 | 不可 | 可能 |
ひっかけ： 「L4ロードバランサでもURLパスに応じた振り分けができる」は誤りです——URLパスの解析にはHTTPヘッダを見る必要がありL7でのみ可能です。また「セッション維持を使えば負荷分散の効果は損なわれない」も誤り＝スティッキーセッションは特定サーバへの負荷偏在を招くトレードオフがあり、根本対策にはセッション情報の外部ストア化（ステートレス化）が有効です。
3.4.4この節のまとめ
- L4はトランスポート層のみで高速、L7はアプリケーション層まで見て高度な振り分け（URLパス・cookie）が可能だが低速
- ヘルスチェックで障害サーバを自動除外、セッション維持は負荷偏在とのトレードオフ
- CDNで静的コンテンツをエッジにキャッシュ、複数サーバの時刻はNTPで同期しログ突合を可能にする
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. ECサイトで「/api配下はAPIサーバ群、/imagesは静的コンテンツサーバ群」というURLパスに応じた振り分けを実現したい。現行のL4ロードバランサに対してどのような判断が必要か。
Q2. アプリケーションサーバのメモリ上にログインユーザーのカート情報を保持する設計で、L7ロードバランサのcookie参照によるセッション維持を導入した。この設計が抱えるトレードオフとして最も適切なものはどれか。
Q3. 複数のWebサーバのログをミリ秒単位で時系列突合し、障害発生時刻を正確に特定したい。この前提として全サーバに整備しておくべき仕組みはどれか。