はじめに
ロードバランシングは現代のアプリケーションデリバリーの背骨です。数千 ― あるいは数百万 ― のユーザーが同時にアプリケーションにアクセスする時、単一のサーバーでは負荷を処理できません。ロードバランサーは受信トラフィックを複数のバックエンドサーバーに分散し、高可用性、最適な性能、フォールトトレランスを確保します。
しかし、ロードバランサーはどのサーバーが各リクエストを処理すべきかをどのように決定するのでしょうか？答えはロードバランシングアルゴリズムにあります。適切なアルゴリズムを選択することは、応答性の高いアプリケーションと、タイムアウトや不均一なサーバー負荷に悩まされるアプリケーションの違いを意味し得ます。
本ガイドは、ロードバランシングアルゴリズムを2つのカテゴリで探ります：サーバー間でトラフィックがどう広がるかを決定する分散アルゴリズム、そしてステートフルなアプリケーションのためにセッション継続性を確保する持続性手法です。
なぜアルゴリズムの選択が重要か
適切なロードバランシングアルゴリズムは、アプリケーションの性能、ユーザー体験、インフラの効率に直接影響します：
アルゴリズムのカテゴリ
ロードバランシングアルゴリズムは2つの主要カテゴリに分かれ、それぞれが異なるアーキテクチャ上のニーズに応えます：
分散アルゴリズム
トラフィックがサーバー間でどう広がるかを決定する ― 順次、ランダム、または接続数や応答時間などのリアルタイムサーバーメトリクスに基づく。
持続性手法
同じクライアント、URI、またはユーザーIDからのリクエストを一貫して同じサーバーへルーティングすることでセッション継続性を確保。
性能ベース
サーバー健全性メトリクス ― 応答時間、キュー深度、接続エラー ― を最適なルーティング決定のために考慮する高度なアルゴリズム。
ハイブリッドアプローチ
分散と持続性を組み合わせる、または洗練されたロードバランシングシナリオのために複数基準選択（Fastest+のような）を使用。
分散アルゴリズム
分散アルゴリズムは、サーバープール全体にトラフィックを広げることに焦点を当てます。選択はサーバーインフラ、リクエストの特性、性能要件に依存します。
Round Robin
Round Robinは最もシンプルで最も広く展開されているロードバランシングアルゴリズムです。名前が示唆するとおりの動作をします：リクエストはサーバーへ循環的・順次的に分散されます。最初のリクエストはサーバー1へ、2番目はサーバー2へ、というように。最後のサーバーに到達した後、サイクルは最初から始まります。
このアルゴリズムは、すべてのサーバーが同等の容量を持ち、すべてのリクエストが類似の処理能力を必要とすることを想定しています。次にどのサーバーがローテーションにあるかを知ること以外、状態追跡を要しないため、最小の計算オーバーヘッドで極めて効率的です。
Round Robinは、サーバーが同一の仕様を持ち、リクエストが比較的均一な同質環境で優れます ― 静的コンテンツ、シンプルなAPIエンドポイント、ステートレスマイクロサービスの提供などです。
Round Robin：一目で
| 観点 | 詳細 |
|---|---|
| 仕組み | 順次分散：サーバー1 → サーバー2 → サーバー3 → 繰り返し |
| 適合する用途 | 同質サーバー、均一なリクエスト負荷、ステートレスアプリケーション |
| 強み | シンプル、予測可能、計算オーバーヘッドゼロ、デバッグが容易 |
| 弱み | サーバー負荷と容量の差を無視 |
| ユースケース | 静的コンテンツ、CDNエッジノード、ステートレスAPI |
Weighted Round Robin
Weighted Round Robinは、各サーバーに容量に基づく重みを割り当てることで基本アルゴリズムを拡張します。より高い重みを持つサーバーが比例的により多くのトラフィックを受け取ります。サーバーAの重みが3、サーバーBの重みが1の場合、サーバーAはサーバーBが1つ処理するごとに3つのリクエストを処理します。
このアルゴリズムは異質サーバー環境に不可欠です。組織はしばしばハードウェアの混合 ― 強力な新サーバーと旧マシン、または異なるvCPU数を持つクラウドインスタンス ― を運用します。Weighted Round Robinは、16コアサーバーが4コアサーバーよりも多くのトラフィックを処理することを保証します。
重みは通常、CPUコア、メモリ、またはベンチマークテストに基づいて構成されます。シンプルなRound Robinより柔軟ですが、このアルゴリズムは依然としてリアルタイムのサーバー負荷を考慮しません ― 高負荷下の重み付けされたサーバーは、現在の容量ではなく重みに基づいてトラフィックを受け取り続けます。
CPUコアまたはメモリに比例する重みから始めます。例えば、サーバーAが8コア、サーバーBが4コアの場合、重み8と4（または2と1）を割り当てます。実際の性能メトリクス ― スループット、応答時間、エラー率 ― に基づいて監視・調整してください。
Least Connection
Least Connectionは動的なアプローチを取ります：各新リクエストは、その瞬間に最少のアクティブ接続を持つサーバーへ行きます。Round Robinと異なり、このアルゴリズムはリアルタイムの条件に適応します ― 1台のサーバーが多くの遅いリクエストを処理している場合、新リクエストはより負荷の少ないサーバーへルーティングされます。
このアルゴリズムは特に長いセッション時間を扱うサーバーに推奨されます。データベース接続（SQL）、ディレクトリサービス（LDAP）、永続接続を持つアプリケーションは、Least Connection分散から大きく恩恵を受けます。
ロードバランサーは各バックエンドサーバーへのアクティブ接続を追跡します。新リクエストが到着すると、この接続テーブルを照会し、最少カウントのサーバーを選択します。この小さなオーバーヘッドは、接続が多いワークロードの性能上の恩恵に比べれば無視できます。
Least Connection：一目で
| 観点 | 詳細 |
|---|---|
| 仕組み | アクティブ接続数が最少のサーバーへルーティング |
| 適合する用途 | 長いセッション時間、永続接続、データベースワークロード |
| 強み | リアルタイム負荷に適応、サーバー過負荷を防止、遅いリクエストを優雅に処理 |
| 弱み | 接続追跡のためのわずかなオーバーヘッド |
| ユースケース | SQLデータベース、LDAPディレクトリ、WebSocketアプリケーション、長時間実行リクエストを持つAPI |
First
Firstアルゴリズムは独自のアプローチを取ります：そのサーバーが最大接続数に達するまで、すべてのトラフィックをプール内の最初のサーバーに送信します。その後で初めて、トラフィックは次のサーバーへ流れます。
このアルゴリズムは、他のサーバーをスタンバイのまま、1つのプライマリサーバーがすべての負荷を処理することを望むアクティブ・パッシブ構成に有用です。また、追加容量を関与させる前に単一ライセンスサーバーの利用を最大化したいライセンスシナリオにも有用です。
Firstは、どのサーバーがトラフィックを処理しているかを正確に知ることができるため、予測可能な動作とトラブルシューティングの簡素化を提供します。ただし負荷分散の恩恵を提供せず、フェイルオーバーには完全に最大接続制限に依存します。
First：一目で
| 観点 | 詳細 |
|---|---|
| 仕組み | 最大接続に達するまで最初のサーバーがすべての負荷を受信 |
| 適合する用途 | アクティブ・パッシブセットアップ、ライセンス最適化、予測可能なルーティング |
| 強み | シンプル、予測可能、単一サーバー利用を最大化 |
| 弱み | 負荷分散なし、最大接続設定に依存 |
| ユースケース | プライマリ・バックアップ構成、ライセンスソフトウェア、容量オーバーフローシナリオ |
Random
Randomアルゴリズムは各受信リクエストに対してサーバーをランダムに選択します。ただし、純粋なランダム化と異なり、この実装は選択確率においてサーバーの重みと応答時間の両方を考慮します。
この重み付けランダムアプローチは、Round Robinの予測可能パターンを避けつつ、統計的な負荷分散を提供します。時間とともに、サーバーは重みに比例するトラフィックを受け取りますが、ランダム要素が周期的な負荷急増を引き起こし得る同期化されたリクエストパターンを防ぎます。
ランダム選択は、大数の法則が均等分散を保証する大規模サーバープールで特に効果的です。複数のクライアントが同時に同じサーバーを標的とする「サンダーリングハード」問題を避けたい時にも有用です。
Random：一目で
| 観点 | 詳細 |
|---|---|
| 仕組み | 重みと応答時間を考慮したランダムなサーバー選択 |
| 適合する用途 | 大規模サーバープール、同期化パターンの回避 |
| 強み | サンダーリングハードを防止、統計的に均等な分散、性能を考慮 |
| 弱み | Round Robinより予測可能性が低い、短期的な不均衡の可能性 |
| ユースケース | 高トラフィックアプリケーション、大規模クラスタ、キャッシュサーバー |
Fastest
Fastestアルゴリズムは、応答時間が最良のサーバーへリクエストをルーティングします。ロードバランサーはサーバー性能を継続的に監視し、現在最も速く応答しているサーバーへトラフィックを向けます。
このアプローチは、リクエストが最も応答性の高いサーバーに行くようにすることでユーザー体験を最適化します。条件の変化に自動的に適応します ― サーバーが高CPU、メモリ圧迫、外部依存により遅くなった場合、トラフィックはより速い代替サーバーへ移行します。
Fastestは、応答時間がユーザー体験やビジネスメトリクスに直接影響するレイテンシ敏感なアプリケーションに理想的です。Eコマースのチェックアウトフロー、リアルタイムAPI、インタラクティブアプリケーションはすべて応答時間ベースのルーティングから恩恵を受けます。
Fastest+
Fastest+は最も洗練されたアルゴリズムで、構成可能な基準を備えた2層の最適化を提供します。サーバー選択のための第1メトリック（Opt-1）を選択し、複数のサーバーが同等の第1値を持つ場合に判定する第2メトリック（Opt-2）を選択します。
利用可能な最適化基準には、Least Response Time、Least Connection Time、Least Queue Time、Least Queues、Least Connection Error、Least Aborted Connections、Least Used Connectionsが含まれます。この柔軟性により、特定のワークロード特性に対する微調整最適化が可能になります。
例えば、Opt-1を「Least Response Time」、Opt-2を「Least Connection Error」として構成できます。アルゴリズムはまず最良の応答時間を持つサーバーを選択し、その中から最少の接続エラーを持つものを選びます。この複数基準アプローチは、単一メトリックでは不十分な複雑な本番シナリオを処理します。
Fastest+最適化オプション
| オプション | 説明 | 適合する用途 |
|---|---|---|
| Least Response Time | リクエストに最速で応答するサーバー | レイテンシ敏感なアプリケーション |
| Least Connection Time | 接続を最速で確立するサーバー | 高接続チャーンワークロード |
| Least Queue Time | リクエストキュー待機時間が最短のサーバー | バースト性のあるトラフィックパターン |
| Least Queues | キューに入ったリクエストが最少のサーバー | リクエストの滞留を回避 |
| Least Connection Error | 失敗した接続が最少のサーバー | 信頼性が重要なアプリケーション |
| Least Aborted Connections | クライアント切断が最少のサーバー | 長時間実行リクエストワークロード |
| Least Used Connections | 接続利用率が最低のサーバー | 接続プールアプリケーション |
Fastest+は、複数のサーバーが第1基準（Opt-1）で同点の時のみ、第2基準（Opt-2）を使用します。これにより、サーバーがしばしば類似の性能特性を持つ同質環境でも最適な選択が保証されます。
持続性手法（セルフパーシステント）
持続性手法は、同じクライアント、セッション、またはコンテキストからの関連リクエストが常に同じバックエンドサーバーに到達することを保証します。これは、共有ストアではなくローカルにセッションデータを保存するステートフルなアプリケーションに不可欠です。
Source（IP持続性）
Source持続性は、サーバー選択にクライアントの送信元IPアドレスのハッシュを使用します。ハッシュ値はサーバーの重みと組み合わされてルーティングを決定します。同じクライアントIPは常に同じハッシュを生成し、同じサーバーへの一貫したルーティングを保証します。
この手法は、Cookieやアプリケーションレベルの変更を要さずにセッション持続性を提供します。特定のIPアドレスからのすべてのリクエストは同じサーバーへ行き、そのサーバーに保存されたセッション状態を維持します。
Source持続性は、複数のユーザーがIPアドレスを共有するNAT環境や、IPアドレスを変更し得るモバイルユーザーに対して制限を持ちます。これらのシナリオでは、アプリケーション層持続性手法（URI、URL Param、HDR）がより良い結果を提供します。
URI（パス持続性）
URI持続性は、サーバールーティングを決定するためリクエストURIパスをハッシュします。指定された長さまで（またはクエリパラメータが存在する場合は'?'文字まで）のURIテキストがハッシュされ、サーバーの重みと組み合わされます。同じURIは常に同じサーバーへルーティングされます。
構成オプションには、URI文字長とURI深度（考慮するパスセグメント数）が含まれます。例えば、深度2の場合、'/api/users/123'と'/api/users/456'の両方が同じ'/api/users'プレフィックスをハッシュします。
この手法は、同じリソースへのすべてのリクエストが同じサーバーに当たることでキャッシュ効率を最大化したいキャッシュシナリオに優れています。異なるURIパターンが異なるデータパーティションにマッピングされるシャード化バックエンドにも有用です。
URL Param（パラメータ持続性）
URL Param持続性は、URL（またはPOSTボディ）から指定されたパラメータを抽出し、その値をサーバールーティングに使用します。これは通常、ユーザーID、セッショントークン、その他のアプリケーション固有識別子を追跡するために使用されます。同じパラメータ値は常に同じサーバーへルーティングされます。
抽出するURLパラメータ名を構成し、必要に応じてフォーム送信のためのPOSTパラメータチェックを有効にします。これは、IPアドレスの変更にかかわらずユーザーセッションに追従するアプリケーション認識持続性を提供します。
この手法は、URLまたはフォームデータにセッションまたはユーザー識別子を埋め込むアプリケーションに理想的です。モバイルユーザーやNAT背後のユーザーに対して、IPベース手法よりも信頼性の高い持続性を提供します。
HDR（ヘッダー持続性）
HDR持続性は、各リクエスト内の指定されたHTTPヘッダーを検査し、その内容に基づいてルーティングします。同じヘッダー値を持つリクエストは常に同じサーバーへ行きます。検査するヘッダー名を構成します。
一般的なユースケースには、カスタムセッションヘッダー、APIキー、マルチテナントアプリケーションのテナント識別子、JWTトークンに基づくルーティングが含まれます。これは、独自のセッション識別子を管理するアプリケーションに最大の柔軟性を提供します。
HDR持続性は、Cookieではなくヘッダーを通じてセッション状態が管理されるAPIファーストアーキテクチャやマイクロサービスにとって特に価値があります。トークンベースの認証システムと滑らかに統合します。
Hash（高度なカスタム持続性）
Hash持続性は最も強力で柔軟な手法であり、トラフィックフロー内のほぼあらゆる要素からカスタム持続性キーを構築できます。ロードバランサーは、構成可能な有効期限（デフォルト7日）を持つカスタムキー値をバックエンドサーバーにマッピングするハッシュテーブル（デフォルトで最大300万エントリ）を維持します。
ハッシュキーは数百の利用可能な変数から構築できます：クライアントIPとポート、タイムスタンプ、SSL証明書フィールド、フロントエンド情報、URLパスとメソッド、HTTPヘッダー、リクエストボディコンテンツ、WAAP処理結果など。複数の変数を組み合わせ、変換関数を適用して、アプリケーションが必要とする持続性ロジックを精密に作成できます。
例えば、次のようなハッシュキーを作成できます：クライアントIPから国を抽出し、特定リストに含まれているかチェックし、SSLクライアント証明書のユーザー名と組み合わせる。この組み合わせから同じハッシュ値を生成するすべてのリクエスト ― つまり同じ証明書アイデンティティを持つ同じ地域のユーザー ― は常に同じバックエンドサーバーへ向けられます。これは、アプリケーションセッション状態を維持しつつ極めてきめ細かな持続性制御を提供します。このレベルのカスタマイズは、他のロードバランサーが単純に達成できない持続性シナリオを可能にし、TR7の差別化能力の1つとなっています。
ハッシュキーの構成要素
ハッシュキーは、これらのトラフィック要素のあらゆる組み合わせから構築できます：
| カテゴリ | 利用可能な変数 | ユースケース例 |
|---|---|---|
| ネットワーク層 | クライアントIP、クライアントポート、サーバーIP、サーバーポート | 地理ベースルーティング、ネットワークセグメントアフィニティ |
| SSL/TLS | 証明書CN、証明書DN、SNI、暗号スイート | クライアント証明書ベースルーティング、mTLSシナリオ |
| HTTPリクエスト | メソッド、パス、URL、クエリパラメータ、Hostヘッダー | コンテンツベースルーティング、APIバージョニング |
| HTTPヘッダー | あらゆるヘッダー値（Authorization、X-Tenant-IDなど） | マルチテナントルーティング、APIキーアフィニティ |
| リクエストボディ | POSTパラメータ、JSONフィールド、フォームデータ | 取引ベース持続性 |
| コンテキスト | 時刻、日付、フロントエンド名、WAAP判定、GeoIP国 | 時間ベースルーティング、コンプライアンスルーティング |
ハッシュキーは変換のための関数をサポートします：文字列操作（部分文字列、正規表現）、エンコーディング（base64、URLエンコード）、ルックアップ（GeoIP国、ASN）、条件付きロジック。これらを組み合わせて複雑な持続性ルールを構築します。例えば：「クライアントがEU諸国からであり、有効なクライアント証明書を持つ場合、証明書CNからハッシュキーを構築。それ以外の場合はAuthorizationヘッダーから構築」 ― 同じ条件に一致するリクエストが常に同じバックエンドサーバーに到達することを確保します。
持続性手法の比較
| 手法 | ベース | 構成 | 適合する用途 |
|---|---|---|---|
| Source | クライアントIPアドレスハッシュ | なし（自動） | シンプルなWebアプリ、レガシーシステム |
| URI | リクエストパスハッシュ | URI長、URI深度 | キャッシュ、コンテンツルーティング、シャード化バックエンド |
| URL Param | URL/POSTパラメータ値 | パラメータ名、POSTチェックオプション | セッション追跡、ユーザー固有ルーティング |
| HDR | HTTPヘッダー値 | ヘッダー名 | API認証、マルチテナントアプリ、JWTルーティング |
| New Cookie | LB管理Cookie | Cookie名、最大アイドル、最大ライフ | アプリ変更不要、セッションタイムアウト制御 |
| Current Cookie | 既存アプリCookie | 追跡するCookie名 | 既存アプリセッションの活用 |
| Hash | カスタムキー式 | キー変数、関数、300万エントリ、7日TTL | 複雑な複数要因持続性、究極の柔軟性 |
アルゴリズム選択ガイド
適切なアルゴリズムの選択は特定の要件に依存します。この比較は主要なトレードオフを浮き彫りにします：
| アルゴリズム | 負荷認識 | 複雑さ | 持続性 | 主要ユースケース |
|---|---|---|---|---|
| Round Robin | なし | 最小 | なし | 同質ステートレスワークロード |
| Weighted Round Robin | 静的（重み） | 低 | なし | 混合サーバー容量 |
| Least Connection | 動的（接続） | 中 | なし | 長いセッション、データベース |
| First | なし | 最小 | なし | アクティブ・パッシブ、ライセンス最適化 |
| Random | 動的（応答時間） | 低 | なし | 大規模クラスタ、キャッシュサーバー |
| Fastest | 動的（応答時間） | 中 | なし | レイテンシ敏感なアプリケーション |
| Fastest+ | 複数基準 | 高 | なし | 複雑な本番環境 |
| Source | 重み経由 | 低 | あり（IP） | シンプルなセッション持続性 |
| URI | 重み経由 | 中 | あり（パス） | キャッシュ、コンテンツルーティング |
| URL Param | 重み経由 | 中 | あり（ユーザーID） | ユーザーセッション追跡 |
| HDR | 重み経由 | 中 | あり（ヘッダー） | APIルーティング、マルチテナント |
アルゴリズムの選び方
分散アルゴリズムを使用する時
- アプリケーションがステートレス、または共有セッションストアを使用
- サーバープール全体に負荷を広げる必要がある
- サーバーが異なる容量を持つ（Weightedを使用）
- 応答時間の最適化が重要（Fastest/Fastest+を使用）
持続性手法を使用する時
- アプリケーションがサーバー上にローカルにセッションデータを保存
- バックエンドサービスがユーザーまたはコンテンツでシャード化
- キャッシュ効率が一貫したルーティングを要求
- トークンまたはヘッダーベースの認証を使用
Fastest+を使用する時
- 単一メトリックでは最適化目標を捉えられない
- 同質サーバーの判定ロジックが必要
- 性能と信頼性の両方が重要
- 多様なワークロードを持つ複雑な本番環境
実装のベストプラクティス
選択するアルゴリズムにかかわらず、これらの慣行が最適なロードバランシング性能を確保します：
堅牢なヘルスチェックを実装
TCP接続性だけでなく、アプリケーション機能を検証するアクティブヘルスチェックを構成します。pingに応答するが500エラーを返すサーバーはローテーションから削除すべきです。
重みを監視・調整
重み付けアルゴリズムの場合、四半期ごとまたはインフラ変更後に重み割り当てを確認します。正確な容量比率を決定するため、現実的な負荷下でサーバーをベンチマークします。
持続性を賢く選択
可能な限りアプリケーションをステートレスに設計し、セッションをRedisのような外部ストアに保存します。持続性が必要な場合、セッション識別子（IP、URI、パラメータ、ヘッダー）に最も合う手法を選びます。
フェイルオーバーシナリオをテスト
サーバー障害を定期的にテストし、優雅なフェイルオーバーを確保します。サーバーがプールから削除・再追加された時のアルゴリズム動作が正しいことを検証します。
複雑なシナリオにFastest+を使用
単一メトリックアルゴリズムがニーズを満たさない場合、第1・第2基準でFastest+を構成します。Opt-1としてLeast Response Time、Opt-2としてLeast Connection Errorから始めます。
よくある質問
はい、持続性手法（Source、URI、URL Param、HDR）はすでにルーティング決定にサーバーの重みを組み込んでいます。これにより、セッションアフィニティと容量認識分散の両方が得られます。ハッシュベース選択はサーバー構成に従って重み付けされます。
応答時間が唯一の懸念で、サーバーが明らかに異なる性能特性を持つ場合にFastestを使用します。より細かな選択が必要な場合 ― 例えば、応答時間を最適化しつつ、応答時間が類似の場合はエラーがより少ないサーバーを優先する ― 場合にFastest+を使用します。
持続的サーバーが利用不可になると、リクエストは持続性アルゴリズムのハッシュ再分散に基づいて他のサーバーへ再ルーティングされます。アプリケーションが外部セッションストレージを使用しない限り、障害サーバー上のセッションデータは失われます。ヘルスチェックは障害サーバーが迅速にプールから削除されることを保証します。
スタンドアロンアルゴリズムとしてのLeast Connectionは、アクティブ接続が最少のサーバーへルーティングします。Fastest+の'Least Used Connections'はサーバーの容量に対する接続利用率を考慮するため、異質サーバー環境により適しています。
モバイルアプリケーションでは、モバイルデバイスが頻繁にIPアドレスを変更するため、Source（IP）持続性を避けてください。ユーザーIDまたはセッショントークンを持つURL Param持続性、または認証ヘッダーを持つHDR持続性を使用します。これらの手法はネットワーク変更にかかわらずユーザーセッションに追従します。
結論
ロードバランシングアルゴリズムはアプリケーションデリバリーの基礎ですが、アーキテクチャ決定中にしばしば見過ごされます。適切なアルゴリズムは均等なサーバー利用、最適な応答時間、強靱なフェイルオーバーを保証します ― 一方、誤った選択はホットスポットを作り、性能を低下させ、トラブルシューティングを複雑化させます。
ほとんどの本番環境では、動的ワークロードにはLeast Connection、静的容量分散にはWeighted Round Robinから始めます。監視能力が成熟するにつれ、複数基準最適化のためのFastest+を探索します。セッション管理戦略に基づいて持続性手法を選択 ― シンプルさにはSource、アプリケーション認識ルーティングにはURI/URL Param/HDR ― します。
インテリジェントなトラフィック分散
TR7のADCは、複数基準最適化を備えた高度なFastest+を含むすべての主要アルゴリズム、そしてセッション認識ルーティングのための柔軟な持続性オプションをサポートします。エンタープライズグレードのロードバランシングでアプリケーションデリバリーを最適化してください。
ADCを見る