PostgreSQL은 오랜 역사를 가진 안정적인 데이터베이스지만, Kubernetes 시대를 맞아 새로운 도전 과제를 안게 되었다. 상태 저장(Stateful) 애플리케이션을 컨테이너 환경에서 안정적으로 운영하는 것은 여전히 쉽지 않으며, 데이터베이스는 그 중심에 있다.
CloudNativePG는 이러한 문제를 해결하고자 태어난 PostgreSQL을 위한 Kubernetes Operator로, 데이터베이스의 설치, 운영, 복제, 장애 복구, 백업 등의 전 과정을 자동화하는 것을 목표로 한다. 이 글에서는 CloudNativePG 프로젝트의 핵심 개념과 실전 운영에서의 가치, 그리고 아키텍처적인 특징을 소개한다.
CloudNativePG란 무엇인가?
CloudNativePG는 EnterpriseDB에서 주도하고 커뮤니티 중심으로 개발되는 오픈소스 프로젝트로, **CNCF(Cloud Native Computing Foundation)**의 Sandbox 프로젝트로 채택되며 신뢰성을 인정받고 있다.
CloudNativePG는 단순한 Helm chart가 아니다. Kubernetes Operator 패턴을 기반으로 PostgreSQL 클러스터의 라이프사이클 전반을 Kubernetes 네이티브 방식으로 관리한다. 사용자는 PostgreSQL 클러스터를 하나의 Custom Resource로 정의하고, 운영자는 Operator가 자동으로 구성과 복제를 관리하도록 맡길 수 있다.
주요 기능
- 클러스터 자동 생성
- Custom Resource를 정의하면 자동으로 StatefulSet, PVC, ConfigMap 등을 구성하여 PostgreSQL 클러스터를 생성한다.
- 동기/비동기 복제 구성
- 기본적으로 세 노드의 클러스터(1 primary, 2 replica)를 권장하며, 자동 복제 설정을 지원한다.
- 동기 복제 설정, replication slots, failover 우선순위 등도 CRD 수준에서 제어 가능하다.
- 자동 장애 복구 (Failover)
- Primary 노드 장애 시 자동으로 가장 적절한 Replica를 승격(promote)하고, 나머지는 재조정된다.
- Patroni와 같은 별도 구성 없이 PostgreSQL의 내부 기능과 Kubernetes의 상태 감시로만 처리한다.
- 백업 및 PITR(Point-in-Time Recovery)
- wal-g를 기반으로 S3-compatible 오브젝트 스토리지에 백업
- 선언형 방식으로 백업 정책을 정의할 수 있고, 특정 시점 복구도 가능하다
- Kubernetes 친화적인 선언적 관리
- YAML 정의를 통해 전체 데이터베이스 라이프사이클을 제어할 수 있어 GitOps와도 궁합이 좋다.
- PostGIS, TLS, Password Rotation 등 부가 기능
- TLS 자동 구성, 패스워드 정책, 확장(extension) 관리 등 다양한 운영 기능도 커버
구성 요소
- PostgreSQL 클러스터 (Custom Resource)
- 사용자가 작성하는 핵심 정의로, 복제 개수, 스토리지 크기, 버전, 파라미터 등을 포함
- CloudNativePG Controller
- CRD를 감시하며, 클러스터 생성/업데이트/복구를 자동화하는 Operator
- Backup/Restore Controller
- S3, Azure Blob 등 외부 스토리지와 연동하여 백업/복구 수행
- WAL Archiving
- wal-g를 통해 WAL을 외부 저장소에 보관, PITR 지원
아키텍처 개요
CloudNativePG는 내부적으로는 PostgreSQL의 replication + Kubernetes Operator 패턴을 조합한 구조이다. StatefulSet 기반의 Primary/Replica 구조를 구성하고, pg_basebackup, pg_rewind, pg_ctl promote 등을 내부적으로 사용하여 데이터 일관성과 장애 복구를 수행한다.
Operator는 CRD의 상태를 주기적으로 확인하고, PostgreSQL 노드의 상태와 Kubernetes 리소스 상태가 불일치할 경우 이를 자동으로 조정한다. Kubernetes 네이티브의 이벤트 루프 방식이기 때문에 GitOps나 ArgoCD 기반 운영에도 적합하다.
실전에서의 가치
- 운영 자동화
- 수동으로 pg_hba.conf, recovery.conf 등을 관리하던 복잡함이 제거된다.
- 운영자는 YAML만 정의하고, Operator가 나머지를 처리한다.
- 고가용성 환경 구성
- 세 노드 클러스터 구성, 자동 장애 조치, 재복구는 기본 제공
- 별도의 외부 HA 도구(Patroni, etcd 등) 없이 운영 가능
- DevOps 및 GitOps 친화성
- 선언적 구성 → Git에 저장 → 변경 관리 → Rollback/Promotion 가능
- 백업/복원도 YAML로 관리 가능
- 클라우드/온프레미스 모두 적용 가능
- Minikube, K3s 같은 테스트 환경에서도 쉽게 적용 가능
- 기업 내 프라이빗 클러스터에도 적합