プライベート アクセス (VNET 統合) を使用する Azure Database for PostgreSQL - フレキシブル サーバーのネットワークの概要

  • [アーティクル]

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

この記事では、Azure Database for PostgreSQL - フレキシブル サーバーの接続とネットワークの概念について説明します。

Azure Database for PostgreSQL フレキシブル サーバーのインスタンスを作成するときは、プライベート アクセス (VNet 統合) またはパブリック アクセス (許可された IP アドレス) とプライベート エンドポイントのいずれかのネットワーク オプションを選ぶ必要があります。 このドキュメントでは、プライベート アクセス (VNet 統合) というネットワーク オプションについて説明します。

プライベート アクセス (VNet 統合)

VNet インジェクションを使って、Azure Database for PostgreSQL フレキシブル サーバーのインスタンスを Azure 仮想ネットワーク (VNet) にデプロイできます。 Azure の仮想ネットワークでは、非公開の、セキュリティで保護されたネットワーク通信が提供されます。 仮想ネットワーク内のリソースは、このネットワークで割り当てられたプライベート IP アドレスを介して通信できます。

次の機能が必要な場合は、このネットワーク オプションを選択します。

  • プライベート IP アドレスを使って、同じ仮想ネットワーク内の Azure リソースから Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続する。
  • VPN または Azure ExpressRoute を使って、Azure 以外のリソースから Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続する。
  • Azure Database for PostgreSQL フレキシブル サーバー インスタンスが、インターネットからアクセスできるパブリック エンドポイントを持たないようにする。

仮想ネットワーク間のピアリングのしくみを示す図。その 1 つとして、Azure Database for PostgreSQL フレキシブル サーバー インスタンスが含まれています。

前の図で:

  • Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、VNet-1 仮想ネットワークのサブネット 10.0.1.0/24 に挿入されます。
  • 同じ仮想ネットワーク内の異なるサブネットにデプロイされたアプリケーションは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスに直接アクセスできます。
  • 異なる仮想ネットワーク (VNet-2) にデプロイされたアプリケーションは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスに直接アクセスできません。 それらがフレキシブル サーバーにアクセスできるようにするには、プライベート DNS ゾーンの仮想ネットワーク ピアリングを実行する必要があります。

仮想ネットワークの概念

Azure 仮想ネットワークには、用途に合わせて構成されたプライベート IP アドレス空間が含まれます。 仮想ネットワークは、Azure Database for PostgreSQL フレキシブル サーバー インスタンスと同じ Azure リージョンに存在する必要があります。 仮想ネットワークの詳細については、Azure Virtual Network の概要に関するページを参照してください。

