다음을 통해 공유

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

  • 아티클

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

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

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

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

서비스 중단

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

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

Azure Portal의 알림을 보여 주는 스크린샷.

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

Azure Portal의 도움말 지원 알림을 보여 주는 스크린샷

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

Service Health 포털의 서비스 중단을 보여 주는 스크린샷

  • Email 알림: 경고를 설정한 경우 서비스 중단이 구독 및 리소스에 영향을 줄 때 메일 알림이 도착합니다. "azure-noreply@microsoft.com"에서 보낸 메일이 도착합니다. "Azure 구독 서비스 문제가 활동 로그 경고 ...을(를) 트리거하였습니다..."로 시작하는 메일입니다. 서비스 상태 경고에 대한 자세한 내용은 Azure Portal로 Azure 서비스 알림에서 활동 로그 경고 받기를 참조하세요.

Important

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

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

계획되지 않은 오류 시나리오 및 복구 프로세스는 다음과 같습니다.

시나리오 복구 프로세스
[영역 중복 HA 없이 구성된 서버]		 복구 프로세스
[영역 중복 HA로 구성된 서버]
데이터베이스 서버 오류 데이터베이스 서버가 다운되면 Azure는 데이터베이스 서버를 다시 시작합니다. 이 작업에 실패하면 다른 실제 노드에서 데이터베이스 서버가 다시 시작됩니다.

RTO(복구 시간 목표)는 데이터베이스 서버 시작 프로세스 중 수행해야 하는 큰 트랜잭션 및 복구 작업의 양과 같은 장애가 발생한 시점의 작업을 포함하여 여러 요소들에 따라 달라집니다.

PostgreSQL 데이터베이스를 사용하는 애플리케이션은 삭제된 연결과 실패한 트랜잭션을 검색하고 다시 시도하도록 빌드되어야 합니다.		 데이터베이스 서버 오류가 검색되면 서버가 대기 서버로 장애 조치(failover)되므로 가동 중지 시간을 줄일 수 있습니다. 자세한 내용은 HA 개념 페이지를 참조하세요. RTO는 데이터 손실 없이 60~120초 이내여야 합니다.
스토리지 오류 디스크 오류 또는 물리적 블록 손상과 같은 스토리지 관련 문제는 애플리케이션에 영향을 주지 않습니다. 데이터가 3개 복사본에 저장되므로 남은 스토리지에서 데이터 복사본이 제공됩니다. 손상된 데이터 블록이 자동으로 복구되고 데이터의 새 복사본이 자동으로 생성됩니다. 전체 스토리지에 액세스할 수 없는 경우처럼 복구할 수 없는 드문 오류가 발생한 경우에는 Azure Database for PostgreSQL 유연한 서버를 대기 복제본으로 장애 조치(failover)하여 가동 중지 시간을 줄입니다. 자세한 내용은 HA 개념 페이지를 참조하세요.
논리적/사용자 오류 실수로 삭제한 테이블 또는 잘못 업데이트된 데이터와 같은 사용자 오류로부터 복구하려면 PITR(지정 시간 복구)를 수행해야 합니다. 복원 작업을 수행하는 동안 사용자 지정 복원 지점을 지정합니다. 이 지점은 오류 발생 직전의 시간입니다.

데이터베이스 서버에 있는 모든 데이터베이스 대신 데이터베이스의 일부 또는 특정 테이블만 복원하려면 새 인스턴스에서 데이터베이스 서버를 복원하고 pg_dump를 통해 테이블을 내보낸 후 pg_restore를 사용하여 테이블을 데이터베이스로 복원하면 됩니다.		 모든 변경 내용이 대기 복제본에 동기적으로 복제되므로 이러한 사용자 오류 고가용성으로 보호되지 않습니다. 해당 오류에서 복구하려면 특정 시점 복원을 수행해야 합니다.
가용성 영역 오류 영역 수준 오류에서 복구하려면 백업을 사용하고 사용자 지정 복원 지점을 선택하여 최신 데이터를 복구할 최신 시간으로 특정 시점 복원을 수행할 수 있습니다. 새로운 Azure Database for PostgreSQL 유연한 서버 인스턴스는 영향을 주지 않는 다른 영역에 배포됩니다. 복원에 걸리는 시간은 이전 백업 및 복구할 트랜잭션 로그의 양에 따라 달라집니다. Azure Database for PostgreSQL 유연한 서버는 데이터 손실 없이 60~120초 이내에 대기 서버에 자동으로 장애 조치(failover) 됩니다. 자세한 내용은 HA 개념 페이지를 참조하세요.
지역 오류 서버가 지역 중복 백업으로 구성된 경우 쌍을 이루는 지역에서 지역 복원을 수행할 수 있습니다. 새 서버가 프로비저닝되고, 이 지역에 복사된 마지막으로 사용 가능한 데이터로 복구됩니다.

지역 간 읽기 복제본을 사용할 수도 있습니다. 지역 장애가 발생한 경우 읽기 복제본을 독립 실행형 읽기-쓰기 가능 서버로 승격하여 재해 복구 작업을 수행할 수 있습니다. RPO는 RPO가 실패 시점의 복제 지연에 근접할 수 있는 심각한 지역 장애의 경우를 제외하고 최대 5분(데이터 손실 가능)으로 예상됩니다.		 동일한 프로세스입니다.

지역별 오류를 복구한 후의 데이터베이스 구성

Important

삭제된 서버는 복원할 수 없습니다. 서버를 삭제하면 삭제된 Azure 데이터베이스 - Azure Database for PostgreSQL 유연한 서버 복원 지침을 따라 서버를 복구할 수 있습니다. Azure 리소스 잠금을 사용하여 사고로 인한 서버 삭제를 방지할 수 있습니다.

다음 단계