글로벌 세션 동기화와 캐시 아키텍처 설계

1. 문제 정의 — 글로벌 세션의 일관성

글로벌 사용자가 늘어나면서 문제가 발생했다. 한 사용자가 홍콩 리전에서 로그인한 뒤 곧바로 한국 리전 서비스로 접근하면, 세션이 존재하지 않아 재로그인이 필요했다. Redis가 지역 단위로 분리되어 있었기 때문이다.

이 문제는 단순한 불편을 넘어 비즈니스 리스크였다. 태국 바이어가 주문을 작성하던 중 API Gateway가 서울 리전으로 라우팅되면 세션이 없어 작성 중이던 데이터가 유실될 수 있다. REINDEERS는 "어디서 로그인하든, 어디서든 세션이 유효해야 한다"는 원칙을 세웠다. 이를 위해 Redis 세션 클러스터 간 실시간 복제와, MQ 기반의 캐시 무효화 구조를 설계했다.

2. 전체 구조 개요

세션·캐시 구조는 다음 세 가지 계층으로 나뉜다.

Redis Cluster: 리전별 세션/캐시 저장소 (HK Primary, KR Secondary)
MQ Broker (LavinMQ): Redis 간 동기화 이벤트 전달
Cloud Function: 세션 복제 및 캐시 무효화 실행

[User Login] → [Redis HK] → MQ("session.create")
                                    ↓
                            [Cloud Function]
                                    ↓
                            [Redis KR Replica]

모든 세션·캐시 변경은 "이벤트"로 MQ에 게시되고, Cloud Function이 이를 수신해 반대 리전에 적용한다. 이 아키텍처의 핵심은 Redis 간의 직접 복제가 아니라 MQ 이벤트를 매개로 한 간접 동기화라는 점이다. 직접 복제는 네트워크 장애 시 데이터 손실 위험이 있지만, MQ를 경유하면 메시지가 큐에 보존되어 장애 복구 후 자동으로 처리된다.

3. Redis 세션 구조와 TTL 전략

세션은 JWT/PASETO에서 파생된 최소 정보를 Redis에 저장한다. 토큰 자체에 이미 사용자 ID와 역할 정보가 포함되어 있지만, Redis 세션은 "서버 측에서 세션을 강제 무효화"할 수 있는 제어점 역할을 한다. 만료 시각은 Access Token 기준 30분으로 설정된다.

SESSION:{uid} → {
  "uid": "U12345",
  "ip": "203.113.22.15",
  "device": "Chrome/Mac",
  "exp": 1719134045,
  "scope": ["buyer","logistics","report"],
  "region": "hk"
}
TTL: 1800s (30분)

TTL 전략은 데이터 유형에 따라 차등 적용된다.

세션 데이터: TTL 1800초(30분). Access Token 만료와 동일.
i18n 캐시 (APPROVED): TTL 없음. 영구 캐싱. 변경 시 MQ 이벤트로 무효화.
i18n 캐시 (MACHINE): TTL 900초(15분). 자동 갱신 가능성이 높으므로 짧게 설정.
환율 데이터: TTL 3600초(1시간). 하루 1회 갱신되므로 충분한 유효 시간.
상품 목록 캐시: TTL 300초(5분). 재고 변동이 잦은 데이터.

4. MQ 기반 세션 복제

LavinMQ는 REINDEERS의 메시지 브로커로 사용된다. 세션 변경, 캐시 무효화, 언어 번역 이벤트 등은 모두 동일한 MQ를 공유하되, 토픽 기반 라우팅으로 분리된다. 세션 복제는 Cloud Function sessionSync()에서 수행된다.

import redis, pika, json

def sessionSync():
    mq = pika.BlockingConnection(pika.ConnectionParameters("mq.hk")).channel()
    mq.queue_declare(queue="session_sync", durable=True)

    def on_message(ch, method, props, body):
        event = json.loads(body)
        target = redis.StrictRedis(host="redis.kr", port=6379)
        key = f"SESSION:{event['uid']}"
        if event.get("action") == "destroy":
            target.delete(key)
        else:
            target.set(key, json.dumps(event), ex=1800)
        ch.basic_ack(method.delivery_tag)

    mq.basic_consume(queue="session_sync", on_message_callback=on_message)
    mq.start_consuming()

로그인, 로그아웃, 토큰 갱신, 강제 세션 종료 등 모든 세션 이벤트가 MQ를 통해 반대 리전으로 전달된다. 평균 동기화 지연은 200~250ms로 유지된다. 이 지연은 사용자가 체감하기 어려운 수준이며, 리전 전환 시에도 로그인 상태가 끊김 없이 유지된다.

5. 캐시 무효화(Event-driven Cache Invalidation)

REINDEERS의 모든 캐시는 Write-through 방식이다. 데이터베이스에 변경이 발생하면 MQ에 cache.invalidate 이벤트가 발행되고, Cloud Function이 이를 구독하여 양쪽 리전의 Redis에서 관련 키를 삭제한다.

def cacheInvalidator():
    mq = pika.BlockingConnection(pika.ConnectionParameters("mq.hk")).channel()
    mq.queue_declare(queue="cache_invalidate", durable=True)
    r_hk = redis.StrictRedis(host="redis.hk")
    r_kr = redis.StrictRedis(host="redis.kr")

    def on_message(ch, method, props, body):
        event = json.loads(body)
        key = f"{event['table']}:{event['id']}"
        r_hk.delete(key)
        r_kr.delete(key)
        ch.basic_ack(method.delivery_tag)

    mq.basic_consume(queue="cache_invalidate", on_message_callback=on_message)
    mq.start_consuming()

이 방식으로 모든 캐시는 데이터베이스 중심으로 자동 갱신된다. Redis 간 TTL 차이는 약 1초 이내로 유지된다.