リソースが Azure Database for PostgreSQL フレキシブル サーバー インスタンスを含む仮想ネットワークに統合されている仮想ネットワークを使うときに理解しておくべきいくつかの概念を以下に示します。

  • 委任されたサブネット。 仮想ネットワークには、サブネット (サブネットワーク) が含まれます。 サブネットを使用すると、仮想ネットワークをより小さなアドレス空間に分割できます。 Azure リソースは、仮想ネットワーク内の特定のサブネットにデプロイされます。

    VNet に統合される Azure Database for PostgreSQL フレキシブル サーバー インスタンスは、"委任された" サブネット内に存在する必要があります。 つまり、Azure Database for PostgreSQL フレキシブル サーバー インスタンスだけがそのサブネットを使用できます。 委任されたサブネットに他の Azure リソースの種類を含めることはできません。 サブネットを委任するには、その委任プロパティを Microsoft.DBforPostgreSQL/flexibleServers として割り当てます。 サブネットに指定できる最小の CIDR 範囲は /28 で、16 個の IP アドレスが提供されますが、どのようなネットワークまたはサブネットでも、最初と最後のアドレスを個別のホストに割り当てることはできません。 5 つの IP は Azure ネットワークで内部的に利用するために予約されており、それには前に説明したホストに割り当てることのできない 2 つの IP も含まれます。 これにより、/28 の CIDR 範囲で使用できる IP アドレスが 11 個残りますが、高可用性機能を備えた 1 つの Azure Database for PostgreSQL フレキシブル サーバー インスタンスで 4 つのアドレスが使われます。 レプリケーションと Microsoft Entra 接続の場合は、ルート テーブルがトラフィックに影響しないことを確認してください。一般的なパターンでは、すべての送信トラフィックが、Azure Firewall またはカスタムのオンプレミス ネットワーク フィルタリング アプライアンスを介してルーティングされます。 サブネットに、すべてのトラフィックを仮想アプライアンスにルーティングするルールに関連付けられたルート テーブルがある場合:

    • 宛先サービス タグ "AzureActiveDirectory" と、ネクスト ホップ "Internet" を含むルールを追加します
    • 宛先 IP 範囲が Azure Database for PostgreSQL フレキシブル サーバーのサブネット範囲と同じで、ネクスト ホップが "Virtual Network" である規則を追加します

    重要

    AzureFirewallSubnet、AzureFirewallManagementSubnet、AzureBastionSubnet、GatewaySubnet を含む名前は、Azure 内で予約されています。 これらのいずれも、サブネット名として使用しないでください。

  • ネットワーク セキュリティ グループ (NSG) 。 NSG のセキュリティ規則を使用して、仮想ネットワークのサブネットとネットワーク インターフェイスに出入りできるネットワーク トラフィックの種類をフィルター処理できます。 詳細については、NSG の概要に関するページを参照してください。

    アプリケーション セキュリティ グループ (ASG) を使用すると、フラットなネットワークで NSG を使用して、レイヤー 4 のセキュリティを簡単に制御できます。 以下を迅速に実行できます。

    • ASG に仮想マシンを参加させる、または ASG から仮想マシンを削除する。
    • これらの仮想マシンに対する規則を動的に適用または削除する。

    詳細については、ASG の概要に関するページを参照してください。

    現時点では、ASG が Azure Database for PostgreSQL フレキシブル サーバーを含む規則の一部である NSG はサポートされていません。 現在、NSG では IP ベースのソースまたは宛先のフィルター処理を使用することをお勧めします。

    重要

    Azure Database for PostgreSQL フレキシブル サーバーの高可用性とその他の機能は、Azure Database for PostgreSQL フレキシブル サーバーがデプロイされている Azure 仮想ネットワーク サブネット内の宛先ポート 5432 へのトラフィックと、ログ アーカイブのための Azure Storage へのトラフィックを、送信および受信できる必要があります。 Azure Database for PostgreSQL フレキシブル サーバー インスタンスがデプロイされているサブネット内で、それとの間のトラフィック フローを拒否するネットワーク セキュリティ グループ (NSG) を作成する場合は、サブネット内の宛先ポート 5432 へのトラフィックを許可し、Azure Storage へのトラフィックも宛先としてサービス タグ Azure Storage を使うことで許可してください。 us-east.storage などのラベルに Azure リージョンを追加することで、この例外規則をさらにフィルター処理できます。 また、Microsoft Entra 認証を使って、Azure Database for PostgreSQL フレキシブル サーバー インスタンスへのログインの認証を行う場合は、Microsoft Entra のサービス タグを使って、Microsoft Entra ID への送信トラフィックを許可します。 Azure リージョン間の読み取りレプリカを設定する場合、Azure Database for PostgreSQL フレキシブル サーバーは、プライマリとレプリカ両方の宛先ポート 5432 へのトラフィックと、プライマリとレプリカ両方のサーバーからプライマリとレプリカ リージョン内の Azure Storage へのトラフィックを、送受信できる必要があります。

  • プライベート DNS ゾーン統合。 Azure プライベート DNS ゾーン統合により、現在の仮想ネットワーク、またはリージョン内でピアリングされた仮想ネットワーク (プライベート DNS ゾーンがこれにリンクされている) 内でプライベート DNS を解決できます。

プライベート DNS ゾーンを使用する

Azure プライベート DNS は、仮想ネットワークのための信頼性が高く安全な DNS サービスとなります。 カスタムの DNS ソリューションを構成しなくても、Azure プライベート DNS によって、仮想ネットワークにおけるドメイン名の管理と解決が行われます。

Azure 仮想ネットワークでプライベート ネットワーク アクセスを使用する場合は、DNS 解決を行うためにプライベート DNS ゾーン情報の提供が必須です。 プライベート ネットワーク アクセスを使って Azure Database for PostgreSQL フレキシブル サーバー インスタンスを新しく作成する場合は、プライベート アクセスで Azure Database for PostgreSQL フレキシブル サーバー インスタンスを構成するときに、プライベート DNS ゾーンを使う必要があります。 API、ARM、または Terraform でプライベート ネットワーク アクセスを使って Azure Database for PostgreSQL フレキシブル サーバー インスタンスを新しく作成する場合は、プライベート DNS ゾーンを作成し、それを使ってプライベート アクセスで Azure Database for PostgreSQL フレキシブル サーバー インスタンスを構成します。 詳細については、Microsoft Azure の REST API 仕様に関するページを参照してください。 Azure Database for PostgreSQL フレキシブル サーバー インスタンスの作成に Azure portal または Azure CLI を使う場合は、同じまたは異なるサブスクリプションで以前に作成したプライベート DNS ゾーン名を指定できます。そうしない場合は、既定のプライベート DNS ゾーンがサブスクリプションに自動的に作成されます。

