프라이빗 액세스(VNET 통합)를 사용한 Azure Database for PostgreSQL - 유연한 서버의 네트워킹 개요

적용 대상: Azure Database for PostgreSQL - 유연한 서버

이 문서에서는 Azure Database for PostgreSQL 유연한 서버에 대한 연결 및 네트워킹 개념을 설명합니다.

Azure Database for PostgreSQL 유연한 서버 인스턴스를 만들 때 프라이빗 액세스(VNet 통합) 또는 퍼블릭 액세스(허용된 IP 주소) 및 프라이빗 엔드포인트의 두 네트워킹 옵션 중 하나를 선택해야 합니다. 이 문서에서는 프라이빗 액세스(VNet 통합) 네트워킹 옵션에 대해 설명합니다.

프라이빗 액세스(VNet 통합)

VNET 삽입을 사용하여 Azure VNet(가상 네트워크)에 Azure Database for PostgreSQL 유연한 서버 인스턴스를 배포할 수 있습니다. Azure 가상 네트워크는 프라이빗하고 안전한 네트워크 통신을 제공합니다. 가상 네트워크의 리소스는 이 네트워크에 할당된 개인 IP 주소를 통해 통신할 수 있습니다.

다음 기능을 원하는 경우 이 네트워킹 옵션을 선택합니다.

• 개인 IP 주소를 사용하여 동일한 가상 네트워크의 Azure 리소스에서 Azure Database for PostgreSQL 유연한 서버 인스턴스에 연결합니다.
• VPN 또는 Azure ExpressRoute를 사용하여 비 Azure 리소스에서 Azure Database for PostgreSQL 유연한 서버 인스턴스에 연결합니다.
• 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 Virtual Network에는 사용자가 사용하도록 구성된 개인 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 범위는 16개의 IP 주소를 제공하는 /28이지만 네트워크 또는 서브넷의 첫 번째 및 마지막 주소는 개별 호스트에 할당할 수 없습니다. Azure는 위에서 언급한 호스트에 할당할 수 없는 2개의 IP를 포함하는 Azure 네트워킹에서 내부적으로 활용할 5개의 IP를 예약합니다. 이렇게 하면 /28 CIDR 범위에 사용할 수 있는 11개의 IP 주소가 남게 되는 반면, 고가용성 기능이 있는 단일 Azure Database for PostgreSQL 유연한 서버 인스턴스는 4개의 주소를 활용합니다. 복제 및 Microsoft Entra 연결의 경우 경로 테이블이 트래픽에 영향을 주지 않는지 확인합니다. 일반적인 패턴은 Azure Firewall 또는 사용자 지정 온-프레미스 네트워크 필터링 어플라이언스를 통해 모든 아웃바운드 트래픽을 라우팅하는 것입니다. 서브넷에 모든 트래픽을 가상 어플라이언스로 라우팅하는 규칙과 연결된 경로 테이블이 있는 경우:

  • 대상 서비스 태그 "AzureActiveDirectory" 및 다음 홉 "인터넷"을 사용하여 규칙을 추가합니다.
  • 대상 IP 범위가 Azure Database for PostgreSQL 유연한 서버 서브넷 범위와 동일하고 다음 홉 "Virtual Network"가 있는 규칙을 추가합니다.

  Important

  AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet 및 GatewaySubnet 이름은 Azure 내에 예약되어 있습니다. 이들 중 어느 것도 서브넷 이름으로 사용하지 마세요.

• NSG(네트워크 보안 그룹) . NSG의 보안 규칙을 사용하면 가상 네트워크 서브넷 및 네트워크 인터페이스 내외부로 이동할 수 있는 네트워크 트래픽 유형을 필터링할 수 있습니다. 자세한 내용은 NSG 개요를 참조하세요.

  ASG(애플리케이션 보안 그룹)를 사용하면 플랫 네트워크에 NSG를 사용하여 Layer-4 보안을 쉽게 제어할 수 있습니다. 다음 작업을 빠르게 수행할 수 있습니다.

  • 가상 머신을 ASG에 조인시키거나 ASG에서 가상 머신을 제거합니다.
  • 해당 가상 머신에 규칙을 동적으로 적용하거나 해당 가상 머신에서 규칙을 제거합니다.

  자세한 내용은 ASG 개요를 참조하세요.

  현재 ASG가 Azure Database for PostgreSQL 유연한 서버를 사용한 규칙의 일부인 NSG는 지원하지 않습니다. 현재 NSG에서 IP 기반 원본 또는 대상 필터링을 사용하는 것이 좋습니다.

  Important

  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 Private DNS는 가상 네트워크에 안정적이고 안전한 DNS 서비스를 제공합니다. Azure Private DNS는 사용자 지정 DNS 솔루션을 구성할 필요 없이 가상 네트워크의 도메인 이름을 관리하고 확인합니다.

