DNS ルーティング ポリシーとヘルスチェック

限定公開ゾーンまたは一般公開ゾーンのリソース レコードセットの DNS ルーティング ポリシーを構成して、特定の条件に基づいてトラフィックをステアリングできます。これらのポリシーを設定するには、特定のルーティング ポリシー値でリソース レコードセットを作成します。これらの値により、Cloud DNS がクエリ トラフィックをルーティングする方法が決まります。

Cloud DNS でサポートされるルーティング ポリシーは次のとおりです。

  • 重み付きラウンドロビン（WRR）ルーティング ポリシー: WRR ルーティング ポリシーを使用して、DNS 名の各リソースレコードセットに異なる重みを割り当てます。WRR ルーティング ポリシーにより、構成済みの重みに従ってトラフィックが分散されます。WRR と位置情報に基づくルーティング ポリシーを組み合わせて使用することはできません。

  • 位置情報に基づくルーティング ポリシー: 位置情報に基づくルーティング ポリシーを使用して、送信元の位置情報を指定し、その位置情報に対応するレスポンスを提供します。位置情報に基づくルーティング ポリシーは、トラフィックの送信元がどのポリシー項目とも完全に一致しない場合、送信元のロケーションに最も近い一致を適用します。

  • フェイルオーバー ルーティング ポリシー: フェイルオーバー ルーティング ポリシーを使用して、アクティブ バックアップ構成を設定します。

次の限定公開ゾーンでは DNS ルーティング ポリシーを構成できません。

  • 転送ゾーン
  • DNS ピアリング ゾーン
  • マネージド逆引き参照ゾーン
  • Service Directory ゾーン

WRR ルーティング ポリシー

WRR ルーティング ポリシーでは、DNS ターゲットごとに異なる重みを指定できます。Cloud DNS は、この重みに従ってトラフィックを分散します。このポリシーは、手動の active-active 構成または active-passive 構成をサポートする場合に使用できます。また、サービスの本番環境バージョンと試験運用版バージョンでトラフィックを分割することもできます。

Cloud DNS は、内部ロードバランサと外部エンドポイントのルーティング ポリシー内でヘルスチェックとフェイルオーバーをサポートしています。 Cloud DNS は、エンドポイントがヘルスチェックに失敗した場合に自動フェイルオーバーを有効にします。フェイルオーバー中に、Cloud DNS は残りの正常なエンドポイント間でトラフィック分割を自動的に調整します。 詳細については、ヘルスチェックをご覧ください。

位置情報に基づくルーティング ポリシー

位置情報に基づくルーティング ポリシーを使用すると、ソースの地理区分（Google Cloud リージョン）から送信されたトラフィックを特定の DNS ターゲットにマッピングできます。このポリシーを使用して、トラフィックの発生元に基づいて受信リクエストを異なるサービス インスタンスに配信します。この機能は、Google Cloud の外部からのトラフィック、または Google Cloud 内で発生して内部パススルー ネットワーク ロードバランサに向かうトラフィックに使用できます。Cloud DNS は、クエリが Google Cloud に入るリージョンをソース地域として使用します。

位置情報に基づくルーティング ポリシーは、パブリック DNS と限定公開 DNS で次の方法でソースを異なる方法でマッピングします。

  • 公開 DNS の場合: クエリの送信元 IP アドレスまたは DNS の拡張機能メカニズム（EDNS）クライアント サブネットを使用します。
  • 限定公開 DNS の場合、EDNS クライアント サブネットは使用されません。代わりに、クエリのロケーションは、クエリのパケットを送信するシステムのロケーションです。
    • VPC ネットワーク内のネットワーク インターフェースを持つ Compute Engine 仮想マシン（VM）インスタンスからのクエリの場合、クエリのロケーションは VM インスタンスを含むリージョンになります。
    • 受信サーバー ポリシー エントリ ポイントによって受信されたクエリの場合、クエリのロケーションは、クエリのパケットを受信した Cloud VPN トンネル、Cloud Interconnect VLAN アタッチメント、またはルーター アプライアンスのリージョンです。エントリポイントの IP アドレスのリージョンは関係ありません。詳細については、インバウンド クエリのネットワークとリージョンをご覧ください。

Cloud DNS は、内部ロードバランサと外部エンドポイントのルーティング ポリシー内でヘルスチェックとフェイルオーバーをサポートしています。 Cloud DNS は、エンドポイントがヘルスチェックに失敗した場合に自動フェイルオーバーを有効にします。位置情報に基づくルーティング ポリシーを使用すると、トラフィックはソース トラフィックに次に最も近い位置情報にフェイルオーバーします。

ジオフェンスを使用した位置情報に基づくルーティング ポリシー

ジオフェンスを使用すると、そのリージョン内のすべてのエンドポイントがヘルスチェックに失敗した場合でも、トラフィックが特定のリージョンに確実に転送されます。

