비즈니스 문제를 기술로 해결하고 시스템의 안정성과 효율을 끌어올린 5년간의 핵심 실무 경험을 정리했습니다. 단순 기능 구현을 넘어 **'왜 이 기술을 선택했는가'**와 **'예외 상황을 어떻게 통제했는가'**에 집중합니다.

1. 다단계 캐시 클라이언트 설계 및 단독 운영 (SK스토아)

기간 2025.04 ~ 2025.09 (이후 단독 운영 ~ 현재)

기술 스택 Spring Boot · Java 21 · Redis (Lettuce) · Caffeine · CompletableFuture

1) 배경 및 문제 상황

• 본 서비스는 Spring MVC / Java 8 기반의 레거시 환경. 선착순 이벤트·방송 노출 시점에 상품 상세로 트래픽이 폭증하는 패턴이 반복됨
• 모든 Read 요청이 DB로 직행 → 단시간 동일 데이터 요청이 집중되며 DB 커넥션 병목 발생

2) 기술적 의사결정

<aside>

왜 캐시 전용 서버(redis-api)를 분리했는가

레거시 본체(Java 8)에서는 Redis 8.x와 Lettuce 최신 기능을 온전히 쓸 수 없었습니다. 그래서 Redis 접근을 Spring Boot · Java 21 기반의 독립 캐시 서버로 격리하고, 본체는 이 서버를 호출하는 구조를 택했습니다.

(캐시 서버 자체 구현은 15년차 선임이 주도했고, 저는 이 서버를 호출하는 클라이언트 레이어 전체를 전담했습니다. 설계 과정의 90% 이상을 함께 공유하며 진행했습니다.)

</aside>

• Redis 단독의 한계 인식 수만 명 동접 시 외부 분산 캐시로 향하는 네트워크 커넥션·RTT 오버헤드 또한 병목이 될 수 있다고 판단 → 통신 비용이 없는 로컬 캐시(Caffeine)를 앞단에 둔 다단계 구조 채택

3) 직접 설계·구현한 부분

• 2-stack 분기 구조 설계 (100% 주도, 선임 승인)
  • 본체는 mobile-front(mfront)와 mobile-api(mapi) 2계층으로 구성
  • 비개인화·완성도 높은 캐시(예: GNB) → mfront에서 캐시 hit 여부를 판단해 mapi 호출 없이 즉시 응답 (네트워크 홉 절감)
  • 개인화 데이터 포함(예: 상품 상세 — 좋아요·장바구니·블라인드 댓글) → mapi까지 가서 캐시 가능 데이터 + DB-only 데이터를 조합해 mfront로 반환
  • 데이터 성격에 따라 경로 자체를 분기시켜 캐시 효율과 응답속도를 동시 확보
• Single → Bulk(mget) 호출 전환 다건 상품 조회 시 개별 호출을 Bulk로 묶고, Bulk 사이사이 DB 조회를 끼워넣는 하이브리드 흐름 구성 → 통신 횟수 대폭 감축 (가장 난도가 높았던 작업)
• 계층적 Key 네이밍 규칙 공동 수립 (예: product:{id}:info)

4) 결과

• 이벤트 피크 구간 활성 DB 세션 약 450 → 70 (84%↓)
• 평시 평균 페이지 로딩 2s → 400ms (최대 80%↓)

다단계 캐시 요청 흐름

flowchart TD
    U["사용자 요청"] --> MF["mobile-front"]
    MF -->|"비개인화 캐시 (예: GNB)"| HIT{"캐시 hit?"}
    HIT -->|"hit"| RESP["즉시 응답 (mapi 미호출)"]
    HIT -->|"miss"| MA["mobile-api"]
    MF -->|"개인화 포함 (예: 상품 상세)"| MA
    MA --> RAPI["redis-api 캐시 서버"]
    RAPI --> RDS[("Redis")]
    MA --> DB[("DB: 개인화·실시간")]
    MA --> MERGE["캐시 + DB 조합"]
    MERGE --> MF