Azure API、Azure Resource Manager テンプレート (ARM テンプレート)、または Terraform を使用する場合は、.postgres.database.azure.com で終わるプライベート DNS ゾーンを作成します。 プライベート アクセスを使う Azure Database for PostgreSQL フレキシブル サーバー インスタンスを構成するときに、それらのゾーンを使います。 たとえば、[name1].[name2].postgres.database.azure.com または [name].postgres.database.azure.com の形式を使います。 [name].postgres.database.azure.com の形式を使う場合は、その名前を、Azure Database for PostgreSQL フレキシブル サーバー インスタンスのいずれかに使われている名前にすることはできません。そのようにすると、プロビジョニング時にエラー メッセージが表示されます。 詳細については、プライベート DNS ゾーンの概要に関するページを参照してください。

Azure Database for PostgreSQL フレキシブル サーバー インスタンスの作成時に指定したプライベート DNS ゾーンは、Azure portal、API、CLI、または ARM を使って、同じまたは異なるサブスクリプションに存在する別のプライベート DNS ゾーンに変更することもできます。

重要

現在、Azure Database for PostgreSQL フレキシブル サーバー インスタンスの作成時に指定したプライベート DNS ゾーンを別のプライベート DNS ゾーンに変更する機能は、高可用性機能が有効なサーバーでは無効にされています。

Azure でプライベート DNS ゾーンを作成した後、仮想ネットワークをそれにリンクする必要があります。 リンクされると、その仮想ネットワークでホストされているリソースはプライベート DNS ゾーンにアクセスできるようになります。

重要

プライベート ネットワークを使う Azure Database for PostgreSQL フレキシブル サーバー用のサーバーの作成時に、仮想ネットワーク リンクの存在は検証されなくなっています。 ポータルでサーバーを作成するとき、お客様はサーバーの作成時に Azure portal の [Link Private DNS Zone your virtual network] (仮想ネットワークにプライベート DNS ゾーンをリンクする) チェックボックスを使って、リンクを作成できます。

ゾーン データはグローバルに利用できるため、DNS プライベート ゾーンは、リージョンの障害に対して回復性があります。 プライベート ゾーン内のリソース レコードは、リージョン間で自動的にレプリケートされます。 Azure プライベート DNS は、可用性ゾーンの基本的なゾーン冗長サービスです。 詳細については、「可用性ゾーンをサポートする Azure サービス」をご覧ください。

カスタム DNS サーバーとの統合

カスタム DNS サーバーを使う場合は、DNS フォワーダーを使って Azure Database for PostgreSQL フレキシブル サーバーの FQDN を解決する必要があります。 フォワーダーの IP アドレスは、168.63.129.16 である必要があります。

カスタム DNS サーバーは、仮想ネットワーク内にあるか、仮想ネットワークの DNS サーバー設定を使用して到達可能である必要があります。 詳細については、「独自の DNS サーバーを使用する名前解決」を参照してください。

プライベート DNS ゾーンと仮想ネットワーク ピアリング

プライベート DNS ゾーンの設定と、仮想ネットワーク ピアリングはそれぞれ独立しています。 同じリージョンまたは異なるリージョンから別の仮想ネットワークにプロビジョニングされたクライアントから、Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続する必要がある場合は、プライベート DNS ゾーンと仮想ネットワークをリンクする必要があります。 詳細については、「仮想ネットワークのリンク」を参照してください。

Note

リンクできるのは、末尾が 'postgres.database.azure.com' のプライベート DNS ゾーン名のみです。 DNS ゾーンの名前を Azure Database for PostgreSQL フレキシブル サーバー インスタンスと同じにすることはできません。同じ場合、名前解決に失敗します。

サーバー名を DNS レコードにマップするには、Azure Cloud Shell で Azure PowerShell または Bash を使って nslookup コマンドを実行します。このとき、下の例の <server_name> パラメーターを、実際のサーバー名に置き換えます。

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

