12.6 자주 묻는 질문(FAQ)

CloudNativePG 공식 문서의 FAQ를 주제별로 옮겨, Kubernetes에서 PostgreSQL을 운영하며 자주 부딪히는 물음을 Q/A로 정리합니다.

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가 PostgreSQL 클러스터 상태를 담는 유일한 진실의 원천이 되고, Operator가 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 하나에 PostgreSQL 인스턴스 하나와 전용 스토리지를 붙이는 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와 이 노트를 마칩니다. 처음으로 돌아가려면 차례로.