대륙을 횡단하는 데이터: 글로벌 분산 데이터베이스의 복제 전략과 정합성(Consistency) 엔지니어링

이전 글에서 생각해보면 데이터베이스 관련 내용을 빼고 적은것 같더라구요. 사실 데이터가 제일 중요하죠. 멀티리전을 쓰는 핵심은 데이터 때문입니다. 보강해서 한번 올려볼게요.

 

지난 포스팅에서는 GSLB를 활용하여 네트워크 레벨에서 트래픽을 대륙별로 효율적으로 분산하는 아키텍처를 살펴보았습니다. 하지만 트래픽을 나누는 것은 첫 단추일 뿐입니다. 인프라 엔지니어가 마주하는 진짜 도전은 "물리적으로 수천 킬로미터 떨어진 데이터베이스 간에 어떻게 데이터 정합성을 유지할 것인가?"라는 질문으로 귀결됩니다.

빛의 속도는 광케이블 내에서 약 200,000km/s로 제한적입니다. 서울 리전과 미국 버지니아 리전 사이의 왕복 지연 시간(RTT)은 물리적 거리에 의해 약 180ms 이상이 필연적으로 발생합니다. 이러한 물리적 제약 조건 아래에서 비즈니스가 요구하는 데이터 무결성을 어떻게 보장할 수 있을까요? 이번 글에서는 글로벌 데이터베이스 복제 전략의 아키텍처 패턴과 기술적 트레이드오프를 심층 분석합니다.

---

핵심 난제: CAP 이론과 물리적 한계의 충돌

CAP 그림

분산 시스템의 근간을 이루는 CAP 이론에 따르면, 네트워크 분단(Partition Tolerance, P)이 발생할 수 있는 글로벌 환경에서 일관성(Consistency, C)과 가용성(Availability, A)을 동시에 완벽하게 만족하는 것은 불가능합니다.

동기식 복제 (Synchronous Replication)의 한계와 성능 저하

동기식 복제는 서울 리전의 Primary(Master) DB에 데이터가 쓰일 때, 버지니아 리전의 Secondary(Slave) DB에도 기록이 완료되었음을 보장하는 방식입니다.

• 메커니즘: 클라이언트의 트랜잭션 커밋 요청이 들어오면, Primary DB는 원격지 리전의 DB로부터 완료 응답(ACK)을 받을 때까지 클라이언트에게 응답을 보내지 않고 대기합니다.
• 치명적 단점: 글로벌 환경에서는 매 쓰기 작업마다 최소 200ms 이상의 물리적 지연이 발생합니다. 초당 수천 건의 트랜잭션을 처리해야 하는 고성능 서비스에서 이는 수용 불가능한 성능 저하(Performance Degradation)를 의미합니다. 따라서 대륙 간 복제에서 순수 동기식 방식은 사실상 불가능에 가깝습니다.

비동기식 복제 (Asynchronous Replication)와 최종 일관성

마스터 DB가 로컬에 데이터를 기록한 직후 즉시 클라이언트에게 응답하고, 복제는 백그라운드 프로세스에서 수행되는 방식입니다.

• 장점: 네트워크 지연 시간이 쓰기 성능에 영향을 주지 않으므로 매우 빠른 응답이 가능합니다.
• 데이터 유실 위험: Primary 리전에서 장애가 발생하여 페일오버가 일어날 때, 아직 복제되지 못한 데이터는 영구적으로 유실될 위험이 있습니다(RPO > 0).
• 복제 지연(Replication Lag): 리전 간 데이터 불일치 구간이 존재하므로, 사용자가 방금 수정한 내용을 다른 리전에서 조회했을 때 이전 데이터가 나타나는 현상이 발생할 수 있습니다.

---

장애 복구 시간의 수학적 모델링

GSLB 기반의 페일오버 상황에서 서비스가 완전히 정상화되기까지 걸리는 총 시간은 단순히 서버가 켜지는 시간이 아닙니다. 아래와 같은 수학적 모델링을 통해 총 소요 시간을 예측할 수 있습니다.

$$T_{total} = T_{detection} + T_{propagation} + T_{client\_cache}$$

• T_detection: GSLB 모니터링 노드가 특정 리전의 장애를 감지하는 시간입니다. 보통 Monitoring Interval \times Failure Threshold 값으로 계산됩니다.
• T_propagation: 변경된 DNS 레코드가 전 세계의 Local DNS(LDNS)로 전파되는 시간입니다. 이론적으로는 설정된 TTL(Time To Live) 값에 수렴합니다.
• T_client_cache: 브라우저나 애플리케이션 내부적으로 유지하는 자체 DNS 캐시 시간입니다. 운영자가 가장 통제하기 어려운 변수 중 하나입니다.

---

실무적인 글로벌 DB 아키텍처 패턴

엔지니어는 비즈니스 성격에 따라 최적의 트레이드오프를 선택해야 합니다.

패턴 A: Read Replicas 기반의 최종 일관성 (Eventual Consistency)

가장 일반적이고 비용 효율적인 패턴입니다.

