Skip to main content

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

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

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

관련 글

Labels:

Popular posts from this blog

11년의 무역 데이터가 AI를 만든다 , RAG 지식 베이스 구축 과정

AI를 제품에 넣겠다고 하면 대부분 두 가지 중 하나를 떠올린다. GPT를 fine-tuning하거나, RAG를 쓰거나. 우리는 RAG를 택했다. 이유가 있다. REINDEERS는 2015년 IMARKET Thailand 설립 이후 약 11년간 동남아시아에서 B2B 무역을 해왔다. 25,000건 이상의 거래, 4,300개 이상의 파트너, 4개국의 규제 데이터. 이 데이터가 우리의 경쟁력이다. 문제는 이 데이터를 AI가 활용할 수 있는 형태로 만드는 과정이 생각보다 훨씬 복잡했다는 거다. 이 글은 그 과정에 대한 기록이다. 한 가지를 먼저 밝히고 시작한다. 이 RAG 지식 베이스는 단순히 "챗봇이 무역 지식을 참조하는 데이터 창고"가 아니다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 Agent들 , 구매 Agent, 물류 Agent, 통관 Agent, 재무 Agent , 이 사람 대신 판단을 내릴 때 "왜 이렇게 결정했는가"를 반드시 설명할 수 있어야 한다. 그 설명의 출처가 바로 이 RAG 지식 베이스다. 11년의 무역 데이터는 Agent가 환각 없이 결정을 내릴 수 있는 유일한 근거다. RAG를 선택한 이유 먼저 RAG(Retrieval-Augmented Generation)가 뭔지를 간단히 정리하자. LLM에 질문을 던질 때, 질문만 보내는 게 아니라 관련 데이터를 함께 보내는 방식이다. "태국산 베어링 수입 단가가 얼마야?"라고 물으면, 우리 데이터베이스에서 관련 거래 이력을 찾아서 LLM에 컨텍스트로 넘긴다. LLM은 그 컨텍스트를 바탕으로 답을 생성한다. Fine-tuning을 선택하지 않은 이유는 명확하다. 무역 데이터는 계속 바뀐다. 베어링 단가는 분기마다 변동한다. 태국 FDA 규제는 수시로 개정된다. 선사 운임은 매...
Read more

B2B 견적의 AI Agent화 , 고객사·공급사·포워더가 AI로 견적을 주고받는 구조

B2B 거래에서 견적은 단순한 가격표가 아니다. 바이어의 구매 이력, 공급사의 재고 상황, 물류 비용, 인코텀즈, 납기일, 결제 조건 , 이 모든 변수가 얽힌 협상의 산물이다. 현재 이 과정은 이메일과 전화, 스프레드시트로 이루어진다. 바이어가 RFQ를 보내면 공급사가 검토하고, 포워더에게 물류 견적을 받아 합산하고, 다시 바이어에게 회신한다. 건당 수일이 걸리는 이 과정을 AI Agent가 대신할 수 있다면 어떨까. REINDEERS는 이 구조를 설계하고 있다. 먼저 이 글의 전제를 분명히 한다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 조직도 안에서 직원을 등록할 때 '사람', 'AI Agent', '로봇' 중에서 선택할 수 있고, 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 글의 Buyer Agent / Supplier Agent / Forwarder Agent는 외부 AI 도구가 아니라, 각 회사의 조직도 안에 '구매팀 담당자', '영업팀 담당자', '물류팀 담당자'로 실제 등록되는 AI 직원이다. 사람 직원과 동일한 권한 모델, 동일한 예산 한도, 동일한 감사 로그 위에서 일한다. B2B 견적의 AI Agent 간 통신 시퀀스 # Buyer Agent → Supplier Agent → Forwarder Agent 1 RFQ 발송 → RFQ 수신 2 물류 견적 요청 → 요청 수신 3 견적 수신 ← 상품 견적 발송 4 물류 견적 수신 ← 물류 견적 발송 ★ 비교표 생성 → 담당자 승인 5 PO 발행 → 주문 확정 6 부킹 요청 → 부킹 확정 왜 견적에 AI Agent인가 견적 업무가 느린 이유는 복잡해서가 아니다. 반복적인 정보 수집과 조합이 사람의 시간을 잡아먹기 때문이다. 공급사 담당자가 바이어의 과거 주문 이력을 ...
Read more

Reindeers Workflow: B2B 파트너 업무 효율과 자동화를 위한 워크플로우 플랫폼

B2B 국제 무역에서 하나의 거래가 완료되기까지 관여하는 시스템과 사람의 수는 예상보다 훨씬 많다. 견적 요청에서 시작해 공급사 선정, 발주, 포워딩 비딩, 통관 서류 준비, 출하, 배송, 정산까지 — 각 단계마다 서로 다른 담당자가 서로 다른 도구에서 수작업을 반복한다. 이 현장에서 반복적으로 발생하는 비효율은 분명하다. 바이어가 견적을 확정하면 공급사에게 이메일이나 메신저로 직접 통보해야 하고, 결제가 완료되면 수동으로 정산 시트에 옮기면서 1~3일이 소요된다. 출하 후에는 선적 정보를 기반으로 CI, PL, CO를 수동 생성하며 누락이 발생하고, 배송 완료 후 공급사/포워더 정산을 수작업으로 대조하면서 오차가 누적된다. ERP, 이메일, 스프레드시트, CRM에 같은 데이터를 반복 입력하는 것도 일상이다. 이 문제들의 공통점은 명확하다. "이벤트가 발생했을 때 후속 작업이 자동으로 실행되지 않는다" 는 것이다. 견적이 확정되었다는 '사실'은 시스템에 기록되지만, 그 사실이 다음 단계의 업무를 자동으로 트리거하지는 않는다. Reindeers Workflow는 이 문제를 해결하기 위해 만들어졌다. 단순히 "자동화 도구를 제공한다"가 아니라, REINDEERS 플랫폼에서 발생하는 실제 거래 이벤트를 기반으로 후속 업무가 자동 실행되는 구조를 만드는 것이다. REINDEERS 플랫폼과의 연결: 거래 이벤트가 워크플로우를 트리거한다 Reindeers Workflow의 가장 중요한 차별점은 범용 자동화 도구가 아니라 REINDEERS 본 플랫폼의 거래 이벤트에 직접 연결 된다는 것이다. REINDEERS에서 발생하는 핵심 거래 이벤트가 MQ(Message Queue)를 통해 워크플로우의 트리거가 된다. 거래 이벤트 트리거되는 워크플로우 실행 내용 quote.confirmed 공...
Read more