Kubernetes에서 PostgreSQL 돌리기, 생각보다 어렵지 않습니다

Bro's Insights
, ,
1

Kubernetes에서 데이터베이스 운영하는 거, 솔직히 쉽지 않죠. 저도 처음에는 stateful 애플리케이션을 K8s에서 돌린다는 게 좀 부담스러웠습니다. 그런데 CloudNativePG(CNPG)를 쓰면서 생각이 많이 바뀌었어요.

CNPG가 뭔가요?

CNPG는 Kubernetes용 PostgreSQL 오퍼레이터입니다. CNCF Sandbox 프로젝트고요. 그냥 PostgreSQL을 컨테이너에 넣은 게 아니라, Kubernetes 방식으로 데이터베이스를 관리할 수 있게 만들어졌습니다.

제가 좋아하는 부분은 정말 많은데요, 페일오버가 보통 5초 안에 끝나고, YAML로 선언만 하면 알아서 HA 클러스터가 뜨고, GitOps로 관리할 수 있다는 점입니다. Barman으로 백업하고 PITR도 되고, PgBouncer 붙이는 것도 간단합니다. Prometheus 메트릭은 기본으로 나오고요.

무엇보다 롤링 업데이트로 PostgreSQL 버전 올리는 게 정말 편합니다. 예전엔 이거 하나 하려고 얼마나 긴장했는지…

EDB 이야기를 좀 해야겠네요

CNPG는 원래 EDB(EnterpriseDB)에서 만들었습니다. 2022년에 CNCF에 기증했고요. 저는 이런 케이스가 오픈소스의 좋은 예시라고 생각해요.

EDB는 지금도 핵심 컨트리뷰터로 활동하면서 프로젝트를 계속 밀어주고 있습니다. 동시에 엔터프라이즈 고객들한테는 상용 지원을 제공하고 있고요. PostgreSQL 커뮤니티에서도 주요 기여자인 EDB가 CNPG를 통해 클라우드 네이티브 쪽으로 PostgreSQL 생태계를 확장하고 있는 거죠.

기업이 만든 걸 커뮤니티에 내놓고, 커뮤니티는 성장하고, 기업은 엔터프라이즈 지원으로 비즈니스 하고. 이런 게 진짜 win-win 아닐까요?

왜 CNPG를 쓰게 됐냐면

다른 솔루션들도 써봤는데, CNPG는 진짜 Kubernetes를 위해 만들어진 느낌입니다. Patroni나 별도 etcd 없이 Kubernetes API를 그냥 쓰거든요.

배포는 정말 간단합니다. YAML 몇 줄이면 3노드 HA 클러스터가 뜹니다. 인스턴스 개수랑 스토리지 크기만 정해주면 끝이에요.

실제로 프로덕션에서 쓰는 곳도 많고, CNCF 프로젝트니까 커뮤니티 지원도 활발합니다. 페일오버, 백업, 스토리지 관리, 모니터링 전부 자동이라 운영 부담이 확 줄어요.

어디서 쓸까요?

금융권에서는 거래 시스템에 많이 씁니다. HA가 필수니까요. SaaS 회사들은 테넌트별로 DB 클러스터 분리해서 운영하고, 이커머스는 트래픽 피크 대응용으로 쓰고, DevOps 팀은 GitOps로 DB 관리하는 데 쓰고 있습니다.

시작해보세요

오퍼레이터 설치하고 클러스터 YAML 하나 올리면 됩니다. cloudnative-pg.io 가면 문서 다 있고, GitHub에 가면 예제도 많습니다.

K8s에서 PostgreSQL 쓰시는 분들, 한번 써보시면 생각 바뀔 겁니다. 저처럼요.

7 Likes
2

CNPG라는 용어는 처음 접해보네요. :slight_smile: 정보 공유 감사합니다.

1 Like
3

@myoungsig.youn 님! 반갑습니다. EDB에 계시는 군요. PG에 궁금한 거 있으면 조언 문의할께요. 저는 프리렌서로 PyTorch 관련 업무를 하고 있습니다. ^^

2 Likes
4

저도 온프렘에서만 PostgreSQL을 다루다가 CNPG에 관심을 갖고 있습니다…ㅎ