Azure Virtual Network에서 개인 네트워크 액세스를 사용하는 경우 DNS 확인을 수행하려면 프라이빗 DNS 영역 정보를 반드시 제공해야 합니다. 개인 네트워크 액세스를 사용하여 새로운 Azure Database for PostgreSQL 유연한 서버 인스턴스를 만들려면 프라이빗 액세스로 Azure Database for PostgreSQL 유연한 서버 인스턴스를 구성하는 동안 프라이빗 DNS 영역을 사용해야 합니다. API, ARM 또는 Terraform에서 개인 네트워크 액세스를 사용하여 새로운 Azure Database for PostgreSQL 유연한 서버 인스턴스를 만들려면 프라이빗 액세스로 Azure Database for PostgreSQL 유연한 서버 인스턴스를 구성하는 동안 프라이빗 DNS 영역을 만들고 사용해야 합니다. Microsoft Azure용 REST API 사양에 대한 자세한 내용을 참조하세요. Azure Database for PostgreSQL 유연한 서버 인스턴스를 만들기 위해 Azure Portal 또는 Azure CLI를 사용하는 경우 이전에 동일하거나 다른 구독에서 만든 프라이빗 DNS 영역 이름을 제공하거나 기본 프라이빗 DNS 영역이 구독에서 자동으로 만들어집니다.

Azure API, ARM 템플릿(Azure Resource Manager 템플릿) 또는 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 Portal, API, CLI 또는 ARM을 사용하여 프라이빗 DNS 영역을 Azure Database for PostgreSQL 유연한 서버 인스턴스를 만들 때 제공한 영역에서 동일하거나 다른 구독이 있는 다른 프라이빗 DNS 영역으로 변경할 수도 있습니다.

Important

Azure Database for PostgreSQL 유연한 서버 인스턴스를 만들 때 제공한 프라이빗 DNS 영역에서 다른 프라이빗 DNS 영역으로 변경하는 기능은 현재 고가용성 기능을 사용하는 서버에서 사용할 수 없습니다.

Azure에서 프라이빗 DNS 영역을 만든 후에는 가상 네트워크를 연결해야 합니다. 연결되면 해당 가상 네트워크에 호스트된 리소스는 프라이빗 DNS 영역에 액세스할 수 있습니다.

Important

프라이빗 네트워킹을 사용하여 Azure Database for PostgreSQL 유연한 서버에 대한 서버를 만들 때 가상 네트워크 링크 존재의 유효성을 더 이상 검사하지 않습니다. 포털을 통해 서버를 만들 때, Azure Portal의 "가상 네트워크에 프라이빗 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 영역을 가상 네트워크와 연결해야 합니다. 자세한 내용은 가상 네트워크 연결을 참조하세요.

참고 항목

'postgres.database.azure.com'으로 끝나는 프라이빗 DNS 영역 이름만 연결할 수 있습니다. DNS 영역 이름은 Azure Database for PostgreSQL 유연한 서버 인스턴스와 같을 수 없습니다. 그렇지 않으면 이름 확인이 실패합니다.

서버 이름을 DNS 레코드에 매핑하려면 Azure PowerShell 또는 Bash를 사용하여 Azure Cloud Shell에서 nslookup 명령을 실행할 수 있습니다. 아래 예에서는 <server_name> 매개 변수를 서버 이름으로 대체합니다.

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

허브 및 스포크 프라이빗 네트워킹 디자인 사용

허브 앤 스포크는 일반적인 통신 또는 보안 요구 사항을 효율적으로 관리하기 위한 널리 사용되는 네트워킹 모델입니다.

허브는 외부 연결을 관리하기 위한 중앙 위치의 역할을 하는 가상 네트워크입니다. 또한 여러 워크로드에서 사용하는 서비스를 호스팅합니다. 허브는 스포크와의 모든 통신을 조정합니다. 보안과 같은 IT 규칙 또는 프로세스는 트래픽을 검사하고, 라우팅하며 중앙에서 관리할 수 있습니다. 스포크는 워크로드를 호스트하고 가상 네트워크 피어링을 통해 중앙 허브에 연결되는 가상 네트워크입니다. 공유 서비스는 스포크 공유를 위한 자체 서브넷에서 호스팅됩니다. 경계 서브넷은 보안 어플라이언스 역할을 합니다.

또한 스포크는 Azure에서 개별 워크로드를 격리하는 데 사용되는 가상 네트워크입니다. 온-프레미스 본사와 Azure 간의 트래픽 흐름은 허브 가상 네트워크에 연결된 ExpressRoute 또는 사이트 간 VPN을 통해 연결됩니다. 스포크에서 허브로의 가상 네트워크가 피어링되며 온-프레미스 리소스에 대한 통신을 지원합니다. 허브 및 각 스포크를 별도 구독 또는 리소스 그룹에서 구현할 수 있습니다.

스포크 가상 네트워크를 서로 연결하는 데는 세 가지 주요 패턴이 있습니다.

