17.7 하이브리드 시나리오

운영 PostgreSQL이 완전 온프레미스도 완전 클라우드도 아닌 혼합 환경을 만나는 경우가 늘고 있습니다. 컴플라이언스·비용·기술 자유도가 이유. 흔한 하이브리드 패턴을 정리합니다.

1. 온프레미스 primary + 클라우드 DR

    flowchart LR
  ONP["onprem primary"]
  CLD["cloud read replica<br/>(DR)"]
  ONP -->|streaming or logical| CLD

  classDef onp fill:#ede9fe,stroke:#6d28d9,color:#3b0764
  classDef cld fill:#d1fae5,stroke:#047857,color:#064e3b
  class ONP onp
  class CLD cld
  

사용처:

• 데이터센터 사고 대비
• on-prem 사고 시 클라우드 promote

구현:

-- 클라우드는 매니지드가 streaming replication source 못 됨 (Aurora 제외 일부)
-- → on-prem primary + on-prem standby on cloud VM (자체 PostgreSQL)

매니지드를 standby로 쓰기 어려움 — IaaS PostgreSQL을 클라우드 VM에 띄워 streaming.

2. 클라우드 primary + 온프레미스 ETL

    flowchart LR
  CLD["cloud primary"]
  ONP["on-prem 분석 클러스터"]
  CLD -->|logical replication| ONP

  classDef cld fill:#ede9fe,stroke:#6d28d9,color:#3b0764
  classDef onp fill:#d1fae5,stroke:#047857,color:#064e3b
  class CLD cld
  class ONP onp
  

사용처:

• 컴플라이언스 — 분석 데이터는 사내
• 클라우드 비용 절감 — 분석은 on-prem
• pg_repack·자유로운 확장 활용

구현: logical replication (12.4) — publisher가 cloud, subscriber가 on-prem.

매니지드 클라우드의 logical replication 지원 여부 확인:

• AWS RDS: 지원 (PG 10+)
• Aurora: 지원
• Azure Flexible Server: 지원
• Cloud SQL: 지원

3. dual write — 마이그레이션 단계

    sequenceDiagram
  participant App
  participant Old as Old (Oracle/MySQL/on-prem PG)
  participant New as New (Cloud PG)

  App->>Old: 쓰기
  App->>New: 쓰기 (dual write)
  App->>Old: 읽기 (validation)
  

• 두 시스템에 같이 쓰기
• 결과 비교로 데이터 일관성 검증
• 일정 기간 후 read도 새 시스템으로
• 마지막에 옛 시스템 제거

위험: dual write가 부분 실패 가능합니다. eventual consistency 검증 도구 필요합니다.

4. CDC (Change Data Capture) 기반

    flowchart LR
  PG["PostgreSQL"]
  WAL["WAL"]
  DBZ["Debezium / Kafka Connect"]
  KAFKA["Kafka"]
  SINK["sink<br/>(다른 DB, DW, search)"]

  PG --> WAL --> DBZ --> KAFKA --> SINK

  classDef pg fill:#ede9fe,stroke:#6d28d9,color:#3b0764
  classDef mid fill:#dbeafe,stroke:#1d4ed8,color:#1e3a8a
  classDef sink fill:#d1fae5,stroke:#047857,color:#064e3b
  class PG pg
  class WAL,DBZ,KAFKA mid
  class SINK sink
  

• Debezium이 PostgreSQL의 logical decoding을 사용
• Kafka에 row 변경 스트림
• 다른 DB·Elasticsearch·DW·application 캐시 등 sink

매우 강력한 패턴 — 한 PG가 많은 다운스트림의 진실의 원천.

5. cross-cloud replication

AWS RDS PostgreSQL → GCP Cloud SQL (DR)

• AWS RDS의 logical replication을 외부 PG로
• 또는 외부 도구 (pgEdge, EDB BDR 등)

용도:

• 멀티 클라우드 전략
• 클라우드 락인 회피
• 비용·기능 비교

6. read-write 분리 — application

client → read (cloud read replica)
client → write (on-prem primary)

application이 read/write를 다른 endpoint로. ORM·DB driver 일부 지원 (Spring @Transactional(readOnly=true), Django routing 등).

7. 단계적 cloud 이전

1. on-prem primary + cloud read replica
2. cut-over: cloud read replica promote
3. on-prem decommission

logical replication 무중단 업그레이드(12.4·18.4)의 cloud 확장.

네트워크 연결

대규모는 전용선 — 안정성·대역폭·비용 균형.

인증·키 관리

secret manager(AWS Secrets Manager·Azure Key Vault·GCP Secret Manager·Hashicorp Vault)로 자격 증명 통합합니다.

모니터링 통합

on-prem PG → postgres_exporter → Prometheus
cloud PG → cloud-specific exporter → Prometheus

Prometheus → Grafana (통합 대시보드)

또는 SaaS (Datadog·New Relic) — 한 화면에서 onprem·cloud 모두.

운영 시 주의

매니지드의 outbound 한계

AWS RDS — pull replication 가능 (외부에서 RDS의 logical 구독)
        — push (RDS에서 외부로 streaming) — 매니지드 standby 만들기 어려움

대부분 매니지드는 outbound streaming 대상으로 못 씀. logical replication 또는 IaaS PostgreSQL을 cloud VM에 띄워 우회합니다.

정리

• 하이브리드 패턴 = on-prem + cloud, cross-cloud, dual write, CDC
• 매니지드 클라우드는 streaming 출발지로 어려움 — logical 또는 IaaS PG
• Debezium/CDC가 많은 시스템과의 통합에 표준
• 전용선·secret manager·통합 모니터링이 운영 기반
• 메이저 마이그레이션은 logical replication 무중단으로

Part XVII 클라우드 PostgreSQL이 끝났습니다. 다음 Part XVIII에서는 버전·시스템 간 이전 — 마이그레이션과 업그레이드를 봅니다.