Azure Database for PostgreSQL 유연한 서버 인스턴스는 수직 및 수평 크기 조정 옵션을 모두 지원합니다.
수직 크기 조정
Azure Database for PostgreSQL 유연한 서버 인스턴스에 더 많은 리소스를 추가하여 인스턴스 크기를 세로로 조정할 수 있습니다. CPU 및 할당된 메모리 수를 늘리거나 줄일 수 있습니다.
인스턴스의 네트워크 처리량은 CPU 및 메모리에 대해 선택한 값에 따라 달라집니다.
Azure Database for PostgreSQL 유연한 서버 인스턴스를 만든 후에는 독립적으로 크기를 조정할 수 있습니다.
- 컴퓨팅 계층 및 SKU.
- 스토리지 계층 및 크기.
- 백업 보존 기간
워크로드 요구 사항에 맞게 조정하도록 버스트 가능, 범용 및 메모리 최적화 간에 컴퓨팅 계층을 확장 또는 축소할 수 있습니다. 이러한 각 계층에서는 다양한 수의 CPU와 설치된 메모리 양을 사용하여 다양한 세대의 미리 구성된 다양한 하드웨어 중에서 선택할 수 있습니다. 운영 비용을 절감하고 요구 사항에 맞게 조정하면서 리소스 요구 사항을 지원하는 옵션을 선택할 수 있습니다.
vCore 및 설치된 메모리 수를 늘리거나 축소할 수 있습니다. 워크로드에 요구되는 처리량 및 IOPS 요구 사항을 수용하도록 스토리지 계층을 위아래로 구성할 수도 있습니다. 스토리지 크기만 늘릴 수 있습니다. 요구 사항에 따라 백업 보존 기간을 7~35일로 늘리거나 줄일 수 있습니다.
여러 인터페이스를 사용하여 이러한 리소스의 크기를 조정할 수 있습니다. 예를 들어 Azure Portal 또는 Azure CLI를 사용할 수 있습니다.
참고
인스턴스에 할당된 스토리지의 크기를 늘리면 더 작은 크기로 축소할 수 없습니다.
수평적 크기 조정
Azure Database for PostgreSQL 탄력적 클러스터를 사용하면 단일 데이터베이스 인스턴스의 기능 이상으로 확장되는 데이터 워크로드를 지원하도록 데이터베이스를 수평적으로 확장할 수 있습니다. 또한 탄력적 클러스터를 사용하면 클러스터의 모든 노드에서 동시에 병렬 작업을 실행할 수 있으므로 처리량이 크게 증가하고 대기 시간이 매우 짧아질 수 있습니다. 탄력적 클러스터는 행 기반 분할 및 스키마 기반 분할이라는 두 개의 테이블 분할 모델을 제공합니다.
읽기 복제본 크기 조정
인스턴스 크기를 수평으로 조정하는 또 다른 방법은 읽기 복제본을 만드는 것입니다. 읽기 복제본을 사용하면 읽기 워크로드를 별도의 Azure Database for PostgreSQL 유연한 서버 인스턴스로 스케일링할 수 있습니다. 주 인스턴스의 성능 및 가용성에는 영향을 주지 않습니다.
가로 크기 조정 설정에서 기본 인스턴스 및 읽기 복제본의 크기를 세로로 조정할 수도 있습니다.
vCore 수 또는 컴퓨팅 계층을 변경하면 할당된 새 하드웨어가 서버 워크로드 실행을 시작하도록 인스턴스가 다시 시작됩니다. 이 시간 동안 시스템은 새 서버 유형으로 전환됩니다. 새 연결을 설정할 수 없으며, 커밋되지 않은 모든 트랜잭션이 롤백됩니다.
서버를 다시 시작하는 데 걸리는 전체 시간은 다시 시작할 때 크래시 복구 프로세스 및 데이터베이스 작업에 따라 달라집니다. 다시 시작에는 일반적으로 1분 이하가 걸리지만 몇 분 정도 걸릴 수 있습니다. 시간은 다시 시작 시 트랜잭션 작업에 따라 달라집니다.
애플리케이션이 컴퓨팅 크기 조정 중에 발생할 수 있는 진행 중인 트랜잭션 손실에 민감하다면 트랜잭션 재시도 패턴을 구현하세요.
스토리지를 스케일링해도 대부분의 경우 서버를 다시 시작할 필요가 없습니다. 자세한 내용은 Azure Database for PostgreSQL의 스토리지 옵션을 참조하세요.
백업 보존 기간 변경은 온라인 작업입니다.
다시 시작 시간을 개선하려면 비혼잡 시간대에 크기 조정 작업을 수행합니다. 이렇게 하면 데이터베이스 서버를 다시 시작하는 데 필요한 시간이 줄어듭니다.
거의 0에 가까운 가동 중지 시간 스케일링
거의 0에 가까운 가동 중지 시간 스케일링은 스토리지 및 컴퓨팅 계층을 수정할 때 가동 중지 시간을 최소화하도록 설계된 기능입니다. vCore 수를 수정하거나 컴퓨팅 계층을 변경하면 서버가 다시 시작하여 새 구성을 적용합니다. 이렇게 새 서버로 전환하는 중에는 새로운 연결을 설정할 수 없습니다.
일반적으로 이 프로세스는 정기적인 스케일링을 통해 2~10분 정도 걸릴 수 있습니다. 가동 중지 시간이 거의 0에 가까운 크기 조정 기능을 사용하면 이 기간이 30초 미만으로 줄어듭니다. 리소스 스케일링 동안 가동 중지 시간이 감소하면 데이터베이스 인스턴스의 전체 가용성이 향상됩니다.
작동 방법
크기 조정 시나리오에서 Azure Database for PostgreSQL 유연한 서버 인스턴스를 업데이트하는 경우 서비스는 업데이트된 구성으로 서버에 대한 새 가상 머신을 만듭니다. 그런 다음 현재 인스턴스를 실행 중인 가상 머신과 동기화한 다음 잠시 중단하여 새 가상 머신으로 전환합니다. 그런 다음 백그라운드 프로세스는 이전 가상 머신을 제거합니다.
이 프로세스는 가동 중지 시간을 최소화하면서 원활한 업데이트를 가능하게 하며 스토리지 또는 컴퓨팅 계층을 변경할 때 자동으로 트리거됩니다. 이 기능을 사용하려면 아무 작업도 수행할 필요가 없습니다. 이 기능은 HA 및 비 HA Azure Database for PostgreSQL 유연한 서버 인스턴스 모두에서 지원됩니다.
주 서버와 하나 이상의 읽기 복제본으로 구성된 수평 크기 조정 구성의 경우 크기 조정 작업은 데이터 일관성을 보장하고 가동 중지 시간을 최소화하기 위해 특정 시퀀스를 따라야 합니다. 해당 시퀀스에 대한 자세한 내용은 읽기 복제본을 사용한 크기 조정을 참조하세요.
참고
거의 0에 가까운 가동 중지 시간 크기 조정이 기본 작업 유형입니다. 다음과 같은 제한 사항이 발생하면 시스템은 정기적인 스케일링으로 전환되며, 가동 중지 시간이 거의 0에 가까운 크기 조정에 비해 가동 중지 시간이 더 많이 발생합니다.
정확한 가동 중지 시간 예상
- 가동 중지 시간: 대부분의 경우 가동 중지 시간은 10~30초입니다.
-
기타 고려 사항: 스케일링 이벤트 후에는 약 30초의 고유한 DNS TTL(
Time-To-Live) 기간이 있습니다. 크기 조정 프로세스는 이 기간을 직접 제어하지 않습니다. DNS 동작의 표준 부분입니다. 애플리케이션 관점에서 스케일링 중에 발생하는 총 가동 중지 시간은 40~60초 범위일 수 있습니다.
고려 사항 및 제한 사항
- 가동 중지 시간이 거의 0에 가까운 크기 조정이 작동하려면 가상 네트워크 통합 네트워킹을 사용할 때 위임된 서브넷의 IP 주소 간에 모든 인바운드 및 아웃바운드 연결을 허용합니다. 이러한 연결을 허용하지 않으면 거의 0에 가까운 가동 중지 시간 크기 조정 프로세스가 작동하지 않으며 표준 크기 조정 워크플로를 통해 크기 조정이 수행됩니다.
- 구독에 지역 용량 제약 조건 또는 할당량 제한이 있는 경우 거의 0에 가까운 가동 중지 시간 크기 조정이 작동하지 않습니다.
- 복제본 서버는 주 서버에서만 지원되므로 거의 0에 가까운 가동 중지 시간 크기 조정이 작동하지 않습니다. 복제본 서버의 경우 크기 조정 작업은 자동으로 일반 프로세스를 거치게 됩니다.
- 가상 네트워크 삽입 서버에 위임된 서브넷에 사용 가능한 IP 주소가 충분하지 않은 경우 거의 0에 가까운 가동 중지 시간 크기 조정이 작동하지 않습니다. 독립 실행형 서버가 있는 경우 하나의 추가 IP 주소가 필요합니다. 고가용성을 사용하는 인스턴스의 경우 두 개의 추가 IP 주소가 필요합니다.
- 논리 복제 슬롯은 거의 0에 가까운 가동 중지 시간 장애 조치(failover) 이벤트 중에 유지되지 않습니다. 논리 복제 슬롯을 유지하고 스케일링 작업 후 데이터 일관성을 보장하려면 pg_failover_slot 확장을 사용합니다. 자세한 내용은 유연한 서버 인스턴스에서 pg_failover_slots 확장 활성화를 참조하세요.
- 가동 중지 시간이 거의 없는 크기 조정은 기록되지 않은 테이블에서는 작동하지 않습니다. 데이터에 대해 기록되지 않은 테이블을 사용하는 경우 거의 0에 가까운 가동 중지 시간 크기 조정 후 해당 테이블의 모든 데이터가 손실됩니다.
- 버스트 가능 계층의 1 또는 2개 vCore의 컴퓨팅 크기로 서버 컴퓨팅의 크기를 조정하는 경우 거의 0은 작동하지 않습니다.