• 스포크를 서로 직접 연결합니다. 허브 가상 네트워크를 트래버스하지 않고 직접 연결하기 위해 스포크 가상 네트워크 간에 가상 네트워크 피어링 또는 VPN 터널을 만듭니다.
• 스포크가 네트워크 어플라이언스를 통해 통신합니다. 각 스포크 가상 네트워크가 Virtual WAN 또는 허브 가상 네트워크에 피어링됩니다. 어플라이언스가 트래픽을 스포크로 라우팅합니다. 어플라이언스 관리는 Virtual WAN와 마찬가지로 Microsoft가 할 수도 있고 사용자가 할 수 있습니다.
• 허브 네트워크에 연결된 Virtual Network 게이트웨이이며 UDR(사용자 정의 경로)을 활용하여 스포크 간 통신을 사용하도록 설정합니다.

AVNM(Azure Virtual Network Manager)을 사용하여 연결 및 보안 제어의 중앙 관리를 위한 새로운 (및 기존 온보딩) 허브 및 스포크 가상 네트워크 토폴로지를 만듭니다.

다른 지역의 개인 네트워크 클라이언트와의 통신

고객이 서로 다른 Azure 지역의 클라이언트에 연결해야 하는 경우가 많습니다. 보다 구체적으로 말하자면, 이 질문은 일반적으로 서로 다른 지역에 있는 두 개의 VNET(1개는 Azure Database for PostgreSQL - 유연한 서버 포함, 다른 1개는 다른 애플리케이션 클라이언트 포함)을 연결하는 방법으로 좁혀집니다. 이러한 연결을 달성하는 방법에는 여러 가지가 있으며, 그 중 일부는 다음과 같습니다.

• 글로벌 VNET 피어링. 서로 다른 지역의 네트워크를 함께 연결하는 가장 쉬운 방법이므로 가장 일반적인 방법입니다. 글로벌 VNET 피어링에서는 두 개의 피어링된 VNET 간에 Azure 백본을 통해 직접 연결을 만듭니다. 이렇게 하면 이 방법을 사용하여 연결에 가장 적합한 네트워크 처리량과 가장 낮은 대기 시간을 제공합니다. VNET이 피어링되면 Azure는 자동으로 라우팅을 처리합니다. 이러한 VNET은 VPN 게이트웨이에 설정된 피어링된 VNET의 모든 리소스와 통신할 수 있습니다.
• 간 연결. VNET 간 연결은 기본적으로 서로 다른 두 Azure 위치 간의 VPN입니다. VNET 간 연결은 VPN Gateway에 설정됩니다. 즉, 글로벌 VNET 피어링과 달리 트래픽으로 인해 두 개의 추가 트래픽 홉이 발생합니다. 또한 해당 방법에 비해 대기 시간이 늘어나고 대역폭이 낮아집니다.
• 허브 및 스포크 아키텍처에서 네트워크 어플라이언스로 통신. 스포크 가상 네트워크를 서로 직접 연결하는 대신 네트워크 어플라이언스를 사용하여 스포크 간에 트래픽을 전달할 수 있습니다. 네트워크 어플라이언스는 딥 패킷 검사 및 트래픽 구분 또는 모니터링과 같은 추가 네트워크 서비스를 제공하지만, 크기를 적절하게 조정하지 않으면 대기 시간 및 성능 병목 현상이 발생할 수 있습니다.

프라이빗 네트워킹을 사용하여 Azure 지역 및 가상 네트워크 간 복제

데이터베이스 복제는 중앙 또는 주 서버에서 복제본으로 알려진 여러 서버로 데이터를 복사하는 프로세스입니다. 주 서버는 읽기 및 쓰기 작업을 수락하는 반면 복제본은 읽기 전용 트랜잭션을 제공합니다. 주 서버와 복제본이 합쳐져서 데이터베이스 클러스터를 형성합니다. 데이터베이스 복제의 목표는 특히 트래픽이 많은 중요 업무용 애플리케이션에서 데이터의 중복성, 일관성, 고가용성 및 액세스 가능성을 보장하는 것입니다.

Azure Database for PostgreSQL 유연한 서버는 기본 제공 읽기 복제본 기능을 통한 실제(예: 스트리밍) 및 논리적 복제의 두 가지 복제 방법을 제공합니다. 둘 다 서로 다른 사용 사례에 이상적이며 사용자는 최종 목표에 따라 다른 하나를 선택할 수 있습니다.

각 지역에 별도의 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 유연한 서버 네트워킹을 참조하세요.

Important

Azure Resource Manager는 보안 제어로 리소스를 잠그는 기능을 지원합니다. 리소스 잠금은 리소스에 적용되고 모든 사용자 및 역할에서 유효합니다. 리소스 잠금에는 CanNotDelete 및 ReadOnly의 두 가지 유형이 있습니다. 이러한 잠금 유형은 프라이빗 DNS 영역 또는 개별 레코드 집합에 적용할 수 있습니다. 프라이빗 DNS 영역 또는 개별 레코드 집합에 대해 잠금 형식을 적용하면 Azure Database for PostgreSQL 유연한 서버가 DNS 레코드를 업데이트하는 기능을 방해할 수 있으며 기본에서 보조로의 고가용성 장애 조치(failover)와 같은 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 유연한 서버 인스턴스를 만드는 방법을 알아봅니다.