ハブ アンド スポーク プライベートネットワーク設計の使用

ハブ アンド スポークは、一般的な通信またはセキュリティ要件を効率的に管理するためのよく使われるネットワーク モデルです。

ハブは、外部接続を管理するための中心的な場所として機能する仮想ネットワークです。 また、複数のワークロードで使用されるサービスをホストします。 ハブでスポーク間のすべての通信が調整されます。 セキュリティのような IT のルールまたはプロセスによって、トラフィックを検査、ルーティング、集中管理できます。 スポークは、ワークロードをホストし、仮想ネットワーク ピアリングを介して中央のハブに接続する仮想ネットワークです。 共有サービスは、スポークと共有するための独自のサブネットでホストされます。 境界サブネットが次に、セキュリティ アプライアンスとして機能します。

スポークは、個々のワークロードを分離するために使用される Azure の仮想ネットワークでもあります。 オンプレミスの本社と Azure の間のトラフィック フローは、ハブ仮想ネットワークに接続されている ExpressRoute またはサイト間 VPN を介して接続されます。 スポークからハブへの仮想ネットワークがピアリングされ、オンプレミス リソースへの通信が可能になります。 ハブと各スポークは、別々のサブスクリプションまたはリソース グループに実装できます。

スポーク仮想ネットワークの相互接続には、次の 3 つの主なパターンがあります。

  • スポークが相互に直接接続される。 仮想ネットワーク ピアリングまたは VPN トンネルがスポーク仮想ネットワーク間に作成され、ハブ仮想ネットワークを通過することなく直接接続できます。
  • スポークがネットワーク アプライアンス経由で通信する。 各スポーク仮想ネットワークは、Virtual WAN またはハブ仮想ネットワークにピアリングされます。 アプライアンスは、スポークからスポークへのトラフィックをルーティングします。 アプライアンスは、 (Virtual WAN と同様に) Microsoft が管理するか、ユーザーが管理することができます。
  • ハブ ネットワークに接続されている仮想ネットワーク ゲートウェイ、およびユーザー定義ルート (UDR) を使用して、スポーク間の通信を有効する。

Express Hub 経由のハイブリッド接続を使用した基本的なハブ アンド スポーク アーキテクチャを示す図。

Azure Virtual Network Manager (AVNM) を使用すると、接続とセキュリティ制御を一元管理するために、ハブ アンド スポーク仮想ネットワーク トポロジを新規に作成したり (既存のものをオンボードしたり) することができます。

異なるリージョンのプライベート ネットワーク クライアントとの通信

お客様は、異なる Azure リージョンのクライアントへの接続が必要になることがよくあります。 具体的には、この質問は一般に、異なるリージョンにある 2 つの VNET (1 つは Azure Database for PostgreSQL - フレキシブル サーバーで、もう 1 つはアプリケーション クライアント) を接続する方法ということになります。 そのような接続を実現するには複数の方法があり、次に示すのはその一部です。

  • グローバル VNET ピアリング。 異なるリージョンのネットワークを接続する最も簡単な方法であるため、最も一般的な手法です。 グローバル VNET ピアリングでは、ピアリングされた 2 つの VNET 間に、Azure バックボーン経由の接続が直接作成されます。 この方法を使って接続すると、最高のネットワーク スループットと最短の待ち時間が提供されます。 VNET がピアリングされていると、ルーティングも Azure によって自動的に処理されます。これらの VNET は、VPN ゲートウェイで確立されたピアリングされている VNET 内のすべてのリソースと通信できます。
  • VNET 間接続。 VNET 間接続は、基本的に 2 つの異なる Azure の場所の間の VPN です。 VNET 間接続は、VPN ゲートウェイで確立されます。 つまり、トラフィックには、グローバル VNET ピアリングと比較して 2 つ多くのトラフィック ホップが発生します。 また、その方法と比較して、待ち時間は長くなり、帯域幅は低くなります。
  • ハブ アンド スポーク アーキテクチャのネットワーク アプライアンスを介した通信。 スポーク仮想ネットワークを相互に直接接続する代わりに、ネットワーク アプライアンスを使用してスポーク間でトラフィックを転送できます。 ネットワーク アプライアンスでは、ディープ パケット インスペクションやトラフィックのセグメント化または監視などのネットワーク サービスがさらに提供されますが、適切なサイズに設定しないと、待ち時間とパフォーマンスのボトルネックが発生する可能性があります。

