この記事では、Azure プライベート DNS ゾーンをシャーディングして運用の回復性を向上させ、変更への影響を軽減し、大規模な Azure 環境をサポートするためのアーキテクチャ ガイダンスを提供します。 このガイダンスは、マルチチームまたはマルチサブスクリプション Azure テナントの DNS を設計するアーキテクトおよびプラットフォーム チームを対象としています。
プライベート DNS ゾーンシャーディングとは
プライベート DNS ゾーンをシャーディングすることは、所有権、環境、ライフサイクル、または目的に基づいて DNS 名前空間を意図的にパーティション分割することを意味します。 この方法では、多くのチームが共有する単一のフラット ゾーンに依存することを回避できます。
一元化されたプライベート DNS ゾーンは、早期導入時に簡単に見える場合があります。 ただし、環境の規模が大きいため、フラット ゾーンには、多くの場合、何千もの DNS レコードと仮想ネットワーク リンクが蓄積されます。 この成長により、定期的な DNS 変更の運用リスクが高くなり、所有権とガバナンスが困難になります。
シャーディングでは、DNS の変更のスコープが明確に定義されたワークロードと仮想ネットワークのセットに設定されるため、このリスクが軽減されます。 各ゾーンは所有権または運用上の境界を表し、関連のないサービス全体に対する意図しない影響を軽減します。
注
シャーディングはアーキテクチャ パターンです。 Azure には、シャーディングを有効にする組み込みの機能やトグルは用意されていません。
図 1: 所有権と環境別にセグメント化されたゾーンを持つシャード化された設計と比較して、多くの仮想ネットワークにリンクされているフラットプライベート DNS ゾーン
シャーディングによって運用の回復性が向上するしくみ
大規模な Azure テナントでは、プライベート DNS ゾーンは、多くの場合、複数のサブスクリプション、リージョン、アプリケーション チームにまたがっています。 1 つのゾーンを広く共有する場合:
DNS レコードの更新は、関係のないワークロードに誤って影響を与える可能性があります。
仮想ネットワーク リンクの変更は、複数の環境での名前解決に影響を与える可能性があります。
所有権が重複しているため、ロールバックがより複雑になります。
運用エラーは、依存システム間で迅速に伝達されます。
シャーディングでは、DNS 変更の爆発半径を減らすことで、運用の回復性が向上します。 レコードの更新または仮想ネットワーク リンクの変更が正しくない場合、影響はその特定のゾーンに関連付けられているワークロードに分離され、トラブルシューティングと回復が簡単になります。
Important
シャーディングにより、運用の回復性と変更の安全性が向上します。 Azure DNS サービスの基になる可用性や SLA は向上しません。
一般的なシャーディング戦略
すべての組織に適合するシャーディング戦略は 1 つもありません。 適切なアプローチは、テナントのサイズ、チーム構造、運用の成熟度によって異なります。
次の方法で DNS ゾーンをパーティション分割します。
チームまたは製品
環境 (開発、テスト、prod など)
リージョン (westus、eastus など)
サービスの種類またはワークロード クラス (データベースなど)
| シャーディング戦略 | ゾーン パターンの例 | メリット | トレードオフ | 最適なシナリオ |
|---|---|---|---|---|
| チーム別 | orders.contoso.internal |
所有権のクリア、RBAC のシンプルさ | チーム間の解決には計画が必要 | 独立したチームを持つ大規模な組織 |
| 環境別 | orders.prod.contoso.internal |
強力な分離、安全なデプロイ | 環境間でのゾーンの重複 | 規制対象または CI/CD 負荷の高いワークロード |
| リージョン別 | orders.eastus.contoso.internal |
リージョン内障害の隔離 | より複雑な名前付けとルーティング | 地理的分散アプリケーション |
| サービスの種類別 | db.contoso.internal |
関数による論理グループ化 | 集中化のリスク | 共有プラットフォーム サービス |
表 1: 一般的なシャーディング戦略の名前空間パターンとトレードオフの例
実装に関する注意事項
- 戦略を組み合わせることができます (たとえば、チーム + 環境別:
orders.prod.contoso.internal) - シャード化された各ゾーンには、分離の利点を維持するための専用の RBAC ポリシーが必要です
- Azure Policy を使用して名前付け規則を適用し、過剰なリンクを防ぐ
設計ガイダンス
シャーディングを意図的に適用します。 有効期間の短いワークロードのゾーンを過剰にシャーディングまたは作成すると、意味のある利点なしに不要な運用オーバーヘッドが発生する可能性があります。 目標は、時間の経過と同時にスケーリングできる明確な所有権の境界を確立することです。
名前解決に関する考慮事項
シャード化されたプライベート DNS ゾーンは、既定で分離されます。 仮想ネットワークは、明示的にリンクされているゾーン内でのみ名前を解決します。
シャード化されたゾーン同士は、自動的に解決されることはありません。
多くの仮想ネットワークを多数のゾーンにリンクすると、広い爆発半径が再導入される可能性があります。
ゾーン間の解決には、明示的な設計上の決定が必要です。
大規模な環境では、一般的に Azure DNS プライベート リゾルバーを使用して一元化された名前解決を実装し、仮想ネットワークを広くリンクすることなくシャード ゾーン間で一貫した解決を有効にします。
プライベート DNS ゾーンシャーディングの実装
シャーディングでは、新しい Azure 機能は必要ありません。 既存のプライベート DNS 機能とアーキテクチャ規範を使用して実装します。 シャーディングでは、1 つのゾーンを分割するのではなく、それぞれ独自の制限を持つ複数のプライベート DNS ゾーンが作成されます。
高度な実装手順
所有権と名前空間の境界を定義する
チーム、環境、リージョン、またはサービスごとにゾーンをパーティション分割する方法を決定します。
一貫性のある名前付け規則を確立します。
複数のプライベート DNS ゾーンを作成する
各ゾーンは、
orders.prod.contoso.internalなどのシャードを表します。ゾーンを個別のサブスクリプションまたはリソース グループにデプロイします。
仮想ネットワークを選択的にリンクする
各ゾーンを、解決が必要な仮想ネットワークにのみリンクします。
広範なリンク パターンや既定のリンク パターンは避けてください。
RBAC とポリシーを適用する
アプリケーション チームに自分が所有するゾーンにのみアクセス許可を付与します。
監査とガバナンスのために中央プラットフォーム アクセスを保持します。
(省略可能)Azure DNS プライベート リゾルバーをデプロイする
一元化されたリゾルバーを使用して、シャード 化されたゾーン間で名前解決を有効にします。
この方法は、ハブ アンド スポークアーキテクチャまたはハイブリッド アーキテクチャに推奨されます。
シャーディングを使用するタイミング
プライベート DNS ゾーンのシャーディングは、次の場合に最も重要です。
複数のチームが 1 つの Azure テナントを共有します。
DNS の変更は頻繁に行われるか、自動化されます。
変更ブラスト半径を減らすことが優先されます。
明確な所有権とガバナンスの境界が必要です。
小規模な環境または単一チームのデプロイでは、重大なリスクなしにフラットプライベート DNS ゾーンを引き続き使用できます。
ゾーン サイズと可観測性に関する考慮事項
Azure プライベート DNS では、ゾーンあたりのレコード セット数とレコード セットあたりのレコード数にサービス制限が適用されます。 ただし、運用の複雑さと回復性は、多くの場合、これらの制限に達する前に大幅に増加します。 現在の制限については、「 Azure プライベート DNS の制限」を参照してください。
プライベート DNS ゾーン (特にマルチチーム環境) が拡大するにつれて、ゾーン サイズが重要な運用シグナルになります。 大規模でフラットなゾーンでは、時間の経過と同時に数万件のレコードが蓄積されるため、ワークロードの管理が困難になり、変更の影響範囲が大きくなります。
シャーディングは、このリスクを軽減するのに役立ちますが、プラットフォーム チームは、ゾーンが運用上大きすぎることを検出するために、可観測性のしきい値も実装する必要があります。
レコード数のしきい値
大規模な運用を行うお客様は、多くの場合、制限に近づく前にアーキテクチャ レビューをトリガーする内部ガードレールを定義します。 その例は次のとおりです。
- ゾーンが内部レコード数のしきい値を超えたときにアラートを生成する
たとえば、数万から数十万のレコードのしきい値は、ゾーンが関連のないワークロードを集計しており、シャーディングの恩恵を受ける可能性があることを示しています。 適切なしきい値は、ワークロードの特性と運用の許容範囲によって異なります。
- 急速な成長傾向に関するアラート
レコード数の急激な増加は、自動化ループ、自動登録が正しく構成されていない、または予期しないワークロードの導入を示している可能性があります。
Azure Resource Graph や Azure Monitor などのツールを使用して、ゾーン サイズと増加傾向を監視できます。
ガバナンスとアクセス制御
シャード DNS ゾーンを使用すると、Azure ロールベースのアクセス制御 (RBAC) によるより正確なアクセス制御が可能になります。 アプリケーション チームには自分が所有するゾーンにのみアクセス許可を付与できますが、中央プラットフォーム チームはより広範な名前空間全体で可視性とガバナンスを維持します。
このモデルでは、次の機能がサポートされます。
アプリケーション チームの委任された所有権
一元的な監査とポリシーの適用
偶発的または未承認の変更のリスクを軽減
一方、モノリシック DNS ゾーンでは、多くの場合、チーム間で広範なアクセス許可が必要です。運用上のリスクが高まります。
その他のリソース
プライベート DNS ゾーンの制限とクォータ の Azure プライベート DNS ゾーンの概要を確認します。
Azure DNS プライベート リゾルバーを評価して、一元的な解決を行う Azure DNS プライベート リゾルバーの概要を確認します。
Azure Policy を使用して、Azure Policy の標準ドキュメントの名前付け、所有権、およびリンクを適用します。
Azure Resource Graph - Azure DNS のプライベート DNS ゾーン のプライベート DNS 情報には、Azure Resource Graph エクスプローラーを使用します。
Azure DNS を監視するモニターとアラートを設定します。