• 동작 방식: 하나의 Primary 리전(예: 서울)에서 모든 '쓰기'를 담당하고, 전 세계 리전(예: 버지니아, 런던)에 Read Replica를 두어 비동기 복제합니다. 모든 쓰기 요청은 GSLB를 통해 서울로 모이고, 읽기 요청은 사용자 기기와 가장 가까운 리전에서 처리됩니다.
• 적합한 사례: SNS 피드 업데이트, 상품 목록 조회 등 약간의 데이터 지연이 비즈니스 치명적이지 않은 경우.
• 운영 이슈: 복제 지연(Replica Lag) 모니터링이 핵심입니다. 지연이 임계치(예: 1~2초)를 넘을 경우, 앱 레벨에서 강제로 Primary 리전에서 데이터를 읽게 하거나 사용자에게 점검 메시지를 노출하는 서킷 브레이커 전략이 병행되어야 합니다.

패턴 B: 다중 마스터 (Multi-Master) 활성-활성 아키텍처

모든 리전이 읽기와 쓰기를 동시에 처리하는 구조로, 가용성을 극대화합니다.

• 핵심 난제 - 충돌 해결(Conflict Resolution): 동일한 데이터에 대해 서로 다른 리전에서 동시 수정이 발생했을 때 이를 어떻게 병합할 것인가가 관건입니다.
  • Last Write Wins (LWW): 타임스탬프가 가장 늦은 데이터를 최종값으로 채택합니다. 단순하지만 중간 과정의 데이터 유실이 발생할 수 있습니다.
  • CRDTs (Conflict-free Replicated Data Types): 데이터 타입 자체에 논리적인 병합 로직을 내장하여 충돌 없이 복제되도록 설계합니다.
• 적합한 사례: 리전 간 데이터 공유가 거의 없는 독립적인 작업 단위가 있는 글로벌 서비스.

패턴 C: NewSQL 기반의 글로벌 분산 데이터베이스

최근의 클라우드 네이티브 환경에서는 인프라 계층의 혁신으로 이 문제를 해결하고 있습니다.

• 스토리지 계층 복제 (Physical Replication): AWS Aurora Global DB와 같이 SQL 엔진이 아닌 스토리지 볼륨의 물리적 변경 블록(Redo Log)만 전송하여 복제 지연을 수백 밀리초 단위로 획기적으로 낮춥니다.
• 글로벌 합의 알고리즘: Google Spanner는 TrueTime API(GPS 및 원자시계 활용)를 통해 전 세계 리전 간의 시간을 동기화하고, Paxos/Raft 변형 알고리즘을 사용하여 분산 환경에서도 강력한 일관성을 제공합니다.

---

운영 및 트러블슈팅 전략: RPO와 RTO의 최적화

글로벌 서비스를 운영하는 엔지니어는 장애 상황에서 다음 두 가지 지표를 관리해야 합니다.

1. 복제 지연 급증 대응: 대량의 배치 작업이 수행될 때 네트워크 대역폭 부족으로 지연이 발생할 수 있습니다. Datadog이나 CloudWatch를 통해 ReplicationLag 메트릭을 감시하고, 임계치 초과 시 자동으로 트래픽을 제어하는 로직이 필요합니다.
2. 리전 페일오버와 승격(Promotion): Primary 리전 다운 시, 데이터 정합성이 가장 높은(지연이 가장 적은) Replica 리전을 새 Primary로 승격시켜야 합니다. 이 과정에서 Split-brain(두 리전이 서로 마스터라고 주장하는 상태)을 막기 위한 정교한 펜싱(Fencing) 기술이 동반되어야 합니다.

---

현실적인 트레이드오프의 예술

글로벌 분산 시스템에서 '완벽한 정합성'과 '제로에 가까운 지연 시간'을 동시에 얻을 수 있는 마법은 존재하지 않습니다. 엔지니어의 역할은 물리적 한계를 인정하고, 비즈니스 요건에 맞춰 RPO(목표 복구 시점)와 RTO(목표 복구 시간)를 정의하는 것입니다.

때로는 '최종 일관성'이라는 기술적 부채를 수용함으로써 압도적인 성능을 얻고, 때로는 'NewSQL'과 같은 고비용 솔루션을 통해 데이터 무결성을 지켜내야 합니다. 기술적 환상보다는 실질적인 아키텍처 패턴을 통해 서비스의 안정성을 확보하는 것이 진정한 엔지니어링의 정수입니다.

 

근데 사실 B2B 나 B2C 같은 경우 보면 다 감정적인 영역이에요. RPO, RTO 딱딱 정해서 하면 책임소재를 딱딱 나누니 좋죠. 그런데 이 말 한마디. 이런게 더 중요하다고 봅니다. 사실 데이터는 감정이 없지만 그 데이터를 다루는 사람은 감정이 있잖아요. 데이터가 날아갔다고 책임소재만 딱딱 나누면 한국 정서에는 안맞죠. 외국 정서에는 맞겠지만요?

---

참고 자료:

• Werner Vogels (Amazon CTO): "Eventually Consistent"
• Google Spanner Whitepaper: Spanner: Google’s Globally-Distributed Database
• Martin Kleppmann: "Designing Data-Intensive Applications"