各クラシックアルゴリズムは、対象vServiceについての前提に基づいています。Round-robinはバックエンドが互換性を持つと前提します。Least-connectionsはセッション数がバックエンド負荷と相関すると前提します。Source-IPは明示的な永続性なしにユーザーとバックエンドの粘着性があると前提します。キャッシュアフィニティハッシュはリクエストキー — URL、ヘッダー、またはセッション — が安定していると前提します。前提が成立するとき、そのアルゴリズムが正しい答えです。
より難しいケースは、それらの前提が崩れるときです：業務時間中にバックエンドのパフォーマンスが変動する、ローリングアップグレード中にハードウェア世代が混在する、地域ごとのレイテンシがリクエストごとに変動する、あるいはワークロード自体に生のリクエスト数とは一致しないバースト的な重いクエリがある。このようなシナリオでは、リクエストごとに実際に最速のバックエンドを選択するか — またはすべてを再シャードすることなくバックエンド変更を吸収するためのハッシュアルゴリズムを使用することが、ユーザーに見えるレイテンシを維持します。
正しい答えは、アルゴリズムをワークロードに合わせること — グローバルではなくvServiceごとに。
TR7のvServiceは、フロントエンドリスナー、トラフィックルール、ヘルスチェック、バックエンドグループを単一の設定オブジェクトにまとめます — これらを別々の場所に分割するクラシックなpool概念より広い範囲をカバーします。各vServiceはドロップダウンから独自のアルゴリズムを選択します — 再ビルドなし、再起動なし。単一のTR7インスタンスで組み合わせ可能：静的アセットvServiceにround-robin、APIのvServiceにFastest+、キャッシュ層のvServiceにMaglev hash。サービスタイプのフィルタリングは自動で行われ、UIはvServiceのプロトコルに有効なアルゴリズムのみを表示します。
アルゴリズムの選択はグローバルADC設定ではなく、vServiceオブジェクトに属します。異なるvServiceは同一のTR7インスタンスで異なるアルゴリズムを実行できます。
UIはvServiceのプロトコルに対して意味のあるアルゴリズムのみを表示します — HTTP、TCP、またはネットワーク層のvServiceはそれぞれ関連するサブセットを取得し、オペレーターが推測する必要はありません。
アルゴリズムは最初のリクエストのバックエンドを選択し、セッション永続性が同じユーザーの後続リクエストを固定します。両方のレイヤーはvServiceごとに独立して設定可能です。
ライブvServiceのアルゴリズムを変更すると、トラフィックは即座に新しいロジックに切り替わります。サービスの再起動も、接続ドレインも不要です。
すべてのクラシックアルゴリズム、2つのモダンなconsistent hashバリアント、1つの最短遅延アルゴリズム、そしてTR7独自のFastest+エンジン。すべてvServiceごとに利用可能 — ドロップダウンから選択、設定コード不要。
vService全体に均等分散、重み付きまたは重みなし。すべてのバックエンドが同一容量を持つ均一なvServiceの標準デフォルト。
現在最も少ない開放接続数のバックエンドにルーティング。セッション数がバックエンド負荷と相関する長期セッションに非常に効果的。重み付きバリアントは容量の差を考慮します。
常に容量のある最初のバックエンドにルーティングし、過負荷の場合のみ次にフォールスルー。ウォーム→コールドのバックエンド順序付けやステージドデプロイメントに有用。
正常なバックエンドからランダムに選択。ステートレス、統計的に均等 — vServiceが大きく均一な場合に有用。低オーバーヘッドの最小負荷選択にはpower-of-two randomをサポート。
同一クライアントIPは常に同一バックエンドにルーティング。アプリケーションが明示的なセッション永続性を管理しない場合のステートフルフローに有用。
URLコンポーネントでハッシュ — URL長、URIパス、または特定のクエリパラメーター（例：?user_id）。キャッシュアフィニティのために同一URLまたはユーザーを同一バックエンドにルーティング。
カスタムHTTPヘッダーでハッシュ。マルチテナントルーティング（tenant-idヘッダー）、フィーチャーフラグ、またはA/Bテストシナリオに有用。
バックエンド選択のためにRDPセッションcookieを読み取り。セッションアフィニティが必要なRDPゲートウェイとリモートデスクトップファームに有用。
バックエンドがvServiceに参加または離脱するときの中断を最小化するモダンなハッシュモード — キーのごく一部のみが再シャードされ、vService全体ではありません。バックエンドの変更がキャッシュ全体を無効化すべきでないキャッシュ層に適切。
ソフトウェアロードバランサーのスケールのために設計されたGoogleのconsistent hashingアルゴリズム。クラシックなconsistent hashより低い分散、レプリカ間で決定論的。予測可能なバックエンド割り当てが必要なステートレスサービスに最適。
アクティブな接続とバックエンドごとの重みを考慮して、最低の期待待機時間のバックエンドにルーティング。バックエンドの容量が大きく異なる場合のleast-connectionsの洗練された代替。Fastest+の全複雑性なしに使用可能。
最低の最近のレスポンス時間のバックエンドにルーティング。レスポンス時間のみが重要な場合のシンプルなレイテンシ対応オプション。
TR7独自の8シグナル適応型エンジン。レスポンス時間、接続時間、キュー深度、アクティブセッション、エラー率などをリクエストごとの速さスコアに統合。以下の詳細セクションを参照。
ほとんどの適応型アルゴリズムは1つのシグナルを監視します — レスポンス時間または接続数。Fastest+はバックエンドごとに8つの独立したパフォーマンスシグナルを継続的にサンプリングし、受信する各リクエストに対して新しく計算された単一の速さスコアに統合します。
バックエンドからの平均レスポンスレイテンシ、継続的にサンプリング。主要シグナル — レスポンスに時間がかかるバックエンドは即座にランキングを下げます。
TCP/TLS接続の確立にかかる時間。接続時間が増加しているバックエンドは飽和に近づいています — レスポンス時間がまだ良好に見えても。
リクエストがバックエンドに到達する前にキューで過ごす時間。キュー時間の上昇は、バックエンドが追いつけていない最初の警告です。
バックエンドごとの現在の開放セッション数。過去の累計のノイズなしに容量対応ルーティングを実現。
現在待機中のリクエスト数。キューが0のバックエンドは、50が待機している同等速度のバックエンドより優先されます。
最近の失敗した接続数。直近10回の試行のうち3回を拒否したバックエンドは、ヘルスチェックが捕捉する前にランキングを下げます。
最近のウィンドウ内でバックエンドが開始したセッションアボート。バックエンドが動作しているが途中で失敗しているケースを捕捉します。
接続プールの利用率 — 各バックエンドのkeep-aliveプールが容量にどれだけ近いか。プール枯渇がユーザーに見える前に検出します。
同一バックエンド、同一容量 — round-robinは計算をシンプルに保ち、負荷を対称に維持。ステートレスな大規模vServiceにはrandomを追加。
WebSocket、ストリーミングサービス、ビデオ通話 — セッションは数分または数時間開放されたまま。Least-connectionsまたはSEDはリクエスト数よりはるかにアクティブ負荷を追跡します。
バックエンドの変更がキャッシュ全体を無効化すべきではありません。Consistent hashまたはMaglevはバックエンド変更時にキーのごく一部のみを再シャードします。
混合ハードウェア、ローリングデプロイ、地域レイテンシ分散 — Fastest+はバックエンドをライブでスコアリングし、理論上最適ではなく実際に最速のものを選択します。
TR7 ADCがvServiceごとにアルゴリズムを設定させる方法、そしてFastest+が他のアルゴリズムが対処できないワークロードをどのように処理するかをご覧ください。