Azure Database for PostgreSQL – Elastic Clusters는 Citus 확장을 사용하여 Azure Database for PostgreSQL 유연한 서버를 기반으로 하는 Azure 분산 PostgreSQL 제품의 다음 진화입니다. 오늘날 PostgreSQL용 Azure Cosmos DB를 실행하는 고객의 경우 Elastic Clusters는 분산 Postgres 워크로드에 대한 기능 패리티를 제공하는 동시에 보다 통합되고 유연하며 비용 효율적인 경로를 제공합니다.
명확한 미래 예측 로드맵: 탄력적 클러스터는 페일오버, 스토리지 자동 증가 및 장기 보존과 같은 계획된 개선 사항에 대한 지속적인 투자를 통해 Azure의 분산 PostgreSQL에 대한 전략적 방향입니다. PostgreSQL용 Azure Cosmos DB는 이 기간 동안 지원이 제한되어 사용 중지 경로에 있습니다.
더 낮고 간단한 비용 모델(전용 코디네이터 추가 요금 없음) : Elastic Clusters에는 별도로 청구되는 코디네이터 전용 노드가 필요하지 않으므로 기준 비용을 줄이고 스케일 아웃할 때 가격을 더 쉽게 예측할 수 있습니다.
보다 유연한 성능 선택: 버스트 가능, 범용 및 메모리 최적화 계층과 최신 컴퓨팅 시리즈 중에서 워크로드가 진화함에 따라 노드당 적절한 크기와 성능을 선택할 수 있습니다.
모든 노드에서 쿼리 실행: 탄력적 클러스터를 사용하면 모든 노드를 통해 쿼리에 액세스할 수 있으므로 여러 수신 지점의 이점을 활용하는 도구, 문제 해결 및 워크로드 패턴에 대한 운영 유연성이 향상됩니다.
최신 PostgreSQL 기능: 최신 PostgreSQL 버전(PostgreSQL 17 지원 포함)을 더 빠르게 채택하면 고객이 보안 업데이트, 성능 향상 및 새로운 언어 기능에 더 일찍 액세스할 수 있습니다.
Azure Database for PostgreSQL 유연한 서버를 기반으로 구축: Elastic Clusters는 고객이 이미 유연한 서버에 사용하고 있는 운영 모델(백업, 모니터링/메트릭, 유지 관리 제어 및 플랫폼 통합)을 상속하여 일-2 작업의 복잡성을 줄입니다.
더 강력한 ID 및 보안 통합: 관리 ID 및 Microsoft Entra ID 인증을 지원하면 비밀 관리를 간소화하고 엔터프라이즈 ID 컨트롤과 데이터베이스 액세스를 정렬할 수 있습니다.
기능 비교
| 기능/범주 | PostgreSQL용 Azure Cosmos DB | Azure Database for PostgreSQL 탄력적 클러스터 | 참고/패리티 |
|---|---|---|---|
| 기본 기술 | PostgreSQL + Citus 확장(분산 테이블/샤드) | PostgreSQL + Citus 확장(가로 분할) | 패리티. |
| 분할 모델 | 행 기반(분산 테이블), 스키마 기반(분산 스키마) | 행 기반 및 스키마 기반 분할 | 패리티. |
| 아키텍처 | 코디네이터 노드 + 작업자 노드(공유 없음) | Citus 클러스터로 상호 연결된 여러 유연한 서버 노드 | 비슷한; Elastic은 유연한 서버 인스턴스를 기반으로 합니다. |
| 가로 크기 조정 | 작업자 노드 추가; 분할된 데이터베이스 리밸런스 | 작업자 노드 추가; 데이터 균형 조정 | 패리티. |
| 수직 크기 조정 | 노드당 컴퓨팅/스토리지 크기 조정 | 노드당 컴퓨팅/스토리지 크기 조정 | 패리티. |
| 고가용성 | 예(영역 중복 옵션, 자동 장애 조치) | 예(클러스터 인식 HA) | 패리티. |
| 복제본 읽기 | 예 | 예 | 패리티. |
| 전용 코디네이터(추가 비용) | 예 | No | 탄력적 이점. |
| 모든 노드에서 쿼리 | No | 예 | 탄력적 이점. |
| 컴퓨팅 선택 | 버스트 가능 또는 고정된 메모리-코어 비율; 컴퓨트 세대 선택 불가 | 버스트 가능, 범용, 메모리 최적화; 컴퓨팅 계열 선택 | 탄력적 이점. |
| 노드당 최대 컴퓨팅(코어) | 96 vCore | 96 (곧 192) | 패리티. |
| 가격 책정(메모리 최적화) | 노드: $0.1425/vCore 시간 + 코디네이터($0.44/시간) 또는 $0.11/vCore 시간 | $0.125/vCore 시간(전용 코디네이터 없음) | 탄력적 이점(더 간단한 비용 모델). |
| 컴퓨팅 가격 책정(범용) | N/A | $0.09/vCore당 시간 | 탄력 전용 |
| 스토리지 가격 책정 | $0.115/GB-month | $0.115/GB당 월간 비용 | 패리티. |
| 온라인 리밸런싱 | 예 | 예 | 패리티. |
| PostgreSQL 버전 | 최신 버전까지(예: 일반적으로 15/16 버전) | PostgreSQL 17을 비롯한 최신 지원 | 탄력적 이점(최신 버전 지원). |
| Postgres 17/18 지원 | No | 예 | 탄력적 이점(최신 버전 지원). |
| 확장 지원 | 키 확장의 하위 집합(예: PostGIS, JSONB) | 표준 유연한 서버 확장; 몇 가지 제한 사항(예: 클러스터 모드에서 TimescaleDB 없음) | 패리티(사소한 차이점). |
| Microsoft Entra ID 인증 | 예 | 예 | 패리티. |
| HA 계획된 장애 조치(failover) | No | 계획됨(GA+) | 간격(계획됨). |
| 프라이빗 엔드포인트 | 예 | 예 | 패리티. |
| 가상 네트워크 | No | No | 패리티(지원되지 않음). |
| PgBouncer 지원 | — | 예 | 탄력적 이점(최신 버전 지원). |
| 노드당 최대 연결 수 | 노드당 300개(0~3 vCore); 노드당 500개(4~15 vCore); 노드당 1000개(16 vCore 이상) 최대 2500 | 노드당 3000 | 탄력적 이점. |
| 클러스터 또는 노드 수준 메트릭 | 예 | 예 | 패리티. |
| 다중 테넌트 모니터링 | 예 | 예 | 패리티. |
| NOLOGIN 역할 만들기 | No | 예 | 탄력적 이점. |
| 유지 관리 창 | 예 | 예 | 패리티. |
| 지역 백업 및 복원 | 예 | 예 | 패리티. |
| 관리되는 아이덴티티 | No | 예 | 탄력적 이점. |
| 고객 관리형 키(암호화) | 예 | 예 | 패리티. |
| 테라폼 | 예 | 예 | 패리티. |
| 스토리지 자동 증가 | No | 계획됨(GA+) | 탄력적 이점. |
| 프리미엄 SSD v2(80K IOPS/노드) | No | 계획됨(GA+) | 탄력적 이점. |
| 노드 제거 | 아니요 | No | Parity |
| 장기 보존 | No | 로드맵(GA+) | 탄력적 이점. |
| 쿼리 저장소 | No | 로드맵(GA+) | 탄력적 이점. |
| 관리 및 통합 | Azure Cosmos DB 포털/환경의 일부 Cosmos 에코시스템과의 관계 | Azure Database for PostgreSQL 유연한 서버에 통합됨(예: 백업, 메트릭, Microsoft Entra ID) | 다른 포털; Elastic은 유연한 서버 기능을 활용합니다. |
| 가격 책정 모델 | vCore 기반; 코디네이터/작업자를 위한 별도의 | vCore, 스토리지, IOPS(Citus에 대한 추가 비용 없음) | 탄력적 이점(더 간단한 모델). |
| 네트워킹 | 공용 액세스(방화벽 규칙), 프라이빗 액세스(Private Link) 또는 둘 다 | 공용 액세스(허용된 IP 주소); 기본 유연한 서버 노드에서 Private Link를 통한 프라이빗 액세스 | 패리티(유사한 옵션). |
1 노드 제거는 노드에서 데이터를 이동하기 위해 리밸런싱을 통해 사용할 수 있지만 노드 자체는 자동으로 프로비전 해제되지 않습니다.
마이그레이션 도구
Azure Cosmos DB for PostgreSQL에서 Azure Database for PostgreSQL Elastic Cluster로 원활하게 전환할 수 있도록 전용 마이그레이션 도구가 제공됩니다. 이 도구는 스키마 및 데이터 마이그레이션을 자동화하고 가동 중지 시간을 최소화하며 데이터 무결성을 보장합니다.
마이그레이션 접근 방식은 CPG 클러스터에서 스냅샷을 만들고 대상 EC(Elastic Cluster)의 기본 데이터 디스크로 탑재하여 Flex에서 새 데이터 디스크를 만드는 데 중점을 두고, 마이그레이션 시간을 대폭 줄이고 네트워크 품질에 영향을 받지 않고 데이터 충실도를 보장합니다. 그런 다음 원래 Flex /datadrive에서 새 디스크로 델타 파일(확장, PG 및 확장 구성, 인증서, 보관 로그 등)을 복사합니다.
팝업 미리 알림과 함께 도구는 4월 13일부터 Azure Cosmos DB for PostgreSQL의 마이그레이션 탭을 통해 사용할 수있습니다.
여기에서 대상 서버에 대한 간단한 세부 정보를 제공하여 마이그레이션을 시작할 수 있습니다.
SKU 매핑
Azure Cosmos DB for PostgreSQL은 아래 매핑 테이블에 따라 대상 Azure Database for PostgreSQL(탄력적 클러스터)과 일치합니다. 마이그레이션 후 고객은 거의 0개의 가동 중지 시간으로 확장 또는 축소할 수 있습니다.
| Source ServerEdition | 원본 vCore | 대상 이름 | 대상 계층 |
|---|---|---|---|
| 버스트 가능한 메모리 최적화 | 1 | Standard_B2s | 버스트 가능 |
| 버스트 가능 범용 | 2 | Standard_B2s | 버스트 가능 |
| 일반적인 목적 | 2 | Standard_D2ds_v5 | 일반적인 목적 |
| 일반적인 목적 | 4 | Standard_D4ds_v5 | 일반적인 목적 |
| 일반적인 목적 | 8 | Standard_D8ds_v5 | 일반적인 목적 |
| 일반적인 목적 | 16 | Standard_D16ds_v5 | 일반적인 목적 |
| 일반적인 목적 | 32 | Standard_D32ds_v5 | 일반적인 목적 |
| 일반적인 목적 | 64 | Standard_D64ds_v5 | 일반적인 목적 |
| 일반적인 목적 | 96 | Standard_D96ds_v5 | 일반적인 목적 |
| 메모리 최적화 | 2 | Standard_E2ds_v5 | 메모리 최적화 |
| 메모리 최적화 | 4 | Standard_E4ds_v5 | 메모리 최적화 |
| 메모리 최적화 | 8 | Standard_E8ds_v5 | 메모리 최적화 |
| 메모리 최적화 | 16 | Standard_E16ds_v5 | 메모리 최적화 |
| 메모리 최적화 | 32 | Standard_E32ds_v5 | 메모리 최적화 |
| 메모리 최적화 | 64 | Standard_E64ds_v5 | 메모리 최적화 |
| 메모리 최적화 | 96 | Standard_E96ds_v5 | 메모리 최적화 |
마이그레이션 흐름
사용자가 Azure Portal의 CPG 클러스터 페이지에서 마이그레이션을 시작합니다.
포털은 사전 유효성 검사를 실행합니다.
검사가 통과되면 포털은 CPG 마이그레이션 설정(예: 데이터 정렬/PG+Citus 버전 설정)을 사용하여 대상 EC(Elastic Cluster)를 프로비전합니다.
포털은 프로비전된 EC에서 마이그레이션을 시작합니다.
마이그레이션 도구는 CPG 클러스터를 읽기 전용으로 전환하고 스냅샷 만들기를 트리거합니다(다중 노드의 경우 노드당 하나).
스냅샷 리소스 ID가 있는 Elastic Cluster를 호출하여 디스크 기반 마이그레이션을 시작합니다.
스냅샷에서 새 데이터 디스크를 만들고, EC를 잠그고, 컨테이너를 중지하고, 새 디스크를 기본 /datadrive로 교환합니다.
"델타" 플랫폼 파일을 새 디스크(확장, PG/확장 구성, 인증서, 보관/WAL 등)에 복사한 다음 소유권/권한을 복원하고 필요한 메타데이터 수정(예: 노드 매핑, 역할, 확장)을 수행합니다.
컨테이너를 시작하고 마이그레이션 작업을 완료합니다.
성공 후 도구가 사용자 재정의 구성 및 HA 설정을 포함하여 EC에 마이그레이션 후 설정을 적용합니다.
마이그레이션 완료: 포털이 완료되면 성공/실패 상태를 업데이트합니다. CPG 클러스터가 중지되고 Elastic Cluster는 고객이 전환할 새 쓰기 가능 대상이 됩니다(새 연결 문자열, 필요한 경우 PEC 다시 만들기).
평균 마이그레이션 타이밍
대부분의 경우 엔드 투 엔드 마이그레이션은 10분 안에 완료됩니다. 원본 클러스터가 읽기 전용으로 전환된 시점부터 대상 Elastic Cluster가 쓰기 가능할 때까지 의 쓰기 잠금(읽기 전용) 창은 일반적으로 평균 5~8분이므로 표준 예약된 유지 관리 기간 내에서 실행하기에 적합합니다.
타이밍에 영향을 줄 수 있는 주요 요인: 데이터베이스 크기 및 노드 수(더 많은 스냅샷/디스크), 확장 공간.