プライベート ネットワークを使用した Azure リージョンと仮想ネットワーク間のレプリケーション

データベース レプリケーションは、中央またはプライマリ サーバーからレプリカと呼ばれる複数のサーバーにデータをコピーするプロセスです。 プライマリ サーバーは読み取りおよび書き込み操作を受け入れますが、レプリカは読み取り専用トランザクションを処理します。 プライマリ サーバーとレプリカを合わせてデータベース クラスターが形成されます。 データベース レプリケーションの目的は、特にトラフィックの多いミッション クリティカルなアプリケーションにおいて、データの冗長性、一貫性、高可用性、アクセシビリティを確保することです。

Azure Database for PostgreSQL フレキシブル サーバーには、レプリケーションの方法として、組み込みの読み取りレプリカ機能による物理的なもの (つまりストリーミング) と論理レプリケーションの 2 つが用意されています。 どちらも異なるユース ケースに最適であり、ユーザーは最終目標に応じてどちらか一方を選択できます。

各リージョンに個別の仮想ネットワーク (VNET) がある Azure リージョン間のレプリケーションでは、仮想ネットワーク ピアリングを介して、またはネットワーク アプライアンス経由のハブ アンド スポーク アーキテクチャにおいて提供可能なリージョンの仮想ネットワーク境界を越えた接続が必要です。

既定では、DNS 名前解決のスコープは仮想ネットワークです。 つまり、ある仮想ネットワーク (VNET1) 内のクライアントが、別の仮想ネットワーク (VNET2) 内の Azure Database for PostgreSQL フレキシブル サーバーの FQDN を解決できなくなります。

この問題を解決するには、VNET1 のクライアントが Azure Database for PostgreSQL フレキシブル サーバーのプライベート DNS ゾーンにアクセスできるようにする必要があります。 これを実現するには、Azure Database for PostgreSQL フレキシブル サーバー インスタンスのプライベート DNS ゾーンへの仮想ネットワーク リンクを追加します。

サポートされない仮想ネットワークのシナリオ

VNET 統合で作成される仮想ネットワークで作業する場合の制限事項を次に示します。

  • Azure Database for PostgreSQL フレキシブル サーバー インスタンスを仮想ネットワークとサブネットにデプロイした後、それを別の仮想ネットワークまたはサブネットに移動することはできません。 仮想ネットワークを別のリソース グループまたはサブスクリプションに移動することはできません。
  • サブネットにリソースを配置した後、そのサブネットのサイズ (アドレス空間) を増やすことはできません。
  • VNet インジェクションされたリソースは、既定では Private Link と対話できません。 プライベート ネットワークに Private Link を使いたい場合は、「Private Link を使用する Azure Database for PostgreSQL フレキシブル サーバーのネットワーク」をご覧ください

重要

Azure Resource Manager は、セキュリティ制御としてリソースをロックする機能をサポートしています。 リソース ロックはリソースに適用され、すべてのユーザーおよびロールが対象になります。 リソースのロックは 2 種類あります｡CanNotDelete と ReadOnly です。 これらは、プライベート DNS ゾーンまたは個別のレコード セットのいずれかに適用できます。 プライベート DNS ゾーンまたは個々のレコードセットにいずれかの種類のロックを適用すると、Azure Database for PostgreSQL フレキシブル サーバーが DNS レコードを更新する機能を妨げる場合があり、プライマリからセカンダリへの高可用性フェールオーバーなどの DNS での重要な操作中に、問題が発生する可能性があります。 以上の理由から、Azure Database for PostgreSQL フレキシブル サーバーで高可用性機能を利用する場合は、DNS プライベート ゾーンまたはレコードのロックを使用しないでください。

ホスト名

選ぶネットワーク オプションに関係なく、Azure Database for PostgreSQL フレキシブル サーバー インスタンスに接続する場合は常に、ホスト名として FQDN を使うことをお勧めします。 サーバーの IP アドレスが静的のままであることは保証されません。 FQDN を使うと、接続文字列を変更する必要がなくなります。

ホスト名として FQDN を使用する例は、hostname = servername.postgres.database.azure.com です。 可能であれば、hostname = 10.0.0.4 (プライベート アドレス) または hostname = 40.2.45.67 (パブリック アドレス) の使用は避けてください。

次のステップ

  • Azure portal または Azure CLI でプライベート アクセス (VNet 統合) オプションを使って Azure Database for PostgreSQL フレキシブル サーバー インスタンスを作成する方法について説明します。