プライベート ゾーンAzure DNS、Azure仮想ネットワーク内で安全な名前解決を提供します。 プライベート DNS ゾーンのスコープを 1 つ以上の仮想ネットワークに設定できます。組織は通常、内部アプリケーションに使用します。 解決するホスト名は、インターネット経由でパブリックにアクセスできないローカル DNS 名です。 解決された IP アドレスは、多くの場合、インターネットからアクセスできないプライベート IP アドレスです。 Azure DNSは、特定の可用性ゾーンまたは単一リージョンにバインドされていないグローバル サービスです。
Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害やリージョン全体の障害など、さまざまな潜在的な障害や問題に対して、Azure DNSプライベート ゾーンに回復性を持たせる方法について説明します。 また、Azure DNS プライベート ゾーンのサービス レベル アグリーメント (SLA) に関する重要な情報も提供します。
信頼性のための運用環境のデプロイに関する推奨事項
運用環境のワークロードの場合は、次の推奨事項に従うことをお勧めします。
適切な TTL 値を構成します。 パフォーマンスと復旧時間のバランスを取る Time to Live (TTL) 値を設定します。 TTL 値を小さくすると、フェールオーバーが高速化されますが、クエリの量が増えます。 運用環境のワークロードの開始点として、300 秒 (5 分) を検討してください。
大きな DNS ゾーンのシャード: 大きな DNS ゾーンがある場合は、ゾーン のシャーディングを 検討して、全体的な信頼性と運用効率を向上させます。
信頼性アーキテクチャの概要
このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。
論理アーキテクチャ
デプロイするプライマリ リソースは ゾーンであり、ホスト名 (ドメイン名) を IP アドレスにマップする DNS レコードのセットを表します。 ゾーンが解決するホスト名は、通常、インターネット経由でパブリックにアクセスできないローカル DNS 名です。
プライベート DNS ゾーンをスタンドアロン リソースとして作成し、仮想ネットワーク リンクを作成して特定の 仮想ネットワークにリンクします。 これらの仮想ネットワーク内のクライアントから DNS 要求が送信されると、プライベート DNS ゾーンが解決プロセスに参加します。 DNS ゾーンにエントリを手動で作成したり、仮想ネットワーク リンク上の VM の自動登録を構成したりできます。 Azure DNSプライベート ゾーンでは、仮想ネットワークを明示的にピアリングしなくても、Azure リージョン間の仮想ネットワーク間の DNS 解決がサポートされます。 ただし、すべての仮想ネットワークが、プライベート DNS ゾーンにリンクされている必要があります。
DNS 名前解決プロセス には、権限のある DNS サーバーに到達する前に要求を処理する DNS リゾルバーや中間層など、複数のコンポーネントが含まれます。 プライベート ゾーンでは、TTL 値やキャッシュ メカニズムなど、パブリック ゾーンと同じ DNS プロトコルと動作が使用されます。
Important
ソリューション全体の信頼性は、仮想マシンやロード バランサーなど、DNS レコードが参照するリソースの構成によって異なります。
この記事では、これらのリソースについては説明しませんが、可用性の構成はアプリケーションの回復性に直接影響します。 ソリューション内の Azure サービスの信頼性ガイド を確認して、各サービスが信頼性要件をどのようにサポートしているかを確認します。
物理アーキテクチャ
Azure DNSは、非地域的なサービスです。 Microsoftは、世界中の複数のAzure リージョンにある複数の可用性ゾーンにインフラストラクチャをデプロイします。 この設計により、別のゾーンまたはリージョン内のインフラストラクチャが引き続き解決要求に応答するため、可用性ゾーンまたはリージョンの停止中にAzure DNSの回復性を維持できます。
Anycast、DNS、Border Gateway Protocol (BGP) などのグローバル インターネット プロトコルは、受信 DNS 解決要求を最も近い正常なAzure DNS インフラストラクチャに自動的にルーティングします。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、一時的なエラーへの対処に関するレコメンデーションを参照してください。
Azure DNSは、グローバル DNS インフラストラクチャを介して一時的な障害を処理します。
DNS 解決中に一時的な障害が発生した場合、クライアントまたは中間リゾルバーは要求を再試行する必要があります。 タイムアウト値を適切に構成します。 通常、DNS クライアントには 2 ~ 5 秒のタイムアウトで十分です。
各 DNS レコードの Time to Live (TTL) は、ソリューションが障害を処理する方法にも影響します。 TTL が非常に低い場合、クライアントはAzure DNSに対してより多くの要求を行います。これにより、一時的な障害の機会が増えます。 TTL が非常に高い場合、バックエンド サーバーで別の IP アドレスにリダイレクトする必要がある真の障害が発生した場合、TTL の有効期限が切れるまで、クライアントのフェールオーバーの遅延が発生する可能性があります。 可用性、待機時間、応答性のバランスを取るために、TTL を慎重に構成します。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
Azure DNSは、非リージョン サービスとして動作します。 Microsoftは、そのインフラストラクチャを複数のAzure リージョン内の複数の可用性ゾーンに分散し、そのインフラストラクチャ全体でプライベート DNS ゾーンに変更をレプリケートします。 可用性ゾーンを選択したり、ゾーンの冗長性を構成したりすることはありません。 可用性ゾーンの停止中、別のゾーンまたはリージョンのインフラストラクチャは引き続き解決要求に応答します。
仮想マシン (VM) などの単一の可用性ゾーンにデプロイしたリソースがゾーン障害時に使用できなくなった場合、Azure DNSはエンドポイントの正常性を監視しないため、リソースの構成済み IP アドレスを返し続けます。 正常なゾーン内のリソースにフェールオーバーする場合は、クライアントが正常なリソースを使用するように DNS レコードを更新する必要があります。 または、正常なゾーン内の VM にトラフィックを送信するゾーン冗長ロード バランサーの背後にリソースを配置します。
リージョン全体の障害に対する回復性
Azure DNSプライベート ゾーンは、ゾーン データがグローバルに利用できるため、リージョンの停止に対する回復性があります。 リージョンで障害が発生した場合、その仮想ネットワークと VM などのリソースは使用できない可能性がありますが、名前解決は引き続き機能します。
次の例は、複数のリージョン間でプライベート ゾーン データを引き続き使用できるようにする方法を示しています。 プライベート ゾーン azure.contoso.com は、リージョン A、リージョン B、リージョン C の 3 つのリージョンの仮想ネットワークにリンクされます。リージョン A と B では自動登録が有効になっています。この図は、障害が発生しているリージョン A を示しています。
リージョン A で一時的な停止が発生したとします。リージョン B と C の VM は、リージョン A から自動登録された名前を含め、プライベート ゾーン内の DNS 名を照会できます。VM1 が使用できない場合でも、リージョン A の VM1 の IP アドレスを引き続き解決できます。 リージョン A でのサービスの中断は、他のリージョンの名前解決には影響しません。
前の例では、ソリューションが別のリージョンの VM1 の代替にフェールオーバーするディザスター リカバリー シナリオは示されていません。 ただし、プライベート ゾーンはグローバルであるため、別のリージョンの仮想ネットワークに VM1 を再作成してワークロードを引き継ぐことができます。
複数のリージョンにまたがって仮想ネットワークとネットワーク リソースを作成する場合は、リージョン間フェールオーバーを必要とするアプリケーションのマルチリージョン戦略を計画して実装する必要があります。
セキュリティの脅威と構成の誤りに対する回復性
セキュリティ攻撃と構成エラーは、DNS ゾーンの最も重要な信頼性リスクの 2 つあります。 いくつかの種類の攻撃は特に DNS 解決を対象としており、誤った構成を行うと、ワークロードが深刻に中断される可能性があります。
プライベート DNS ゾーンに固有の包括的なセキュリティ ガイダンスについては、「 プライベート DNS ゾーンとレコードの保護」を参照してください。
サービスの停止に対する回復性
Azure DNSは回復性の高いサービスであり、アプリケーションが特定の条件を満たしている場合、100% 可用性 SLA が提供されます。 サービスの停止は非常に異常ですが、ネットワークやその他のインフラストラクチャの問題により、Azure DNS サービスへの接続が中断される可能性があります。
サービスの停止を監視する
Microsoft は、リージョンで障害が発生しても、自動的に通知することはありません。 ただし、 Azure Service Health を使用して、リージョンの障害を含むサービスの全体的な正常性を把握し、 Service Health アラート を設定して問題を通知することができます。
サービスの停止をテストする
Azure Chaos Studioは、DNS 解決に関する問題をシミュレートするための一連の障害を提供します。 たとえば、Chaos Studio エージェントは DNS エラーの種類を提供し、Chaos Mesh Azure Kubernetes Service (AKS)は DNS Chaos 機能を提供します。 これらの障害の種類を使用して、DNS 解決要求が失敗したときにアプリケーションとインフラストラクチャが応答する方法をテストできます。これは、部分的なネットワーク障害時に発生する可能性があります。
ポータルと管理ツールの停止に対する回復性
Azure ポータルで DNS ゾーンを管理する場合は、特にプラットフォームの停止中に DNS ゾーンを再構成する必要がある場合に、アクセスできないシナリオに備えます。
さまざまなツールを使用して、Azure DNSプライベート ゾーンをデプロイおよび管理できます。 Azure CLIまたはAzure PowerShellを使用してプライベート ゾーンを管理する方法について説明します。 または、Bicepや Terraform などのコードとしてのインフラストラクチャ (IaC) を使用して、プライベート ゾーンをデプロイして構成します。 Azure ポータルが機能低下した場合でも、これらのツールは引き続き動作します。
バックアップと復元
Azure DNSはステートレス サービスです。 プライベート DNS ゾーンのマネージド バックアップやポイントインタイム リストアは提供されません。
Azureリソースの完全な構成を保持するには、Bicepや Terraform などの IaC を使用してプライベート DNS ゾーンを定義し、その定義をソース管理に格納します。 定義を定期的にテストして、それらを使用して構成を再デプロイできるようにします。
サービス メンテナンスに対する回復性
Microsoft は定期的にサービス更新プログラムを適用し、その他のメンテナンスを実行します。 Azure プラットフォームは、これらのアクティビティを自動的に処理し、メンテナンスがシームレスで透過的であることを保証します。 Azure Service Health の計画メンテナンスを通じて通知されていない限り、メンテナンス イベント中にダウンタイムは想定されていません。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。
Azure DNSでは、特定の条件を満たす場合に有効な DNS クエリ応答に対して 100% 可用性 SLA が提供されます。 これらの条件には、少なくとも 60 秒間連続して失敗した要求の再試行が含まれます。 詳細な条件については、SLA ドキュメントを確認してください。