2025-11-14

1일 1아티클

올리브영 테크블로그

이중 캐싱 전략

배경

  • ``SDUI(Server-Driven UI)` : 서버가 주도하는 사용자 인터페이스, 화면 구성요소를 서버가 설계도(JSON 데이터)로 전달하는 방식
  • 서버의 UI 구성 → 서비스 화면 실시간 수정
  • SDUI의 특성 상 API 응답 속도 및 네트워크 지연 시, 사용자 경험 문제 발생
    • 로컬 캐시를 활용한 최적화 전략 선택 → 초당 6만건 이상의 트래픽에도 응답 속도 1ms 미만 달성

기존 개발 방식의 한계

  • 비효율적인 개발 : 플랫폼별 UI 중복 구현으로 인한 개발 리소스 낭비 및 팀 피로도 문제
  • 느린 반영 속도 : UI 수정 시 앱스토어 배포 필수 → 시장 변화에 민첩한 대응 어려움
  • 일관성 없는 사용자 경험 : 플랫폼 간 UI 일부 불일치 → 브랜드 경험 일관성 저해

SDUI의 문제 : 성능 병목 현상

  1. API 응답 속도 저하
    • 초기 로딩 시간 증가
  2. 네트워크 트래픽 증가
    • 동일 데이터(탭바, 테마드로워)를 대규모 사용자 반복 요청 → 서버와 Redis 사이 구간 네트워크 트래픽 증가
  3. 사용자 경험 악화
    • 앞선 2가지 문제로 인한 응답 지연으로, 렌더링 속도 저하 및 사용자 경험 악화

해결 방법 : 이중 캐싱

  1. 캐시 정책
    • 동일 파라미터 요청 시 캐시를 통한 응답
    • API 단위의 key로 관리
  2. API 응답 구조 개선
    • 멱등성 보장하도록 API 설계
    • 동일 입력값 → 동일 출력 반환 보장되도록 구조화하여 캐시 유효성 증대
  3. 캐시 무효화 전략
    • 백오피스 연동을 통한 즉시 무효화
    • → 관리자가 UI 변경 시, 이벤트 감지 후 관련 Redis 캐시 즉각 삭제
    • → 캐시 오염 시나리오 방지
    • 주기적인 배치 작업을 통한 캐시 갱신
    • → 데이터 불일치 방지 및 캐시 안정성 확보를 위한 1일 주기 배치 작업
    • → 주요 SDUI 데이터 사전 조회 후, 캐시를 신규 데이터로 사전 캐싱
  4. 아키텍처 및 Caffeine 설정
    • 1차 로컬 캐시로 Caffeine 활용 → JVM 메모리 내 고성능 캐싱
    • 캐시 계층을 두 단계로 명확히 분리 → DB 부하 최소화, 다중 서버 환경에서 캐시 데이터 일관성 유지

성과

  • 초당 약 63,000건 요청 처리
  • P90 Response Time 최대 < 1ms : 대부분의 사용자가 1ms보다 훨씬 빠른 시간 안에 응답 수신
  • iOS, AOS, Web 모든 플랫폼에서 동일한 탭바 및 테마드로워 UI 제공

오늘 배운 것

  1. 관통 프로젝트 기획

내일 할 일

참고자료

results matching ""

    No results matching ""