従来のロードバランシングアプローチでは、アルゴリズムの選択はしばしば単一変数のリストに還元されます：順番に分配する、最小接続数へ送る、ソースアドレスで固定する、または重みを使う。このモデルは通常のトラフィック下では十分に見えるかもしれません。しかしキャンペーン、APIの急増、ストリーミングトラフィック、または突然のユーザー集中が始まると、単独で判断するには弱いものとなります。
例えば2つのbackendが同じレスポンス時間を返している場合、システムが2つ目の比較を行う手段を持たなければ、トラフィックは無作為に分配されます。レスポンス時間が低く見えるがキューが満杯のサービスが選ばれる可能性があり、接続数が少なく見えるがエラーを生成し始めたサービスが依然として候補に残る可能性があります。
この不安定さは特にテール遅延の値に影響します。平均レスポンス時間が許容範囲に見える一方で、高いパーセンタイルではユーザー体験が劣化する可能性があります。セキュリティ、アクセス制御、アプリケーション層コントロールが追加する遅延も考慮されないと、速く見えるが実際には遅く振る舞う候補が前面に出る可能性があります。
正しいモデルは、判断の瞬間にライブのサービスシグナルを読み取り、不健全またはメンテナンスモードの候補を自動的に除外すべきです。セッションアフィニティが有効な場合は既存のユーザーの結び付きを崩さず、自由なリクエストでのみ最適なサービスを選ぶべきです。
Fastest+ Routingが解決する核心的な問題はこれです：ロードバランシングの判断を、単一のラベルではなく、リアルタイムで2段階のサービス挙動に結び付けること。
TR7はFastest+ Routingを、ライブシグナルの読み取り、2段階のスコアリング、ヘルス認識、インターフェースベースの構成で扱います。
判断ロジックはデータプレーンに組み込まれて動作し、各HTTPまたはTCPリクエストでライブのサービス統計を読み取ります。選択されたサービスはルーティング変数に書き込まれ、トラフィックはこの判断に従って進められます。オペレーターは独自のコードを書かずに、リクエストごとの動的な選択を得られます。
第1段階ではprimaryシグナルで最良の値を持つサービスが候補リストに入ります。複数のサービスが同じスコアを共有する場合、第2段階でsecondaryシグナルが作動します。これにより「レスポンス時間が同じなら、キューがより空いているものを選ぶ」といった実用的な判断が単一のアルゴリズム内で適用されます。
メンテナンスモードまたはヘルス状態が適切でないサービスは候補リストに入りません。動的セッションアフィニティが有効な場合、Fastest+の選択はスキップされ、既存のセッションの結び付きが保護されます。このアプローチはパフォーマンス最適化を行いながらユーザーセッションを崩しません。
オペレーターはprimaryとsecondaryの判断シグナルを選ぶだけです。システムは必要なルーティング行を構成生成段階で自動的に作成します。複雑な判断ロジックが、日常運用のためのシンプルなポリシー選択へと変わります。
Fastest+ Routingは、backend間でライブのパフォーマンス、ヘルス、セッションの結び付きを同時に評価する高度なルーティング機能を提供します。
primary判断シグナルで新たな最良値が見つかると候補リストはリセットされ、同じ値を共有するサービスがリストに追加されます。第2段階でこれらの候補がsecondaryシグナルに従って再び絞り込まれます。デフォルト構成では、Fastest+はレスポンス時間が低い候補の中から、瞬間セッション負荷がより低いサービスを優先します。これにより速く見えるサービスの中から、負荷がより低いものが選ばれます。
オペレーターはFastest+のために2つの判断シグナルを選択します：平均レスポンス時間、接続確立時間、キュー待機時間、瞬間セッション負荷、瞬間キュー混雑度、接続エラー、クライアントエラー密度、サーバーエラー密度、サービス起因の切断、または使用中の接続キャパシティ。これらのシグナルはシステム内で関連するライブサービスカウンターに接続されます。ユーザーは生のメトリック名と格闘しません。これによりトラフィックは単に「速く見える」サービスではなく、その時点でより健全で、より空いていて、エラーをより少なく生成するbackendへルーティングできます。
2つ目の比較が不要なサービスプールでは単一シグナルモードを使用できます。このモードでは、判断は選択されたprimaryシグナルの最良値のみに従って行われます。よりシンプルなサービスグループには不要な判断の深さは追加されません。オペレーターは同じインターフェースから単一シグナルモードと2シグナルモードの両方を管理できます。
backendがメンテナンスモードにある、またはヘルス状態が適切でない場合、候補リストに入りません。この挙動はアルゴリズムに組み込まれており、手動ルール、追加のアクセス制御リスト、運用上の介入を別途必要としません。計画されたメンテナンス、問題のあるサービスの分離、一時的なサービス除外がトラフィック判断に自動的に反映されます。これによりシステムは適切な候補の中からのみ選択を行います。
セッションアフィニティの条件が成立すると、Fastest+の選択は無効になります。リクエストは既存のスティッキーセッションロジックで決定されたサービスへルーティングされます。生成されるルーティング条件はシステムによって透過的に構成されます。これによりパフォーマンス最適化がユーザーセッションの継続性を妨げることはありません。
Fastest+はHTTPリクエスト段階でもTCPコンテンツ検査段階でも動作できます。TCPサービスでは判断に必要な検査ウィンドウが自動的に作成されます。これによりアプリケーション層トラフィックとTCPベースのサービスが同じ管理モデルで扱われます。オペレーターはサービスタイプに応じて異なる製品ロジックを学ぶ必要がありません。
動的アフィニティを使用する場合、Fastest+はまだ固定されたセッションを持たないクライアントに対してのみ動作します。既存のセッションが保護される一方で、新規または自由なリクエストはライブシグナルに従って分配されます。このモデルは、ユーザーの継続性と瞬間的なキャパシティ利用の両面でバランスの取れたアプローチを提供します。特に高負荷で変動の激しいトラフィック下で、サービスプールのより効率的な利用に役立ちます。
判断プロセスで適切なbackendが見つからない場合、特殊なルーティング判断は空のままになります。この場合、デフォルトのロードバランシング挙動が作動します。システムは特殊なルーティング判断を生成できない場合、トラフィックを無駄に落とすのではなく、既知のデフォルト挙動へフォールバックします。このフォールバックロジックが運用リスクを軽減します。
Fastest+ Routingは、アルゴリズムの選択だけでなく、高可用性、可視性、リロード、統合の挙動とともに設計されています。
判断ロジックはサービス開始時にロードされ、単一シグナルと2シグナルの2つの別個のアクションとして定義されます。単一シグナルアクションは1つの判断入力で、2シグナルアクションは2つの判断入力で動作します。アクションはHTTPおよびTCPリクエスト段階で使用できます。
サービス統計はメモリ内のテーブルから読み取られます。追加のソケット、ファイル読み取り、外部クエリは不要です。判断プロセスはサービス数に応じて線形スキャンを行います。この構造は、多数のbackendを持つプールでもルーティング判断をデータプレーンに近く保ちます。
2ノードの高可用性構成では、各ノードが同じアルゴリズムを独立して実行します。ライブシグナルはノードローカルで評価されるため、failover後に新しいアクティブノードが自身が観測した統計で判断を続けます。外部の共有スコアストアへの依存は生じません。
選択されたbackendはルーティング変数に保持され、ログ形式に追加できます。これにより、どのリクエストがどのサービスへルーティングされたかを遡って確認できます。運用チームはトラフィック判断を単なる結果としてではなく、追跡可能なルーティング証跡として確認できます。
ソフトリロード中、判断コンテキストは再ロードされ、アルゴリズムは新しいメモリ状態で開始します。過去のレスポンス時間の観測は引き継がれないため、最初のリクエストでは判断は現在の瞬間データに基づきます。プールを再起動せずに構成変更を適用できることが、運用上の中断を軽減します。
WAAP層がリクエストをブロックすると、Fastest+は呼び出されません。これにより不要なサービス選択は行われません。Fastest+はHTTPおよびTCPサービスプールでのみ有効です。Layer 4サービスではプラットフォームのLayer 4アルゴリズムオプションが使用されます。
繁忙な販売期間には、多数のbackendが同時にトラフィックを受け取ります。Fastest+はレスポンス時間やキュー混雑度などのシグナルを同時に評価することで、速いがキューが満杯のサービスが不要に前面に出ることを防ぎます。結果として、よりバランスの取れたサービス利用と、より制御されたユーザー体験が得られます。
金融API層では、速いレスポンスだけでは不十分です。エラー生成の挙動も判断の一部であるべきです。Fastest+はサーバーエラー密度が低いサービスを前面に出し、同点では瞬間セッション負荷を考慮できます。この構造は重要なAPIトラフィックでより意識的な分配を提供します。
ストリーミングおよびメディアトラフィックでは、最も負荷の低いノードが常に最良のユーザー体験を提供するとは限りません。Fastest+は使用中の接続キャパシティとレスポンス時間の組み合わせにより、現在の接続利用とレスポンス挙動の両方を同時に評価します。これによりエッジサービス間でより精緻なトラフィック共有が行われます。
マルチテナント構成では、各テナントのサービスグループが異なる挙動を示すことがあります。Fastest+はサービス起因の切断や接続確立時間などのシグナルにより、より安定して動作するサービスを優先できます。このアプローチはテナントごとのサービス品質をより管理しやすくします。
ライブシグナルによる2段階の、コードを書かずに構成されるトラフィック分配。お客様のサービス上でのライブセットアップでご案内します。