12.6 자주 묻는 질문(FAQ)
CloudNativePG 공식 문서의 FAQ를 주제별로 옮겨 정리한다. Kubernetes에서 PostgreSQL을 운영하는 것에 대한 근본적인 의문, operator 설계 선택, 고가용성과 데이터베이스 운영에 관한 물음이 이어진다.
Kubernetes에서 PostgreSQL 운영하기
Q. stateful 워크로드는 Kubernetes에 못 올린다는 통념이 있는데, PostgreSQL은 왜 되는가?
A. 2021년 Data on Kubernetes Community 설문에서 응답자의 90%가 Kubernetes가 stateful 워크로드를 감당할 수 있다고 봤고, 70%는 실제로 데이터베이스를 운영 환경에서 돌리고 있었다. Kubernetes 1.14(2019년 4월)에서 들어온 local persistent volume 지원이 이 흐름의 전환점이었다.
Q. “immutable application container"란 무엇인가?
A. 컨테이너를 단일 프로세스 워크로드로 설계해, PostgreSQL 프로세스만 PID 1로 돈다는 뜻이다. SSH·systemd·syslog 같은 다른 프로세스는 허용하지 않는다. immutability 덕분에 컨테이너는 생애주기 동안 변경되지 않으며, 업데이트는 live 컨테이너를 패치하는 대신 이미지를 다시 빌드·배포해 이뤄진다.
Q. bare metal Kubernetes 클러스터에서도 돌아가는가?
A. 그렇다. 2019년 파일럿에서 local persistent volume을 쓴 bare metal 위 PostgreSQL을 측정한 결과, 컨테이너로 인한 성능 영향은 무시할 만한 수준이었다.
Q. 왜 단순한 컨테이너 Pod가 아니라 operator를 쓰는가?
A. operator는 Kubernetes 컨트롤러를 확장해 운영 환경의 복잡한 애플리케이션을 관리한다. 단순 배포는 failover를 사람이 처리해야 하지만, operator는 클러스터를 배포하는 데서 그치지 않고 예기치 못한 사건 뒤에 알맞게 반응한다. 선언적 설정, self-healing, 고가용성, 백업·복구 자동화가 여기서 나온다.
Q. CloudNativePG 말고 어떤 PostgreSQL operator가 있는가?
A. Crunchy Data(2017), Zalando(2017), Stackgres(2020), Percona(2021), Kubegres(2021) 등이 있다. 선택 전에 비교해 볼 것을 권한다.
Q. Kubernetes에서 PostgreSQL을 운영하려면 어떤 역량이 필요한가?
A. PostgreSQL과 Kubernetes 양쪽 지식이 모두 필요하다. DBA가 Kubernetes 핵심 개념에 익숙해지고 Kubernetes 관리자와 소통할 수 있을 때 가장 좋은 경험이 나온다. CNCF의 Certified Kubernetes Administrator 인증을 권한다.
Q. CloudNativePG는 왜 StatefulSet을 쓰지 않는가?
A. CloudNativePG는 PVC를 직접 관리하며, 선택한 storage class로 동적 provisioning을 활용한다. 자세한 이유는 “Custom Pod Controller” 문서를 참고한다.
고가용성
Q. operator Pod가 내려가면 어떻게 되는가?
A. PostgreSQL은 Kubernetes service를 통해 정상 동작을 이어 간다. 각 PostgreSQL Pod 안의 instance manager가 계속 돌며 데이터베이스 서버를 살리고, 로깅·metric export·WAL 연속 archiving 같은 부속 기능도 유지한다. operator 장애는 데이터베이스 장애와 다르다. 관리자가 잠시 자리를 비운 채 데이터베이스가 도는 상황에 가깝다.
Q. 왜 Patroni·repmgr·Stolon 같은 failover 도구에 기대지 않는가?
A. CloudNativePG는 Kubernetes 컨트롤러를 직접 확장하는 길을 택했다. Kubernetes API server가 Postgres 클러스터 상태를 담는 유일한 진실의 원천이 되고, instance manager와 이를 통해 HA를 조율한다. 외부 도구를 두지 않는다.
Q. failover 뒤 옛 primary를 수동으로 재동기화해야 하는가?
A. 아니다. operator가 자동으로 처리하며, pg_rewind로 옛 primary를 새 primary에 맞춘다.
데이터베이스 운영
Q. 왜 PostgreSQL인가?
A. native streaming replication, point-in-time recovery를 갖춘 연속 hot backup, 선언적 partitioning, PostGIS 같은 확장성, 병렬 질의, hybrid multi-model을 위한 JSON 지원까지 갖춘다. 운영 체제에서 Linux가 차지하는 위상에 견줄 만한 종합적인 엔터프라이즈 역량이다.
Q. 한 PostgreSQL 인스턴스에 데이터베이스를 몇 개 두는 것이 좋은가?
A. 데이터베이스 하나당 클러스터 하나가 권장된다. microservice 아키텍처 원칙에 맞다. 여러 데이터베이스를 두는 것도 기술적으로는 가능하지만, 하나의 애플리케이션에 자원을 전용하면 자원 관리가 쉬워지고, 연속 백업·복구가 단순해지며, 애플리케이션을 독립적으로 업데이트하고 PostgreSQL 버전도 자유롭게 고를 수 있다.
Q. Kubernetes를 고려할 때 데이터베이스 크기의 상한이 있는가?
A. 상한은 없다. Kubernetes는 가상 머신이나 bare metal처럼 확장된다. 아주 큰 데이터베이스라면 worker node 하나에 Postgres 인스턴스 하나와 전용 스토리지를 붙이는 shared nothing 아키텍처를 고려한다. tablespace와 수평 partitioning이 확장을 돕는다.
Q. timezone은 어떻게 설정하는가?
A. .spec.postgresql.parameters에서 지정한다. 예를 들어 timezone: "Europe/Rome"처럼 클러스터 수준으로 설정한다.
Q. 사업 연속성에 가장 좋은 아키텍처는?
A. availability zone과 worker node에 인스턴스를 분산하고 스토리지를 전용으로 붙인다. synchronous replication으로 RPO=0을 보장할 수 있도록 standby를 최소 둘 둔다. object storage로 연속 백업을 건다. 그리고 이 구조를 다른 region의 클러스터에 replica cluster 기능으로 복제해 재해 복구와 글로벌 규모의 HA에 대비한다.
Q. 인스턴스를 시작·정지하려면?
A. “Fencing” 또는 “Hibernation” 문서를 참고한다. (Part XI 참고)
Q. operator가 자동으로 만드는 전역 객체는?
A. application user(기본 app)와 그 user가 소유하는 application database(기본 app)를 만든다. 덕분에 superuser 없이도 microservice를 도입할 수 있고, 개발자는 application user로 마이그레이션을 관리하며 추가 role은 선언적 기능으로 다룬다.
정리
- Kubernetes는 이제 stateful 워크로드를 감당한다 — local persistent volume이 전환점
- operator를 쓰는 이유는 배포를 넘어 장애에 자동 반응하기 위함
- CloudNativePG는 외부 failover 도구 대신 Kubernetes API를 진실의 원천으로 삼는다
- operator가 내려가도 instance manager가 데이터베이스를 지킨다
- 권장 구성: 데이터베이스당 클러스터 하나, standby 2개 이상, object storage 백업, 크로스 region replica cluster
이것으로 Part XII와 이 노트를 마친다. 처음으로 돌아가려면 차례로.