ジオフェンスが無効になっていて、特定の位置情報でヘルスチェックが失敗した場合、トラフィックは次に最も近い位置情報に自動的にフェイルオーバーします。 ただし、ジオフェンスが有効になっている場合、この自動フェイルオーバーは行われません。 権威サーバーとして、Cloud DNS は値を返す必要があります。このシナリオでは、エンドポイントがヘルスチェックに失敗した場合に、Cloud DNS はすべての IP アドレスを変更せずに返します。

フェイルオーバー ルーティング ポリシー

フェイルオーバー ルーティング ポリシーを使用すると、アクティブ バックアップ構成を設定して、VPC ネットワーク内の内部リソースに高可用性を提供できます。

通常のオペレーションでは、Cloud DNS は常に active セットから IP アドレスを返します。active セット内のすべての IP アドレスが異常になった場合、Cloud DNS は backup セットの IP アドレスを提供します。backup セットを位置情報に基づくルーティング ポリシーとして構成すると、位置情報に基づくルーティング ポリシーのセクションで説明されているように動作します。内部ロードバランサに backup を設定すると、Cloud DNS ヘルスチェックはすべてのバックアップの仮想 IP（VIP）アドレスを確認します。

Cloud DNS では、バックアップ VIP アドレスへのトラフィックを段階的にトリクリングできます。これにより、バックアップ VIP アドレスが機能していることを確認できます。バックアップに送信されるトラフィックの割合は、0～1 の分数で構成できます。トラフィックの 100% をバックアップ VIP アドレスに送信することで、フェイルオーバーを手動でトリガーできます。通常の値は 0.1 です。ヘルスチェックは、内部ロードバランサと外部エンドポイントにのみ適用されます。

ヘルスチェック

Cloud DNS は、次の内部ロードバランサと外部エンドポイントのルーティング ポリシー内でのヘルスチェックとフェイルオーバーをサポートしています。

マネージド ゾーンでヘルスチェックを使用し、DNS Security Extensions（DNSSEC）が有効になっている場合、各ポリシー項目（WRR または位置情報）で使用できる IP アドレスは 1 つだけです。特定のポリシーで、ヘルスチェックされた IP アドレスとヘルスチェックされていない IP アドレスを混在させることはできません。

Cloud DNS レコードとヘルスチェックを構成する際に留意すべきベスト プラクティスについては、ベスト プラクティスをご覧ください。

内部ロードバランサのヘルスチェック

内部ロードバランサのヘルスチェックは、限定公開ゾーンでのみ使用できます。

内部アプリケーション ロードバランサと内部プロキシ ネットワーク ロードバランサの場合、Cloud DNS はルーティングの決定中にロードバランサ自体の健全性を考慮します。クエリを受信すると、ロードバランサは正常なバックエンド サービスにのみトラフィックを分散します。正常なバックエンドを確保するために、マネージド インスタンス グループ（MIG）などのサービスを使用してバックエンドのライフサイクルを管理できます。Cloud DNS では、個々のバックエンドのヘルス ステータスを認識する必要はありません。ロードバランサがこのタスクを処理します。

内部パススルー ネットワーク ロードバランサの場合、Cloud DNS はロードバランサの個々のバックエンド インスタンスの健全性情報を確認します。Cloud DNS はデフォルトの 20% のしきい値を適用します。20% 以上のバックエンド インスタンスが正常である場合、ロードバランサ エンドポイントは正常とみなされます。DNS ルーティング ポリシーは、このしきい値に基づいてエンドポイントに正常または異常のマークを付け、それに応じてトラフィックをルーティングします。

単一の内部パススルー ネットワーク ロードバランサの仮想 IP アドレス（VIP）は、複数のバックエンド インスタンスを持つことができます。内部パススルー ネットワーク ロードバランサにバックエンド インスタンスがない場合も、Cloud DNS は正常であるとみなします。ヘルスチェックが正常に機能するためには、ロードバランサの構成内で少なくとも 1 つのバックエンド インスタンスを指定します。

́エンドポイントが異常とマークされると、次の状態が発生する可能性があります。

  • ポリシーに対してプログラムされた複数の VIP アドレスがある場合は、正常な VIP アドレスのみが返されます。

  • ポリシー バケットに対してプログラムされたすべての VIP アドレスが異常な場合、そのポリシー行は失敗しています。次の動作が適用されます。

    • WRR ポリシーの場合、Cloud DNS はポリシーで定義された残りの正常なエンドポイントにトラフィックを比例的に分散します。
    • フェンシングが有効になっていない位置情報ポリシーの場合、トラフィックはポリシーで定義されているソース Google Cloud リージョンに次に最も近い地域のエンドポイントに切り替わります。
    • ジオフェンスが有効になっている位置情報ポリシーの場合、Cloud DNS は、ポリシーで定義された送信元 Google Cloud リージョンに最も近い VIP アドレスにトラフィックを分散します。
    • フェイルオーバー ポリシーの場合、Cloud DNS はポリシーで定義されたバックアップ エンドポイントにトラフィックを切り替えます。
    • すべてのポリシー バケットが異常な場合、Cloud DNS はすべてのエンドポイントが正常であるかのように動作します。 このシナリオでは、応答しないエンドポイントにトラフィックが分散される可能性があります。

