MQ + Redis 기반 글로벌 데이터 일관성 구조

요약:
본 기록은 글로벌 서비스 간 데이터 일관성을 확보하기 위해 MQ와 Redis를 결합한 구조를 설계하고 검증한 과정을 기술한다. 각국 서버 간 세션, 캐시, 재고, 주문 데이터의 동기화를 보장하기 위해 TTL, 해시 동기화, 이벤트 브로커를 통합하였고, AI Ops-Agent가 동기화 상태를 실시간 감시하며 자동 복구를 수행한다.

1. 문제 인식 — 다국가 데이터 일관성의 복잡성

8월 초, 홍콩(HK), 서울(KR), 쿠알라룸푸르(MY), 방콕(TH)의 네 개 리전이 동시에 서비스되면서 가장 큰 문제는 데이터 일관성이었다. 각 리전의 Redis 캐시와 MySQL 데이터베이스가 서로 다른 타임스탬프로 업데이트되어, 동일 상품의 재고 수량, 세션, 장바구니 데이터가 불일치하는 현상이 자주 발생했다.

기존 복제(Replication) 방식은 지연이 300~800ms 수준으로 불안정했고, Redis async replication은 트래픽 피크 시 복제 손실이 발생했다. 이 문제는 단순 데이터 복제가 아니라 **이벤트 레벨에서의 보정(Event-level Consistency)** 으로 접근해야 했다.

2. MQ 이벤트 기반 복제 구조 설계

우리는 Redis 복제 대신 MQ 기반의 “Event-driven Sync” 구조로 전환했다. 각 리전의 데이터 변경 이벤트는 LavinMQ를 통해 “data.sync” 토픽으로 발행된다. 이벤트는 Cloud Function 소비자가 수신하여 상대 리전의 Redis에 직접 반영한다.

{
  "event": "data.sync",
  "source": "HK",
  "target": "KR",
  "key": "product:SKU_104311",
  "value": {"stock": 88, "price": 10.95},
  "timestamp": 1723459882310
}

Cloud Function은 이벤트 수신 후 SHA256 해시를 계산해 데이터 위조를 방지한다. 동일 해시가 감지되면 업데이트를 건너뛰어 불필요한 쓰기를 줄였다. 평균 처리 속도는 85ms, 리전 간 지연은 200ms 이내로 유지되었다.

3. Redis 구조 — TTL 및 해시 동기화

Redis는 단순 캐시 용도가 아니라 글로벌 데이터 동기화의 중추 역할을 했다. 주요 테이블(세션, 상품, 주문)은 모두 해시 구조로 저장되었다. 각 항목은 TTL(시간 만료)을 설정하여 오래된 데이터를 자동 정리했다. TTL은 리전별 네트워크 지연을 고려해 10분 ± 30초로 랜덤 오프셋이 적용되었다.

HSET product:SKU_104311 stock 88 price 10.95 updated 1723459882310
EXPIRE product:SKU_104311 600

데이터 불일치가 감지되면 AI Ops-Agent가 즉시 sync.repair 이벤트를 발행한다. 이 이벤트를 받은 Cloud Function은 Redis → MySQL → Redis 간 재동기화를 수행한다.

if redis_hash["updated"] < db_row["updated"]:
    redis.hmset(key, db_row)
    publish("sync.fixed", {"key": key, "source": "DB"})

이 메커니즘을 통해 데이터 동기화 신뢰도는 98.9%까지 향상되었다.

4. 세션 및 인증 데이터 처리

사용자 세션은 지역 간 이동이 빈번하기 때문에 지연에 특히 민감했다. 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이 해당 세션만 재발행한다. 인위적 리셋 없이 자가 복구가 가능한 구조를 완성했다.

5. 큐 병목과 메시지 순서 보장 문제

8월 18일, MQ 처리량이 초당 4,000건을 초과하면서 메시지 순서가 역전되는 현상이 발견되었다. 예를 들어 재고 감소 이벤트보다 재고 갱신 이벤트가 먼저 처리되는 문제였다. LavinMQ의 메시지 타임스탬프가 서버 간 drift(시간 불일치)를 일으킨 것이 원인이었다.

해결책으로 각 이벤트에 sequence 번호를 추가하고, 수신 측에서 시퀀스 검증 후 재정렬하도록 했다. 메시지가 순서대로 정렬될 때까지 최대 3초간 대기 큐에서 보류된다.

{
  "event": "stock.update",
  "sku": "104311",
  "seq": 203,
  "ts": 1723459882
}

이 조정으로 순서 역전 문제는 0.3% 이하로 감소했고, 전체 큐 처리 효율은 약 18% 향상되었다.

6. 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 타임아웃으로 분류되었다. AI는 이 데이터를 학습해 특정 리전에서 반복되는 패턴을 인식하고, 사전 예측 경고를 발송한다.

7. 지연 및 손실 대응을 위한 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%로 감소했다. 사용자 입장에서는 다국가 이동 간 로그아웃 현상이 거의 사라졌다.

8. 통합 모니터링 및 리포팅

모든 이벤트와 동기화 상태는 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의 재동기화 루프가 대부분의 문제를 자율적으로 해결한다. AI는 단순 모니터링 도구가 아니라 “복구 가능한 운영 주체”로 자리잡았다.

9. 결과 및 현재 상태

MQ + Redis 기반 글로벌 동기화 구조는 실시간 운영에 투입된 이후 완전히 안정화되었다. 각 리전 간 데이터 일관성은 99% 이상 유지되며, 세션·상품·주문 데이터가 1초 이내에 모든 리전에 반영된다.

주요 지표:

데이터 일관성 99.2%
평균 동기화 지연 210ms
자동 복구 성공률 98.7%
TTL 보정 성공률 99.1%
AI 예측 정확도 93%

이 구조를 기반으로 이후 9월에는 외부 데이터 크롤링, 물류 및 주문 시스템의 실시간 동기화로 확장할 예정이다. AI는 단순한 복구 에이전트를 넘어, 데이터의 “자율 일관성 유지 엔진”으로 진화했다.

Blog of Reindeers

Search This Blog