혹시 운영 중 스토리지나 네트워크 쪽에서 겪으신 이슈가 있을까요? 온프레 환경과 비교했을 때 주의해야 할 점이 있다면 공유해주시면 감사하겠습니다!

2 Likes
5

저는 데이터베이스는 본질적으로 안정성과 백업이 가장 중요하다고 생각하기 때문에, 원칙적으로는 Kubernetes와 분리하여 운영하는 것이 맞다고 봅니다.
그런데 실제 운영 과정에서 데이터베이스 업데이트 시 무중단 처리가 가능한지, 또 Kubernetes 자체 업데이트 시 무중단을 어떻게 보장하시는지 궁금합니다.

2 Likes
6

가장 핵심적인 차이는 DBA가 직접 명령을 내리는 ‘명령형(Imperative)’ 방식에서, 원하는 상태를 정의하면 시스템이 알아서 맞추는 ‘선언형(Declarative)’ 방식으로 전환된다는 점입니다.

온프레미스와 비교하여 CNPG 환경에서 특별히 주의해야 할 핵심적인 5가지 사항을 말씀드리겠습니다.

1. 스토리지 (Storage): 영속성에 대한 새로운 접근

온프레미스 환경에서 스토리지는 안정적인 SAN이나 로컬 디스크 그 자체였습니다. 하지만 쿠버네티스에서는 완전히 다른 개념으로 접근해야 합니다.

  • 온프레미스: DBA가 직접 스토리지 경로(/data)를 지정하고 관리하며, 서버가 재부팅되어도 데이터는 그 자리에 그대로 있습니다.

  • CNPG (주의점): 컨테이너(Pod)는 언제든지 죽고 새로 생길 수 있는 ‘휘발성’ 존재입니다. 따라서 데이터의 영속성을 보장하기 위해 Persistent Volume (PV)과 Persistent Volume Claim (PVC) 개념을 반드시 이해해야 합니다.

    • 핵심: StorageClass의 선택이 DB 성능을 좌우합니다. 일반 파일 스토리지가 아닌, 데이터베이스 워크로드에 맞는 고성능 블록 스토리지 기반의 StorageClass를 반드시 사전에 설계하고 준비해야 합니다. 잘못된 스토리지를 선택하면 클러스터 전체의 성능 저하를 피할 수 없습니다.

2. 네트워크 (Networking): 동적인 IP와 서비스 추상화

온프레미스에서는 서버의 IP 주소가 고정되어 있고 예측 가능합니다. 하지만 쿠버네티스에서는 이 가정이 깨집니다.

  • 온프레미스: DB 서버 IP (192.168.1.10)는 거의 바뀌지 않으며, 애플리케이션은 이 IP로 직접 접속합니다.

  • CNPG (주의점): Pod의 IP 주소는 동적(Dynamic)입니다. Pod가 재시작되면 IP가 변경됩니다. 따라서 애플리케이션이 Pod의 IP로 직접 접속하면 장애가 발생합니다.

    • 핵심: 반드시 쿠버네티스가 제공하는 서비스(Service) 객체를 통해 접속해야 합니다. CNPG는 자동으로 Primary 접속용(-rw)과 Standby 접속용(-ro, -rr) 서비스를 생성해 줍니다. 애플리케이션은 절대로 Pod IP가 아닌, 이 안정적인 서비스 DNS 이름에 접속하도록 구성해야 합니다.

3. 관리 방식: psql에서 kubectl과 YAML로

온프레미스 DBA는 서버에 직접 접속해 설정 파일을 수정하고 서비스를 재시작하는 데 익숙합니다. CNPG에서는 이런 방식이 통하지 않습니다.

  • 온프레미스: vi postgresql.conf → pg_ctl restart

  • CNPG (주의점): 모든 설정 변경은 YAML Manifest 파일을 통해 ‘선언’ 되어야 합니다. 예를 들어, 인스턴스 수를 3개에서 5개로 늘리고 싶다면, Pod를 수동으로 만드는 것이 아니라 YAML 파일의 instances: 3을 instances: 5로 수정하고 kubectl apply를 실행해야 합니다.

    • 핵심: CNPG 오퍼레이터가 YAML 파일의 변경 사항을 감지하고, 현재 상태와 목표 상태의 차이를 파악하여 자동으로 Pod를 추가 생성하고 클러스터에 편입시킵니다. DBA는 '어떻게’가 아닌 '무엇을 원하는지’만 정의하면 됩니다.

