Azure Database for PostgreSQL - 유연한 서버를 사용한 비즈니스 연속성 개요

아티클
01/19/2024

적용 대상: Azure Database for PostgreSQL - 유연한 서버

Azure Database for PostgreSQL 유연한 서버의 비즈니스 연속성은 특히 컴퓨팅 인프라와 관련하여 중단 시 비즈니스를 계속 운영할 수 있는 메커니즘, 정책 및 절차를 의미합니다. 대부분의 경우 Azure Database for PostgreSQL 유연한 서버는 클라우드 환경에서 발생할 수 있는 중단 이벤트를 처리하고 애플리케이션 및 비즈니스 프로세스를 계속 실행합니다. 그러나 다음과 같이 자동으로 처리할 수 없는 일부 이벤트가 있습니다.

사용자가 실수로 테이블의 행을 삭제하거나 업데이트합니다.
지진으로 인해 정전이 발생하고 가용성 영역 또는 지역을 일시적으로 사용하지 않도록 설정합니다.
버그 또는 보안 문제를 해결하는 데 필요한 데이터베이스 패치입니다.

Azure Database for PostgreSQL 유연한 서버는 계획 및 계획되지 않은 가동 중지 시간 이벤트 중에 데이터를 보호하고 중요 업무용 데이터베이스의 가동 중지 시간을 완화하는 기능을 제공합니다. 강력한 복원력과 가용성을 제공하는 Azure 인프라를 기반으로 구축된 Azure Database for PostgreSQL 유연한 서버에는 또 다른 오류 보호를 제공하고 복구 시간 요구 사항을 처리하며 데이터 손실 노출을 줄이는 비즈니스 연속성 기능이 있습니다. 애플리케이션을 설계할 때 가동 중지 시간 허용 시간(RTO(복구 시간 목표) 및 데이터 손실 노출- RPO(복구 지점 목표)를 고려해야 합니다. 예를 들어 중요 비즈니스용 데이터베이스에는 테스트 데이터베이스보다 더 엄격한 가동 시간이 필요합니다.

아래 표에서는 Azure Database for PostgreSQL 유연한 서버에서 제공하는 기능을 보여 줍니다.

기능	설명	고려 사항
자동 백업	Azure Database for PostgreSQL 유연한 서버는 데이터베이스 파일의 매일 백업을 자동으로 수행하고 트랜잭션 로그를 지속적으로 백업합니다. 백업은 7일에서 최대 35일까지 보존할 수 있습니다. 백업 보존 기간 내의 특정 시점으로 데이터베이스 서버를 복원할 수 있습니다. RTO는 복원할 데이터의 크기 + 로그 복구를 수행하는 시간에 따라 달라집니다. 몇 분에서 12시간까지 가능합니다. 자세한 내용은 개념 - 백업 및 복원을 참조하세요.	지역 내에서 데이터를 다시 기본.
영역 중복 고가용성	Azure Database for PostgreSQL 유연한 서버는 주 서버와 대기 서버가 지역 내의 두 가지 가용성 영역에 배포되는 영역 중복 HA(고가용성) 구성을 사용하여 배포할 수 있습니다. 이 HA 구성은 영역 수준 오류로부터 데이터베이스를 보호하고 계획 및 계획되지 않은 가동 중지 시간 이벤트 중에 애플리케이션 가동 중지 시간을 줄이는 데도 도움이 됩니다. 주 서버의 데이터는 동기 모드에서 대기 복제본에 복제됩니다. 주 서버가 중단되는 경우 서버는 대기 복제본(replica) 자동으로 장애 조치(failover)됩니다. 대부분의 경우 RTO는 120초 미만이 될 것으로 예상됩니다. RPO는 0(데이터 손실 없음)이어야 합니다. 자세한 내용은 개념 - 고가용성을 참조 하세요.	일반 용도 및 메모리에 최적화된 컴퓨팅 계층에서 지원됩니다. 여러 영역을 사용할 수 있는 지역에서만 제공됩니다.
동일 영역 고가용성	Azure Database for PostgreSQL 유연한 서버는 주 서버와 대기 서버가 지역의 동일한 가용성 영역에 배포되는 동일한 HA(영역 고가용성) 구성으로 배포할 수 있습니다. 이 HA 구성은 노드 수준의 오류로부터 데이터베이스를 보호하고 계획되거나 계획되지 않은 가동 중지 시간 이벤트 중 애플리케이션 가동 중지 시간을 줄이는 데에도 도움이 됩니다. 주 서버의 데이터는 동기 모드에서 대기 복제본에 복제됩니다. 주 서버가 중단되는 경우 서버는 대기 복제본(replica) 자동으로 장애 조치(failover)됩니다. 대부분의 경우 RTO는 120초 미만이 될 것으로 예상됩니다. RPO는 0(데이터 손실 없음)이어야 합니다. 자세한 내용은 개념 - 고가용성을 참조 하세요.	일반 용도 및 메모리에 최적화된 컴퓨팅 계층에서 지원됩니다.
프리미엄 관리 디스크	데이터베이스 파일은 내구성이 뛰어나고 안정적인 프리미엄 관리 스토리지에 저장됩니다. 이는 자동 데이터 복구 기능을 사용하여 가용성 영역 내에 저장된 세 개의 복제본 복사본을 사용하여 데이터 중복성을 제공합니다. 자세한 내용은 Managed Disks 설명서를 참조 하세요.	가용성 영역 내에 저장된 데이터입니다.
영역 중복 백업	Azure Database for PostgreSQL 유연한 서버 백업은 지역에서 가용성 영역을 지원하는 경우 지역 내의 영역 중복 스토리지에 자동으로 안전하게 저장됩니다. 서버가 프로비전되는 영역 수준 오류가 발생한 동안 서버가 영역 중복으로 구성되지 않은 경우에도 다른 영역의 최신 복원 지점을 사용하여 데이터베이스를 복원할 수 있습니다. 자세한 내용은 개념 - 백업 및 복원을 참조 하세요.	여러 영역을 사용할 수 있는 지역에만 적용됩니다.
지역 중복 백업	Azure Database for PostgreSQL 유연한 서버 백업은 원격 지역에 복사됩니다. 주 서버 지역이 다운된 경우 재해 복구 상황에 도움이 되는 입니다.	이 기능은 현재 선택한 지역에서 사용됩니다. 복원할 데이터의 크기와 수행할 복구의 양에 따라 RTO가 더 길어지고 RPO가 더 늘어납니다.
읽기 복제본	지역 간 읽기 복제본(replica) 배포하여 지역 수준 오류로부터 데이터베이스를 보호할 수 있습니다. 읽기 복제본은 PostgreSQL의 물리적 복제 기술을 사용하여 비동기 업데이트되며, 주 복제본이 지연될 수 있습니다. 자세한 내용은 개념 - 읽기 복제본을 참조 하세요.	일반 용도 및 메모리에 최적화된 컴퓨팅 계층에서 지원됩니다.

다음 표에서는 일반적인 워크로드 시나리오에서 RTO 및 RPO를 비교합니다.

기능	버스터 가능	범용	메모리에 최적화
백업에서 특정 시점 복원	보존 기간 내 모든 복원 지점 RTO - 다양 RPO < 15분	보존 기간 내 모든 복원 지점 RTO - 다양 RPO < 15분	보존 기간 내 모든 복원 지점 RTO - 다양 RPO < 15분
지리적으로 복제된 백업에서 지역 복원	RTO - 다양 RPO < 1시간	RTO - 다양 RPO < 1시간	RTO - 다양 RPO < 1시간
읽기 복제본	RTO - 분* RPO < 5분*	RTO - 분* RPO < 5분*	RTO - 분* RPO < 5분*

* RTO 및 RPO는 사이트 간의 대기 시간, 전송되는 데이터의 양 및 주 데이터베이스 쓰기 워크로드를 비롯한 다양한 요소에 따라 증가할 수 있습니다.

계획된 가동 중지 시간 이벤트

다음은 계획된 몇 가지 기본 테넌트 시나리오입니다. 이러한 이벤트는 일반적으로 데이터 손실 없이 최대 몇 분의 가동 중지 시간이 발생합니다.

시나리오	처리
컴퓨팅 크기 조정(사용자가 시작한)	컴퓨팅 크기 조정 작업 중에 활성 검사포인트를 완료할 수 있고, 클라이언트 연결이 드레이닝되고, 커밋되지 않은 트랜잭션이 취소되고, 스토리지가 분리된 다음, 종료됩니다. 동일한 데이터베이스 서버 이름을 가진 새 Azure Database for PostgreSQL 유연한 서버 인스턴스가 확장된 컴퓨팅 구성으로 프로비전됩니다. 그런 다음 스토리지가 새 서버에 연결되고 필요한 경우 클라이언트 연결을 수락하기 전에 복구를 수행하는 데이터베이스가 시작됩니다.
스토리지 확장(사용자가 시작한)	스토리지 확장 작업이 시작되면 활성 검사포인트가 완료되고 클라이언트 연결이 드레이닝되고 커밋되지 않은 트랜잭션이 취소됩니다. 그 후 서버가 종료됩니다. 스토리지 크기가 원하는 크기로 조정된 다음 새 서버에 연결됩니다. 클라이언트 연결을 허용하기 전에 필요한 경우 복구가 수행됩니다. 스토리지 크기 축소는 지원되지 않습니다.
새 소프트웨어 배포(Azure 시작)	새로운 기능 롤아웃 또는 버그 수정은 서비스의 계획된 기본 테넌트의 일부로 자동으로 발생하며, 이러한 활동이 발생할 시기를 예약할 수 있습니다. 자세한 내용은 포털을 검사.
부 버전 업그레이드(Azure 시작)	Azure Database for PostgreSQL은 Azure에서 결정한 부 버전에 데이터베이스 서버를 자동으로 패치합니다. 이는 서비스의 계획된 기본 테넌트의 일부로 발생합니다. 데이터베이스 서버는 새 부 버전으로 자동으로 다시 시작됩니다. 자세한 내용은 설명서를 참조하세요. 포털을 검사 수도 있습니다.

Azure Database for PostgreSQL 유연한 서버 인스턴스가 고가용성으로 구성된 경우 서비스는 먼저 대기 서버에서 크기 조정 및 기본 테넌트 작업을 수행합니다. 자세한 내용은 개념 - 고가용성을 참조 하세요.

계획되지 않은 가동 중지 시간 완화

기본 하드웨어 오류, 네트워킹 문제 및 소프트웨어 버그와 같은 예기치 않은 중단으로 인해 계획되지 않은 가동 중지 시간이 발생할 수 있습니다. 고가용성으로 구성된 데이터베이스 서버가 예기치 않게 중단되면 대기 복제본(replica) 활성화되고 클라이언트가 작업을 다시 시작할 수 있습니다. HA(고가용성)로 구성되지 않은 경우 다시 시작 시도가 실패하면 새 데이터베이스 서버가 자동으로 프로비전됩니다. 계획되지 않은 가동 중지 시간을 방지할 수는 없지만 Azure Database for PostgreSQL 유연한 서버는 사용자의 개입 없이 복구 작업을 자동으로 수행하여 가동 중지 시간을 완화하는 데 도움이 됩니다.

고가용성을 제공하기 위해 지속적으로 노력하고 있지만 Azure Database for PostgreSQL 유연한 서버가 중단되어 데이터베이스를 사용할 수 없게 되어 애플리케이션에 영향을 미치는 경우가 있습니다. 서비스 모니터링에서 광범위한 연결 오류, 오류 또는 성능 문제를 일으키는 문제를 감지하면 서비스가 자동으로 중단을 선언하여 사용자에게 정보를 제공합니다.

서비스 중단

Azure Database for PostgreSQL 유연한 서버 가동 중단의 경우 다음 위치에서 중단과 관련된 자세한 정보를 볼 수 있습니다.

Azure Portal 배너: 구독이 영향을 받을 것으로 확인되면 Azure Portal 알림에 서비스 문제에 대한 중단 경고가 표시됩니다.

Screenshot showing notifications in Azure portal.

도움말 + 지원 또는 지원 + 문제 해결: 도움말 + 지원 또는 지원 + 문제 해결에서 지원 티켓을 만들 때 리소스에 영향을 주는 문제에 대한 정보가 있습니다. 자세한 내용 및 영향 요약을 보려면 중단 세부 정보 보기를 선택합니다. 새 지원 요청 페이지에도 경고가 표시됩니다.

Screenshot showing Help Support notifications in Azure portal.

서비스 도움말: Azure Portal의 Service Health 페이지에는 Azure 데이터 센터 상태 대한 정보가 전역적으로 포함되어 있습니다. Azure Portal의 검색 창에서 "서비스 상태"를 검색한 다음 활성 이벤트 범주에서 서비스 문제를 확인합니다. 도움말 메뉴에 있는 리소스의 리소스 상태 페이지에서 개별 리소스의 상태를 볼 수도 있습니다. 동남 아시아의 활성 서비스 문제에 대한 정보와 함께 Service Health 페이지의 샘플 스크린샷은 다음과 같습니다.

Screenshot showing service outage in Service Health portal.

전자 메일 알림: 경고를 설정한 경우 서비스 중단이 구독 및 리소스에 영향을 줄 때 이메일 알림이 도착합니다. 전자 메일은 "azure-noreply@microsoft.com"에서 도착합니다. 이메일 본문은 "활동 로그 경고 ... Azure 구독에 대한 서비스 문제로 트리거되었습니다...". 서비스 상태 경고에 대한 자세한 내용은 Azure Portal을 사용하여 Azure 서비스 알림에 대한 활동 로그 경고 수신을 참조하세요.

Important

이름에서 알 수 있듯이 PostgreSQL의 임시 테이블스페이스는 임시 개체뿐만 아니라 정렬과 같은 다른 내부 데이터베이스 작업에 사용됩니다. 따라서 서버 다시 시작, HA 장애 조치(failover) 등 이후에는 이러한 개체의 내구성을 보장하지 않으므로 임시 테이블스페이스에 사용자 스키마 개체를 만들지 않는 것이 좋습니다.

예기치 않은 가동 중지 시간: 오류 시나리오 및 서비스 복구

다음은 계획되지 않은 몇 가지 오류 시나리오 및 복구 프로세스입니다.

시나리오	복구 프로세스 [영역 중복 HA 없이 구성된 서버]	복구 프로세스 [영역 중복 HA로 구성된 서버]
데이터베이스 서버 오류	데이터베이스 서버가 다운된 경우 Azure는 데이터베이스 서버를 다시 시작하려고 시도합니다. 이 작업에 실패하면 다른 실제 노드에서 데이터베이스 서버가 다시 시작됩니다. RTO(복구 시간)는 큰 트랜잭션과 같은 오류 시의 활동 및 데이터베이스 서버 시작 프로세스 중에 수행할 복구 볼륨을 비롯한 다양한 요인에 따라 달라집니다. PostgreSQL 데이터베이스를 사용하는 애플리케이션은 삭제된 연결과 실패한 트랜잭션을 검색하고 다시 시도하도록 빌드되어야 합니다.	데이터베이스 서버 오류가 감지되면 서버가 대기 서버로 장애 조치되어 가동 중지 시간이 줄어듭니다. 자세한 내용은 HA 개념 페이지를 참조하세요. RTO는 데이터 손실이 없는 60~120초가 될 것으로 예상됩니다.
스토리지 오류	디스크 오류 또는 물리적 블록 손상과 같은 스토리지 관련 문제는 애플리케이션에 영향을 주지 않습니다. 데이터가 3개 복사본에 저장되므로 남은 스토리지에서 데이터 복사본이 제공됩니다. 손상된 데이터 블록이 자동으로 복구되고 데이터의 새 복사본이 자동으로 만들어집니다.	전체 스토리지와 같은 희귀하고 복구할 수 없는 오류의 경우 Azure Database for PostgreSQL 유연한 서버 인스턴스가 대기 복제본(replica) 장애 조치(failover)되어 가동 중지 시간을 줄입니다. 자세한 내용은 HA 개념 페이지를 참조하세요.
논리적/사용자 오류	실수로 삭제된 테이블 또는 잘못 업데이트된 데이터와 같은 사용자 오류를 복구하려면 PITR(지정 시간 복구)을 수행해야 합니다. 복원 작업을 수행하는 동안 사용자 지정 복원 지점을 지정합니다. 이 지점은 오류 발생 직전의 시간입니다. 데이터베이스 서버에 있는 모든 데이터베이스 대신 데이터베이스의 일부 또는 특정 테이블만 복원하려면 새 인스턴스에서 데이터베이스 서버를 복원하고 pg_dump를 통해 테이블을 내보낸 후 pg_restore를 사용하여 테이블을 데이터베이스로 복원하면 됩니다.	이러한 사용자 오류는 모든 변경 내용이 동기적으로 대기 복제본(replica) 복제본(replica) 때문에 고가용성으로 보호되지 않습니다. 해당 오류에서 복구하려면 특정 시점 복원을 수행해야 합니다.
가용성 영역 오류	영역 수준 오류에서 복구하려면 백업을 사용하여 특정 시점 복원을 수행하고 최신 데이터를 복원하는 최신 시간으로 사용자 지정 복원 지점을 선택할 수 있습니다. 새로운 Azure Database for PostgreSQL 유연한 서버 인스턴스는 영향을 주지 않는 다른 영역에 배포됩니다. 복원에 걸리는 시간은 이전 백업 및 복구할 트랜잭션 로그의 양에 따라 달라집니다.	Azure Database for PostgreSQL 유연한 서버는 데이터가 손실되지 않은 상태에서 60-120년대 내에 대기 서버로 자동으로 장애 조치(failover)됩니다. 자세한 내용은 HA 개념 페이지를 참조하세요.
지역 오류	서버가 지역 중복 백업으로 구성된 경우 쌍을 이루는 지역에서 지역 복원을 수행할 수 있습니다. 새 서버가 프로비저닝되고, 이 지역에 복사된 마지막으로 사용 가능한 데이터로 복구됩니다. 지역 간 읽기 복제본(replica) 사용할 수도 있습니다. 지역 오류가 발생하는 경우 읽기 복제본(replica) 독립 실행형 읽기/쓰기 가능 서버로 승격하여 재해 복구 작업을 수행할 수 있습니다. RPO가 실패 시 복제본(replica) 지연에 근접할 수 있는 심각한 지역 오류의 경우를 제외하고 RPO는 최대 5분(데이터 손실 가능)이 될 것으로 예상됩니다.	동일한 프로세스입니다.

지역별 오류로부터 복구한 후 데이터베이스 구성

지역 복원 또는 지역 복제본(replica) 사용하여 중단에서 복구하는 경우 일반 애플리케이션 함수를 다시 시작하도록 새 서버에 대한 연결이 제대로 구성되었는지 확인해야 합니다. 복원 후 작업을 수행할 수 있습니다.
이전에 원래 서버에서 진단 설정을 설정한 경우 필요한 경우 Azure Database for PostgreSQL - 유연한 서버의 로그 구성 및 액세스에 설명된 대로 대상 서버에서 동일한 작업을 수행해야 합니다.
원격 분석 경고를 설정하려면 기존 경고 규칙 설정이 새 서버에 매핑되도록 업데이트되었는지 확인해야 합니다. 경고 규칙에 대한 자세한 내용은 Azure Portal을 사용하여 Azure Database for PostgreSQL - 유연한 서버에 대한 메트릭에 대한 경고를 설정하는 방법을 참조 하세요.