高可用性の DNS: ハイブリッド クラウド環境における高可用性を実現

※この投稿は米国時間 2020 年 11 月 14 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud のお客様は、特に複数のオンプレミス ロケーションに接続する複数の VPC がある場合に、DNS 転送について多面的な要件を持っています。以前のブログ投稿でもご紹介したとおり、ハブアンドスポーク型を利用して、Google の DNS プロキシ範囲を使用することによるリバース ルーティングの課題に対処することをおすすめしています。

ただし、一部の構成ではこのアプローチによってハブ ネットワーク内に単一障害点（SPOF）がもたらされることがあり、デプロイ内に接続性の問題があれば、すべての VPC ネットワークで停止が発生する可能性があります。この投稿では、Cloud DNS を常時利用できるようにして DNS リクエストを処理するための冗長性メカニズムをいくつかご紹介します。

ハブアンドスポーク型における冗長性の実現

ハブアンドスポーク型で冗長性を持たせる必要がある場合は、DNS 転送を行う VPC ネットワークで複数の Google Cloud リージョンをカバーし、オンプレミス ネットワークに対して各リージョンに（相互接続または他の手段を介して）個別のパスを設定するモデルを検討します。以下の画像では、VPC Network H が us-west1 と us-east1 をカバーし、各リージョンにはお客様のオンプレミス ネットワークに対する専用の相互接続があります。他の VPC ネットワークはハブ ネットワークとピアリングされます。

このシナリオでは高可用性の DNS 機能が提供され、VCP ではどちらの相互接続パスからもクエリを送信でき、戻りのクエリはいずれかの相互接続パスを介して戻ることができます。送信リクエストのパスは、常にリクエスト元に最も近い相互接続を介して Google Cloud から送信されます（障害が発生した場合を除きます。その場合は別の相互接続パスを使用します）。

Cloud DNS では、常にリージョンに最も近い相互接続を介してオンプレミスにリクエストがルーティングされますが、オンプレミス ネットワークから Google Cloud への応答は WAN ルーティングに依存します。等コスト ルーティングが行われている場合、返される応答に非対称のルーティング動作が見られることがあります。この場合、行きとは異なるパスを通ることで、解決のレイテンシが高くなる可能性があります。

代替の DNS 構成

しかし、高可用性のハブアンドスポーク型を使えない企業もあります。

一部の組織では、複数のロケーションに分散したアドレス ブロックが IP アドレス空間に混在しています。多くの場合、企業の合併や買収によってこのような状況になり、位置に基づいたクリーンな DNS を設定するのが難しくなります。ここからは、異なる DNS 構成を示し、お客様がどのようにして DNS スタックの障害に対応する必要があるかについて説明します。

問題を理解するために、Google Cloud のあるお客様の例を考えてみましょう。このお客様は、DNS クエリのレイテンシを短縮するために、東海岸の VPC 用に米国東海岸の DNS リゾルバを運用し、西海岸の VPC 用に米国西海岸のリゾルバを運用していました。問題は、冗長性を確保しようとしたときに発生しました。具体的には、このお客様は西海岸と東海岸のいずれかのリゾルバに障害が発生したときのバックアップとして 3 つ目のリゾルバを用意しようとしていました。

残念ながら、図 1.3 のような構成では障害シナリオで問題が発生する可能性があります。

この構成では、西海岸の DNS リゾルバの障害によって、米国中部で実行しているバックアップ サーバーにトラフィックが転送されます。これらの DNS リクエストのソース IP アドレスは Google Cloud の DNS プロキシ サーバー アドレス範囲（35.199.192.0/19）に対応しています。しかし、2 つの VPC があり、WAN には Google Cloud の DNS プロキシ サーバーのアドレス範囲に戻るための 2 つの異なるルートがあるため、通常であれば Google Cloud の DNS プロキシ IP 範囲をアドバタイズする最も近いリンクを介して戻りのリクエストがルーティングされます。このケースの場合は東海岸の相互接続です。そして、リクエスト元とは異なる VPC に東海岸の相互接続が接続されているため、応答は Google Cloud の DNS プロキシによってドロップされます（戻りパケットの仮想ネットワーク ID（VNID）が東海岸の VPC の VNID と異なるため）。この問題の原因は DNS レイヤーそのものではなく、ルーティングとサブネット アドバタイジングにあります。

ここで問題になるのが、複数の VPC と DNS リゾルバがあるネットワーク トポロジをサポートしながら、オンプレミスで高可用性の DNS リゾルバを実現するにはどうすればよいかという点です。

以下の図 1.4 で示しているように、DNS リクエストをプロキシするのも一つの手です。すべての DNS リクエストを VPC 内（または目的の粒度に応じて特定のサブネット内）のプロキシ構成に転送することで、VPC 固有の IP アドレスを使って、オンプレミス インフラストラクチャから適切な VPC に対して正確に応答を送信できるようになります。これにより、オンプレミスのファイアウォール構成も簡略化されます。Google の DNS プロキシ IP 範囲に対して開ける必要がないためです。DNS 転送用に複数の IP アドレスを指定できるため、複数のプロキシ VM を実行してプロキシの冗長性を高め、可用性をさらに引き上げることができます。

高可用性の DNS: 細部が肝心

どの企業にとっても DNS は重要な機能ですが、高可用性の DNS アーキテクチャを構築するのは簡単なことではありません。多くの障害シナリオに対応できる、冗長性の高い DNS スタックは簡単に構築できますが、なんらかの障害が発生して DNS クエリが解決できなくなるまで、基盤となるルーティングが見過ごされる傾向にあります。ハイブリッド環境用の DNS アーキテクチャを設計する際は、基盤となるインフラストラクチャを細かく確認し、障害シナリオが DNS クエリの解決に与える影響について検討する必要があります。

Google Cloud で高可用性アーキテクチャを設計する方法について詳しくは、スケーラブルで復元性の高いアプリのためのパターンをご覧ください。

-カスタマー エンジニア兼ネットワーキング スペシャリスト Ryan Przybyl

-プロダクト マネージャー Karthik Balakrishnan