マルチ プロバイダ設定でパブリック DNS ネームサービスの堅牢性を向上
Google Cloud Japan Team
※この投稿は米国時間 2023 年 9 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。
DNS は、インターネットで配信するアプリケーションの基盤となるコンポーネントです。DNS が停止すると、サービスの停止を引き起こし、モニタリングや問題の修復に支障が出ることもあります。クラウド内のマルチテナント環境では、基盤となる DNS インフラストラクチャを共有する多くのプロバイダのサービスが影響を受けるため、この問題はさらに深刻です。最も一般的な単一プロバイダのデプロイは、設定と保守が容易ですが、そのことが単一障害点にもなります。信頼性を全体的に向上させるには、パブリック DNS のホスティングに 2 つの異なるプロバイダを利用する方法が有効です。
マルチ プロバイダ DNS を設定する方法の一つは、DNS プロトコル（RFC 5936）内でサポートされているゾーン転送機能を使用することです。しかし、この機能をサポートしているクラウド プロバイダはほとんどありません。もう 1 つの方法は、DNS の更新が両方のプロバイダに確実に反映されるようにすることです。これは通常、CI / CD パイプラインを調整することで、両方のプロバイダで同時に DNS レコードを作成および更新することで行います。複数のプロバイダの管理と保守は運用の負担が大きく、人為的なミスが起こりやすくなります。マルチプロバイダ設定があまり一般的ではない理由は、このことが一因でもあります。
もっとシンプルな方法はないでしょうか。単一のプロバイダを更新し続けるだけで、変更を自動的に取得し、別のプロバイダに反映できるオーバー ザ トップ ソリューションがあるとしたらどうでしょうか。このたびリリースされた Terraform スクリプトは、Cloud DNS をパブリック DNS ホスティングの 2 番目の権威 DNS サーバーとして簡単に使用できるようにするものです。このソリューションは、Terraform と OctoDNS を使用して構築された自動化を利用して、現在の DNS ゾーンをモニタリングし、変更を Cloud DNS 上でホストされているマネージド DNS ゾーンに反映します。スクリプトにより、Cloud DNS に新しいマネージド ゾーンが確実に作成され、個々の DNS レコードが更新されると、その更新が Cloud DNS の対応する DNS ゾーンに自動的に転送されます。既存の CI / CD パイプラインに変更を加える必要はありません。このソリューションはオープンソースで公開しているため、お客様のニーズや環境に合わせたカスタマイズが可能です。以下に、ニーズに応じて検討すべきアプローチを 2 つご紹介します。
アクティブ / アクティブ設定のデュアル プロバイダ
最初に説明するオプションは、2 つのプロバイダをアクティブ / アクティブ設定で使用する方法です。どちらのプロバイダもプライマリであるため、両方のプロバイダの適切な DNS ネームサーバーをドメインの担当ネームサーバーとして構成する必要があります。これには、登録事業者と協力して、親ドメインのレジストリで更新された「NS レコード」を公開することや、ドメインの「ゾーン apex」で一致する NS レコードを公開することが含まれる場合があります。これにより、どちらかのプロバイダがダウンした場合に、リゾルバはもう一方の利用可能なプロバイダのネームサーバーにフォールバックできます。サービスの停止がすぐに復旧できない場合は、NS レコードを更新し、問題が解決されるまで、影響を受けたプロバイダのネームサーバーのリストを除外できます。リゾルバは通常、使用するネームサーバーのヘルス ステータスを追跡しており、ネームサーバーの部分的なダウンタイムは通常、サービスに影響を与えません。
長所
- 単一障害点がない - 両方のプロバイダが同時に停止する可能性が非常に低い
- フェイルオーバーが透過的かつ自動的に行われる
短所
- プライマリとセカンダリ間の同期が必要なため、単一プロバイダのデプロイよりも複雑
- 同じサービスが 2 つの異なるプロバイダから提供されるため、費用が高くなる可能性がある
アクティブ / パッシブ設定のデュアル プロバイダ
次に説明するオプションは、2 つのプロバイダをアクティブ / パッシブ構成で使用する方法です。一方のプロバイダをプライマリ、別のプロバイダをセカンダリとして指定できます。ドメイン登録事業者に提供する「NS レコード」にプライマリ ベンダーのネームサーバーのみをリストすることで、デフォルトですべての DNS リクエストがプライマリに送信されます。
バックグラウンドでは、すべての DNS ゾーンの更新がプライマリとセカンダリの両方のプロバイダに送信されます。クラウド プロバイダを 2 つ選択すると、API サポートによってこの作業が簡単になります。両方の API を連続して呼び出して、プライマリ ゾーンとセカンダリ ゾーンが同期していることを確認できます。また、OctoDNS などのオープンソースのツールを利用してプロバイダの同期を保つこともできます。
アクティブ / パッシブ設定では、障害を検知してセカンダリ DNS サービスに切り替えるトリガーを設定する必要があります。トリガーが単一障害点となる可能性があるため、トリガーの設計とデプロイは慎重に行う必要があります。親（TLD）ドメインの中には NS TTL が長いものがあるため、アクティブ / パッシブ モードでは、パブリック サフィックスで登録されたドメインの復旧に時間がかかる場合があることに注意してください。
長所
- 単一プロバイダ システムよりも信頼性が高いため、両方のプロバイダが同時に停止する可能性が低い
- セカンダリはゾーン情報を保存するだけであり、セカンダリ モードである限りクエリ トラフィックを処理しないため、費用を抑えられる可能性がある
短所
- プライマリとセカンダリ間の同期が必要なため、単一プロバイダのデプロイよりも複雑
- セカンダリ プロバイダがプライマリに切り替わるまでの間と、その後にリゾルバのキャッシュが追いつくまでの間、ダウンタイムが発生する
- プライマリとセカンダリのサービスを切り替えるトリガー メカニズムが必要なため、SPOF になる可能性がある
Cloud DNS を 2 番目の権威プロバイダとして使用する
Google Cloud は、アクティブ / アクティブ構成が、障害によるダウンタイムを最小限に抑える最良のメカニズムであると考えており、Cloud DNS を 2 番目の権威プロバイダとして使用するお客様を支援するために、自動化作業の大部分を実行する Terraform スクリプトをリリースしました。
このソリューションは、お客様のニーズに応じて、1 回限りのデータ転送、または、Cloud DNS への DNS レコードの定期的な転送を支援します。この際の注意点は、プロバイダ固有の DNS レコード（カスタム apex CNAME レコードなど）は Cloud DNS では機能しないということです。また、マルチプロバイダ ゾーンの DNSSEC もサポートされません。現在は、Amazon Route 53 および Azure DNS から Cloud DNS への移行をサポートしています。また、このソリューションを他の API 対応プロバイダに拡張することも容易です。
これらのスクリプトのオープンソース版は、Google Cloud の GitHub リポジトリから入手できます。
-Cloud DNS プロダクト マネージャー Karthik Balakrishnan
