古典的なDNSラウンドロビンは、同じレコード下のIPアドレスをほぼ等しく分散します。そのモデルは単純なロードシェアリングには適切かもしれませんが、新リリースロールアウト、A/Bテスト、ブルー/グリーンカットオーバー、データセンター移行に必要な制御を提供しません。運用チームは通常、新しい宛先にトラフィックの5%だけを送り、残りを既存システムに残したいと考えます。
DNSレベルでの重み付けなしでは、トラフィック分割はアプリケーション層または別のトラフィック分割層で解決される必要があります。これは追加のアーキテクチャ、追加の監視、追加の証明書管理、追加の障害ポイントを意味します。判断が代わりにDNS応答で行えるとき、クライアントは最初のクエリから適切な宛先に向けられます。
メンテナンスとドレインシナリオも、レコードを削除することで処理されるとき粗いです。DNSレコードからIPを削除することは新しいクエリには有効ですが、トラフィックシェアを徐々に減らしたり、ターゲットを制御された方法でローテーションから外したりするニーズに対応しません。TTLウィンドウを超えるクライアントと中間リゾルバーのキャッシュ動作も考慮する必要があります。
正しいモデルは、各DNSレコードに別個の重みを割り当て、シナリオに合うアルゴリズムを選ぶことです。重み付きラウンドロビンはバランスの取れた順序付き分散に適し、重み付きランダムは統計的なパーセンテージベース選択を提供します。0の重みはターゲットを実質的なドレインモードに置き、新しいDNS応答から削除します。
TR7重み付きDNSは、レコードごとの重み、重み付きラウンドロビン、重み付きランダム、ライブ構成リロード、weight=0ドレイン動作を通じてDNSレイヤーで制御されたトラフィック分散を提供します。
TR7はDNS応答を静的レコードリストから持ち上げ、重み値と選択可能なアルゴリズムによって統治されるトラフィック分散判断に変えます。
各IPまたはレコードメンバーに整数重みが定義されます。重み付きラウンドロビンアルゴリズムは、これらの重みを使用してプール全体にDNS応答を比例的に分散します。
重み付きランダムアルゴリズムは、すべてのクエリで重みに比例したランダム選択を実行します。高いクエリボリュームでは、観察されたトラフィック分布が定義された重み比に収束します。
重み変更はライブ構成リロードパイプラインに入り、新しいクエリは即座に更新された分布を受け取ります。以前にキャッシュされた応答はTTLが期限切れになるまで生き続けるため、高速遷移シナリオではTTL計画が不可欠です。
レコードの重みが0に設定されると、アクティブな候補リストから削除されます。この動作は、メンテナンス、ロールバック、またはデータセンター廃止のための制御されたドレインを提供します。
重み付きDNSは、レコードごとの重み値をアルゴリズム選択、ライブ更新、トポロジー統合、メンテナンスシナリオと共に管理します。
TR7では、すべてのレコードメンバーが独自の重み値を持てます。この値はトラフィック分散の相対的シェアを決定します — 5と2の重みは約5:2の比率をターゲットにします。floatが提供されると、使用前に整数に丸められます。このモデルは、容量の大きいターゲットに大きなシェアを、テストターゲットに小さなシェアを与えることを簡単にします。
重み付きラウンドロビンは重み比に従ってローテーションでレコードを選択します。バランスの取れた分散が期待され、レコードの順次使用が許容される場合に好まれる選択です。カナリアリリース、段階的ロールアウト、容量比例トラフィック共有のための実用的なアルゴリズムです。運用者は重み値を変更するだけで分散を再形成します。
重み付きランダムは、すべてのDNSクエリで重みに比例したランダム選択を生成します。短い時間窓では小さな偏差が現れることがあります。高いクエリボリュームでは、分布は定義された比に収束します。A/Bテストと実験的トラフィックルーティングに適しています。低い重みの新しいターゲットは、同じレコードプール内で安全に試せます。
重み値が変更されると、GTM構成はライブリロードプロセスに入ります。デバウンスメカニズムが急速な連続変更を統合し、不要な再レンダリングを低減します。典型的なライブリロードレイテンシは約3秒です。新しいDNSクエリは更新された重み分布を受け取ります。クライアントとリゾルバーキャッシュの以前にキャッシュされた応答はTTLが期限切れになるまで残ります。
DNS重みが変更されると、システムは新しい応答を即座に更新します。しかしすでに発行されたDNS応答は、TTLが期限切れになるまで中間キャッシュに生き続けます。カナリア、ブルー/グリーン、または高速ロールバックシナリオでは、TTLを低く保つべきです。5〜60秒の範囲の値は、遷移をより速く反映できるようにします。安定した運用期間中は、より高いTTLが適切です。
IPまたはレコードメンバーの重みが0に達すると、そのターゲットは新しいDNS応答から削除されます。これにより、削除せずにメンテナンスのためにレコードをドレインできます。既存のキャッシュされた応答はTTLが期限切れになるまで古い応答を使用し続け、新しいクエリはターゲットを受け取らなくなります。メンテナンス、ロールバック、データセンター廃止のための制御された可逆的な方法です。
TR7では、分散は単一のIPレベルに限定されません — データセンターグループとレコードメンバーの重みロジックが組み合わせて機能できます。適切なデータセンターまたは候補グループが最初に選択され、そのグループ内のレコードは重みで分散されます。このモデルは、グローバルトラフィック管理で容量とロケーションの両方を考慮するのに役立ちます。大規模展開では、分散がよりレイヤー化され管理しやすくなります。
ジオまたはトポロジーベースの選択が使用されると、適切な候補グループが最初に識別されます。重み分散はその候補セット内で適用されます。例えばヨーロッパのユーザーはヨーロッパのデータセンターグループにルーティングされ、そのグループ内のIPは重み付けされます。トポロジー判断と重み判断は互いに干渉せずに順次適用されます。
重み付き分散を必要としないレコードは、古典的なラウンドロビンまたはランダム選択を使用できます。ラウンドロビンはレコードを等しく分散し、ランダムはランダムに選択します。これらのアルゴリズムは単純なシナリオに十分で、同じレコードモデルを通じて管理されるため、重み付きアルゴリズムへの切り替えに構造的変更は不要です。運用者は各DNSレコードに適切な分散動作を選択します。
closestアルゴリズムはIP近接性選択を必要とするAおよびAAAAレコードに利用可能です。重み付き分散とは異なり、クライアントに最も近いまたは最も適切なターゲットを選択することに焦点を当てます。トポロジー、closest、重みはグローバルトラフィック管理において異なる判断レイヤーとして機能できます。結果は単にランダムではなくコンテキスト認識のDNS応答です。
重み付きDNSは、重み形式、アルゴリズム選択、ライブリロードレイテンシ、TTL影響、レコード選択動作と共に運用されます。
重みは数値として定義され、整数として使用されます。floatが提供されると丸められます。重み比はレコード間の相対的シェアを表し、絶対パーセンテージではありません。
重み付きラウンドロビンおよび重み付きランダムアルゴリズムは、レコードリストと重みマップを一緒に使用します。各レコードに対してインデックス化された重み値が生成されます。この構造は、DNS応答生成中にセレクター関数によって評価されます。
構成変更はデバウンスされたライブリロードプロセスを通過します。典型的なデバウンス値は3秒で、急速な連続変更のバースト中は最大待機制限が適用される可能性があります。この動作により、不要な頻繁な再レンダリング操作が低減されます。
重み変更は新しいDNSクエリに反映されます。以前の応答をすでに受け取ったクライアントまたはリゾルバーは、TTLが期限切れになるまでキャッシュされたレコードを使用し続けます。このため、TTLは遷移を計画する際に重みと同じくらい重要な運用パラメータです。
重み0は、レコードをアクティブな候補リストから削除するために使用されます。これにより、レコードを完全に削除せずにメンテナンスや移行を実行できます。レコードを復元するには、重みを正の値に戻します。
特定のシナリオでは、アルゴリズムの代わりに数値を提供して候補リストから最初のN個のレコードを選択できます。この動作は単純で決定論的なレコード制限に有用です。重み付き分散が不要な特殊ケースに実用的なオプションです。
新リリースIPは低い重みを受け取り、現在のリリースは高い重みを受け取ります。新バージョンは約5%のトラフィックで開始し、メトリックが健全に見えるにつれて重みは段階的に上げられます。問題が発生した場合、新リリースは重みを0に設定することでドレインされます。
ブルー環境がアクティブな間、グリーン環境は低い重みでテストされます。カットオーバー時、ブルーの重みは0に下げられ、グリーンは唯一のアクティブターゲットになります。ロールバックが必要な場合、重みは反転して以前の環境に戻ります。
2つのランディングページまたは2つのサービスバリアントが別々のIPレコードで定義されます。重みは均等テストのために1:1、または制限された実験のために9:1に設定できます。結果分析に基づいて、トラフィック比はDNSレベルで調整されます。
古いデータセンターは高い重みで開始し、新しいデータセンターは低い重みで導入されます。運用チームは100 → 80 → 50 → 20 → 0のような段階的削減でトラフィックを新しいセンターにシフトします。TTLを低く保つと、各ステップの影響がより速く観察されます。
容量の大きいバックエンドは高い重みを受け取り、より制約のあるリソースは低い重みを受け取ります。トラフィック分散はサーバー容量に比例します。運用者は重み値の更新だけで分散を再形成します。
メンテナンスに入れられるバックエンドの重みは0に下げられます。新しいDNSクエリはもはやそのターゲットにルーティングされず、以前にキャッシュされた応答はTTLが期限切れになるまで使用され続けます。メンテナンスが完了すると、重みは正の値に戻され、バックエンドはサービスに再参加します。
レコードごとの重みとライブリロードでカナリアリリース、ブルー/グリーンカットオーバー、A/Bテスト、データセンター移行を実現。ご自身の環境でライブセットアップをご案内します。