메인 콘텐츠로 건너뛰기
Managed Postgres는 내구성 및 성능 요구 사항에 맞는 여러 수준의 고가용성을 제공합니다. 데이터베이스를 Provisioning할 때 대기 인스턴스를 1개 또는 2개 추가할 수 있으며, 필요에 따라 나중에 설정 페이지에서 이 구성을 조정할 수도 있습니다.

​
고가용성 옵션

​
2개의 대기 인스턴스

대기 인스턴스 2개를 사용하는 경우, 프라이머리와 함께 2개의 레플리카 노드가 프로비저닝됩니다. 두 대기 인스턴스는 모두 프라이머리와 동일한 크기이며, 프라이머리에 장애가 발생하면 둘 중 어느 쪽이든 역할을 넘겨받을 수 있습니다. 이 구성은 **동기 복제(synchronous replication)**를 사용합니다. 즉, 프라이머리는 쓰기를 확정하기 전에 최소 1개의 대기 인스턴스로부터 확인 응답을 받아야 합니다. 따라서 비동기 복제보다 더 강력한 내구성을 보장합니다. 두 대기 인스턴스 모두의 응답이 아니라 1개의 응답만 필요하므로, 단일 대기 인스턴스를 사용하는 동기 복제보다 성능 저하도 덜합니다.

​
1개 대기 인스턴스

대기 인스턴스 1개를 사용하는 경우, 프라이머리와 함께 레플리카 노드 1개가 프로비저닝됩니다. 대기 인스턴스는 프라이머리와 동일한 크기이며, 프라이머리에 장애가 발생하면 대신 서비스를 인계할 수 있습니다. 데이터는 비동기 복제(asynchronous replication) 를 사용해 대기 인스턴스로 복제됩니다. 즉, 쓰기는 대기 인스턴스의 확인 응답을 기다리지 않고 프라이머리에 커밋됩니다. 비동기 복제는 추가적인 네트워크 지연 시간으로 인해 고가용성이 쓰기 성능을 저하시키지 않도록 합니다. 하지만 프라이머리에 장애가 발생하는 시점에는 대기 인스턴스가 최신 트랜잭션을 아직 받지 못했을 수도 있습니다. 대부분의 애플리케이션에서는 성능과 아주 최근의 쓰기 일부가 손실될 수 있는 작은 위험 사이의 이러한 절충이 충분히 합리적입니다. 쓰기 내구성이 중요하다면 대기 인스턴스 2개 옵션을 선택하는 것이 좋습니다.

​
대기 인스턴스 없음

이 옵션을 사용하면 선택한 크기로 프라이머리 노드만 프로비저닝됩니다. 대기 인스턴스 노드는 생성되지 않습니다. 프라이머리 노드의 장애는 계속 모니터링되지만, 즉시 인계할 준비가 된 레플리카가 없으므로 문제의 성격에 따라 복구에 더 오랜 시간이 걸릴 수 있습니다. 이 구성은 어느 정도 다운타임을 허용할 수 있는 개발 환경, 테스트 또는 중요도가 낮은 워크로드에 가장 적합합니다.

​
대기 인스턴스와 읽기 레플리카 비교

대기 인스턴스와 읽기 레플리카는 Managed Postgres에서 용도가 서로 다르며, 각각 별도로 구성됩니다. 대기 인스턴스는 고가용성과 자동 장애 조치만을 위한 전용 구성입니다. 프라이머리의 데이터를 스트리밍 복제로 복제하며, 프라이머리에 장애가 발생할 경우 즉시 승격될 수 있도록 항상 준비되어 있습니다. 대기 인스턴스는 읽기 쿼리용으로는 제공되지 않습니다. 읽기 레플리카는 읽기 스케일링을 위해 설계되었습니다. 객체 스토리지에서 WAL(Write-Ahead Log) 데이터를 가져오며, 자체 endpoint를 갖춘 별도의 네트워크 환경에서 실행됩니다. 읽기 레플리카를 사용하면 고가용성(HA) 보장에 영향을 주지 않으면서 프라이머리의 읽기 트래픽을 분산할 수 있습니다.

​
대기 인스턴스가 읽기 쿼리를 처리하지 않는 이유

일부 데이터베이스 제공업체는 읽기 전용 쿼리를 위한 핫 대기 인스턴스를 제공하지만, Managed Postgres는 의도적으로 이를 제공하지 않습니다. 대기 인스턴스에서 읽기 쿼리를 허용하면 프라이머리에 장애가 발생했을 때 즉시 역할을 넘겨받을 준비 상태를 유지한다는 본래 목적이 훼손될 수 있습니다. 주요 우려 사항은 두 가지입니다.
  1. WAL 재생 경쟁: 쓰기 부하가 큰 환경에서는 대기 인스턴스의 읽기 쿼리가 시스템 리소스를 두고 WAL 재생과 경쟁하게 됩니다. 이 경쟁으로 복제 지연이 크게 늘어날 수 있으며, 그 결과 대기 인스턴스가 프라이머리를 따라가지 못할 수 있습니다. 대기 인스턴스에 지연이 발생한 상태에서 장애 조치가 일어나면 최신 데이터가 반영되지 않았을 수 있으므로, 원활하게 역할을 넘겨받지 못할 수 있습니다.
  2. VACUUM 간섭: 대기 인스턴스에서 장시간 실행되는 읽기 쿼리는 프라이머리에서 VACUUM(및 AUTOVACUUM)이 dead tuple을 정리하지 못하게 만들 수 있습니다. PostgreSQL은 어떤 레플리카에서든 활성 쿼리가 여전히 접근해야 할 가능성이 있는 행은 제거할 수 없습니다. 이로 인해 테이블 팽창이 발생하고 시간이 지날수록 성능이 저하될 수 있습니다.
Managed Postgres는 대기 인스턴스를 장애 조치 전용으로 유지함으로써 항상 동기화 상태를 유지하고, 최소한의 데이터 손실과 다운타임으로 역할을 넘겨받을 수 있도록 보장합니다. 읽기 스케일링이 필요하다면 대신 읽기 레플리카를 사용하십시오.

​
장애 처리

고가용성 활성화 여부와 관계없이 모든 Managed Postgres 인스턴스는 장애 발생 여부를 지속적으로 모니터링합니다. 모든 경우에 시스템은 장애를 자동으로 복구하려고 시도합니다. 대기 인스턴스를 사용할 수 있으면 자동 복구가 더 빠르고 간단해집니다. 일반적으로 대기 인스턴스를 프라이머리로 승격하여 몇 분 내에 복구됩니다. 대기 인스턴스가 없으면 복구에 수동 개입이 필요할 수 있으며, 이로 인해 장애 지속 시간이 크게 늘어날 수 있습니다.
마지막 수정일 2026년 6월 10일