Azure Database for PostgreSQL - 유연한 서버의 지역 복제
적용 대상: 
Azure Database for PostgreSQL - 유연한 서버
읽기 복제본은 주 서버와 동일한 지역 또는 다른 지역에 만들어질 수 있습니다. 지역 복제는 재해 복구 계획 또는 사용자에게 더 가까운 데이터 가져오기 등의 시나리오에 유용할 수 있습니다.
Azure Database for PostgreSQL 유연한 서버 지역에 주 서버를 둘 수 있습니다. 주 서버에는 Azure Database for PostgreSQL 유연한 서버를 지원하는 Azure의 모든 글로벌 지역에도 복제본이 있을 수 있습니다. 또한 21Vianet에서 운영하는 Azure Government 및 Microsoft Azure 특별 지역도 지원합니다.
재해 복구를 위해 쌍을 이루는 지역
지원되는 모든 지역에서 복제본을 만들 수 있지만 특히 재해 복구 목적으로 설계할 때 쌍을 이루는 지역에서 복제본을 선택하면 다음과 같은 주목할만한 이점이 있습니다.
지역 복구 순서: 지리적으로 전체 지역이 가동을 중단하는 경우 쌍을 이루는 모든 집합에서 한 지역을 복구하는 것이 우선시되므로 쌍을 이루는 지역의 애플리케이션에서 복구를 위해 항상 신속하게 복구할 수 있습니다.
순차적 업데이트: 쌍을 이루는 지역의 업데이트는 시차를 두고 진행되므로 업데이트 관련 문제로 인한 가동 중지 시간의 위험을 최소화합니다.
물리적 격리: 쌍을 이루는 지역의 데이터 센터 간에 최소 거리 300마일이 유지되므로 중요한 이벤트 때문에 동시에 중단될 위험이 줄어듭니다.
데이터 보존: 몇 가지 예외를 제외하고 쌍을 이루는 집합의 지역은 동일한 지역 내에 보존하여 데이터 보존 요구 사항을 충족합니다.
성능: 쌍을 이루는 지역은 일반적으로 네트워크 대기 시간이 짧고 데이터 접근성과 사용자 환경이 향상되지만 항상 대기 시간이 가장 짧은 지역은 아닐 수 있습니다. 재해 복구의 우선 순위를 지정하지 않고 사용자에게 더 가까운 곳에서 데이터를 제공하는 것이 주요 목표인 경우 사용 가능한 모든 지역의 대기 시간을 평가하는 것이 중요합니다. 경우에 따라 페어링되지 않은 지역의 대기 시간이 가장 낮을 수 있습니다. 포괄적인 이해를 위해 Azure의 왕복 대기 시간 수치를 참조하여 정보에 입각한 선택을 할 수 있습니다.
쌍을 이루는 지역의 이점에 대한 자세한 내용은 지역 간 복제에 대한 Azure 설명서를 참조하세요.
지역 오류 및 복구
다양한 지역의 Azure 시설은 높은 안정성을 제공하도록 설계되었습니다. 그러나 드문 경우지만 네트워크 오류에서 자연 재해와 같은 심각한 시나리오에 이르기까지 다양한 이유로 인해 전체 지역에 액세스할 수 없게 될 수 있습니다. Azure의 기능을 사용하면 여러 지역에 분산된 애플리케이션을 만들 수 있으므로 한 지역의 오류가 다른 지역에 영향을 주지 않습니다.
지역 재해 준비
잠재적인 지역 재해에 대비하는 것은 애플리케이션 및 서비스의 중단 없는 작업을 보장하는 데 중요합니다. Azure Database for PostgreSQL 유연한 서버 인스턴스에 대한 강력한 대체 계획을 고려하는 경우 주요 단계 및 고려 사항은 다음과 같습니다.
- 지역에서 복제된 읽기 복제본 설정: 읽기 복제본을 주 복제본과 별도의 지역에 설정해야 합니다. 이렇게 하면 주 지역에서 중단이 발생할 경우 연속성이 보장됩니다.
- 서버 대칭 확인: ‘주 서버로 승격’ 작업은 지역 중단을 처리하는 데 가장 권장되지만 서버 대칭 요구 사항이 함께 제공됩니다. 즉, 주 서버와 복제본 서버 모두 특정 설정 구성이 동일해야 합니다. 이 작업을 사용할 경우의 이점은 다음과 같습니다.
- 가상 엔드포인트를 사용하는 경우 애플리케이션 연결 문자열을 수정할 필요가 없습니다.
- 영향을 받는 지역이 다시 온라인 상태가 되면 원래 주 서버가 자동으로 해당 기능을 다시 시작하지만 새 복제본 역할에서 원활한 복구 프로세스를 제공합니다.
- 가상 엔드포인트 설정: 가상 엔드포인트를 사용하면 중단이 있는 경우 애플리케이션을 다른 지역으로 원활하게 전환할 수 있습니다. 애플리케이션의 연결 문자열을 변경할 필요가 없습니다.
- 읽기 복제본 구성: 주 서버의 모든 설정이 읽기 복제본으로 복제되는 것은 아닙니다. 필요한 모든 구성 및 기능(예: PgBouncer)이 읽기 복제본에 적절하게 설정되도록 하는 것이 중요합니다. 자세한 내용은 구성 관리 섹션을 참조하세요.
- HA(고가용성) 준비: 설정에 고가용성이 필요한 경우 승격된 복제본에서 자동으로 사용하도록 설정되지 않습니다. 승격 후 활성화할 준비를 합니다. 가동 중지 시간을 최소화하려면 이 단계를 자동화하는 것이 좋습니다.
- 정기 테스트: 지역 재해 시나리오를 정기적으로 시뮬레이션하여 기존 임계값, 대상, 구성의 유효성을 검사합니다. 이러한 테스트 시나리오 중에 애플리케이션이 예상대로 응답하는지 확인합니다.
- Azure의 일반적인 지침 따르기: Azure는 안정성 및 재해 대비에 대한 포괄적인 지침을 제공합니다. 이러한 리소스를 참조하고 모범 사례를 준비 계획에 통합하는 것은 매우 유용합니다.
사전에 대응하고 지역 재해에 대비하여 애플리케이션 및 데이터의 복원력과 안정성을 보장합니다.
중단이 SLA에 영향을 미치는 경우
애플리케이션의 SLA(서비스 수준 계약)를 위협하는 특정 지역에서 Azure Database for PostgreSQL 유동 서버의 장기간 중단이 발생하는 경우 아래에 설명된 두 작업이 모두 서비스 기반이 아니라는 점에 유의하세요. 두 작업 모두 사용자 개입이 필요합니다. 전체 프로세스를 최대한 자동화하고 강력한 모니터링을 구현하는 것이 가장 좋습니다. 중단 중에 제공되는 정보에 대한 자세한 내용은 서비스 중단 페이지를 참조하세요. 지역 다운 시나리오에서는 강제 승격만 가능합니다. 즉, 데이터 손실량은 복제본과 주 복제본 간의 현재 지연 시간과 거의 같습니다. 따라서 지연을 모니터링하는 것이 중요합니다. 또한 다음 단계도 고려합니다.
주 서버로 승격
가상 엔드포인트가 구성된 경우 이 옵션은 애플리케이션에서 연결 문자열을 업데이트할 필요가 없습니다. 활성화되면 기록기 엔드포인트는 다른 지역의 새 주 복제본을 다시 지정하고 Azure Portal의 복제 상태 열에 ‘다시 구성’이 표시됩니다. 영향을 받는 지역이 복원되면 이전 주 서버가 자동으로 다시 시작되지만 이제는 복제본 역할을 맡게 됩니다.
독립 서버로 승격 및 복제에서 제거
이 경우 이것이 유일한 실행 가능한 옵션입니다. 서버를 승격한 후 애플리케이션의 연결 문자열을 업데이트해야 합니다. 원래 지역이 복원되면 이전 주 복제본이 다시 활성화될 수 있습니다. 불필요한 비용이 발생하지 않도록 제거해야 합니다. 이전 토폴로지를 유지하려면 읽기 복제본을 다시 만듭니다.