증권사 토큰 캐싱 · single-flight

증권사 토큰 캐싱 · single-flight A workflow diagram generated by Archify. 01 / 요청 02 / 재발급 조정 (Redis) 03 / 발급 (OAuth) 04 / 반환 캐시 확인 조정 발급 · 저장 토큰 요청 · getAccessToken() · 요청 › 캐시 확인 토큰 요청 getAccessToken() 캐시 확인 · TTL 유효? · 요청 › 캐시 확인 캐시 확인 TTL 유효? 재발급 락 · SET NX EX 10s · 재발급 조정 (Redis) › 조정 재발급 락 SET NX EX 10s 대기 폴링 · 100ms × 20회 · 재발급 조정 (Redis) › 조정 대기 폴링 100ms × 20회 토큰 발급 · client_credentials · 발급 (OAuth) › 발급 · 저장 토큰 발급 client_credentials 캐시 저장 · TTL = 만료 − 여유 · 발급 (OAuth) › 발급 · 저장 캐시 저장 TTL = 만료 − 여유 재사용 반환 · 발급 없음 · 반환 › 캐시 확인 재사용 반환 발급 없음 신규 반환 · 락 해제 후 · 반환 › 발급 · 저장 신규 반환 락 해제 후 있음 없음 Legend Agent logic Policy Tool action Context / trace External system

왜 single-flight인가

  • • KIS는 유효기간 내 잦은 발급 시 이용 제한 — 하루 1회 발급이 원칙
  • • 락을 못 잡은 호출은 발급하지 않고 기다렸다가 남이 넣은 토큰을 쓴다
  • • 락 획득 후에도 double-check로 중복 발급을 막는다

저장·복구

  • • Redis 키는 앱별로 격리(kis:* vs pa:kis:*)
  • • PVC + RDB·AOF 영속화로 파드·노드 재시작에도 토큰이 남는다
  • • 401이면 토큰을 버리고 1회 재시도(withAuthRetry)

영속화가 못 막는 것

  • • CoreDNS 단절로 Redis 이름 해석이 실패하면 '토큰 없음'으로 판정돼 재발급이 일어난다
  • • 앱 레벨 L1 캐시(SCRUM-81)가 그 구간을 덮는 후속 과제