プライベートゾーンまたはパブリックゾーンのリソース レコードセットに対する 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 は、内部ロードバランサと外部エンドポイントのルーティング ポリシー内でヘルスチェックとフェイルオーバーをサポートしています。エンドポイントのヘルスチェックに失敗すると、自動的にフェイルオーバーが有効になります。フェイルオーバー中は、残りの正常なエンドポイントの間でトラフィックが分割されるように自動的に調整されます。詳細については、ヘルスチェックをご覧ください。
位置情報に基づくルーティング ポリシー
位置情報に基づくルーティング ポリシーでは、特定の送信元地域（Google Cloud リージョン）からのトラフィックを特定の DNS ターゲットにマッピングできます。このポリシーを使用して、トラフィックの発生元に基づいて受信リクエストを異なるサービス インスタンスに配信します。この機能は、Google Cloud の外部からのトラフィック、または Google Cloud の内部で発生して内部パススルー ネットワーク ロードバランサにバインドされたトラフィックに使用できます。クエリが 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 はすべての IP アドレスをそのまま返します。
フェイルオーバー ルーティング ポリシー
フェイルオーバー ルーティング ポリシーを使用すると、アクティブ バックアップ構成を設定して、VPC ネットワーク内の内部リソースに高可用性を提供できます。
通常のオペレーションでは、Cloud DNS は常に active セットの IP アドレスを返します。active セット内のすべての IP アドレスが異常になった場合は、backup セットの IP アドレスを提供します。 backup セットを位置情報に基づくルーティング ポリシーとして構成すると、このセットは位置情報に基づくルーティング ポリシーのセクションで説明されているように動作します。内部ロードバランサ用の backup セットを構成した場合は、すべてのバックアップ仮想 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 はロードバランサの個々のバックエンド インスタンスのヘルス情報をチェックします。デフォルトで適用されるしきい値は 20% です。20% 以上のバックエンド インスタンスが正常である場合、そのロードバランサ エンドポイントは正常とみなされます。DNS ルーティング ポリシーは、このしきい値に基づいてエンドポイントに正常または異常のマークを付け、それに応じてトラフィックをルーティングします。
内部パススルー ネットワーク ロードバランサの 1 つの仮想 IP アドレス（VIP）に複数のバックエンド インスタンスを設定できます。内部パススルー ネットワーク ロードバランサにバックエンド インスタンスが 1 つもない場合でも、Cloud DNS はこれを正常とみなします。ヘルスチェックを適切に機能させるには、ロードバランサの構成内で少なくとも 1 つのバックエンド インスタンスを指定します。
エンドポイントが異常とマークされると、次の状況が起こる可能性があります。
- 特定のポリシーに対して複数の VIP アドレスがプログラムされている場合は、正常な VIP アドレスのみが返されます。
ポリシー バケットに対してプログラムされたすべての VIP アドレスが異常な場合、そのポリシー行は失敗しています。次の動作が適用されます。
- WRR ポリシーの場合は、ポリシーで定義された残りの正常なエンドポイントにトラフィックが比例的に分散されます。
- ジオフェンスが有効になっていない位置情報ポリシーの場合は、ポリシーで定義された送信元 Google Cloud リージョンに次に最も近い地域のエンドポイントにトラフィックが切り替えられます。
- ジオフェンスが有効になっている位置情報ポリシーの場合は、ポリシーで定義された Google Cloud 送信元リージョンに最も近い VIP アドレスにトラフィックが分散されます。
- フェイルオーバー ポリシーの場合は、ポリシーで定義されたバックアップ エンドポイントにトラフィックが切り替えられます。
- すべてのポリシー バケットが異常な場合、Cloud DNS はすべてのエンドポイントが正常であるかのように動作します。このシナリオでは、応答しないエンドポイントにトラフィックが分散される可能性があります。
内部ロードバランサのヘルスチェックの詳細については、ヘルスチェックの概要をご覧ください。
外部エンドポイントのヘルスチェック
外部エンドポイントのヘルスチェックは、パブリック ゾーンでのみ使用できます。ヘルスチェックするエンドポイントには、パブリック インターネット経由でアクセスできる必要があります。任意の外部 IP アドレスとポートをエンドポイントにすることができます。たとえば、グローバル外部アプリケーション ロードバランサ VIP、リージョン外部アプリケーション ロードバランサ VIP、グローバル外部プロキシ ネットワーク ロードバランサ VIP、オンプレミス エンドポイント、パブリック インターネット経由でアクセス可能なその他のエンドポイントなどがこれに該当します。
外部エンドポイントのヘルスチェックは、次のようなシナリオで使用します。
- グローバル外部アプリケーション ロードバランサのバックエンドまたはグローバル外部プロキシ ネットワーク ロードバランサのバックエンドが異常になった場合に、トラフィックをリージョン外部アプリケーション ロードバランサに再ルーティングするため。
- 特定のリージョン外部アプリケーション ロードバランサのバックエンドが異常になった場合に、トラフィックを別のリージョン外部アプリケーション ロードバランサに再ルーティングするため。
- オンプレミス エンドポイントの状態またはパブリック インターネット経由で到達可能なその他のエンドポイントの状態をモニタリングするため。
外部エンドポイントのヘルスチェックを含む DNS ルーティング ポリシーを作成すると、エンドポイントにヘルスチェック プローブが送信されます。このヘルスチェック プローブは、指定した 3 つの Google Cloud ソース リージョンから発信されます。各リージョンのヘルスチェック プローバーは独立して動作し、Cloud DNS はそれらの結果を総合してエンドポイントの全体的な状態を判断します。各リージョン内で、3 つのヘルスチェック プローバー インスタンスが各エンドポイントをプローブします。1 つのプローブで障害が発生しても、残りのプローブを使用してエンドポイントの状態を判断できます。つまり、エンドポイントごとに計 9 個のプローバーがあり、各プローブはヘルスチェックのチェック間隔で指定された頻度で実行されます。Cloud DNS は、ルーティング ポリシーのパラメータとヘルス情報に基づいてエンドポイントを選択し、選択したエンドポイントにトラフィックをルーティングします。
Cloud DNS は、TCP、HTTP、HTTPS プロトコルをサポートしています。ただし、次の点に注意してください。
- TCP リクエスト フィールドはサポートされていません。
- HTTP、HTTPS、TCP の
proxyHeaderフィールドはサポートされていません。
SSL、HTTP/2、gRPC プロトコルはサポートされていません。
TCP プロトコルの場合、Cloud DNS はエンドポイントへの接続を試みます。HTTP プロトコルと HTTPS プロトコルの場合は、エンドポイントが HTTP レスポンス コード 200 を返すことを確認します。コンテンツ ベースのヘルスチェックを構成することもできます。この場合は、レスポンスに特定の文字列が含まれていることが確認されます。
内部ロードバランサのヘルスチェックとは異なり、Cloud DNS による外部エンドポイントのヘルスチェックは、固定の IP アドレス範囲から発信されません。プローブの送信元 IP アドレス範囲は、時間の経過とともに変わる場合があります。
ヘルスチェックの作成時に指定したプロトコルとポートによって、ヘルスチェック プローブの実行方法が決まります。ポートを指定しない場合は、ポート 80 が使用されます。ヘルスチェックを適切に機能させるため、任意の送信元 IP アドレスからヘルスチェックで構成された特定のポートで送信されたヘルスチェック プローブを許可するようにファイアウォール ルールを構成します。
ヘルスチェック プローブを許可するようにファイアウォールが構成されていない場合、プローブは失敗し、ブロックされたエンドポイントは異常とみなされます。すべてのエンドポイントが異常と返された場合でも、Cloud DNS はそれらすべてを（異常であるにもかかわらず）単一の結果として提供します。
ヘルスチェック間隔
Cloud DNS は、ヘルスチェック間隔に従ってヘルスチェック プローブを定期的に送信します。たとえば、ヘルスチェック間隔が 30 秒の場合は、30 秒ごとに 1 つのヘルスチェック プローブが送信されます。
Cloud DNS の外部エンドポイントのヘルスチェックでは、ヘルスチェック間隔を 30～300 秒にする必要があります。
重み付きラウンドロビン ルーティング ポリシーとヘルスチェック
Cloud DNS は、0～1,000 の重み（両端を含む）をサポートします。ヘルスチェックを含めると、次のようになります。
- 複数のターゲットをすべて重み 0 で構成すると、トラフィックはターゲット間で均等に分配されます。
- 重みがゼロでないターゲットを新しく構成すると、それがプライマリ ターゲットになり、すべてのトラフィックがそのターゲットにシフトします。
- 重みがゼロでないターゲットをさらに追加すると、（リクエストごとに）ターゲット間でトラフィック分割が動的に計算され、それに応じてトラフィックが分配されます。たとえば、3 つのターゲットを構成してそれぞれの重みを 0、25、75 にした場合、重み 0 のターゲットにはトラフィックは分配されず、重み 25 のターゲットにはトラフィックの 4 分の 1、残りのターゲットにはトラフィックの 4 分の 3 が分配されます。
- ゼロ以外の重み付けのターゲットにヘルスチェックが関連付けられていても、ゼロの重み付けのターゲットに関連付けられていない場合は、ゼロの重み付けのターゲットは常に正常とみなされます。重みがゼロでないレコードがすべて異常な場合は、重みゼロのレコードが返されます。
- ヘルスチェックが重みゼロでないレコードと重みゼロのレコードの両方に関連付けられている場合に、すべてのレコードがヘルスチェックに失敗すると、重みがゼロでないターゲットが返され、重みゼロのターゲットは無視されます。
- リクエスト元に返す重みバケット（単一のポリシー項目）が選択されると、その重みバケット内の IP アドレスのみが返されます。重みバケットに 1 つの IP アドレスのみを指定した場合、その IP アドレスのみが応答に含まれます。重みバケットに複数の IP アドレスがある場合は、すべての IP アドレスがランダムな順序で返されます。
位置情報に基づくルーティング ポリシーとヘルスチェック
位置情報ポリシーでヘルスチェックを有効にすると、次のようになります。
- ポリシーに複数の IP アドレスが構成されていて、すべての IP アドレスがヘルスチェックされる場合は、正常な IP アドレスのみが返されます。
- ヘルスチェック対象の IP アドレスとヘルスチェック対象外の IP アドレスが混在して一致し、ヘルスチェック対象の IP アドレスがすべて失敗した場合は、ヘルスチェックが構成されていないすべての IP アドレスが返されます。このシナリオでは、次に最も近い地域への自動フェイルオーバーは発生しません。
ヘルスチェックのロギング
Cloud DNS はヘルスチェックのロギングをサポートしており、ヘルスチェックが有効な IP アドレスを参照する DNS 名をクエリすると、その IP アドレスのヘルス ステータスがログに記録されます。
ヘルスチェックのロギングを使用すると、次のことができます。
- ルーティング ポリシーが期待どおりに機能しているかどうかを検証する。次に例を示します。
- 位置情報ポリシーの場合、そのポリシーによって正しい地域が検出され、正しいリソース レコード データセットが返されているかどうかを検証できます。
- WRR ポリシーの場合、正しい重みで IP アドレスが返されているかどうかを検証できます。
- 障害が発生している特定のバックエンドと IP アドレスに関するインフラストラクチャの問題を特定する。
- 特定のバックエンドが含まれない問題、または特定のバックエンドだけが返される問題をトラブルシューティングする。
詳細については、ヘルスチェックのロギング情報をご覧ください。
DNS ルーティング ポリシーでサポートされているレコードタイプ
DNS ルーティング ポリシーは、Cloud DNS でサポートされているレコードタイプをすべてサポートしているわけではありません。
次のレコードタイプがサポートされています。
| レコードタイプ | 説明 |
|---|---|
| A | 内部（プライベート ゾーン） と外部（パブリック ゾーン） のヘルスチェック用の IPv4 アドレス。 |
| AAAA | 外部（パブリック ゾーン）のヘルスチェック用の IPv6 アドレス。 |
| CNAME | 正規名。ヘルスチェックはサポートされていません。 |
| MX | Mail Exchange レコード。ヘルスチェックはサポートされていません。 |
| SRV | ホスト / ポート（RFC 2782）。ヘルスチェックはサポートされていません。 |
| TXT | テキストデータ。ヘルスチェックはサポートされていません。 |