1.2 사용 사례

CloudNativePG는 어떤 상황에서 쓰는가. 공식 문서는 애플리케이션의 위치를 기준으로 두 가지 대표 사례를 든다. 애플리케이션이 PostgreSQL과 같은 Kubernetes 클러스터 안에 있는 경우와, 클러스터 밖(VM·전통 환경)에 있는 경우다. CNPG는 “같은 Kubernetes 클러스터 안에 있는 애플리케이션과 함께 동작하도록 설계"됐지만, 모든 워크로드를 컨테이너화하기 어려운 현실도 수용한다.

두 경우의 갈림길은 결국 애플리케이션이 데이터베이스에 어떤 경로로 접속하느냐다.

    flowchart TD
    START[애플리케이션 위치] --> IN{같은 클러스터 안?}
    IN -->|예| CASE1[내부 Service로 접속]
    IN -->|아니오| CASE2[LoadBalancer로 외부 노출]
  

사례 1: 애플리케이션이 Kubernetes 안에 있을 때

애플리케이션과 데이터베이스가 같은 Kubernetes 클러스터, 흔히 같은 namespace에서 함께 동작하는 구성이다. CNPG가 지향하는 완전한 cloud native 경험에 가장 가깝다.

• 애플리케이션은 여러 replica를 가진 stateless Deployment로 여러 node에 분산 배포한다.
• 외부 사용자에게는 Ingress와 load balancer를 통해 HTTPS로 노출하고, 클러스터 내부에서는 ClusterIP service로 접근한다.
• 애플리케이션은 CNPG Cluster 리소스가 노출하는 read-write service를 통해 PostgreSQL에 접속하며, TLS로 암호화된 연결을 쓴다.

여기서 핵심은 Cluster 리소스가 “single primary + multiple standby 아키텍처의 로직을 내장해, PostgreSQL high availability 클러스터 관리의 복잡성을 감춘다"는 점이다. 애플리케이션은 어느 Pod가 primary인지 신경 쓸 필요 없이, read-write service 이름 하나만 바라보면 된다. failover가 일어나 primary가 바뀌어도 service가 새 primary를 가리키므로 접속 지점은 그대로다.

    flowchart TD
    U[사용자] -->|HTTPS| ING[Ingress]
    ING --> APP[애플리케이션 Deployment]
    APP -->|TLS 접속| RW[read-write Service]
    RW --> PRI[Primary Pod]
    PRI -.replication.-> REP[Replica Pod들]
  

사례 2: 애플리케이션이 Kubernetes 밖에 있을 때

PostgreSQL은 Kubernetes에서 돌리되, 애플리케이션은 VM이나 기존 가상화 인프라 같은 전통 환경에 남아 있는 구성이다. 모든 것을 한 번에 컨테이너화하기 어려운 이행기의 현실적인 선택이다.

• PostgreSQL은 외부에서 IP 주소나 호스트명 + TCP 포트로 표현된다.
• 보통 LoadBalancer 타입 service를 통해, Ingress 리소스로 외부에 노출한다.
• 이 경우에도 애플리케이션은 PostgreSQL과 TLS로 암호화된 연결을 유지할 수 있다.

    flowchart TD
    APP[클러스터 밖 애플리케이션] -->|TCP + TLS| LB[LoadBalancer Service]
    LB --> PRI[Primary Pod]
    PRI -.replication.-> REP[Replica Pod들]
  

정리

두 사례 모두 애플리케이션은 개별 Pod가 아니라 CNPG가 제공하는 service를 바라본다는 원칙은 같다. 다음 절에서는 로컬 kind 클러스터에 Operator를 설치하고 첫 Cluster를 직접 띄워 이 구조를 눈으로 확인한다.