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