MQ + Redis 기반 글로벌 데이터 일관성 구조
1. 문제 인식 — 다국가 데이터 일관성의 복잡성
8월 초, 홍콩(HK), 서울(KR), 쿠알라룸푸르(MY), 방콕(TH)의 네 개 리전이 동시에 서비스되면서 가장 큰 문제는 데이터 일관성이었다. 각 리전의 Redis 캐시와 MySQL 데이터베이스가 서로 다른 타임스탬프로 업데이트되어, 동일 상품의 재고 수량, 세션, 장바구니 데이터가 불일치하는 현상이 자주 발생했다.
기존 복제(Replication) 방식은 지연이 300~800ms 수준으로 불안정했고, Redis async replication은 트래픽 피크 시 복제 손실이 발생했다. 이 문제는 단순 데이터 복제가 아니라 이벤트 레벨에서의 보정(Event-level Consistency)으로 접근해야 했다.
특히 B2B 무역 플랫폼에서는 재고 데이터의 불일치가 실제 주문 오류로 직결된다. 한 리전에서 재고가 0인 상품이 다른 리전에서는 재고가 있는 것으로 표시되면, 주문이 접수된 후 취소되는 상황이 발생한다. 이는 공급사와 바이어 양쪽 모두에게 신뢰 문제를 만든다. 따라서 데이터 일관성은 단순 기술 과제가 아니라 비즈니스 신뢰도의 문제였다.
2. MQ 토폴로지 설계 — Topic Exchange와 Routing Key
우리는 Redis 복제 대신 MQ 기반의 "Event-driven Sync" 구조로 전환했다.
LavinMQ의 Topic Exchange를 사용하여 이벤트를 라우팅한다.
각 리전의 데이터 변경 이벤트는 data.sync 토픽으로 발행되며,
routing key는 data.sync.{source_region}.{data_type} 형식을 따른다.
# Routing key examples
data.sync.HK.product -> 홍콩발 상품 데이터 변경
data.sync.KR.session -> 한국발 세션 데이터 변경
data.sync.TH.order -> 태국발 주문 데이터 변경
data.sync.MY.inventory -> 말레이시아발 재고 데이터 변경
각 리전의 소비자(Consumer)는 자신의 리전을 제외한 나머지 리전의 이벤트만 구독한다.
예를 들어 한국 리전의 소비자는 data.sync.HK.*, data.sync.TH.*, data.sync.MY.*를 구독하지만
data.sync.KR.*는 구독하지 않는다. 자기 자신의 이벤트를 다시 소비하는 루프를 방지하기 위해서다.
{
"event": "data.sync",
"routing_key": "data.sync.HK.product",
"source": "HK",
"target": ["KR", "TH", "MY"],
"key": "product:SKU_104311",
"value": {"stock": 88, "price": 10.95},
"timestamp": 1723459882310
}Cloud Function은 이벤트 수신 후 SHA256 해시를 계산해 데이터 위조를 방지한다. 동일 해시가 감지되면 업데이트를 건너뛰어 불필요한 쓰기를 줄였다. 평균 처리 속도는 85ms, 리전 간 지연은 200ms 이내로 유지되었다.
3. Redis Cache-Aside 패턴과 해시 동기화
Redis는 단순 캐시 용도가 아니라 글로벌 데이터 동기화의 중추 역할을 했다. Cache-Aside 패턴을 적용하여 읽기 시 Redis를 먼저 조회하고, 캐시 미스가 발생하면 MySQL에서 조회한 후 Redis에 적재하는 방식이다. 쓰기 시에는 MySQL을 먼저 업데이트하고, 성공 후 Redis를 갱신한다.
주요 테이블(세션, 상품, 주문)은 모두 해시 구조로 저장되었다. 각 항목은 TTL(시간 만료)을 설정하여 오래된 데이터를 자동 정리했다. TTL은 리전별 네트워크 지연을 고려해 10분 +/- 30초로 랜덤 오프셋이 적용되었다. 이 랜덤 오프셋은 여러 키의 TTL이 동시에 만료되면서 발생하는 Cache Stampede를 방지하기 위한 것이다.
HSET product:SKU_104311 stock 88 price 10.95 updated 1723459882310
EXPIRE product:SKU_104311 600
# Cache-Aside read pattern
def get_product(sku):
cached = redis.hgetall(f"product:{sku}")
if cached:
return cached
row = db.query("SELECT * FROM products WHERE sku = %s", sku)
redis.hmset(f"product:{sku}", row)
redis.expire(f"product:{sku}", 600 + random.randint(-30, 30))
return row
데이터 불일치가 감지되면 AI Ops-Agent가 즉시 sync.repair 이벤트를 발행한다.
이 이벤트를 받은 Cloud Function은 Redis와 MySQL 간 재동기화를 수행한다.
if redis_hash["updated"] < db_row["updated"]:
redis.hmset(key, db_row)
publish("sync.fixed", {"key": key, "source": "DB"})이 메커니즘을 통해 데이터 동기화 신뢰도는 98.9%까지 향상되었다.
4. 이벤트 순서 보장과 Idempotency 처리
8월 18일, MQ 처리량이 초당 4,000건을 초과하면서 메시지 순서가 역전되는 현상이 발견되었다. 예를 들어 재고 감소 이벤트보다 재고 갱신 이벤트가 먼저 처리되는 문제였다. LavinMQ의 메시지 타임스탬프가 서버 간 drift(시간 불일치)를 일으킨 것이 원인이었다.
해결책으로 각 이벤트에 sequence 번호를 추가하고, 수신 측에서 시퀀스 검증 후 재정렬하도록 했다. 메시지가 순서대로 정렬될 때까지 최대 3초간 대기 큐에서 보류된다.
{
"event": "stock.update",
"sku": "104311",
"seq": 203,
"idempotency_key": "stock_104311_203",
"ts": 1723459882
}Idempotency 처리도 함께 도입되었다. 각 이벤트는 고유한 idempotency_key를 가지며, 수신 측에서는 이 키를 Redis에 저장하여 동일 이벤트의 재처리를 방지한다. 키의 TTL은 24시간으로 설정되어, 같은 날 내에 동일 이벤트가 중복 소비되는 것을 차단한다.
def process_event(event):
idem_key = event["idempotency_key"]
if redis.exists(f"idem:{idem_key}"):
return # already processed
redis.set(f"idem:{idem_key}", 1, ex=86400)
handle(event)이 조정으로 순서 역전 문제는 0.3% 이하로 감소했고, 전체 큐 처리 효율은 약 18% 향상되었다.
5. Eventual Consistency와 트레이드오프
REINDEERS의 글로벌 동기화 구조는 Strong Consistency가 아닌 Eventual Consistency를 선택했다. 4개 리전 간 네트워크 지연이 존재하는 상황에서 모든 쓰기를 동기적으로 처리하면 응답 시간이 허용 범위를 초과하기 때문이다.
대신 "일관성 보장 시간(Consistency Window)"이라는 개념을 도입했다. 데이터 변경 후 최대 1초 이내에 모든 리전에 반영되는 것을 목표로 하되, 이 시간 내에 반영되지 않으면 자동 복구 이벤트가 발행된다. 실제 측정 결과 95% 이상의 이벤트가 500ms 이내에 전파되었다.
이 트레이드오프를 수용한 이유는 B2B 거래의 특성상 밀리초 단위의 일관성보다 시스템 가용성과 전체 처리 속도가 더 중요했기 때문이다. 재고가 0이 되는 순간의 경쟁 조건(race condition)은 주문 단계에서 별도의 DB 레벨 검증으로 최종 확인된다.
6. 세션 및 인증 데이터 처리
사용자 세션은 지역 간 이동이 빈번하기 때문에 지연에 특히 민감했다. Access Token과 Refresh Token은 Redis에 해시 형태로 저장되어, 각 리전에서 로컬 캐시처럼 접근할 수 있도록 설계되었다. AI Ops-Agent는 세션 복제 성공률을 1분 간격으로 측정하고 보고했다.
*Session Replication Report*
HK->KR: 99.4% success (avg delay 210ms)
KR->TH: 98.7% success (avg delay 260ms)
KR->MY: 99.1% success (avg delay 230ms)문제 발생 시 Redis의 만료시간을 조정하거나, Cloud Function이 해당 세션만 재발행한다. 인위적 리셋 없이 자가 복구가 가능한 구조를 완성했다.
7. 크로스 리전 이벤트 전파 지연 관리
리전 간 물리적 거리에 따라 이벤트 전파 지연은 불가피하다. 홍콩에서 방콕까지는 약 180ms, 홍콩에서 서울까지는 약 210ms, 서울에서 쿠알라룸푸르까지는 약 250ms 수준의 네트워크 지연이 존재한다.
이 지연을 관리하기 위해 각 이벤트에 "expected_delivery_time" 필드를 추가했다.
소비자는 이 시간 내에 이벤트가 도착하지 않으면 소스 리전에 재전송을 요청한다.
재전송 요청은 sync.request_resend 이벤트로 처리되며,
소스 리전은 해당 키의 최신 값을 다시 발행한다.
이 방식은 네트워크 장애로 이벤트가 유실된 경우에도 데이터 일관성을 복원할 수 있게 해준다. 일일 평균 재전송 요청은 전체 이벤트의 0.08% 수준이다.
8. AI Ops-Agent의 자동 복구 루프
동기화 구조의 안정성은 AI Ops-Agent의 자율 제어에 달려 있었다. 이 에이전트는 매 10분마다 Redis 키의 샘플링 검사를 수행한다. 값이 누락되거나 해시 필드가 다를 경우, 자동으로 복구 이벤트를 발행한다.
def audit_consistency():
for key in redis.scan_iter("product:*"):
hk_val = redis_hk.hgetall(key)
kr_val = redis_kr.hgetall(key)
if hk_val != kr_val:
publish("sync.repair", {"key": key})복구 성공률은 96~99% 범위에서 안정적으로 유지되었다. 실패 케이스는 대부분 네트워크 지연이나 MQ 타임아웃으로 분류되었다.
9. TTL 보정 로직과 세션 보호
리전 간 네트워크 상태가 불안정할 때 TTL이 먼저 만료되면 세션이 조기에 삭제된다. 이를 방지하기 위해 Redis 키의 TTL을 자동으로 갱신하는 보정 로직을 추가했다. AI Ops-Agent가 TTL이 60초 이하인 키를 탐지하면 즉시 연장한다.
if redis.ttl(key) < 60:
redis.expire(key, 600)
publish("ttl.extended", {"key": key})이 로직 덕분에 세션 만료로 인한 로그아웃 비율은 3.1%에서 0.4%로 감소했다. 사용자 입장에서는 다국가 이동 간 로그아웃 현상이 거의 사라졌다.
10. 통합 모니터링 및 리포팅
모든 이벤트와 동기화 상태는 Telegram 기반 대시보드로 시각화되었다. Ops-Agent는 각 리전의 지연, 오류, 복구율을 요약해 자동 보고했다.
*Sync Health Report*
Region: HK <-> KR <-> TH <-> MY
Events: 1,200,432 / 24h
Consistency: 99.3%
Latency(avg): 210ms
Repairs: 112관리자 개입은 거의 없으며, Ops-Agent의 재동기화 루프가 대부분의 문제를 자율적으로 해결한다.
11. 결과 및 현재 상태
MQ + Redis 기반 글로벌 동기화 구조는 실시간 운영에 투입된 이후 완전히 안정화되었다. 각 리전 간 데이터 일관성은 99% 이상 유지되며, 세션, 상품, 주문 데이터가 1초 이내에 모든 리전에 반영된다.
주요 지표:
- 데이터 일관성 99.2%
- 평균 동기화 지연 210ms
- 자동 복구 성공률 98.7%
- TTL 보정 성공률 99.1%
- Idempotency 중복 차단율 99.97%
- 이벤트 순서 보장 정확도 99.7%
이 구조를 기반으로 이후 9월에는 외부 데이터 크롤링, 물류 및 주문 시스템의 실시간 동기화로 확장할 예정이다. MQ의 Topic Exchange와 Redis의 Cache-Aside 패턴, 그리고 Idempotency 키 기반의 중복 방지가 결합되면서 분산 환경에서도 안정적인 데이터 일관성을 유지하는 구조가 완성되었다.