# Webロードバランシング ## 定義 ウェブロードバランシング（web load balancing）とは、ウェブリクエストを複数のサーバーに分散する機構の総称である。スケーラビリティ（負荷の増加への対応）・可用性（障害時の継続稼働）・管理性（サーバー間移行の容易化）・セキュリティ（DoS 攻撃の吸収）の 4 つを実現する手段として位置づけられる。対象は主に **ディスパッチャーベースのクラスタ（Cluster-based Web System）** ——仮想 IP（VIP）を持つフロントエンドが全リクエストを受けてバックエンドサーバー群に振り分ける構成——であり、DNS・CDN 等のグローバルスケールアウトは別領域で扱われる。（出典: [[@2011__World Wide Web__An up-to-date survey in web load balancing]]） 主な分類軸は OSI 層と応答返路の 2 つ。 | 分類軸 | 選択肢 | |---|---| | OSI 層 | L2（MAC 書き換え）/ L3（IP 書き換え・トンネリング）/ L7（アプリケーション解析） | | 応答返路 | 双方向（ロードバランサー経由）/ 一方向（サーバーからクライアントへ直送） | | コンテンツ把握 | コンテンツ非依存（content-blind、L4 以下）/ コンテンツ依存（content-aware、L7） | ## 横断的知見 - **「コンテンツ依存(content-aware) L7 ロードバランシング」は、2011 年時点ではディスパッチャーが持つ静的な振り分けアルゴリズムとして構想されていたが、2021 年の実務報告ではロードバランサー自体にスクリプト言語で任意ロジックを実装する形へ発展している**: [[@2011__World Wide Web__An up-to-date survey in web load balancing]] の分類軸(content-aware = L7 でリクエストの内容を解析して振り分け)は「あらかじめ定義されたアルゴリズム(URL 単位・セッション単位等)の選択」を前提にしていた。一方 [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] が報告する[[スクリプタブルロードバランサー]]は、ヘッダ・URI・クライアント IP など任意の属性の組み合わせから振り分け先を導出するロジックを Lua 等の高水準言語で自由に記述できる点で、content-aware の分類を「固定アルゴリズムの選択」から「プログラム可能な振る舞い」へ質的に転換した。両ソースの10年の隔たりは、L7 ロードバランシングの実装がアルゴリズムのカタログから汎用スクリプティング環境へ移行した過程を示す。(Source: [[@2011__World Wide Web__An up-to-date survey in web load balancing]], [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] ch.25 §25.1) - **アプリケーション認識型ロードバランシングの実装コストという課題を、2021年報告は「宣言型設定 vs C言語カスタムビルド」という二極対立として明示的に定式化し、その中間解を提示する**: 2011年のサーベイは content-aware ロードバランシングを技術分類として整理するにとどまり、実装難易度の議論は薄い。[[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]]は、従来ロードバランサーの宣言型設定言語(アプリケーションロジックの表現もテストも困難)と、Facebook の Proxygen のようなカスタムビルド(C言語、メモリ安全性なし)という両極端を明示し、Lua 等のサンドボックス化されたスクリプト言語がその中間解であると論じる。これは 2011 年のサーベイが実装面で言語化しなかった「content-aware をどう実装するか」というコスト構造を10年後に補完する。(Source: [[@2011__World Wide Web__An up-to-date survey in web load balancing]], [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] ch.25 §25.1.1) - **2011年サーベイのOSI層分類(L2 vs L3、双方向 vs 一方向)は抽象的な分類にとどまるが、SRE Book第19章はGoogle実運用における各層の選択が「スケールするか」という単一基準で時系列的に切り替わったことを具体化する**: 2011年サーベイの表は「OSI層(L2=MACアドレス書き換え / L3=IPアドレス書き換え・トンネリング)」と「応答返路(双方向 / 一方向)」を独立した分類軸として並列に提示するのみだった。SRE Book第19章は、L2のMACアドレス書き換えを Direct Server Response(DSR)として具体化する——応答返路を一方向(バックエンドから直接クライアントへ)にすることでロードバランサの通信量を大幅に削減する一方、ロードバランサとバックエンド全台が単一のブロードキャストドメインに存在する必要があるためGoogleの規模では放棄されたと報告する。代わりに採用されたL3のトンネリングはGREによるパケットカプセル化として実装され、ブロードキャストドメインの制約を除去して大陸をまたぐ配置を可能にする代わりに、カプセル化オーバーヘッド(IPv4+GREで24バイト)によるMTU超過・フラグメンテーションという新たなコストを生む。2011年サーベイが並列な選択肢として提示した「L2/一方向」と「L3/トンネリング」は、SRE Bookの実運用報告では「ブロードキャストドメインの制約から逃れられるか」という単一基準による時系列的な移行(L2/DSRからL3/GREカプセル化へ)であったことが明らかになる。(Source: [[@2011__World Wide Web__An up-to-date survey in web load balancing]], [[@2016__OReilly__SRE Book - Chapter 19 Load Balancing at the Frontend]]) ## 未解決の問い - GREカプセル化のMTU超過・フラグメンテーション問題は、SRE Book第19章によればデータセンター内では大きなMTUをサポートするネットワークで回避できるとされるが、データセンター間(WAN)区間での対策は章内に記載がない。2011年サーベイのL3トンネリング分類にもこの運用コストへの言及はなく、両ソースとも未解決のまま残る。 - **動的コンテンツのサービス時間予測**: CGI・データベースアクセスを含むリクエストの完了時間の見積もり困難性は 2010 年時点で未解決。現代の LLM 推論サービング（[[Towards Efficient Generative Large Language Model Serving]]）での推論時間不均一性と同型の問題か？ - **負荷情報の陳腐化（staleness）**: 分散サーバーからの監視データが意思決定時に古い場合の対処（Dahlin 2000 が指摘）。現代のリアルタイムオブザーバビリティ（[[オブザーバビリティ]]・[[テレメトリ]]）でどこまで解決されたか？ - **HTTP/2・HTTP/3 への拡張**: HTTP/1.1 の持続接続問題（リクエスト粒度）は本論文で議論されるが、マルチプレクシングが標準化された HTTP/2・QUIC（HTTP/3）環境での同等問題は？ - **クラウド/マイクロサービス時代のロードバランシング**: Kubernetes の Service/Ingress・サービスメッシュ（Istio 等）は本論文のアーキテクチャをどう変化させたか？[[コンテナ配置最適化]]・[[マイクロサービスアーキテクチャ]] との接合点。 - **AI/LLM 推論特有の負荷不均一**: LLM 推論は出力トークン数が可変で入力長依存コストも大きく、従来のリクエスト均等分散では性能が出にくい。エネルギー効率も未解決課題（本論文§7）として残る。 - **スクリプタブルロードバランサーの状態管理は「負荷情報の陳腐化」問題をどう再構成するか**: [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]]が示す「共有データストア(正確だが単一障害点) vs ロードバランサーごとのローカル状態(弾力性優先だが不正確)」というトレードオフは、2011年サーベイが指摘した負荷情報の陳腐化問題の解法選択肢を具体化したものと言えるか。両者を接続する定量評価は未見。 ## 関連 - [[@2011__World Wide Web__An up-to-date survey in web load balancing]] — 本概念の主要一次ソース - [[コンテナ配置最適化]] — コンテナ間トラフィック観測に基づく配置最適化。ロードバランシングの後継問題としての位置づけ - [[マイクロサービスアーキテクチャ]] — マイクロサービスにおけるサービス間負荷分散はウェブロードバランシングの進化形 - [[オブザーバビリティ]] — サーバー状態の監視情報取得はロードバランシングの動的方針に必須 - [[テレメトリ]] — サーバー負荷情報の陳腐化問題はリアルタイムテレメトリの課題と直結 - [[スクリプタブルロードバランサー]] — content-aware L7 ロードバランシングを「固定アルゴリズム選択」から「プログラム可能な振る舞い」へ発展させた実装形態 - [[@2016__OReilly__SRE Book - Chapter 19 Load Balancing at the Frontend]] — L2/Direct Server ResponseからL3/GREカプセル化への移行という、Google実運用でのOSI層選択の具体例 ## 出典 - [[@2011__World Wide Web__An up-to-date survey in web load balancing]] — Gilly・Juiz・Puigjaner、World Wide Web Vol.14 pp.105–131、2011、DOI:10.1007/s11280-010-0101-5 - [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] — Emil Stolarsky、L7スクリプタブルロードバランサーの実務報告(ch.25 §25.1) - [[@2016__OReilly__SRE Book - Chapter 19 Load Balancing at the Frontend]] — Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), *Site Reliability Engineering: How Google Runs Production Systems*, O'Reilly, 2016, Chapter 19 (Written by Piotr Lewandowski)