SDUI의 성능 병목을 넘어: 올리브영 로컬 캐시 기반 백엔드 최적화 성공기

Context

SDUI(Server-Driven UI) 도입 후 성능 테스트에서 올영세일 기준 트래픽 시 P50 서버 응답 시간이 733ms까지 증가했으며, 네트워크 트래픽 증가로 인한 사용자 경험 악화가 발생했다. 대규모 동시 사용자가 동일한 탭바 및 테마드로워 데이터를 반복 요청하면서 Redis와 서버 간 구간의 네트워크 병목이 심화되었다.

Technical Solution

• 3단계 캐시 아키텍처 구축: Caffeine(로컬 메모리) → Redis(원격 캐시) → Oracle DB로 계층화하여 네트워크 트래픽 감소 및 DB 부하 최소화
• 로컬 캐시(Caffeine) 설정: expireAfterWrite로 TTL 10초 설정해 JVM 메모리 내에서 고성능 응답 제공
• 멱등성 보장 설계: 동일 파라미터 요청에 대해 항상 같은 결과 반환하도록 API 설계해 캐시 효율성 극대화
• 즉시 무효화 전략: 백오피스에서 SDUI 데이터(탭바, 테마드로워) 수정 시 관련 Redis 캐시를 즉시 삭제해 변경사항 실시간 반영
• 배치 기반 캐시 갱신: 일 1회 주기로 새벽 시간대 배치 작업 실행해 주요 SDUI 데이터를 미리 조회(Pre-warming)하고 콜드 캐시 문제 방지
• 계층별 책임 분리: TabbarController(요청처리) → IntegratedSduiService(로컬 캐시) → TabbarService(원격 캐시) → Repository(DB) 단일 책임 원칙으로 구현

Impact

• 최대 초당 처리량: 63.3k TPS (기존 대비 응답 시간 733ms → 1ms 이하로 단축)
• P90 Response Time: 1ms 미만 달성 (전체 요청의 90%가 1ms 이내 처리)
• 2025년 9월 올영세일 첫째날에 안정적 운영 입증

Key Takeaway

Server-Driven UI 같이 실시간성과 높은 동시성을 요구하는 시스템에서는 로컬 캐시를 1차 계층으로 도입해 네트워크 왕복을 제거하는 것이 레이턴시 개선의 핵심이며, 백오피스 연동 즉시 무효화 + 주기적 배치 갱신의 투트랙 전략으로 데이터 신선도와 캐시 안정성을 동시에 확보할 수 있다.