PostgreSQL 클러스터 구성하기(1)

최근 진행한 프로젝트에서 PostgreSQL을 활용해 데이터베이스를 구축하게 되었습니다. 당연하게도 단일 인스턴스만으로는 장애 대응이 어려웠고, Master-Slave 구조를 통한 Failover와 고가용성(High Availability) 구성이 필수적이었습니다.

 

이런 상황에서 기술적으로 두 가지 선택지가 있었습니다.

• AWS의 RDS 서비스를 활용해 쉽게 구성하기
• EC2 인스턴스를 기반으로 직접 PostgreSQL 클러스터를 구성하기

RDS

• 장점
  • 몇 번의 클릭으로 복제 및 Multi-AZ 구성 가능
  • 백업, 모니터링, 패치 관리가 자동화
  • 장애 발생 시 자동 Failover 지원 (보통 수 분 이내 복구)
• 단점
  • 내부 복제 구조나 장애 전환 로직에 대한 제어가 어려움
  • 특정 확장 기능이나 커스텀 파라미터 설정에 제약
  • 비용 측면에서 EC2보다 비쌈 (특히 스토리지와 I/O 요금)

 

EC2 + PostgreSQL + 클러스터링

• 장점
  • 복제 방식(wal, slot 등), 장애 조치 로직, 구성 도구를 직접 선택하고 제어 가능
  • 오픈소스 도구들(Patroni, Etcd, HAProxy 등)과의 자유로운 연동
  • RDS보다 비용을 유연하게 조절 가능 (EBS 스토리지나 EC2 스펙 조정)
• 단점
  • 초기 구축 과정이 복잡하고 시간 소요됨
  • 운영, 모니터링, 장애 대응을 직접 설계하고 테스트해야 함
  • 구성 실수 시 데이터 손실 위험도 존재

PostgreSQL 고가용성 구조를 구축하는 데 있어, 두 가지 측면에서 EC2 기반의 직접 구성 방식을 선택하게 되었습니다.

 

1. 비용 절감

 

AWS RDS는 손쉽게 복제와 Multi-AZ 구성을 제공하지만, 구성 비용이 높은 편이고 숨겨진 과금 요소도 많습니다.

예를 들어, Multi-AZ 구성 시 인스턴스와 스토리지가 이중으로 필요하고 I/O 요청이나 스냅샷, 자동 백업에 따른 추가 비용도 발생합니다.

반면 EC2 기반 구성에서는 인스턴스 사양, EBS 용량/IOPS, 네트워크 등 모든 자원을 세밀하게 조정할 수 있으며, 예약 인스턴스, 스팟 인스턴스 활용 등 비용 최적화 전략을 직접 적용할 수 있습니다.

 

즉, 장기적으로 운영할수록 직접 구성 방식이 훨씬 유연하고 비용 효율적이라고 생각했습니다.

 

2. 커스터마이징 가능성

무엇보다 중요한 건 구성과 운영을 내 서비스에 맞게 커스터마이징할 수 있다는 점입니다. Patroni, Etcd, HAProxy를 직접 활용하면 다음과 같은 유연한 설정이 가능합니다.

• 장애 조치 조건을 내 기준에 맞게 정의
• PostgreSQL의 파라미터나 인증 정책을 상황에 따라 동적으로 조정
• 장애 발생 시 Slack 알림, 로깅, 모니터링 연동 등 자동화 스크립트 실행
• 클러스터 리더를 항상 추적하는 프록시 계층 구성

이러한 커스터마이징은 RDS나 Aurora 같은 관리형 DB에서는 제공되지 않는 유연성입니다. 직접 구성함으로써 복제 구조, 장애 대응 흐름, 트래픽 분산 정책 등 모든 것을 제 서비스 환경에 맞춰 최적화할 수 있습니다.