다중 리전 배포 시 데이터 정합성 이슈와 그 해결법
1. 문제 상황: 글로벌 사용자 대응을 위한 다중 리전 배포
서비스 확장에 따라 북미, 유럽, 아시아 사용자에게 빠른 응답 속도를 제공하기 위해 다중 리전 배포를 진행하게 되었다. AWS의 Route 53과 Global Accelerator를 사용해 사용자 요청을 지리적으로 가까운 리전으로 분산 처리했다.
그러나 예상치 못한 문제가 발생했다. 여러 리전에서 동일한 데이터를 읽고 쓸 때 데이터 정합성 문제가 나타났고, 사용자 경험에도 직접적인 영향을 주기 시작했다.
- 주문 처리 중복 발생
- 댓글 작성 후 바로 보이지 않는 현상
- 로그인 상태가 리전마다 불일치
초기에는 단순한 캐싱 문제로 생각했으나, 근본 원인은 동기화 지연과 마스터-슬레이브 구조의 한계에 있었다.
2. 원인 분석: 정합성 문제가 발생한 이유
2.1 데이터베이스 구조의 한계
RDS의 리드 리플리카를 각 리전에 배포하고, 마스터는 싱가포르 리전에 단일하게 구성되어 있었다. 각 리전에서 읽기는 가능했지만, 쓰기 요청은 모두 싱가포르로 향하면서 다음 문제가 발생했다.
- 쓰기 지연으로 인해 사용자 체감 속도 저하
- 읽기 리전과 쓰기 리전 간 동기화 지연 발생
- 최신 데이터가 리플리카에 반영되기까지 최대 수 초 지연
2.2 클라이언트 세션 상태 동기화 실패
세션 정보를 Redis에 저장하고 있었는데, Redis 역시 리전별로 독립 구성되어 있어 사용자 로그인 상태가 리전마다 달라지는 현상이 발생했다. 특히 로드 밸런서가 리전을 변경할 때, 로그아웃된 것으로 인식되는 문제가 두드러졌다.
3. 해결 과정: 정합성을 유지하면서 다중 리전 구성하기
3.1 Global Database 아키텍처 도입
RDS Aurora의 Global Database를 도입했다. 이를 통해 싱가포르를 마스터로 유지하되, 각 리전에 Read Replica를 분산 배치하고, 복제 지연을 1초 이하로 유지할 수 있었다.
단, 쓰기 요청은 여전히 싱가포르에서만 가능하므로, 쓰기 빈도가 낮고 읽기 중심의 서비스 구조에서만 적합했다.
3.2 쓰기 요청 리디렉션 처리
모든 쓰기 요청은 Route 53의 지리적 라우팅을 통해 싱가포르로 강제 리디렉션 처리했다. API Gateway에서 리전별 엔드포인트를 유지하면서, 쓰기 요청은 api.sg.example.com 으로 전송되도록 구성했다.
이를 통해 사용자 단말은 항상 동일한 엔드포인트를 사용하되, 내부적으로는 요청이 리디렉션되도록 처리했다.
3.3 Redis 클러스터 글로벌 동기화
세션 데이터는 Redis 대신 Amazon ElastiCache Global Datastore를 도입하여 글로벌 환경에서 세션 동기화를 실시간에 가깝게 유지했다.
또한 세션 유지를 위해 클라이언트에 JWT 토큰 기반 인증을 병행 적용하여, 완전한 무상태(stateless) 인증 구조로 점차 전환해 나갔다.
3.4 CloudFront 캐시 TTL 조정
정적 컨텐츠에 한해 CloudFront를 통한 캐시를 활용하면서도, API 응답에 대해서는 TTL을 0으로 설정하여 데이터 정합성이 보장되도록 조정했다.
Cache-Control: no-cache, no-store, must-revalidate
캐싱을 통한 성능 향상과 데이터 최신성 간의 균형을 유지하는 것이 핵심이었다.
4. 결과 및 교훈
이러한 구조 개선을 통해 데이터 정합성 문제는 대부분 해결되었으며, 글로벌 사용자 환경에서도 안정적인 응답성과 일관된 사용자 경험을 제공할 수 있었다.
핵심 정리
- 다중 리전 구성 시 데이터베이스의 동기화 전략은 사전에 설계 필요
- 쓰기 중심 서비스는 단일 리전, 읽기 중심은 다중 리전 전략이 유효
- 세션 공유는 Redis Global Datastore 또는 무상태 인증으로 해결 가능
- API 응답 캐시는 데이터 최신성을 침해하지 않도록 TTL을 신중히 조정
다중 리전 배포는 기술적으로 매력적이지만, 실제로는 다양한 제약과 고려사항이 따른다. 정합성 문제를 사전에 예측하고 구조적으로 해결할 수 있어야 진정한 글로벌 서비스를 제공할 수 있다.