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시간까지 가능합니다. 자세한 내용은 개념 - 백업 및 복원을 참조하세요. | 백업 데이터는 지역 내에 유지됩니다. |
| 영역 중복 고가용성 | 영역 중복 HA(고가용성) 구성을 사용하여 Azure Database for PostgreSQL 유연한 서버 인스턴스를 배포할 수 있습니다. 여기서 주 서버와 대기 서버는 지역 내의 두 가지 가용성 영역에 배포됩니다. 이 HA 구성은 영역 수준 오류로부터 데이터베이스를 보호하고 계획 및 계획되지 않은 가동 중지 시간 이벤트 중에 애플리케이션 가동 중지 시간을 줄이는 데도 도움이 됩니다. 주 서버의 데이터는 동기 모드에서 대기 복제본에 복제됩니다. 주 서버에 대해 중단이 발생하는 경우 서버는 자동으로 대기 복제본으로 장애 조치(failover) 됩니다. 대부분의 경우 RTO는 120초 미만이 될 것으로 예상됩니다. RPO는 0(데이터 손실 없음)이어야 합니다. 자세한 내용은 개념 - 고가용성을 참조하세요. | 일반 용도 및 메모리에 최적화된 컴퓨팅 계층에서 지원됩니다. 여러 영역을 사용할 수 있는 지역에서만 제공됩니다. |
| 동일 영역 고가용성 | 주 서버와 대기 서버가 지역의 동일한 가용성 영역에 배포되는 동일한 HA(영역 고가용성) 구성을 사용하여 Azure Database for PostgreSQL 유연한 서버 인스턴스를 배포할 수 있습니다. 이 HA 구성은 노드 수준 오류로부터 데이터베이스를 보호하고 계획 및 계획되지 않은 가동 중지 시간 이벤트 중에 애플리케이션 가동 중지 시간을 줄이는 데도 도움이 됩니다. 주 서버의 데이터는 동기 모드에서 대기 복제본에 복제됩니다. 주 서버에 대해 중단이 발생하는 경우 서버는 자동으로 대기 복제본으로 장애 조치(failover) 됩니다. 대부분의 경우 RTO는 120초 미만이 될 것으로 예상됩니다. RPO는 0(데이터 손실 없음)이어야 합니다. 자세한 내용은 [개념 - 고가용성]/azure/reliability/reliability-postgresql-flexible-server를 참조하세요. | 일반 용도 및 메모리에 최적화된 컴퓨팅 계층에서 지원됩니다. |
| 프리미엄 관리 디스크 | 데이터베이스 파일은 내구성이 뛰어나고 안정적인 프리미엄 관리 스토리지에 저장됩니다. 이 스토리지는 자동 데이터 복구 기능을 사용하여 가용성 영역 내에 저장된 복제본의 복사본 3개가 포함된 데이터 중복성을 제공합니다. 자세한 내용은 관리 디스크 설명서를 참조하세요. | 가용성 영역 내에 저장된 데이터 |
| 영역 중복 백업 | Azure Database for PostgreSQL 유연한 서버 인스턴스 백업은 지역에서 가용성 영역을 지원하는 경우 지역 내의 영역 중복 스토리지에 자동으로 안전하게 저장됩니다. 서버가 프로비전되는 영역 수준 오류가 발생한 동안 서버가 영역 중복으로 구성되지 않은 경우에도 다른 영역의 최신 복원 지점을 사용하여 데이터베이스를 복원할 수 있습니다. 자세한 내용은 개념 - 백업 및 복원을 참조하세요. | 여러 영역을 사용할 수 있는 지역에서만 해당합니다. |
| 지역 중복 백업 | Azure Database for PostgreSQL 유연한 서버 인스턴스 백업은 원격 지역에 복사됩니다. 이 기능은 주 서버 지역이 다운된 경우 재해 복구 상황에 도움이 됩니다. | 이 기능은 현재 선택한 지역에서 사용됩니다. 복원할 데이터의 크기와 수행할 복구의 양에 따라 RTO가 더 길어지고 RPO가 더 늘어납니다. |
| 읽기 복제본 | 지역 간 읽기 복제본을 배포하여 지역 수준 오류로부터 데이터베이스를 보호할 수 있습니다. 읽기 복제본은 PostgreSQL의 물리적 복제 기술을 사용하여 비동기적으로 업데이트되며 주 복제본이 지연될 수 있습니다. 자세한 내용은 개념 - 읽기 복제본을 참조하세요. | 일반 용도 및 메모리에 최적화된 컴퓨팅 계층에서 지원됩니다. |
다음 표에서는 일반적인 워크로드 시나리오에서 RTO 및 RPO를 비교합니다.
| 능력 | 버스트 가능 | 프로덕션 SKU(범용/메모리 최적화) |
|---|---|---|
| 백업에서 특정 시점 복원 | 보존 기간 내 모든 복원 지점 RTO - 다양 RPO < 5 분 |
보존 기간 내 모든 복원 지점 RTO - 다양 RPO < 5 분 |
| 지리적으로 복제된 백업에서 지역 복원 | RTO - 다양 RPO < 1시간 |
RTO - 다양 RPO < 1시간 |
| 읽기 복제본 | 해당 없음 | RTO - 분* RPO - 일반적으로 30초에서 5분까지의 범위* |
| 고가용성 | 해당 없음 | RTO < 120초 RPO = 0 |
계획된 가동 중지 시간 이벤트
다음 표에서는 몇 가지 일반적인 계획된 유지 관리 시나리오에 대해 설명합니다. 이러한 이벤트는 일반적으로 몇 분의 가동 중지 시간을 발생하지만 데이터 손실을 일으키지는 않습니다.
| 시나리오 | 프로세스 |
|---|---|
| (사용자가 시작한) 컴퓨팅 스케일링 | 컴퓨팅 크기 조정 작업 중에 프로세스는 활성 검사점을 완료하고, 클라이언트 연결을 드레이닝하고, 커밋되지 않은 트랜잭션을 취소하고, 스토리지를 분리한 다음, 종료할 수 있도록 허용합니다. 이 프로세스는 데이터베이스 서버 이름이 같지만 크기가 조정된 컴퓨팅 구성을 사용하여 새로운 Azure Database for PostgreSQL 유연한 서버 인스턴스를 프로비전합니다. 이 프로세스는 스토리지를 새 서버에 연결하고 필요한 경우 클라이언트 연결을 수락하기 전에 복구를 수행하는 데이터베이스를 시작합니다. |
| (사용자가 시작한) 스토리지 스케일링 | 스토리지 확장 작업을 시작하면 프로세스에서 활성 검사점을 완료하고 클라이언트 연결을 드레이닝하며 커밋되지 않은 트랜잭션을 취소할 수 있습니다. 그런 다음 프로세스가 서버를 종료합니다. 이 프로세스는 스토리지 크기를 원하는 크기로 조정한 다음 새 서버에 연결합니다. 이 프로세스는 클라이언트 연결을 수락하기 전에 필요한 경우 복구를 수행합니다. 스토리지 크기 축소는 지원되지 않습니다. |
| (Azure에서 시작한) 새 소프트웨어 배포 | 이 서비스는 계획된 유지 관리의 일환으로 새로운 기능 또는 버그 수정을 자동으로 롤아웃합니다. 이러한 활동이 발생하는 시기를 예약할 수 있습니다. 자세한 내용은 포털을 확인하세요. |
| (Azure에서 시작한) 부 버전 업그레이드 | Azure Database for PostgreSQL은 Azure에서 확인된 부 버전으로 데이터베이스 서버를 자동으로 패치합니다. 이 패치는 서비스의 계획된 유지 관리의 일부로 발생합니다. 이 프로세스는 새 부 버전으로 데이터베이스 서버를 자동으로 다시 시작합니다. 자세한 내용은 설명서를 참조하세요. 포털을 확인할 수도 있습니다. |
고가용성을 사용하여 Azure Database for PostgreSQL 유연한 서버 인스턴스를 구성하는 경우 서비스는 먼저 대기 서버에서 크기 조정 및 유지 관리 작업을 수행합니다. 자세한 내용은 [개념 - 고가용성]/azure/reliability/reliability-postgresql-flexible-server를 참조하세요.
계획되지 않은 가동 중지 시간 완화
계획되지 않은 가동 중지 시간은 기본 하드웨어 결함, 네트워킹 문제 및 소프트웨어 버그와 같은 예상되지 않은 중단의 결과로 발생할 수 있습니다. 고가용성으로 구성된 데이터베이스 서버가 예기치 않게 중단되면 서비스는 대기 복제본을 활성화하고 클라이언트는 작업을 다시 시작할 수 있습니다. HA(고가용성)를 사용하여 서버를 구성하지 않으면 다시 시작 시도가 실패하면 서비스에서 새 데이터베이스 서버를 자동으로 프로비전합니다. 계획되지 않은 가동 중지 시간을 방지할 수는 없지만 Azure Database for PostgreSQL 사용자의 개입 없이 복구 작업을 자동으로 수행하여 가동 중지 시간을 완화하는 데 도움이 됩니다.
엔지니어링 팀은 계속해서 고가용성을 제공하기 위해 노력하지만, Azure Database for PostgreSQL 데이터베이스를 사용할 수 없게 되어 애플리케이션에 영향을 주는 중단이 발생하는 경우가 있습니다. 서비스 모니터링에서 광범위한 연결 오류, 오류 또는 성능 문제를 일으키는 문제를 감지하면 서비스가 자동으로 중단을 선언하여 사용자에게 정보를 제공합니다.
서비스 중단
Azure Database for PostgreSQL 유연한 서버 인스턴스가 중단되는 경우 다음 위치에서 중단에 대한 자세한 내용을 확인할 수 있습니다.
- Azure 포털 배너: 구독이 영향을 받으면 Azure 포털 알림에 서비스 문제에 대한 중단 경고가 표시됩니다.
- 도움말 + 지원 또는 지원 + 문제 해결: 도움말 + 지원 또는 지원 +문제 해결에서 지원 티켓을 만들 때 포털에는 리소스에 영향을 주는 문제에 대한 정보가 포함됩니다. 자세한 정보 및 영향의 요약을 보려면 중단 세부 정보 보기를 선택합니다. 새 지원 요청 페이지에는 경고도 포함됩니다.
- Service Health: Azure Portal의 Service Health 페이지에는 Azure 데이터 센터 상태에 대한 정보가 전역적으로 포함되어 있습니다. Azure 포털의 검색 창에서 "서비스 상태"를 검색한 다음 활성 이벤트 범주에서 서비스 문제를 확인합니다. 도움말 메뉴 아래 리소스의 리소스 상태 페이지에서 개별 리소스의 상태를 볼 수도 있습니다. Service Health 페이지의 다음 스크린샷은 동남 아시아의 활성 서비스 문제에 대한 정보를 보여 줍니다.
- 전자 메일 알림: 경고를 설정하는 경우 서비스 중단이 구독 및 리소스에 영향을 주는 경우 이메일 알림을 받습니다. 전자 메일은 "azure-noreply@microsoft.com"에서 제공됩니다. "Azure 구독 서비스 문제가 활동 로그 경고 ...을(를) 트리거하였습니다..."로 시작하는 메일입니다. 서비스 상태 경고에 대한 자세한 내용은 Azure 포털을 사용하여 Azure 서비스 알림에 대한 활동 로그 경고 수신을 참조하세요.
중요합니다
이름에서 알 수 있듯이 PostgreSQL의 임시 테이블 스페이스는 임시 개체뿐만 아니라 정렬 등 다른 내부 데이터베이스 작업에도 사용됩니다. 따라서 서버를 다시 시작한 후 이러한 개체의 내구성, HA 장애 조치(failover) 및 유사한 이벤트가 보장되지 않으므로 임시 테이블스페이스에 사용자 스키마 개체를 만들지 마세요.
의도하지 않은 가동 중지 시간: 실패 시나리오 및 서비스 복구
다음 표에서는 일반적인 계획되지 않은 오류 시나리오 및 복구 프로세스에 대해 설명합니다.
| 시나리오 |
복구 프로세스 [영역 중복 HA 없이 구성된 서버] |
복구 프로세스 [영역 중복 HA로 구성된 서버] |
|---|---|---|
| 데이터베이스 서버 오류 | 데이터베이스 서버가 중단되면 Azure 데이터베이스 서버를 다시 시작하려고 시도합니다. 이 시도가 실패하면 Azure 다른 물리적 노드에서 데이터베이스 서버를 다시 시작합니다. RTO(복구 시간)는 큰 트랜잭션과 같은 오류 시의 활동 및 데이터베이스 서버 시작 프로세스 중에 수행할 복구 볼륨을 비롯한 다양한 요인에 따라 달라집니다. PostgreSQL 데이터베이스를 사용하는 애플리케이션은 삭제된 연결 및 실패한 트랜잭션을 검색하고 다시 시도해야 합니다. |
데이터베이스 서버 오류가 감지되면 서버가 대기 서버로 장애 조치되어 가동 중지 시간이 줄어듭니다. 자세한 내용은 [HA 개념 페이지]/azure/reliability/reliability-postgresql-flexible-server를 참조하세요. RTO는 60-120초로 예상되며 데이터 손실은 없습니다. |
| 스토리지 오류 | 애플리케이션은 디스크 오류 또는 물리적 블록 손상과 같은 스토리지 관련 문제로 인한 영향을 볼 수 없습니다. 데이터는 세 개의 복사본에 저장되므로 남아 있는 스토리지는 데이터의 복사본을 제공합니다. 손상된 데이터 블록이 자동으로 복구되고 데이터의 새 복사본이 자동으로 생성됩니다. | 전체 스토리지에 액세스할 수 없는 경우와 같은 드물고 복구할 수 없는 오류가 발생하면 Azure Database for PostgreSQL 유연한 서버 인스턴스는 가동 중지 시간을 줄이기 위해 대기 복제본으로 장애 조치됩니다. 자세한 내용은 [HA 개념 페이지]/azure/reliability/reliability-postgresql-flexible-server를 참조하세요. |
| 논리적 또는 사용자 오류 | 실수로 테이블이 삭제되거나 데이터가 잘못 업데이트되는 등의 사용자 오류를 복구하려면 PITR( 지정 시간 복구 )을 수행합니다. 복원 작업을 수행하는 동안 오류가 발생하기 직전인 사용자 지정 복원 지점을 지정합니다. 데이터베이스 서버의 모든 데이터베이스가 아닌 데이터베이스 또는 특정 테이블의 하위 집합만 복원하려는 경우 새 인스턴스에서 데이터베이스 서버를 복원하고, pg_dump 통해 테이블을 내보낸 다음, pg_restore 사용하여 해당 테이블을 데이터베이스로 복원할 수 있습니다. |
모든 변경 내용이 대기 복제본에 동기적으로 복제되기 때문에 이러한 사용자 오류는 고가용성으로 보호되지 않습니다. 이러한 오류를 복구하려면 특정 시점 복원을 수행해야 합니다. |
| 가용성 영역 오류 | 영역 수준 오류에서 복구하려면 백업을 사용하여 특정 시점 복원을 수행하고 최신 데이터를 복원하는 최신 시간이 있는 사용자 지정 복원 지점을 선택합니다. 영향을 주지 않는 다른 영역에 새 Azure Database for PostgreSQL 유연한 서버 인스턴스를 배포합니다. 복원에 걸리는 시간은 이전 백업 및 복구할 트랜잭션 로그의 양에 따라 달라집니다. | Azure Database for PostgreSQL 유연한 서버 인스턴스는 60~120초 이내에 대기 서버로 자동 장애 조치되며, 데이터 손실이 없습니다. 자세한 내용은 [HA 개념 페이지]/azure/reliability/reliability-postgresql-flexible-server를 참조하세요. |
| 지역 오류 | 서버가 지역 중복 백업으로 구성된 경우 쌍을 이루는 지역에서 지역 복원을 수행할 수 있습니다. Azure 이 지역에 복사된 마지막 사용 가능한 데이터로 새 서버를 프로비전하고 복구합니다. 지역 간 읽기 복제본을 사용할 수도 있습니다. 지역 오류가 발생하는 경우 읽기 복제본을 독립 실행형 읽기/쓰기 가능 서버로 승격하여 재해 복구 작업을 수행할 수 있습니다. RPO는 실패 시 RPO가 복제 지연에 근접할 수 있는 심각한 지역 오류의 경우를 제외하고 최대 5분(데이터 손실 가능)이 될 것으로 예상됩니다. |
동일한 프로세스입니다. |
지역별 오류를 복구한 후의 데이터베이스 구성
- 지역 복원 또는 지역 복제본을 사용하여 중단에서 복구하는 경우 일반 애플리케이션 함수를 다시 시작할 수 있도록 새 서버에 대한 연결이 제대로 구성되었는지 확인합니다. 복원 후 작업을 따릅니다.
- 이전에 원래 서버에서 진단 설정을 설정한 경우 Azure Database for PostgreSQL 구성 및 액세스 로그에 설명된 대로 필요한 경우 대상 서버에서 동일한 작업을 수행해야 합니다.
- 원격 분석 경고를 설정하려면 기존 경고 규칙 설정이 새 서버에 매핑되도록 업데이트되었는지 확인합니다. 경고 규칙에 대한 자세한 내용은 Azure Portal을 사용하여 Azure Database for PostgreSQL에 대한 메트릭에 대한 경고를 설정합니다.
중요합니다
삭제된 서버를 복원할 수 있습니다. 서버를 삭제하는 경우 삭제된 서버 복원 의 지침에 따라 복구합니다. Azure 리소스 잠금을 사용하여 사고로 인한 서버 삭제를 방지할 수 있습니다.
관련 콘텐츠
- Azure Database for PostgreSQL의 고가용성
- 최신 복원 지점으로 복원합니다.
- 사용자 지정 복원 지점으로 복원합니다.
- 전체 백업(빠른 복원)으로 복원합니다.
- 페어링된 지역으로 복원(지리적 복원).