ほとんどのGSLB実装は単一のシグナルクラスからデータセンター選択を判断します。地理的距離は一般的な選択肢の1つ、プラットフォームの測定ポイントからのラウンドトリップタイムが2つ目、静的トポロジールックアップが3つ目です。それぞれ有用な次元を捉えていますが、他の次元を見逃しています。
地理は負荷を無視します — 最も近いデータセンターが現在容量プレッシャーにあるDCである可能性があります。GSLBのプローブからのレイテンシはユーザーを無視します — ユーザーの実際のネットワーク経路はプローブが通った経路ではありません。静的トポロジーは構成が書かれて以来ネットワークが変わっていないことを前提とします。
本番判断にはこれら3つの視点が同時に必要です: DCプラットフォームは健全か? DC上のアプリケーションは現在パフォーマンスを発揮しているか? ユーザーからDCへのネットワークは今実際に良好か? 各視点には他では置き換えられないシグナルがあります。
TR7 GTMは3つのシグナルクラス — ホスト、サービス、クライアント — をDC選択への独立した入力として公開し、運用者がワークロードに本当に合うポリシーを記述できるようにします。
DC選択はDNSレコードごとに構成されます。運用者は使用するシグナルソース、そのソース内の特定メトリック、選択するDC数、選択結果間でどう分散するかを選びます。
DCプラットフォームで測定される5つのメトリック: CPU、メモリ、帯域、ステータス(アップ/ダウン複合値)、パケットロス。ルーティング判断でDCプラットフォーム圧力が支配的シグナルである場合に有用です。
サービスごとに測定される8つのメトリック: CPU、メモリ、帯域、リクエスト率、コネクション数、新規セッション率、ステータス、healthyBackends。ホストがアップしているかだけでなく、アプリケーションが実際に何をしているかでトラフィックをルーティングします。
リクエスト元クライアントへのネットワーク経路で測定される4つのメトリック: ホップ数、MOS(平均オピニオンスコア)、パケットロス、TTL。DC側プローブでは見えないユーザー側体験を捉えます。
`pickDcCount`は返すDC数を選びます。`balanceAlgorithm`は選択結果に分散します — all、top-N、ラウンドロビン、重み付きラウンドロビン、ランダム、重み付きランダム、closest。
DCモードの各DNSレコードは、シグナルソース、基準、分散動作を独立して選択します。
DCホストソースはcpu、mem、bw、status、packetLossを公開します。statusはDCのWANおよびLANアクセスポイントから計算される複合到達性/健全性状態です。ホストレベルの容量が支配的なルーティングシグナルである場合に有用です。
サービスソースはcpu、mem、bw、request、connection、session_new、status、healthyBackendsを公開します。healthyBackends数は特に重要です — プラットフォームがアップしているDCではなく、アプリケーションが今最も多くの稼働中容量を持つDCにトラフィックをルーティングします。
クライアントソースはhops(経路長)、mos(VoIP/リアルタイムトラフィック品質を表す平均オピニオンスコア)、packetLoss、ttlを公開します。これらのシグナルはクライアントネットワークに対して測定され、DC側ヘルスプローブでは見えないユーザー体験を捉えます。
静的モードはマルチソース選択をバイパスし、運用者定義のルールに基づいてDCを割り当てます。レガシーDNSレコード、コンプライアンス駆動のルーティング(特定クライアントに特定DC)、テストに有用です。
選択基準は運用者が制御します: 最小値が勝つ、最大値が勝つ、値がターゲットと等しい、値がマージンで異なる。同じDSLが3つすべてのシグナルソースで基準評価を駆動します。
`pickDcCount`はデフォルトで1ですが、DNS応答で複数DCを返すために高く設定できます。これにより、常に1つだけを選ぶルーティングではなく、真のマルチDCロードバランシングが可能になります — DNSクライアントは複数の応答を受け取り、クライアント側リゾルバーまたはスタブがそれらの間で選択します。
DCが選択されると、各DC内のレコードは`balanceAlgorithm`に従って分散されます: all(すべてのレコードを返す)、top-1/2/3(上位N個を返す)、ラウンドロビン、重み付きラウンドロビン、ランダム、重み付きランダム、closest(リクエスト元への近接性)。適切なアルゴリズムは、広範囲分散、トップN集中、スティッキネスのいずれを望むかによって異なります。
サービスソースを使用する場合、運用者はサービス名を指定します — 同じDC群で動作する異なるアプリケーションは異なるルーティングルールを持てます。サービスAとサービスBのhealthyBackends数は別々のDC選択を駆動できます。
選択が健全なDCを返さない場合、レコードのフェイルセーフリストが最終手段の応答を提供します — マルチソースシグナルがすべて失敗した時に常に返される運用者定義のIPです。最終応答としてのNXDOMAINを防ぎます。
DC選択はDNSレコードごとに構成されます。同じドメインがservice.healthyBackendsでルーティングされるAレコード、host.statusでルーティングされるMXレコード、client.packetLossでルーティングされるCNAMEを持つことができます。運用者は各レコードをそのワークロードに合わせて調整します。
マルチソース選択はDC定義、ヘルスチェックシナリオ、重み付きDNSアルゴリズム、フェイルセーフレコードと共に機能します。
各シグナルソースには独自の測定頻度があります。ホストおよびサービスメトリックはGTMのメトリック収集サイクル(通常30〜60秒ごと)で更新されます。クライアントメトリックはリゾルバーセッションごとに更新されます。運用者はDCトポロジーに対してソースごとに頻度を調整します。
選択はレコードごとに一度に1つのソースを使用します。運用者がホストシグナルでサービスシグナルをゲートしたい場合(「ホストが健全な場合のみサービスメトリックを考慮」)、サービスソースレコードにホストベースのシナリオをバインドします。レイヤリングは明示的です。
healthyBackends数は外部プローブから近似されるのではなく、各DCのアプリケーションのロードバランシング層から直接読み取られます。この数値は、その瞬間にサービスの背後で実際に稼働中のバックエンドプールを反映します。
MOSはリクエスト元クライアントネットワークに対するネットワーク品質測定値(ジッター、パケットロス、レイテンシ)から計算されます。継続的なクライアントセッションに対して最も正確であり、初回クライアントについては数測定ウィンドウ以内に収束します。
`pickDcCount`が利用可能な健全なDC数を超える場合、利用可能なすべての健全なDCが返されます。プラットフォームはカウント目標に合わせて偽のDCを発明しません — 運用者は実際に適格だったDCを正確に確認できます。
選択と分散アルゴリズムは合成されます: 選択は基準で適格DCを選び、分散は各DC内のレコードがどう返されるかを決定します。レコードはservice.healthyBackendsで3つのDCを選び、その後重み付きランダムで各DC内のレコードを返せます。
healthyBackends基準を伴うサービスソースは、アプリケーションが最も多くの稼働中容量を持つDCにトラフィックをルーティングします。ホストはアップしているがアプリケーションバックエンドが劣化したDCをホットスポット化することを避けます。
packetLoss基準を伴うクライアントソースは、各ユーザーをそのネットワークから最もクリーンなネットワーク経路を持つDCにルーティングします。経路品質が地理的近接性より重要なVoIP、ビデオ、ゲーム、リアルタイムアプリケーションに有用です。
ピックN(例: 上位3つのDCを返す)と重み付きランダム分散を組み合わせて、複数の健全な地域にトラフィックを共有します。各DNSクライアントは複数のオプションを受け取り、リゾルバーとスタブが自然にそれらに分散します。
ホストベースのシナリオをゲートとして使用し(「DCはプラットフォーム健全」)、サービスベースの基準を選択者として使用します(「ゲートされたDCの中でhealthyBackends数が最も多いDC」)。重要なワークロードはスクリプティングなしに2層選択を得られます。
ご自身のトポロジーでマルチソースDC選択をお試しください: ホストメトリック、サービスメトリック、クライアント側ネットワーク測定値が同じルーティング判断を駆動します。