内部ロードバランサのヘルスチェックの詳細については、ヘルスチェックの概要をご覧ください。

外部エンドポイントのヘルスチェック（プレビュー）

外部エンドポイントのヘルスチェックは、一般公開ゾーンでのみ使用できます。ヘルスチェックするエンドポイントには、パグリック インターネット経由でアクセスできる必要があります。指定するエンドポイントは、グローバル外部アプリケーション ロードバランサ VIP、リージョン外部アプリケーション ロードバランサ VIP、グローバル外部プロキシ ネットワーク ロードバランサ VIP、オンプレミス エンドポイント、またはパブリック インターネット経由でアクセス可能なその他のエンドポイントなど、任意の外部 IP アドレスとポートにできます。

次のようなシナリオでは、外部エンドポイントのヘルスチェックを使用します。

  • グローバル外部アプリケーション ロードバランサのバックエンドまたはグローバル外部プロキシ ネットワーク ロードバランサのバックエンドが異常になった場合に、トラフィックをリージョン外部アプリケーション ロードバランサに再ルーティングするため。
  • 特定のリージョン外部アプリケーション ロードバランサのバックエンドが異常になった場合に、トラフィックを別のリージョン外部アプリケーション ロードバランサに再ルーティングするため。
  • オンプレミス エンドポイントまたはパブリック インターネットで到達可能な他のエンドポイントの状態をモニタリングするため。

外部エンドポイントのヘルスチェックを使用する DNS ルーティング ポリシーを作成すると、Cloud DNS はヘルスチェック プローブをエンドポイントに送信します。このヘルスチェック プローブは、指定した 3 つの Google Cloud ソース リージョンから発信されます。各リージョンのヘルスチェック プローバーは独立して実行され、Cloud DNS は結果を集約してエンドポイントの全体的な状態を判断します。各リージョン内で、3 つのヘルスチェック プローバー インスタンスが各エンドポイントをプローブします。1 つのプローブが失敗した場合でも、Cloud DNS は残りのプローブを使用してエンドポイントの正常性を特定できます。つまり、各エンドポイントに合計 9 個のプローバーがあり、各プローブはヘルスチェックのチェック間隔で指定された頻度で実行されます。Cloud DNS は、ルーティング ポリシーのパラメータとヘルス情報に基づいてエンドポイントを選択し、選択したエンドポイントにトラフィックをルーティングします。

Cloud DNS は、TCP、HTTP、HTTPS プロトコルをサポートしています。ただし、次の点に注意してください。

  • TCP リクエスト フィールドはサポートされていません。
  • HTTP、HTTPS、TCP の proxyHeader フィールドはサポートされていません。

SSL、HTTP/2、gRPC プロトコルはサポートされていません。

TCP プロトコルの場合、Cloud DNS はエンドポイントへの接続を試みます。 HTTP プロトコルと HTTPS プロトコルの場合、Cloud DNS はエンドポイントが HTTP レスポンス コード 200 を返すことを確認します。また、コンテンツ ベースのヘルスチェックを構成することもできます。この場合、Cloud DNS はレスポンスに特定の文字列が含まれていることを確認します。

内部ロードバランサのヘルスチェックとは異なり、外部エンドポイントの Cloud DNS ヘルスチェックは固定 IP アドレス範囲から発信されません。プローブの送信元 IP アドレス範囲は、時間の経過とともに変更される場合があります。

ヘルスチェック プローブの作成時に指定するプロトコルとポートによって、ヘルスチェック プローブの実行方法が決まります。ポートを指定しない場合、Cloud DNS はポート 80 を使用します。ヘルスチェックが正しく機能するように、任意の送信元 IP アドレスとヘルスチェックで構成された特定のポートでヘルスチェック プローブを許可するようにファイアウォール ルールを構成します。

ヘルスチェック プローブを許可するようにファイアウォールを構成していない場合、プローブが失敗するため、Cloud DNS はブロックされたエンドポイントを異常とみなします。すべてのエンドポイントが異常として返された場合、Cloud DNS は異常なエンドポイントであっても、結果としてそれらをすべて提供します。

ヘルスチェック間隔

