Azure Database for PostgreSQL 은 데이터베이스 관리 기능 및 구성 설정에 대한 세부적인 제어 및 유연성을 제공하도록 설계된 완전 관리형 데이터베이스 서비스입니다. 이 서비스는 요구 사항에 따라 고가용성 및 재해 복구 기능을 제공합니다.
Azure를 사용하는 경우 안정성은 공유 책임입니다. Microsoft는 복원력 및 복구를 지원하는 다양한 기능을 제공합니다. 이러한 기능이 사용하는 모든 서비스 내에서 작동하는 방식을 이해하고 비즈니스 목표 및 가동 시간 목표를 충족하는 데 필요한 기능을 선택할 책임이 있습니다.
이 문서에서는 일시적인 오류, 가용성 영역 중단, 지역 중단 및 서비스 유지 관리를 포함하여 다양한 잠재적 중단 및 문제에 대해 Azure Database for PostgreSQL을 복원하는 방법을 설명합니다. 또한 백업을 사용하여 다른 유형의 문제에서 복구하는 방법을 설명하고 Azure Database for PostgreSQL SLA(서비스 수준 계약)에 대한 몇 가지 주요 정보를 강조 표시합니다.
프로덕션 배포 권장 사항
솔루션의 안정성 요구 사항을 지원하기 위해 Azure Database for PostgreSQL을 배포하는 방법과 안정성이 아키텍처의 다른 측면에 미치는 영향에 대해 알아보려면 Azure Well-Architected Framework에서 Azure Database for PostgreSQL에 대한 아키텍처 모범 사례를 참조하세요.
안정성 아키텍처 개요
이 섹션에서는 안정성 관점에서 가장 관련성이 높은 서비스가 작동하는 방식의 몇 가지 중요한 측면을 설명합니다. 이 섹션에서는 배포하고 사용하는 일부 리소스 및 기능을 포함하는 논리 아키텍처를 소개합니다. 또한 서비스의 작동 방식에 대한 세부 정보를 제공하는 물리적 아키텍처에 대해서도 설명합니다.
논리 아키텍처
Azure Database for PostgreSQL을 사용하는 경우 데이터베이스 서버를 지원하는 데 필요한 컴퓨팅 및 스토리지 리소스를 나타내는 서버를 배포합니다. 서버에 하나 이상의 데이터베이스를 배포합니다 .
서버는 버스트 가능, 범용 및 메모리 최적화와 같은 여러 컴퓨팅 계층에 배포할 수 있으며, 각 서버는 다양한 종류의 워크로드에 최적화되어 있습니다. 일부 Azure 지역에서는 Azure 기밀 컴퓨팅을 사용하여 서버를 배포할 수 있습니다.
일반 서비스 아키텍처 및 배포 모델에 대한 자세한 내용은 Azure Database for PostgreSQL이란?을 참조하세요.
물리적 아키텍처
컴퓨팅 및 스토리지 분리: Azure Database for PostgreSQL은 컴퓨팅 및 스토리지 분리 아키텍처를 사용하여 고가용성을 지원합니다. 데이터베이스 엔진은 Linux 가상 머신에서 실행되며 데이터 파일은 Azure Storage에 저장되며, 데이터 내구성을 보장하기 위해 데이터베이스 파일의 로컬 중복 동기 복사본 3개를 유지 관리합니다.
고가용성: 필요에 따라 서버에서 고가 용성 구성 을 사용하도록 설정할 수 있습니다. 고가용성 구성을 사용하도록 설정하면 서비스는 웜 대기 서버를 프로비전하고 서버 유지 관리를 수행합니다. 주 서버의 데이터 변경 내용은 주 서버가 실패하는 동안 데이터가 손실되지 않도록 대기 서버에 동기적으로 복제됩니다.
아키텍처는 컴퓨팅 계층을 스토리지 계층과 분리하여 서비스가 다양한 유형의 오류를 적절하게 처리할 수 있도록 합니다. 복원력을 높이기 위해 가용성 영역에 서버를 분산할 수 있습니다.
대기 서버는 vCore, 스토리지 및 네트워크 설정을 포함하여 주 서버와 동일한 VM 구성에 배포됩니다.
장애 조치( failover)를 수행하여 서버 간에 전환할 수 있습니다. 장애 조치(failover)에는 주 서버가 실패할 때 사용되는 강제 장애 조치( failover)와 일부 유지 관리 작업 중 및 장애 조치(failover) 중에 애플리케이션 가동 중지 시간을 최소화해야 하는 다른 시나리오에서 사용되는 계획된 장애 조치( failover)의 두 가지 유형이 있습니다.
중지, 시작, 다시 시작과 같은 작업은 주 데이터베이스 서버와 대기 데이터베이스 서버 모두에서 동시에 수행됩니다. 계획된 이벤트는 스케일 아웃 컴퓨팅 및 스케일 아웃 스토리지와 같이 대기 서버에서 먼저 발생하고, 이후 주 서버에서 발생합니다. 현재 서버는 이러한 계획된 작업에 대해 장애 조치(failover)하지 않습니다.
백업을: Azure Database for PostgreSQL은 자동으로 서버 백업을 만듭니다. 자세한 내용은 백업 및 복원을 참조하세요.
일시적인 오류에 대한 복원력
일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리할 수 있는 것이 중요합니다.
모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 임시 오류 처리 지침을 따라야 합니다. 자세한 내용은 임시 오류 처리를 위한 권장 사항을 참조하세요.
애플리케이션은 유지 관리, 크기 조정 작업 또는 네트워크 중단 중에 발생할 수 있는 일시적인 연결 오류를 처리해야 합니다. 다음 권장 사항을 따릅니다.
- 애플리케이션에 일시적인 오류가 발생하면 지수 백오프를 사용하여 작업을 다시 시도합니다. 재시도 사이의 지연 시간을 늘리고 시도 횟수를 제한합니다. 최대 재시도 후에도 작업이 계속 실패하는 경우 실패로 처리합니다.
- 가능한 경우 재시도를 자동으로 처리하는 클라이언트 라이브러리(드라이버라고도 함)를 사용합니다.
- 쓰기 작업 중에 발생하는 일시적인 오류는 더 신중하게 고려해야 합니다. 여러 번 안전하게 실행할 수 있도록 쓰기 작업을 idempotent로 만드는 것이 좋습니다.
자세한 내용은 Azure Database for PostgreSQL의 일시적인 연결 오류 처리를 참조하세요.
가용성 영역 오류에 대한 복원력
가용성 영역은 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.
고가용성 구성을 통해 가용 영역 지원 유형을 선택할 수 있습니다. 고가용성을 사용하도록 설정하면 주 서버와 함께 대기 서버가 배포됩니다. 이 고가용성 모델은 오류가 발생하는 동안 커밋된 데이터가 손실되지 않도록 하는 데 도움이 됩니다. 서버에서 사용하는 고가용성 배포 모델 중에서 데이터는 기본 서버와 대기 서버 모두에 동기적으로 커밋됩니다. 주 서버에 중단이 발생하면 서버는 자동으로 대기 서버로 전환됩니다.
데이터 파일 및 WAL(미리 쓰기 로그)은 각 가용성 영역 내의 프리미엄 관리 디스크에 저장되며, 각 영역 내에 세 개의 데이터 복사본을 자동으로 저장하는 LRS(로컬 중복 스토리지)가 있습니다.
Azure Database for PostgreSQL은 고가용성을 사용하는 경우 두 가지 가용성 영역 구성 유형을 지원합니다.
영역 중복 고가용성: 영역 중복성은 하나의 가용성 영역에 주 서버를 배포하고 다른 가용성 영역에 대기 서버를 배포하여 가장 높은 수준의 영역 복원력을 제공합니다. 대기 서버는 주 서버와 비슷한 컴퓨팅, 스토리지 및 네트워크 구성을 사용합니다. 영역 중복 구성은 주 서버와 대기 서버 간의 전체 스택을 물리적으로 격리합니다.
기본 및 대기 서버의 가용성 영역을 선택하거나 Microsoft에서 선택하도록 할 수 있습니다.
프로덕션 서버에 대한 영역 중복 배포를 권장합니다.
쓰기 작업은 서비스가 대기 서버에 데이터를 동기적으로 복제하기 때문에 커밋 대기 시간이 약간 증가할 수 있습니다. 그 영향은 워크로드, 선택한 SKU 및 지역에 따라 달라집니다.
영역(동일한 영역) 고가용성: 주 서버와 대기 서버는 동일한 가용성 영역을 사용합니다. 주 서버에 장애가 발생해도 영역이 여전히 정상이면 서버가 자동으로 대기 서버로 장애 조치됩니다. 영역 배포는 단일 가용성 영역 내에서 고가용성을 제공합니다. 노드 수준 오류로부터 보호하고 계획 및 계획되지 않은 가동 중지 시간 이벤트 중에 애플리케이션 가동 중지 시간을 줄이는 데도 도움이 됩니다. 하지만 해당 지역에서의 서비스 중단을 방지하지는 않습니다.
영역(동일한 영역) 고가용성은 다음 상황에서만 사용할 수 있습니다.
- 이 지역은 가용성 영역을 지원하지 않습니다. 지역은 효과적으로 단일 영역으로 작동하므로 선택할 수 있는 유일한 고가용성 구성은 동일한 영역입니다.
- 지역에 영역 중복 배포에 충분한 용량이 없는 경우 서비스는 처음에 두 서버를 동일한 가용성 영역에 배치하고 용량을 사용할 수 있게 되면 자동으로 별도의 영역으로 마이그레이션할 수 있습니다. 이 옵션은 Azure Portal 또는 Azure CLI를 사용하여 서버를 배포할 때 사용할 수 있습니다. 자세한 내용은 중요 비즈니스용(고가용성) 구성 옵션을 참조하세요.
서버는 동일한 영역에 있으므로 동일한 영역 내에 배포하는 애플리케이션에 대한 쓰기 대기 시간을 줄일 수 있습니다.
고가용성 없이 서버를 구성하는 경우 단일 서버에서 실행됩니다. 해당 서버 또는 해당 영역이 다운되면 서버를 사용할 수 없습니다. 자세한 내용은 가용성 영역이 없는 구성을 참조하세요.
요구 사항
지역 지원: Azure Database for PostgreSQL의 가용성 영역 구성 지원은 Azure 지역마다 다릅니다. 전체 지역 목록 및 가용성 영역 지원 유형 및 해당 지역에 대한 특정 고려 사항은 Azure 지역을 참조하세요.
컴퓨팅 계층: 다음 표에서는 각 가용성 영역 지원 유형에 대한 컴퓨팅 계층 지원을 나열합니다.
가격 책정 계층 Zone-redundant 영역(동일 영역) 버스트 가능 지원되지 않음 지원됨 일반적 목적 지원됨 지원됨 메모리 최적화 지원됨 지원됨 서비스 계층: 영역 중복에는 일반 범용 또는 메모리 최적화 계층이 필요합니다.
영역(동일한 영역) 배포는 모든 가격 책정 계층에서 지원됩니다.
고려 사항
지역 용량: 지역에 영역 중복 배포에 충분한 용량이 없는 경우 서비스는 처음에 두 서버를 동일한 가용성 영역에 배치하고 용량을 사용할 수 있게 되면 자동으로 별도의 영역으로 마이그레이션할 수 있습니다. 이 옵션은 Azure Portal 또는 Azure CLI를 사용하여 서버를 배포할 때 사용할 수 있습니다. 자세한 내용은 중요 비즈니스용(고가용성) 구성 옵션을 참조하세요.
Cost
고가용성을 사용하도록 설정하면 대기 서버가 생성되고 기본 서버와 동일한 속도로 요금이 청구됩니다. 가용성 영역 구성은 비용에 영향을 주지 않습니다. 가용성 영역 내에서 또는 가용성 영역 간에 데이터 복제에 대한 요금은 없습니다. 백업 스토리지 볼륨에 따라 백업 스토리지에 대한 요금이 청구될 수도 있습니다. 자세한 가격 책정 정보는 Azure Database for PostgreSQL 가격 책정을 참조하세요.
가용성 영역 지원 구성
서버에 대한 가용성 영역 지원을 구성하려면 고가용성 설정을 구성합니다.
영역 중복 서버를 만듭니다. 고가용성 및 영역 중복을 사용하도록 설정된 서버를 만드는 방법을 알아보려면 빠른 시작: Azure Portal에서 Azure Database for PostgreSQL 만들기를 참조하세요.
기존 서버에 대한 가용성 영역 구성을 변경 합니다. 고가용성 설정을 변경하여 기존 서버에 대한 가용성 영역 구성을 변경할 수 있습니다. 자세한 단계는 기존 서버에 고가용성을 활성화하기를 참조하세요.
기본 또는 대기 서버에 사용되는 영역은 만든 후에는 변경할 수 없습니다. 서버를 다시 만들어야 합니다.
팁 (조언)
고가용성 구성을 변경하기 전에 서버 활동이 낮을 때까지 기다리는 것이 좋습니다.
고가용성 사용 안 함: 고가용성을 사용하지 않도록 설정하면 대기 서버가 제거되므로 서버가 가용성 영역의 중단에 복원력이 없습니다. 자세한 내용은 고가용성 비활성화를 참조하세요.
모든 영역이 정상인 경우의 동작
이 섹션에서는 서버가 고가용성 및 가용성 영역 지원으로 구성되고 모든 가용성 영역이 작동할 때 예상되는 사항에 대해 설명합니다.
영역 간 작업: PostgreSQL 클라이언트 애플리케이션은 데이터베이스 서버 이름을 사용하여 주 서버에 연결합니다. Azure Database for PostgreSQL은 모든 데이터베이스 연결 및 쿼리가 주 가용성 영역의 주 서버에서 처리되는 활성/수동 구성을 사용합니다. 대기 서버는 정상적인 작업 중에 클라이언트 트래픽을 제공하지 않습니다.
영역 간 데이터 복제: 데이터에 대한 변경 내용은 주 서버와 대기 서버 간에 동기적으로 복제됩니다. 트랜잭션은 주 서버와 대기 서버가 모두 쓰기를 승인할 때까지 완료된 것으로 간주되지 않습니다.
애플리케이션 트랜잭션에 의해 트리거된 쓰기 및 커밋이 주 서버의 WAL에 첫 번째 로그로 기록됩니다. 주 서버는 Postgres 스트리밍 프로토콜을 사용하여 이러한 로그를 대기 서버로 스트리밍합니다. 대기 서버 스토리지가 로그를 유지하면 주 서버는 쓰기 완료를 승인합니다. 애플리케이션은 이 승인 후에만 트랜잭션을 커밋합니다. 이 승인 프로세스는 로그가 대기 서버에 적용될 때까지 대기하지 않습니다.
복제의 효과는 서버에서 사용하는 가용성 영역 구성에 따라 다릅니다.
영역 중복: 서버는 별도의 영역에 있으므로 이 방법을 사용하면 영역 오류가 발생한 동안 데이터가 손실되지 않습니다. 영역 장애에 대해 회복 지점 목표(RPO) 0에 도달하는 상황이라고도 합니다.
그러나 영역 간 복제로 인해 약간의 추가 대기 시간이 발생할 수 있습니다. 대기 시간의 영향은 애플리케이션에 따라 달라지며 대부분의 애플리케이션에서는 무시할 수 있습니다.
영역: 두 서버가 동일한 영역에 있으므로 영역 간에 트래픽이 복제되지 않습니다.
메모
시스템은 로그 데이터를 대기 서버에 실시간으로 복제합니다. 실수로 테이블 삭제 또는 잘못된 데이터 업데이트와 같은 주 서버의 사용자 오류는 대기 서버에 복제됩니다. 따라서 대기를 사용하여 이러한 종류의 오류를 복구할 수 없으며 백업에서 지정 시간 복원을 수행해야 합니다. 자세한 내용은 백업 및 복원을 참조하세요.
영역 오류 중 동작
이 섹션에서는 서버가 고가용성 및 가용성 영역 지원으로 구성되고 가용성 영역 중단이 발생할 때 예상되는 사항에 대해 설명합니다.
검색 및 응답: Azure는 주 서버와 대기 서버의 상태를 주기적으로 확인합니다. 여러 ping 후 상태 모니터링에서 주 서버에 연결할 수 없음을 감지하면 서비스는 대기 서버에 대한 자동 장애 조치(failover)를 시작합니다. 상태 모니터링 알고리즘은 여러 데이터 요소를 사용하여 가양성 상황을 방지합니다.
영역 오류가 발생할 경우 서버에서 사용하는 가용성 영역 구성에 따라 동작이 다릅니다.
영역 중복: Azure Database for PostgreSQL은 가용성 영역 오류를 자동으로 검색합니다. 가능한 고가용성 상태 유형을 보려면 고가용성 상태 유형을 참조하세요. 영역이 실패하면 Azure는 별도의 작업 없이 대기 서버로 강제 장애 조치를 시작합니다.
영역: 영역 서버를 호스트하는 가용성 영역을 사용할 수 없게 되면 주 서버와 대기 서버를 모두 사용할 수 없습니다. 이 시나리오에서 서비스는 자동 장애 조치(failover)를 제공하지 않습니다. 영역 중단을 감지하고 다른 가용성 영역 또는 지역의 별도 서버로 영역 중복 백업 복원과 같은 복구 작업을 수행할 책임이 있습니다.
알림: Azure Database for PostgreSQL의 HA(고가용성) 상태 모니터링은 HA 사용 인스턴스의 상태 및 준비 상태에 대한 지속적인 개요를 제공합니다. 모니터링 기능은 Azure Resource Health를 기반으로 하며 데이터베이스의 장애 조치(failover) 준비 상태 또는 전체 가용성에 영향을 줄 수 있는 문제를 감지하고 경고할 수 있습니다. 연결 상태, 장애 조치 상태 및 데이터 복제 상태와 같은 주요 메트릭을 평가하여 사전 문제 해결을 사용하도록 설정하고 데이터베이스의 작동 시간 및 성능을 유지하는 데 도움이 됩니다.
HA 상태 구성 및 해석에 대한 자세한 가이드는 Azure Database for PostgreSQL에 대한 HA(고가용성) 상태 모니터링을 참조하세요.
활성 요청: 가용성 영역을 사용할 수 없게 되면 영향을 받는 영역의 서버에 대한 진행 중인 요청이 종료될 수 있습니다. 애플리케이션은 이러한 요청을 다시 시도해야 합니다. 클라이언트가 짧은 시간 후에 다시 시도하여 일시적인 오류를 적절하게 처리하는 경우 일반적으로 상당한 영향을 받지 않습니다.
예상 데이터 손실: 데이터 손실의 양은 서버에서 사용하는 가용성 영역 구성에 따라 달라집니다.
영역 중복: 서로 다른 영역의 주 서버와 대기 서버 간의 동기 복제로 인해 영역 장애 조치(failover) 중에 데이터 손실이 0으로 예상됩니다.
영역: 영역이 복구될 때까지 영향을 받는 영역의 서버에 있는 데이터를 사용할 수 없습니다.
예상 가동 중지 시간: 가동 중지 시간은 서버에서 사용하는 가용성 영역 구성에 따라 달라집니다.
영역 중복: 장애 조치(failover)는 일반적으로 60-120초 내에 완료됩니다. 클라이언트가 짧은 시간 후에 다시 시도하여 일시적인 오류를 적절하게 처리하는 경우 일반적으로 상당한 영향을 받지 않습니다.
영역: 영향을 받은 영역의 서버는 가용성 영역이 복구될 때까지 사용할 수 없습니다.
재배포: 트래픽 경로 변경 동작은 서버에서 사용하는 가용성 영역 구성에 따라 달라집니다.
영역 중복: 장애 조치(failover) 후 이전 대기 서버는 새로운 주 서버가 되고, 새 연결을 수락하기 시작합니다. Azure는 복구 후 원래 주 영역에 새 대기 서버를 자동으로 설정합니다. 자세한 내용은 강제 장애 조치(failover)를 참조하세요.
영역: 영역을 사용할 수 없는 경우 서버를 사용할 수 없습니다. 다른 가용성 영역 또는 지역에서 미리 생성한 별도의 서버가 있는 경우 해당 서버로 트래픽을 다시 라우팅해야 합니다.
영역 복구
영역 복구 동작은 서버에서 사용하는 가용성 영역 구성에 따라 달라집니다.
영역 중복: 가용성 영역이 복구되면 Azure Database for PostgreSQL은 복구된 영역에서 대기 서버를 자동으로 다시 빌드하고 현재 주 서버와 동기화합니다. 그러면 복구된 영역이 대기 위치로 사용됩니다. 서비스는 불필요한 중단을 방지하기 위해 기본 역할을 원래 영역으로 자동으로 다시 이동하지 않습니다. 주 영역을 원래 위치로 복원하려는 경우 계획된 장애 조치(failover)를 수동으로 시작할 수 있습니다.
영역: 영역이 정상이면 영역의 서버를 다시 사용할 수 있습니다. 워크로드에 필요한 영역 복구 절차 및 데이터 동기화를 담당합니다.
영역 오류 테스트
영역 오류 테스트 옵션은 인스턴스에서 사용하는 가용성 영역 구성에 따라 달라집니다.
영역 중복: 강제 장애 조치를 시작하여 애플리케이션의 장애 복원력을 테스트할 수 있습니다. 강제 장애 조치(failover)를 사용하면 워크로드를 실행하는 동안 계획되지 않은 중단 시나리오를 시뮬레이션하고 애플리케이션 가동 중지 시간을 관찰할 수 있습니다. 비프로덕션 환경에서 또는 조용한 시간에 시뮬레이션을 실행하는 것이 좋습니다. 자세한 내용은 강제 장애 조치(failover) 시작을 참조하세요.
영역: 전체 영역 중단을 시뮬레이트할 수는 없지만 영역 중단 시 발생하는 것과 비슷한 방식으로 서버를 사용할 수 없는 것을 시뮬레이션할 수 있습니다. 자세한 내용은 서버의 컴퓨팅 중지를 참조하세요.
지역 전체 오류에 대한 복원력
Azure Database for PostgreSQL은 지역 간 읽기 복제본을 지원하므로 더 빠른 복구를 위해 다른 지역에서 데이터베이스의 동기화된 복사본을 유지하는 데 사용할 수 있습니다.
지원되는 지역에서 지역 중복 백업을 사용하여 지역 간 복구를 제공할 수도 있습니다. 그러나 백업에는 일반적으로 복제보다 더 많은 가동 중지 시간과 데이터 손실이 포함됩니다. 자세한 내용은 백업 및 복원을 참조하세요.
지역 간 읽기 복제본
읽기 복제본을 배포하여 지역 수준 오류로부터 데이터베이스를 보호할 수 있습니다. 각 읽기 복제본은 별도의 Azure Database for PostgreSQL 서버입니다. 두 번째 Azure 지역에 읽기 복제본을 배치하면 데이터베이스 서버가 지역 전체 문제에 대한 복원력을 제공할 수 있습니다. 필요에 따라 다른 Azure 지역에 있을 수 있는 최대 5개의 읽기 복제본을 배포할 수 있습니다. PostgreSQL의 물리적 복제 기술은 읽기 복제본을 비동기적으로 업데이트하며 주 복제본을 지연할 수 있습니다. 지역 간 읽기 복제본은 필요에 따라 읽기 전용 워크로드를 사용하여 전역적으로 분산된 애플리케이션의 대기 시간을 줄이거나 주 서버에서 읽기 트래픽을 오프로드할 수 있습니다. 읽기 복제본 기능 및 고려 사항에 대한 자세한 내용은 읽기 복제본을 참조하세요.
가상 엔드포인트는 읽기-쓰기 및 읽기 전용 엔드포인트를 제공하고 복제본이 승격될 때 트래픽을 자동으로 리디렉션하므로 장애 조치(failover) 이벤트 중 가동 중지 시간을 최소화할 수 있습니다. 애플리케이션 복원력을 향상하려면 지역 간 읽기 복제본이 있는 가상 엔드포인트를 사용하는 것이 좋습니다. 자세한 내용은 Azure Database for PostgreSQL의 읽기 복제본에 대한 가상 엔드포인트를 참조하세요.
주 리전이 실패하면 보조 복제본이 주 복제본이 되도록 승격을 트리거할 수 있습니다. 읽기 복제본을 사용하는 방법에 따라 트리거할 수 있는 다양한 유형의 장애 조치(failover)가 있습니다. 읽기 복제본을 사용하여 지역 오류로부터 복원력을 높이려는 경우, 일반적으로 가상 엔드포인트를 업데이트하는 기본 서버로 승격 방법을 사용합니다. 지역 장애 중에 강제 승격을 수행해야 하며, 이로 인해 복제되지 않은 데이터에 대한 일부 데이터 손실이 발생할 수 있습니다. 주 지역이 정상인 계획된 시나리오에서는 데이터 손실을 방지하기 위해 계획된 승격을 수행하도록 선택할 수 있습니다. 자세한 내용은 Azure Database for PostgreSQL에서 읽기 복제본 승격을 참조하세요.
메모
이 섹션에서는 읽기 복제본이 지역 전체 오류에 대한 복원력을 지원할 수 있는 방법에 대한 몇 가지 중요한 정보를 요약합니다. 읽기 복제본을 사용하여 성능을 향상시키고 지리적으로 분산된 대규모 사용자 기반을 지원할 수도 있습니다. 자세한 내용은 리드 레플리카 참조하세요.
요구 사항
지역 지원: Azure Database for PostgreSQL을 지원하는 모든 지역에서 지역 간 읽기 복제본을 만들 수 있습니다. Azure 페어링 지역에만 제한되지 않습니다.
컴퓨팅 계층: 범용 및 메모리 최적화 컴퓨팅 계층은 읽기 복제본을 지원합니다. 버스트 가능 계층은 읽기 복제본을 지원하지 않습니다.
고려 사항
구성 차이점: 읽기 복제본은 주 서버에서 모든 구성 설정을 상속할 수 없습니다. 필요한 설정을 장애 조치 후에 구성할 계획을 세우세요. 주 서버와 복제본은 대칭적이어야 합니다. 즉, 일부 설정에 대해 동일한 계층, 스토리지 크기 및 값이 있어야 합니다. 지역 오류가 발생하면 강제 승격에 대한 대칭 서버 요구 사항을 포기할 수 있지만 예기치 않은 문제를 방지하기 위해 가능한 경우 대칭 구성을 사용하는 것이 좋습니다. 자세한 내용은 구성 관리를 참조하세요.
복제 지연 모니터링: 비동기 복제 프로세스에는 여러 요인에 따라 달라질 수 있는 복제 지연 시간이 필요합니다. 복제 지연 시간이 매우 높으면 서버에 문제가 발생할 수 있습니다. 문제가 에스컬레이션되기 전에 완화할 수 있도록 복제 지연 시간을 모니터링하는 것이 중요합니다. 자세한 내용은 복제 모니터링을 참조하세요.
고가용성: 읽기 복제본은 고가용성을 활성화할 수 없으며 승격된 이후에도 고가용성을 사용할 수 없습니다. 복제본을 승격한 후 고가용성을 설정할 책임이 있습니다.
승격 프로세스에 적용되는 추가 고려 사항은 Azure Database for PostgreSQL에서 읽기 복제본 승격 - 고려 사항을 참조하세요.
Cost
읽기 복제본에는 복제에 대한 지역 간 데이터 전송 요금뿐만 아니라 컴퓨팅 및 스토리지 비용이 발생합니다. 자세한 가격 책정 정보는 Azure Database for PostgreSQL 가격 책정 및 대역폭 가격을 참조하세요.
다중 지역 지원 구성
읽기 복제본 만들기: 읽기 복제본을 만드는 방법을 알아보려면 읽기 복제본 만들기를 참조하세요. 주 서버가 실행되고 액세스할 수 있는 한 주 서버를 만든 후에 복제본을 구성할 수 있습니다.
가상 엔드포인트를 만들려면 가상 엔드포인트 만들기를 참조하세요.
읽기 복제본을 삭제합니다. 읽기 복제본을 삭제하는 방법을 알아보려면 읽기 복제본 삭제를 참조하세요.
모든 지역이 정상인 경우의 동작
이 섹션에서는 서버가 다른 지역 및 가상 엔드포인트의 읽기 복제본으로 구성되고 모든 지역이 작동할 때 예상되는 사항에 대해 설명합니다.
지역 간 트래픽 라우팅: 일반적인 작업에서 가상 엔드포인트는 읽기-쓰기 엔드포인트에 대한 트래픽을 주 지역의 주 서버로 전달합니다. 또한 가상 엔드포인트의 읽기 전용 엔드포인트를 사용하는 경우 구성한 복제본으로 트래픽을 전달합니다.
지역 간 데이터 복제: 지역 간 읽기 복제본은 비동기 복제를 사용하여 주 서버 성능에 미치는 영향을 최소화합니다. 복제 지연 시간은 쓰기 로드 및 주 서버와 복제본 간의 대기 시간을 비롯한 다양한 요인에 따라 달라집니다. 복제 지연 시간은 일반적으로 몇 분 이상이지만 훨씬 더 길어질 수 있습니다. 자세한 내용은 복제 모니터링을 참조하세요.
지역 오류 중 동작
이 섹션에서는 서버가 다른 지역 및 가상 엔드포인트의 읽기 복제본으로 구성되고 주 지역에서 중단이 발생할 때 예상되는 사항에 대해 설명합니다.
검색 및 응답: 주 지역에서 서비스 중단을 감지하고, 읽기 복제본 서버를 새 주 서버로 수동으로 승격합니다. 지역 장애 발생 시, 복제되지 않은 데이터의 손실을 초래하는 강제 승격을 수행해야 합니다.
중요합니다
프로모션을 트리거할 책임이 있습니다. Azure는 지역 장애가 발생하더라도 읽기 복제본을 자동으로 활성화하지 않습니다.
승격을 시작하는 자세한 단계는 읽기 복제본 전환 - 주 복제본으로를 참조하십시오.
알림: Microsoft는 지역이 다운된 경우 자동으로 알리지 않습니다. 그러나 Azure Service Health 를 사용하여 지역 오류를 포함하여 서비스의 전반적인 상태를 파악할 수 있으며, 문제를 알리도록 Service Health 경고를 설정할 수 있습니다.
활성 요청: 주 지역에 대한 모든 활성 연결이 삭제됩니다. 애플리케이션은 승격 프로세스가 완료된 후 승격된 복제본에 대한 연결을 다시 시도해야 합니다.
예상 데이터 손실: 지역 가동 중단 중에 강제 승격을 수행해야 하며, 이로 인해 설명되지 않은 데이터가 영구적으로 손실됩니다.
데이터 손실의 양은 중단 시의 복제 지연에 따라 달라집니다. 복제 지연 시간은 일반적으로 몇 분 이상이지만 훨씬 더 길어질 수 있습니다. 자세한 내용은 복제 모니터링을 참조하세요.
예상 가동 중지 시간: 강제 승격은 일반적으로 트리거된 후 1-3분 이내에 완료됩니다. 애플리케이션은 올바른 엔드포인트에 다시 연결해야 할 수도 있습니다. 가상 엔드포인트는 강제 승격 프로세스의 일부로 업데이트됩니다. 애플리케이션은 승격이 완료된 후 올바른 복제본에 신속하게 다시 연결되도록 엔드포인트 DNS 레코드의 TTL(Time-to-Live)을 준수해야 합니다.
트래픽 경로 변경: 서버의 가상 엔드포인트는 애플리케이션 트래픽을 새 주 복제본으로 자동으로 리디렉션합니다.
메모
읽기 복제본이 주 서버로 승격된 후에는 고가용성 구성을 사용하도록 설정하지 않습니다. 고가용성 구성을 수동으로 사용하도록 설정하거나 사용자 고유의 자동화 프로세스에 추가해야 합니다.
지역 복구
가상 엔드포인트를 사용하는 경우 주 지역이 복구되면 이전 주 서버가 자동으로 읽기 복제본으로 구성됩니다. 다른 프로모션을 수행하여 기본 작업을 선호하는 기본 지역으로 반환할 수 있습니다.
지역 오류 테스트
읽기 복제본 승격 절차를 정기적으로 테스트하여 프로세스가 유효하고 기능이 RTO 및 RPO 요구 사항을 충족하는지 확인합니다.
모든 지역이 정상인 경우에도 언제든지 읽기 복제본을 주 서버로 승격할 수 있습니다. 테스트의 경우:
- 강제 승격 테스트를 수행할 수 있습니다. 데이터가 손실될 수 있으므로 비프로덕션 환경에서 이러한 테스트를 수행하는 것이 좋습니다. 강제 프로모션 테스트는 지역 장애 시 나타나는 행동을 시뮬레이션하는 데 도움이 됩니다.
- 계획된 유지 관리 또는 데이터 손실을 방지하려는 테스트 시나리오의 경우 계획된 승격을 대신 사용합니다. 계획된 승격은 지역 가동 중단 시 승격과는 다른 프로세스를 따릅니다.
단계별 지침은 읽기 복제본을 주 복제본으로 전환을 참조하세요.
재해 복구 전략의 일환으로 정기적으로 전체 복구 훈련을 실행합니다. 이러한 훈련에는 데이터 유효성 검사, 애플리케이션 기능 테스트, 문서화된 롤백 절차가 포함되어야 합니다.
백업 및 복원
Azure Database for PostgreSQL은 특정 시점 복구 기능을 제공하고 실수로 인한 데이터 손상 및 삭제로부터 사용자를 보호하는 백업을 자동으로 수행합니다. 백업은 Microsoft에서 완전히 관리되며, 서버의 가용성을 방해하지 않으며, 전체 백업 및 트랜잭션 로그 백업을 모두 포함합니다.
백업 스토리지: 서버가 영역 중복 고가용성으로 구성된 경우 백업은 ZRS(영역 중복 스토리지)에 저장됩니다. 고가용성 없이 또는 영역(단일 영역) 고가용성으로 구성된 서버의 경우 백업은 LRS(로컬 중복 스토리지)에 저장됩니다.
쌍이 있는 Azure 지역에서는 서버 생성 시 GRS(지역 중복) 백업 스토리지 를 구성하여 지역 오류에 대한 추가 보호를 위해 Azure 쌍을 이루는 지역에 백업을 복제할 수 있습니다. 백업은 비동기적으로 복제됩니다.
기본 백업 보존 기간은 7일이며 보존 기간을 최대 35일로 연장할 수 있습니다. 최대 10년 동안 수동 백업의 장기 스토리지에 Azure Backup을 사용할 수도 있습니다. 모든 백업이 암호화됩니다.
복원: 지정 시간 복구를 사용하면 백업 보존 기간 내에 언제든지 데이터베이스를 복원할 수 있습니다. 복원 프로세스는 사용자가 제공한 새 서버 이름을 사용하여 새 데이터베이스 서버를 만든 다음, as-is 사용하거나 데이터를 복사할 수 있습니다.
지역 중복 백업을 복원하는 경우 쌍을 이루는 지역에 새 서버를 만듭니다.
이 기능은 실수로 인한 데이터 수정, 애플리케이션 오류 또는 테스트 시나리오에서 복구하는 데 유용합니다.
대부분의 솔루션의 경우 백업에만 의존해서는 안 됩니다. 대신 이 가이드에 설명된 다른 기능을 사용하여 복원력 요구 사항을 지원합니다. 그러나 백업은 다른 방법이 사용하지 않는 일부 위험으로부터 보호합니다. 자세한 내용은 중복도, 복제 및 백업이란?을 참조하세요.
자세한 내용은 Azure Database for PostgreSQL의 백업 및 복원을 참조하세요.
서비스 유지 관리에 대한 복원력
Azure Database for PostgreSQL은 기본 하드웨어, 운영 체제 및 데이터베이스 엔진의 패치를 포함하여 중요한 서비스 작업을 자동으로 처리합니다. 이 서비스에는 계획된 유지 관리의 일부로 보안 업데이트, 소프트웨어 업데이트 및 부 버전 업그레이드가 포함됩니다.
유지 관리 기간 동안 서버를 계속 사용할 수 있도록 하려면 다음 권장 사항을 따르세요.
고가용성 사용: 유지 관리 중에는 업데이트 프로세스의 일부로 서버를 다시 시작해야 할 수 있습니다. 고가용성을 사용하는 경우 유지 관리 작업은 일반적으로 롤링 업데이트를 사용하여 가동 중지 시간을 최소화합니다. 부 버전 업그레이드와 같은 정기적인 유지 관리 작업은 먼저 대기 복제본에서 발생합니다. 가동 중지 시간을 줄이기 위해 유지 관리 작업이 나머지 노드에 적용되는 동안 워크로드가 계속 작동할 수 있도록 대기 상태가 기본으로 승격됩니다. 이 시퀀싱은 서버에서 영역 중복 또는 영역 고가용성을 사용하는지 여부에 따라 적용됩니다.
고가용성을 사용하도록 설정하지 않은 서버의 경우 유지 관리 작업 중에 짧은 가동 중지 시간이 예상됩니다. 고가용성을 사용하도록 설정하면 일반적으로 가동 중지 시간을 최소화하거나 사용하지 않고 유지 관리 작업이 완료됩니다.
사용자 지정 유지 관리 기간 구성: 유지 관리 일정을 시스템 관리로 구성하거나 사용자 지정 유지 관리 기간을 정의하여 비즈니스 운영에 미치는 영향을 최소화할 수 있습니다. 낮은 작업 기간 동안 유지 관리를 예약하여 비즈니스 영향을 최소화합니다. 자세한 내용은 예정된 유지 관리를 참조하세요.
재시도 논리 구현: 애플리케이션이 유지 관리 다시 시작 중에 발생할 수 있는 간단한 연결 중단을 처리할 수 있는지 확인합니다. 이러한 유형의 문제에 대해 애플리케이션을 복원할 수 있도록 하려면 일시적인 오류에 대한 복원력 지침을 참조하세요.
서비스 수준 약정
Azure 서비스에 대한 SLA(서비스 수준 계약)는 각 서비스의 예상 가용성과 솔루션이 가용성 기대치를 달성하기 위해 충족해야 하는 조건을 설명합니다. 자세한 내용은 온라인 서비스 SLA를 참조하세요.
Azure Database for PostgreSQL은 서버의 구성에 따라 다른 가용성 SLA를 제공합니다.
- 영역 중복 고가용성으로 구성된 서버.
- 단일 영역 내 고가용성으로 구성된 서버.
- 고가용성 없이 구성된 서버.
관련 콘텐츠
- Azure 안정성
- Azure Database for PostgreSQL에 대한 아키텍처 모범 사례
- Azure Database for PostgreSQL의 비즈니스 연속성 개요
- Azure Database for PostgreSQL의 지역 재해 복구
- Azure Database for PostgreSQL 복원력 솔루션 가속기 - 이 문서에 설명된 많은 복원력 및 복구 가능성 원칙을 구현하는 Terraform 스크립트입니다.