4. 성능과 리소스: '체감 성능’의 변동성

온프레미스, 특히 물리 서버 환경에서는 리소스가 보장되므로 성능이 비교적 일정하고 예측 가능합니다.

  • 온프레미스: 할당된 CPU, 메모리는 온전히 DB가 사용합니다.

  • CNPG (주의점): DB Pod는 쿠버네티스 클러스터의 여러 노드(Worker Node) 중 하나에서 실행됩니다. 다른 애플리케이션 Pod와 리소스를 공유하므로 ‘시끄러운 이웃(Noisy Neighbor)’ 문제가 발생할 수 있습니다.

    • 핵심: DB Pod의 최소/최대 리소스 사용량을 정의하는 Requests와 Limits를 명확하게 설정하여 최소한의 성능을 보장해야 합니다. 또한, DB와 같이 중요한 워크로드는 nodeSelector나 Taints/Tolerations를 이용해 특정 노드에서만 실행되도록 격리하는 전략이 필요합니다.

5. 장애 대응: 자동 복구에 대한 신뢰

온프레미스에서 서버가 다운되면 DBA가 직접 원인을 파악하고 복구 절차를 수행합니다.

  • 온프레미스: 장애 발생 → DBA 호출 → 원인 분석 → 수동 복구

  • CNPG (주의점): 쿠버네티스와 CNPG 오퍼레이터의 핵심 가치는 '자가 치유(Self-Healing)'입니다. DB Pod 하나에 문제가 생기면 쿠버네티스는 해당 Pod를 즉시 종료하고 새로운 Pod를 자동으로 생성합니다. CNPG 오퍼레이터는 이 상황을 감지하고 필요 시 자동 Failover를 수행합니다.

    • 핵심: DBA는 개별 Pod의 장애에 일일이 대응하기보다, 클러스터 전체가 선언된 상태를 잘 유지하는지를 모니터링해야 합니다. 수동 개입을 최소화하고 자동화된 시스템을 신뢰하는 마음가짐의 전환이 필수적입니다.
2 Likes
7

말씀하신 ‘안정성’ 문제를 CNPG는 다음과 같이 '지능적인 자동화’로 해결합니다.

1. 데이터베이스 업데이트 시 (무중단 롤링 업데이트)

마치 달리는 자동차의 바퀴를 하나씩 갈아 끼우는 것과 같습니다.

CNPG는 절대 Primary(메인 DB)부터 건드리지 않습니다. 먼저 Standby(보조 DB)들을 새로운 버전으로 안전하게 교체한 뒤, 가장 건강한 Standby를 새로운 Primary로 승격시키는 '안전한 전환(Switchover)'을 수행합니다. 마지막으로 구(舊) Primary를 업데이트합니다.

이 모든 과정 동안 애플리케이션은 항상 정상적인 DB에 연결되어 있어 중단을 전혀 인지하지 못합니다.

2. 쿠버네티스(인프라) 업데이트 시 (지능적인 자동 대응)

CNPG는 쿠버네티스와 "우리 DB는 최소 2대 이상 항상 살아있어야 해"라는 약속(PodDisruptionBudget)을 맺습니다.

관리자가 특정 서버(노드)를 점검하려고 하면, CNPG는 이 약속을 지키기 위해 자동으로 움직입니다. 만약 점검할 서버에 Primary가 있다면, CNPG가 먼저 안전한 다른 서버로 Primary 역할을 넘기는 'Switchover’를 수행한 뒤 점검을 허락합니다. 덕분에 인프라가 변경되어도 DB 서비스는 절대 중단되지 않습니다.

결론적으로, 전통적인 '물리적 분리’가 주던 안정감을, CNPG는 'DB 전문가의 운영 노하우가 코드화된 지능적인 자동화’로 대체하여 더 높은 수준의 무중단 운영을 보장합니다.

3 Likes
8

답변감사합니다

답변주신 내용을 검색하던 중 흥미로운 글이 있어서 공유드립니다

2 Likes