6. 캐시 워밍(Cache Warming) 전략

캐시 무효화만으로는 충분하지 않다. 서비스가 재시작되거나 Redis가 flush된 후 첫 요청들이 모두 DB로 몰리면 이른바 "캐시 스탬피드(Cache Stampede)" 현상이 발생한다. 동시에 수백 개의 동일한 쿼리가 DB에 도달하여 과부하를 유발한다.

이를 방지하기 위해 REINDEERS는 캐시 워밍 전략을 적용했다. 서비스 배포 직후 Cloud Function이 자동으로 실행되어 핫 데이터(최근 24시간 내 조회된 상품, 활성 세션, 최신 환율)를 미리 캐시에 적재한다. 워밍 대상은 조회 빈도 기반으로 자동 선정되며, 상위 5,000건의 데이터가 배포 후 60초 이내에 캐시에 적재된다.

def cache_warming():
    hot_keys = db.query("""
        SELECT table_name, record_id FROM access_log
        WHERE accessed_at > DATE_SUB(NOW(), INTERVAL 24 HOUR)
        GROUP BY table_name, record_id
        ORDER BY COUNT(*) DESC LIMIT 5000
    """)
    for row in hot_keys:
        data = db.fetch(row.table_name, row.record_id)
        r_hk.set(f"{row.table_name}:{row.record_id}", json.dumps(data), ex=900)
        r_kr.set(f"{row.table_name}:{row.record_id}", json.dumps(data), ex=900)

7. Cross-Region 캐시 미스 처리

KR 리전에서 캐시 미스가 발생하면 어떻게 되는가? 일반적인 구조에서는 DB로 직접 쿼리를 보낸다. 그러나 KR 리전의 DB는 Secondary(읽기 전용)이고, 복제 지연으로 인해 최신 데이터가 아직 도착하지 않았을 수 있다.

REINDEERS는 이 시나리오를 위해 "Cross-Region Fallback" 경로를 설계했다. KR Redis 미스 → KR DB 조회 → 데이터 없음 시 HK Redis 조회 → HK DB 조회 순서로 진행된다. HK에서 데이터를 가져오면 KR Redis에도 캐싱하여 다음 요청부터는 로컬에서 처리된다. 이 전체 과정은 400ms 이내에 완료되도록 타임아웃이 설정되어 있다.

8. Idempotency와 중복 이벤트 방지

MQ 이벤트 발생 빈도는 초당 3천 건 이상일 수 있다. Cloud Function은 자동 확장(Autoscaling) 설정으로 최대 50 인스턴스까지 병렬 처리한다. 이때 동일한 이벤트가 중복 처리되면 캐시가 잘못된 상태로 전환될 수 있다.

{
  "event": "session.update",
  "uid": "U1203",
  "timestamp": 1719134001,
  "idempotency": "3c78f67a-d10a-49a5-91d4-7fbcaaad9322"
}

이벤트 누락을 방지하기 위해 idempotency 키가 모든 메시지에 추가된다. Cloud Function은 처리 전 해당 키가 Redis에 존재하는지 확인하여 중복 실행을 방지한다. 처리가 완료되면 idempotency 키를 Redis에 5분간 저장한다. 이 TTL은 MQ의 최대 재전송 간격보다 길게 설정하여 재전송된 메시지도 필터링한다.

9. Telegram 운영 통합

모든 세션 복제와 캐시 이벤트는 Telegram을 통해 모니터링된다. Cloud Function은 일정 주기로 통계 요약을 전송한다.

def notify_stats(stats):
    text = (
      f"*Session Sync Report*\n"
      f"Total: {stats['count']} | Delay avg: {stats['delay_ms']}ms\n"
      f"Cache Hit Rate: {stats['hit_rate']}%\n"
      f"Cross-Region Fallback: {stats['fallback_count']}건\n"
      f"Last Event: {stats['last_uid']}"
    )
    requests.post(
        f"https://api.telegram.org/bot{os.getenv('TELEGRAM_TOKEN')}/sendMessage",
        json={"chat_id": os.getenv("TELEGRAM_CHAT_ID"),
              "text": text, "parse_mode": "Markdown"})

Telegram 명령 /sessionstat을 실행하면 현재 세션 복제율, 평균 지연 시간, 캐시 적중률이 텍스트로 반환된다. 복제 지연이 500ms를 초과하면 자동으로 알림이 발생한다.

10. 기술적 결과

세션 복제 지연: 평균 0.22초
캐시 무효화 지연: 평균 0.18초
캐시 적중률: 96% 이상
글로벌 트래픽 대응: 초당 8,000건 MQ 이벤트
Cloud Function 자동 확장: 최대 50 컨테이너
Cross-Region Fallback 평균 응답: 380ms

실제 부하 테스트에서도 10만 명 동시 로그인 상황에서 세션 유효성 검증 실패율은 0.02% 이하로 유지되었다. 캐시 워밍 후 첫 5분간의 DB 부하가 기존 대비 78% 감소했다.

11. 결론 — "동기화가 아닌 실시간 반영"

이 구조는 단순한 데이터 복제가 아니다. 세션과 캐시의 변경을 이벤트로 실시간 전파하고, Cloud Function이 이를 자동으로 반영하는 완전한 이벤트 기반 아키텍처다. 캐시 워밍이 콜드 스타트를 방지하고, Cross-Region Fallback이 복제 지연 상황에서도 데이터 가용성을 보장한다.

이제 REINDEERS의 모든 사용자 세션은 어느 리전에서나 동일한 상태로 유지된다. "한 번 로그인하면 전 세계 어디서든 동일한 세션"이라는 목표를 기술적으로 완성했다.

Blog

Search This Blog