단일 클러스터의 한계와 멀티 클러스터의 필요성
Kubernetes 위에서 데이터베이스를 운영하는 것은 이제 일반적인 패턴이 되었다. 단일 클러스터 환경에서 Kubernetes는 Pod 재시작, 노드 장애 복구 등 자가 치유(Self-healing) 메커니즘을 잘 제공한다. 그러나 클러스터 자체가 실패하는 상황—리전 전체 장애, 컨트롤 플레인 손상, 네트워크 파티션—에 대해서는 기본적으로 아무런 자동 복구 경로를 제공하지 않는다.
이 상황에서 데이터베이스 노드를 복수의 Kubernetes 클러스터에 분산 배치하는 멀티 클러스터 아키텍처가 필요해진다. 단순히 HA(고가용성) 수준을 높이는 것을 넘어, 진짜 재해 복구 시나리오를 감당할 수 있는 구조를 만드는 것이 목표다.
멀티 클러스터가 해결하는 세 가지 핵심 시나리오
멀티 클러스터 데이터베이스 구성이 실무에서 의미 있는 이유는 아래 세 가지 구체적인 시나리오로 설명할 수 있다.
- 재해 복구(Disaster Recovery): 리전 전체가 다운되더라도, 보조 클러스터의 노드들이 이미 전체 데이터 복사본과 충분한 투표권(votes)을 보유하고 있어 자동으로 새 Primary를 선출하고 쓰기를 재개할 수 있다.
- 무중단 라이브 마이그레이션: 두 클러스터에 노드를 분산 운영하면, 클라우드 프로바이더 전환 같은 시나리오에서 데이터베이스를 오프라인으로 만들지 않고 애플리케이션 트래픽을 점진적으로 이전할 수 있다. 다만 커넥션 스트링 및 쓰기 일관성에 대한 애플리케이션 레벨 계획은 별도로 필요하다.
- 무중단 유지보수: 한쪽 클러스터 전체를 드레인하고 업그레이드하는 동안, 나머지 클러스터가 서비스를 지속하므로 다운타임 없이 인프라 작업이 가능하다.
배포 구조와 오퍼레이터 활용
멀티 클러스터 MongoDB를 Kubernetes 위에서 구성할 때, Percona Operator for MongoDB 같은 오픈소스 Kubernetes Operator를 활용하면 복잡한 ReplicaSet 구성을 선언적으로 관리할 수 있다. 관계형 워크로드라면 Vitess나 CloudNativePG도 유사한 멀티 클러스터 패턴을 지원한다.
핵심 배포 원칙은 MongoDB ReplicaSet 멤버를 클러스터 경계에 걸쳐 분산시키고, 각 클러스터가 독립적인 컨트롤 플레인을 갖도록 하는 것이다. 예를 들어 3개 노드 ReplicaSet을 두 클러스터에 배치할 경우, 일반적으로 2+1 또는 1+1+1(arbiter 포함) 구성을 취한다.
# 개념적 예시: 멀티 클러스터 ReplicaSet 멤버 분산
replsets:
- name: rs0
members:
- cluster: cluster-ap-northeast # 리전 A
votes: 1
priority: 2
- cluster: cluster-ap-northeast
votes: 1
priority: 1
- cluster: cluster-ap-southeast # 리전 B
votes: 1
priority: 0
이 구성에서 리전 A가 완전히 다운되더라도 리전 B의 노드가 과반수 투표를 확보해 새 Primary 선출을 트리거할 수 있으려면, arbiter 배치 전략과 투표 수 설계가 매우 중요하다. 단순히 노드를 분산하는 것으로는 부족하고, 장애 시나리오별로 quorum을 확보할 수 있는지를 사전에 검증해야 한다.
운영 관점에서 반드시 고려할 사항
멀티 클러스터 구성은 단순히 배포만으로 끝나지 않는다. 클러스터 간 네트워크 레이턴시가 MongoDB의 쓰기 성능에 직접 영향을 미치므로, 리전 간 RTT(왕복 지연) 를 측정하고 허용 가능한 수준인지 검증해야 한다. 또한 클러스터 간 인증서 관리, 서비스 디스커버리, 방화벽 정책 등 보안 및 네트워크 구성이 단일 클러스터 대비 훨씬 복잡해진다.
운영 자동화 측면에서는 각 클러스터의 Operator 버전 동기화, 장애 발생 시 페일오버 테스트 주기화(Chaos Engineering), 모니터링 대시보드의 클러스터 간 통합 뷰 확보가 필수적이다. 실제 장애를 경험하기 전에 정기적인 장애 주입 훈련을 통해 자동 복구 경로가 설계대로 동작하는지 반드시 검증해야 한다.
정리
- 단일 Kubernetes 클러스터는 노드/Pod 레벨 장애에는 강하지만, 리전 장애나 컨트롤 플레인 손상에는 자동 복구 경로가 없다.
- 멀티 클러스터 데이터베이스 구성은 재해 복구, 무중단 마이그레이션, 무중단 유지보수를 가능하게 하며 Operator 기반 선언적 관리로 복잡도를 낮출 수 있다.
- 노드 분산 배치만큼 quorum 설계, 레이턴시 검증, 정기적 페일오버 테스트가 운영 안정성의 핵심이다.