Cloud DNS は、ヘルスチェック間隔に従ってヘルスチェック プローブを定期的に送信します。たとえば、ヘルスチェック間隔が 30 秒の場合、Cloud DNS は 30 秒ごとに 1 回のヘルスチェック プローブを送信します。

Cloud DNS 外部エンドポイントのヘルスチェックの場合、ヘルスチェック間隔は 30～300 秒にする必要があります。

重み付きラウンドロビン ルーティング ポリシーとヘルスチェック

Cloud DNS は、0 ～ 1,000 の重み（両方を含む）をサポートします。ヘルスチェックを含めると、次のようになります。

  • 複数のターゲットをすべて重み 0 で構成すると、トラフィックはターゲット間で均等に分配されます。
  • ゼロ以外で重み付けされたターゲットを新しく構成すると、それがプライマリ ターゲットになり、すべてのトラフィックがそのターゲットにシフトします。
  • ゼロ以外で重み付けされたターゲットを追加すると、Cloud DNS は（リクエストごとに）ターゲット間でトラフィック分割を動的に計算し、トラフィックを適切に分配します。たとえば、重みを 0、25、75 で 3 つのターゲットを構成した場合、重みが 0 のターゲットはトラフィックを取得せず、重みが 25 のターゲットはトラフィックの 4 分の 1 を取得し、残りのターゲットは受信トラフィックの 4 分の 3 を取得します。
  • ゼロ以外の重み付けのターゲットにヘルスチェックが関連付けられていても、ゼロの重み付けのターゲットに関連付けられていない場合は、ゼロの重み付けのターゲットは常に正常とみなされます。ゼロ以外のレコードがすべて異常な場合は、Cloud DNS がゼロの重み付けのレコードを返します。
  • ヘルスチェックがゼロ以外の重み付けのレコードとゼロの重み付けレコードの両方に関連付けられている場合に、すべてのレコードがヘルスチェックに失敗すると、Cloud DNS はゼロ以外の重み付けのターゲットを返し、ゼロの重み付けのターゲットを無視します。
  • Cloud DNS がリクエスト元に返す重みバケット（単一のポリシー アイテム）を選択すると、その重みバケット内の IP アドレスのみが返されます。重みバケットに 1 つの IP アドレスのみを指定した場合、その IP アドレスのみが応答に含まれます。重みバケットに複数の IP アドレスがある場合、Cloud DNS はすべての IP アドレスをランダムな順序で返します。

位置情報に基づくルーティング ポリシーとヘルスチェック

ヘルスチェックを有効にした位置情報に基づくルーティング ポリシーの場合、次のようになります。

  • ポリシーに複数の IP アドレスが構成されていて、すべての IP アドレスがヘルスチェックされる場合は、正常な IP アドレスのみが返されます。
  • ヘルスチェックありとヘルスチェックなしの IP アドレスが混在して一致し、ヘルスチェックしたすべての IP アドレスが失敗すると、Cloud DNS はヘルスチェックが構成されていないすべての IP アドレスを返します。このシナリオでは、次に最も近い地域への自動フェイルオーバーは発生しません。

ヘルスチェックのロギング

Cloud DNS は、ヘルスチェックのロギングをサポートし、それらの IP アドレスを参照する DNS 名をクエリすると、ヘルスチェック対応の IP アドレスのヘルス ステータスをログに記録します。

ヘルスチェックのロギングでは、次のことができます。

  • ルーティング ポリシーが期待どおりに機能しているかどうかを検証します。次に例を示します。
    • 位置情報ポリシーの場合、ポリシーが正しい地域を検出し、正しいリソースレコード データセットを返しているかどうかを検証できます。
    • WRR ポリシーの場合、ポリシーが正しい重みで IP アドレスを返しているかどうかを検証できます。
  • 障害が発生している特定のバックエンドと IP アドレスに関するインフラストラクチャの問題を特定します。
  • 特定のバックエンドが含まれないか、それらだけが返される問題をトラブルシューティングします。

詳細については、ヘルスチェックのロギングに関する情報をご覧ください。

DNS ルーティング ポリシーでサポートされるレコードタイプ

DNS ルーティング ポリシーは、Cloud DNS でサポートされているレコードタイプをすべてサポートしているわけではありません。

サポートされているレコードタイプは次のとおりです。

レコードタイプ 説明
A 内部（プライベート ゾーン）と外部（一般公開ゾーン）のヘルスチェック用の IPv4 アドレス。
AAAA 外部（一般公開ゾーン）ヘルスチェック用の IPv6 アドレス。
CNAME 正規名。ヘルスチェックはサポートされていません。
MX メール エクスチェンジ レコード。ヘルスチェックはサポートされていません。
SRV ホスト / ポート（RFC 2782）。ヘルスチェックはサポートされていません。
TXT テキストデータ。ヘルスチェックはサポートされていません。

次のステップ