이 문서에서는 Azure Database for PostgreSQL 유연한 서버 인스턴스에 대한 연결 및 네트워킹 개념을 설명합니다.
Azure Database for PostgreSQL 유연한 서버 인스턴스를 만들 때 다음 네트워킹 옵션 중 하나를 선택해야 합니다.
- 프라이빗 액세스(가상 네트워크 통합)
- 공용 액세스(허용된 IP 주소) 및 프라이빗 엔드포인트
이 문서에서는 프라이빗 액세스(가상 네트워크 통합) 네트워킹 옵션에 대해 설명합니다.
프라이빗 액세스(가상 네트워크 통합)
가상 네트워크 주입을 사용하여 Azure Virtual Network에 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 리소스는 가상 네트워크 내의 특정 서브넷에 배포됩니다.
가상 네트워크에 통합된 Azure Database for PostgreSQL 유연한 서버 인스턴스는 위임된 서브넷에 있어야 합니다. 즉, Azure Database for PostgreSQL 유연한 서버 인스턴스만 해당 서브넷을 사용할 수 있습니다. 다른 Azure 리소스 유형은 위임된 서브넷에 있을 수 없습니다. 서브넷의 위임 속성을
Microsoft.DBforPostgreSQL/flexibleServers로 할당하여 서브넷을 위임합니다.서브넷에 지정할 수 있는 가장 작은 CIDR 범위는 /28이며, 이는 16개의 IP 주소를 제공합니다. 모든 네트워크나 서브넷의 첫 번째 주소와 마지막 주소는 어떤 개별 호스트에도 할당될 수 없습니다. Azure는 Azure 네트워킹에서 내부적으로 사용할 5개의 IP를 예약해 두었는데, 여기에는 앞서 언급했듯이 호스트에 할당할 수 없는 2개의 IP가 포함됩니다. 이렇게 하면 /28 CIDR 범위에 사용 가능한 IP 주소가 11개 남습니다. 고가용성 기능이 있는 단일 Azure Database for PostgreSQL 유연한 서버 인스턴스는 네 개의 주소를 사용합니다.
복제 및 Microsoft Entra 연결의 경우, 경로 테이블이 트래픽에 영향을 미치지 않는지 확인합니다. 일반적인 패턴은 모든 아웃바운드 트래픽을 Azure Firewall이나 사용자 지정 온-프레미스 네트워크 필터링 어플라이언스를 통해 라우팅하는 것입니다.
서브넷에 모든 트래픽을 가상 어플라이언스로 라우팅하는 규칙과 연결된 경로 테이블이 있는 경우:
- 대상 서비스 태그
AzureActiveDirectory및 다음 홉Internet을 사용하여 규칙을 추가합니다. - 대상 IP 범위가 Azure Database for PostgreSQL 유연한 서버 인스턴스 서브넷 범위 및 다음 홉
Virtual Network과 동일한 규칙을 추가합니다.
중요
AzureFirewallSubnet,AzureFirewallManagementSubnet,AzureBastionSubnet및GatewaySubnet이름은 Azure 내에 예약되어 있습니다. 이러한 이름을 서브넷 이름으로 사용하지 마세요. 또한 가상 네트워크는 지역 간 복제본을 만들기 위해 중복되는 주소 공간을 가져서는 안 됩니다.- 대상 서비스 태그
NSG(네트워크 보안 그룹): NSG의 보안 규칙을 사용하면 가상 네트워크 서브넷과 네트워크 인터페이스에서 들어오고 나갈 수 있는 네트워크 트래픽 형식을 필터링할 수 있습니다. 자세한 내용은 NSG 개요를 참조하세요.
ASG(애플리케이션 보안 그룹)를 사용하면 플랫 네트워크에 NSG를 사용하여 Layer-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로의 트래픽을 허용해야 하며, 대상으로 서비스 태그 Storage를 사용하여 Storage로도 트래픽을 허용해야 합니다. 고가용성을 위해 WAL(Write Ahead Log) 파일을 업로드하는 데 사용되는 Azure Storage 계정으로 올바른 트래픽 라우팅을 보장하므로 Microsoft.Storage 서비스 엔드포인트를 추가하는 것이 가장 좋습니다.
Azure 지역을
us-east.storage와 같은 레이블에 추가하여 이 예외 규칙을 추가로 필터링할 수 있습니다. 또한 Microsoft Entra 인증 을 사용하여 Azure Database for PostgreSQL 유연한 서버 인스턴스에 대한 로그인을 인증하도록 선택한 경우 Microsoft Entra 서비스 태그를 사용하여 Microsoft Entra ID로의 아웃바운드 트래픽을 허용합니다.Azure 지역 전체에 읽기 복제본을 설정하는 경우 Azure Database for PostgreSQL 유연한 서버 인스턴스에는 기본 및 복제본 모두에 대한 대상 포트 5432와 기본 및 복제본 서버 모두에서 기본 및 복제본 지역의 Azure Storage로 트래픽을 보내거나 받을 수 있는 기능이 필요합니다. 스토리지에 필요한 대상 TCP 포트는 443입니다.
프라이빗 DNS 영역 통합: Azure 프라이빗 DNS 영역 통합을 사용하면 현재 가상 네트워크 또는 프라이빗 DNS 영역이 연결된 지역 내 피어링된 가상 네트워크 내에서 프라이빗 DNS를 확인할 수 있습니다.
프라이빗 DNS 영역 사용
Azure Private DNS는 가상 네트워크에 안정적이고 안전한 DNS 서비스를 제공합니다. Azure Private DNS는 사용자 지정 DNS 솔루션을 구성할 필요 없이 가상 네트워크의 도메인 이름을 관리하고 확인합니다.
Azure 가상 네트워크에서 개인 네트워크 액세스를 사용하는 경우 DNS 확인을 수행하려면 프라이빗 DNS 영역 정보를 제공하는 것이 필수입니다. 프라이빗 네트워크 액세스를 사용하여 새 Azure Database for PostgreSQL 유연한 서버 인스턴스를 만들려면 프라이빗 액세스 권한이 있는 Azure Database for PostgreSQL 유연한 서버 인스턴스를 구성하는 동안 프라이빗 DNS 영역을 사용해야 합니다.
중요
다른 구독에서 프라이빗 DNS 영역을 사용하는 경우 해당 구독에는 Microsoft.DBforPostgreSQL 리소스 공급자도 등록 되어 있어야 합니다 . 그렇지 않으면 Azure Database for PostgreSQL 유연한 서버 인스턴스의 배포가 완료되지 않습니다.
API, ARM 템플릿(Azure Resource Manager 템플릿), Bicep 또는 Terraform과 함께 프라이빗 네트워크 액세스를 사용하여 새 Azure Database for PostgreSQL 유연한 서버 인스턴스 만들기의 경우 프라이빗 DNS 영역을 만듭니다. 그런 다음, 프라이빗 액세스를 사용하여 Azure Database for PostgreSQL 유연한 서버 인스턴스를 구성하는 동안 사용합니다. 자세한 내용은 Azure용 REST API 사양을 참조하세요.
Azure Portal 또는 Azure CLI를 사용하여 Azure Database for PostgreSQL 유연한 서버 인스턴스를 만드는 경우 이전에 동일하거나 다른 구독에서 만든 프라이빗 DNS 영역 이름을 제공하거나 기본 프라이빗 DNS 영역이 구독에 자동으로 만들어집니다.
Azure API, ARM 템플릿, Bicep 또는 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, Azure CLI 또는 ARM 템플릿을 사용하는 경우 Azure Database for PostgreSQL 유연한 서버 인스턴스를 만들 때 제공한 프라이빗 DNS 영역을 동일하거나 다른 구독에 존재하는 다른 프라이빗 DNS 영역으로 변경할 수도 있습니다.
중요
Azure Database for PostgreSQL 유연한 서버 인스턴스를 만들 때 제공한 것에서 다른 프라이빗 DNS 영역으로 프라이빗 DNS 영역을 변경하는 기능은 현재 고가용성 기능을 사용하도록 설정된 서버에서 사용할 수 없습니다.
Azure에서 프라이빗 DNS 영역을 만든 후에는 가상 네트워크를 연결해야 합니다. 연결된 가상 네트워크에 호스트된 리소스는 프라이빗 DNS 영역에 액세스할 수 있습니다.
중요
프라이빗 네트워킹을 사용하는 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 간의 트래픽 흐름은 허브 가상 네트워크에 연결된 Azure ExpressRoute 또는 사이트 간 VPN을 통해 연결됩니다. 스포크에서 허브까지의 가상 네트워크는 피어링되어 온-프레미스 리소스와의 통신을 가능하게 합니다. 허브와 각 스포크를 별도의 구독이나 리소스 그룹으로 구현할 수 있습니다.
스포크 가상 네트워크를 서로 연결하는 데는 세 가지 주요 패턴이 있습니다.
- 스포크가 서로 직접 연결됨: 가상 네트워크 피어링 또는 VPN 터널이 스포크 가상 네트워크 간에 만들어져 허브 가상 네트워크를 거치지 않고도 직접 연결을 제공합니다.
- 스포크가 네트워크 어플라이언스를 통해 통신 각 스포크 가상 네트워크에는 Virtual WAN 또는 허브 가상 네트워크에 대한 피어링이 있습니다. 어플라이언스가 트래픽을 스포크로 라우팅합니다. 해당 어플라이언스는 Microsoft(Virtual WAN과 마찬가지로)나 사용자가 직접 관리할 수 있습니다.
- 가상 네트워크 게이트웨이가 허브 네트워크에 연결되어 사용자 정의 경로를 활용: 스포크 간 통신을 가능하게 합니다.
Azure Virtual Network Manager를 사용하면 연결 및 보안 제어의 중앙 관리를 위해 새로운 허브 및 스포크 가상 네트워크 토폴로지를 만들고 기존 토폴로지를 온보딩할 수 있습니다.
다른 지역의 개인 네트워크 클라이언트와의 통신
고객이 서로 다른 Azure 지역의 클라이언트에 연결해야 하는 경우가 많습니다. 보다 구체적으로 말하자면, 이 질문은 일반적으로 서로 다른 지역에 있는 두 개의 가상 네트워크(Azure Database for PostgreSQL 유연한 서버 인스턴스가 있고 다른 하나는 애플리케이션 클라이언트가 있는 네트워크)를 연결하는 방법으로 귀결됩니다.
이러한 연결을 달성하는 데는 다음을 포함하여 여러 가지 방법이 있습니다.
- 글로벌 가상 네트워크 피어링: 이 방법은 서로 다른 지역의 네트워크를 연결하는 가장 쉬운 방법이기 때문에 가장 일반적입니다. 글로벌 가상 네트워크 피어링은 Azure 백본을 통해 두 피어링된 가상 네트워크 간에 직접 연결을 만듭니다. 이 방법은 최고의 네트워크 처리량과 가장 낮은 연결 대기 시간을 제공합니다. 가상 네트워크가 피어링되면 Azure에서 자동으로 라우팅을 처리합니다. 이러한 가상 네트워크는 VPN 게이트웨이에 설정된 피어링된 가상 네트워크의 모든 리소스와 통신할 수 있습니다.
- 네트워크 간 연결. 가상 네트워크 간 연결(네트워크 간 연결)은 기본적으로 두 Azure 위치 간의 VPN입니다. 네트워크 간 연결은 VPN 게이트웨이에서 설정됩니다. 사용자의 트래픽은 글로벌 가상 네트워크 피어링에 비해 두 번 더 많은 트래픽 홉을 발생합니다. 또한 이 방법에 비해 대기 시간이 더 길고 대역폭도 낮습니다.
- 허브 및 스포크 아키텍처에서 네트워크 어플라이언스로 통신입니다. 스포크 가상 네트워크를 서로 직접 연결하는 대신 네트워크 어플라이언스를 사용하여 스포크 간에 트래픽을 전달할 수 있습니다. 네트워크 어플라이언스는 딥 패킷 검사 및 트래픽 구분 또는 모니터링과 같은 추가 네트워크 서비스를 제공하지만, 크기를 적절하게 조정하지 않으면 대기 시간 및 성능 병목 현상이 발생할 수 있습니다.
프라이빗 네트워킹을 사용하여 Azure 지역 및 가상 네트워크 간 복제
데이터베이스 복제는 중앙 또는 주 서버에서 복제본으로 알려진 여러 서버로 데이터를 복사하는 프로세스입니다. 주 서버는 읽기 및 쓰기 작업을 허용하지만 복제본은 읽기 전용 트랜잭션만 처리합니다. 주 서버와 복제본이 합쳐져서 데이터베이스 클러스터를 형성합니다. 데이터베이스 복제의 목표는 특히 트래픽이 많은 중요 업무용 애플리케이션에서 데이터의 중복성, 일관성, 고가용성 및 액세스 가능성을 보장하는 것입니다.
Azure Database for PostgreSQL은 기본 제공 읽기 복제본 기능 과 논리적 복제를 통한 물리적(즉, 스트리밍)의 두 가지 복제 방법을 제공합니다. 둘 다 서로 다른 사용 사례에 이상적이며 사용자는 최종 목표에 따라 다른 하나를 선택할 수 있습니다.
각 지역에 별도의 가상 네트워크가 있는 Azure 지역 간 복제에는 가상 네트워크 피어링을 통해 제공될 수 있는 지역 가상 네트워크 경계를 통한 연결이나 네트워크 어플라이언스를 통한 허브 및 스포크 아키텍처가 필요합니다.
기본적으로 DNS 이름 확인은 가상 네트워크로 범위가 지정됩니다. 한 가상 네트워크(VNET1)의 모든 클라이언트는 다른 가상 네트워크(VNET2)에 있는 Azure Database for PostgreSQL 유연한 서버 인스턴스 FQDN을 확인할 수 없습니다.
이 문제를 해결하려면 VNET1의 클라이언트가 Azure Database for PostgreSQL 유연한 서버 인스턴스 프라이빗 DNS 영역에 액세스할 수 있는지 확인해야 합니다. Azure Database for PostgreSQL 유연한 서버 인스턴스의 프라이빗 DNS 영역에 가상 네트워크 링크를 추가합니다.
지원되지 않는 가상 네트워크 시나리오
다음은 가상 네트워크 통합을 통해 만든 가상 네트워크 작업에 대한 몇 가지 제한 사항입니다.
- Azure Database for PostgreSQL 유연한 서버 인스턴스를 가상 네트워크 및 서브넷에 배포한 후에는 다른 가상 네트워크 또는 서브넷으로 이동할 수 없습니다. 가상 네트워크를 다른 리소스 그룹 또는 구독으로 이동할 수 없습니다.
- 서브넷에 리소스가 있으면 서브넷 크기(주소 공간)를 늘릴 수 없습니다.
- 가상 네트워크 삽입 리소스는 기본적으로 Private Link와 상호 작용할 수 없습니다. 프라이빗 네트워킹에 Private Link 를 사용하려면 Private Link를 사용하여 Azure Database for PostgreSQL 네트워킹을 참조하세요.
중요
Azure Resource Manager는 보안 제어로 리소스를 잠그는 기능을 지원합니다. 리소스 잠금은 리소스에 적용되고 모든 사용자 및 역할에서 유효합니다. 리소스 잠금에는 CanNotDelete와 ReadOnly의 두 가지 형식이 있습니다. 이러한 잠금 유형은 프라이빗 DNS 영역 또는 개별 레코드 집합에 적용할 수 있습니다.
프라이빗 DNS 영역 또는 개별 레코드 집합에 대해 형식의 잠금을 적용하면 Azure Database for PostgreSQL 유연한 서버 인스턴스가 DNS 레코드를 업데이트하는 기능을 방해할 수 있습니다. 또한 기본 DNS에서 보조 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(퍼블릭 주소)은 사용하지 않습니다.