> [!abstract] 概要（abstract 和訳） > 本サーベイは、ウェブロードバランシング機構の最新動向を網羅し、あらゆる分類を含み、ウェブシステムの性能向上にロードバランシングソリューションを活用することの利点に焦点を当てる。ウェブロードバランシングソリューションの一般的な説明を、ロードバランシングが依拠する OSI プロトコルスタック層ごとに分類して提示する。文献中で提案されている最も重要なリクエスト分散方針も含まれる。本論文はウェブロードバランシングに関するすべての先行サーベイを要約し、最新のロードバランシング提案で技術動向を更新する。 ## 論文情報 - **タイトル**: An up-to-date survey in web load balancing - **著者**: [[Katja Gilly]]（[[Miguel Hernández University]]、スペイン・エルチェ）/ [[Carlos Juiz]]・[[Ramon Puigjaner]]（[[University of Balearic Islands]]、スペイン・パルマ） - **掲載誌**: World Wide Web (Springer) - **発行**: Vol. 14、pp. 105–131、2011（オンライン 2010-12-02） - **DOI**: 10.1007/s11280-010-0101-5 - **受理歴**: 2009-10-06 受稿 / 2010-10-21 改訂 / 2010-11-19 採択 - **助成**: スペイン教育科学省 Grant TIN2006-02265 - **キーワード**: internet、performance、web load balancing - **ページ数**: 27 ページ ## 概要 2010 年時点のウェブロードバランシング機構を OSI 層別に網羅したサーベイ。コンテンツ非依存（L4）とコンテンツ依存（L7）の 2 系統に分類し、アーキテクチャ（一方向 vs 双方向）とスケジューリング方針（局所性考慮 / 非局所性考慮 / QoS 考慮）を組み合わせて体系化する。先行サーベイ（Cardellini et al. 2002 ほか）を更新し、2009 年までの最新提案を含む。 ## 問題設定 - **対象**: ディスパッチャーベースのウェブクラスタ（Cluster-based Web System）。クライアントからは仮想 IP（VIP）単体として見え、内部サーバー群を透過的に束ねる。 - **前提**: DNS・CDN などの大域分散は対象外。ウェブシステム管理者が直接制御できるローカルスケールアウト構成に限定。 - **目的**: スケーラビリティ・可用性・管理性・セキュリティを同時に改善するロードバランシング機構の分類と比較。 ## 提案手法（分類フレームワーク） ### 2. ロードバランシング分類 文献上の主な分類軸: 1. **地理的スケール**: ローカルスケールアウト（本論文の対象）vs グローバルスケールアウト（CDN 等） 2. **可視 IP**: 分散ウェブシステム（サーバー IP が見える）vs クラスタベース（VIP のみ） 3. **配信決定場所**: クライアント / DNS / ネットワーク / **ウェブシステム内**（本論文の対象） 4. **実装レベル**: ハードウェア / システムソフトウェア / ミドルウェア / アプリケーション 5. **OSI 層**: L2 / L3 / L7（本論文の主軸） 6. **応答返路**: 双方向（two-way）/ 一方向（one-way） ### 4. コンテンツ非依存ロードバランシング（L4、Table 1） ロードバランサーはアプリケーション内容を見ず、TCP SYN パケット情報のみで転送先を決定する。 | 転送技術 | レイヤー | アーキテクチャ | 代表 | |---|---|---|---| | Direct Routing (DR) | L2 | 一方向 | LVS、ONE-IP、LSMAC | | NAT | L3 | 双方向 | LVS、Cisco CSS 11500、NLB（Windows Server 2003） | | IP Tunneling (IPTun) | L3 | 一方向 | LVS | **スケジューリング方針**（コンテンツ非依存）: - **Round Robin (RR)**: 均等割り当て。均質サーバー向け。 - **Weighted RR (WRR)**: サーバー容量の重み付き割り当て。異質サーバー向け。 - **Least Connection (LC)**: 接続数最少サーバーへ割り当て。動的。 - **Weighted LC (WLC)**: LC に重みを加えた版。 - **Least Loaded (LL)**: 最も空き容量が大きいサーバーへ。エージェントが負荷を報告。 - **Random**: 一様ランダム割り当て。 **主な制限**: NAT はすべてのパケットをロードバランサーが中継するため、高負荷でボトルネックになる（IP チェックサム再計算オーバーヘッド）。 ### 5. コンテンツ依存ロードバランシングアーキテクチャ（L7、Table 2） ロードバランサーが HTTP リクエストを解析してサーバーを選択する。 #### 双方向アーキテクチャ | 機構 | 概要 | |---|---| | **TCP Connection Binding**（Yang & Luo）| ロードバランサーがクライアント側・サーバー側の 2 つの TCP 接続を維持し、事前確立サーバー接続を再利用。HTTP/1.1 リクエスト粒度を実現できる。商用例: IBM Network Dispatcher（現在は廃止）。 | | **TCP Splicing**（Maltz & Bhagwat）| 類似した仕組みで、2 接続を OS の IP レイヤーで Splice し、アプリケーション層解析後の転送コストを削減。商用例: Cisco CSS 11500、F5 BIG-IP、Foundry ServerIron ほか。 | | **Redirect Flows**（Colby et al.）| TCP Splicing の NAT ベース版。Arrowpoint Communications（後に Cisco が買収）の独自機構。 | #### 一方向アーキテクチャ 双方向の主な欠点（応答がロードバランサーを経由することによるボトルネック）を解消するため、サーバーからクライアントへの応答パスを直接化する。 | 機構 | 概要 | |---|---| | **TCP Hand-off**（Hunt et al.）| ロードバランサーとクライアント間の TCP 接続エンドポイントを選択サーバーへ移管。最も普及した一方向方式。Linux TCPHA として実装あり。ただし、Aron et al. によればクラスタ規模 4 サーバー超で限界がある。 | | **One-packet TCP State Migration to Packet Filter**（Lin et al.）| 各サーバーに Packet Filter プロセスを置き、カーネル非改変でコンテンツ判定後に適切なサーバーへリダイレクト。LVS ベース実装。 | | **TCP Connection Hop** | Resonate Central Dispatch の独自機構。TCP 接続移行プロトコル（TCP state migration）ベース。 | | **Socket Cloning**（Sit et al.）| L4 フロントエンドが SYN を受けてサーバーを割り当て、ミスマッチ時にソケットをクローンして別サーバーへ移管。HTTP/1.1 対応。Linux カーネル改変が必要。 | | **One-way TCP Splicing**（Marwah et al.）| 通常の TCP Splicing を一方向化し、サーバー側で Splice を分割してクライアントへ直接応答。HTTP/1.1 リクエスト粒度対応。 | | **One-way Connection Binding**（Luo et al.）| TCP Connection Binding のサーバー側接続を長期保持し、接続移行コストを回避。TCP Hand-off より低オーバーヘッド。 | | **TCP Rebuilding**（Liu et al.）| LVS-CAD プラットフォーム上で実装。サーバーがシーケンス番号・ACK 番号を推定して TCP 接続を再構築し、追加パケット交換なしで接続を確立。 | **共通トレンド**: HTTP/1.1 持続接続のリクエスト粒度問題に個別対応が必要。また、L7 フロントエンドのボトルネックを避けるため、多くの提案が **L4 フロントエンド + 別ノードでのコンテンツ依存配信** という二段階方式へ移行。 ### 6. コンテンツ依存リクエスト分散方針（Table 3） 26 の方針を 3 種類に分類（Table 3 より抜粋）: **局所性考慮（Locality-aware）方針**（1998–2009 年中心）: - **LARD**（Pai et al. 1998）: 静的ページごとにサービングノードセットを定義し最小負荷ノードへ送信。TCP Hand-off 使用。 - **WARD**（Cherkasova & Karlsson 2001）: 高頻度ファイルをコア（全ノードで共有）と低頻度ファイルの分割で管理。Multiple TCP Hand-off 使用。 - **PRESS**（Carrera & Bianchini 2001）: キャッシュミス率が閾値を超えるまでコンテンツ非依存方針を維持、超えたら局所性考慮へ切り替えるハイブリッド。 - **CAWLL / xLARD/R / CAHRD**（Liu et al. 2007、LVS-CAD）: 動的コンテンツ比率 30% 超では CAWLL（最小負荷）が局所性方針より優位。 - **CWARD/CR / CWARD/FR**（Chiang et al. 2008）: CWARD/FR（アクセス頻度比例複製）が CWARD/CR（コア固定複製）より優位。 **非局所性考慮（Non locality-aware）方針**（2001 年以降中心）: - **CAP**（Casalicchio & Colajanni 2001）: リクエストをサーバー資源消費量別に分類して振り分け。サーバー状態は非考慮。 - **FARD**（Borzemski & Zatwarnicki 2003）: ファジー推定でサーバーごとのレスポンス時間を予測し最短予測サーバーへ。LARD / WRR より異質環境で優位。 - **MAA**（Yao et al. 2008）: Cisco AON 製品向け。メッセージ種別と資源消費に基づき最早完了時刻を推定。 **QoS 考慮方針**: - **E-FSPF**（Shan et al. 2002）: SHLPN モデリングを使いプロセス優先度を考慮したフロントエンド + サーバー連携スケジューリング。 - **Gage**（Li et al. 2003）: SLA を資源消費量でモデル化し WRR で割り当て。 - **IQRD**（Shafirian et al. 2008）: 動的残余容量推定 + 入場制御付き。CAP / WRR より応答時間・スループットで優位（オーバーヘッドは増）。 ## 新規性 - 2010 年時点の最新提案（2007–2009 年の手法）を既存サーベイ（Cardellini et al. 2002 ACM Comput. Surv. が標準参照）に追加。 - OSI 層（L2/L3/L7）と応答返路（一方向/双方向）の 2 軸を組み合わせた統一分類を提示。 - コンテンツ依存アーキテクチャと分散方針を別章（§5 / §6）で独立整理し、アーキテクチャ選択と方針選択の分離を明確化。 ## 実験設定 本論文はサーベイであり、著者ら独自の実験は含まない。各提案の実験結果は原著論文から引用・整理。 ## 実験結果 各方針の相対性能比較（原著実験からの引用まとめ）: - CWARD/FR > CWARD/CR（Chiang et al. 2008） - TCP Hand-off は 4 サーバー超でスケーラビリティが頭打ち（Aron et al. 2000） - FARD は LARD・WRR より異質環境で優位（Borzemski & Zatwarnicki 2003） - IQRD は CAP・WRR よりスループット・レイテンシで優位（Shafirian et al. 2008） ## 考察 ### 結論（§7） - コンテンツ非依存: **DR（一方向 L2）と NAT（双方向 L3）** が最重要の 2 手法。 - コンテンツ依存: L7 スイッチのボトルネック問題 → **L4 フロントエンド + 他ノードへの配信委譲** パターンが有力解。TCP Hand-off が最も普及した一方向方式。 - HTTP/1.1 持続接続の **リクエスト粒度** 問題は各機構が個別対応。 - 局所性方針は静的コンテンツで効果大、動的コンテンツへの拡張は未解決課題。 - 非局所性: サーバー監視情報の陳腐化（staleness）が問題（Dahlin 2000 も指摘）。 - QoS + 入場制御の研究はまだ少なく、提案は 2 件（IQRD・APRA）のみ。 ### オープン課題 1. 動的コンテンツのサービス時間の測定・予測困難性 2. 監視情報の陳腐化への対処 3. QoS + 入場制御の組み合わせ提案の拡充 4. 仮想サーバー（サーバー仮想化）を活用したロードバランシング改善 5. エネルギー効率の考慮（「グリーンコンピューティング」） ## 強み / 弱点・課題 **強み**: - OSI 層別の包括的分類で 2010 年時点の技術全体を俯瞰できる。 - Table 1〜3 の比較表が各提案の特性を整理し参照性が高い。 - 先行サーベイ（Cardellini et al. 2002）との差分が明確。 **弱点・限界**: - クラウドコンピューティング（仮想化・IaaS）への対応は将来課題として言及のみ。論文がクラウド登場期（2010 年）に書かれており、Kubernetes 等の登場以前。 - 著者らが指摘するとおり、量的な比較実験（独自ベンチマーク）は含まない。 - 動的コンテンツ（CGI・データベース処理）の予測困難性への解答は提示されていない。