캐싱 전략 — Caffeine L1 로컬 캐시로 검색 응답 14배 개선

이전 글

검색 품질 고도화 — 구절 검색, 커뮤니티 랭킹, P@10/MAP 평가에서 PhraseQuery(slop=2)로 구절 검색을 구현하고, BM25 + FeatureField(viewCount, likeCount) + RecencyDecay 결합 랭킹을 적용했습니다.

이전 글 요약

이전 글에서 검색 품질을 고도화했습니다.
15개 테스트 쿼리로 P@10/MAP을 측정하여 검색 품질을 정량적으로 평가했습니다.

개선율이 소폭인 이유: 초기 데이터(위키 덤프) 특성상 대부분의 게시글이 viewCount=0, likeCount=0.
실제 커뮤니티 운영 시 인기도 신호가 쌓이면 차이가 더 커질 것으로 예상.

개요

참고: 정보 검색 13.4장 캐싱

현재 아키텍처

검색 품질 고도화까지의 아키텍처:

현재 요청 흐름:

• 검색: 클라이언트 → API 서버 → Lucene 검색 (JVM 내부, SearcherManager acquire/release)
• 자동완성: 클라이언트 → API 서버 → Lucene PrefixQuery
• 목록 조회: 클라이언트 → API 서버 → MySQL SELECT (Deferred Join)
• 상세 조회: 클라이언트 → API 서버 → MySQL SELECT

검색/자동완성은 Lucene이 JVM 내부에서 처리하므로 MySQL 부하가 아닌 JVM CPU/메모리 부하입니다.
목록/상세 조회는 여전히 MySQL을 직접 거칩니다. 캐싱 레이어는 없습니다.

왜 캐싱이 필요한가

검색 쿼리의 특성: 반복적입니다.

검색 트래픽은 Zipf 분포를 따릅니다. 소수의 인기 검색어가 전체 트래픽의 대부분을 차지합니다. 위키피디아의 경우 상위 1%의 문서가 전체 조회수의 약 80%를 차지합니다.

이 말은 같은 검색어에 대해 Lucene이 같은 검색을 반복 실행하고 있다는 뜻입니다. “대한민국”을 100명이 검색하면, SearcherManager acquire → BM25 검색 → DB에서 Post 엔티티 조회를 100번 반복합니다. 99번은 낭비입니다.

핵심 문제: 부하를 줄여야 비용이 줄어듭니다.

Lucene 전환 이후, 검색 부하의 병목은 두 곳입니다:

1. JVM CPU — Lucene BM25 검색, SearcherManager acquire/release, 인덱스 I/O
2. MySQL — 검색 결과 Post ID → DB에서 엔티티 조회, 목록/상세 조회

검색 결과를 캐싱하면 Lucene 검색 + DB 엔티티 조회가 모두 스킵됩니다. JVM CPU와 DB 부하가 동시에 줄어듭니다.

속도 향상과 비용 절감은 별개가 아니라 인과관계입니다. 캐시가 검색 결과를 0.1ms 만에 반환하면, 그 요청은 MySQL의 CPU를 전혀 사용하지 않습니다. CPU를 안 쓰면 같은 인스턴스에서 더 많은 요청을 처리할 수 있고, 그러면 더 비싼 인스턴스로 올릴 필요가 없습니다. 즉, 속도가 빨라지면 비용이 줄어드는 건 당연한 결과입니다.

이 단계의 목표

Caffeine 로컬 캐시(L1)를 도입하여 반복 요청의 Lucene + DB 부하를 80%+ 감소시킵니다.

Caffeine 의존성은 이미 존재: TokenBlacklist에서 JWT 블랙리스트용으로 사용 중.
Spring Cache 추상화(@Cacheable, CacheManager)는 미적용 상태였습니다.

비용 분석 및 대안 검토

비용 시나리오 분석

실제 AWS 서울 리전 가격 기준으로, DB 비용을 월 20만원 수준으로 사용하고 있다고 가정합니다.

DB 중심 아키텍처의 비용 구조:

현재 구조에서 트래픽이 증가하면 선택지는 두 가지뿐입니다:

1. DB 스케일업: 더 비싼 인스턴스로 교체
2. Read Replica 추가: 읽기 전용 복제본 추가

둘 다 비용이 선형으로 증가합니다.

AWS RDS MySQL 기준 서울 리전 실제 가격:

출처: Holori RDS Calculator, DB Cost

AWS 공식 벤치마크에서 30,000 QPS를 달성하기 위해:

• RDS만 사용: db.r5.xlarge 1대 + Read Replica 4대 = $1,740/월 (~235만원)
• RDS + ElastiCache: db.r5.xlarge 1대 + ElastiCache 클러스터 = $780/월 (~105만원) → 55% 절감

출처: AWS Database Blog — Optimize cost and boost performance of RDS for MySQL using ElastiCache for Redis

시나리오별 비용 비교

핵심은 “캐시를 추가하니까 비용이 더 들었다”가 아니라, “캐시 덕분에 DB 부하가 줄어서 DB 스펙을 낮출 수 있었고, 총 비용이 줄었다”는 흐름입니다.

서버가 1대이고 트래픽이 크지 않은 현 시점에서는, 시나리오 D (Caffeine + CDN)가 비용 대비 가장 효율적입니다. 서버가 여러 대로 늘어나면 그때 Redis를 도입하면 됩니다.

대안 검토 — Redis vs CDN vs Caffeine

성능 비교

DB도 InnoDB Buffer Pool이라는 자체 메모리 캐시가 있습니다. Buffer Pool이 뜨거운(warm) 상태라면 디스크 I/O 없이 메모리에서 데이터를 반환하므로, 단순 SELECT는 Redis와 극적인 차이가 나지 않을 수 있습니다. 차이가 나는 건 CPU 집약적인 쿼리(FULLTEXT 검색, 복잡한 JOIN, 정렬)와 동시 접속 수가 많을 때입니다.

어떤 상황에서 어떤 캐시를 쓰는가

멀티 레이어 캐시 아키텍처

실무에서는 한 가지 캐시만 쓰지 않습니다. 카카오페이, 올리브영 등 국내 기업들이 실제로 사용하는 구조입니다:

카카오페이는 L1(Caffeine) → L2(Redis) → DB 3계층 캐시를 사용하며, Redis Pub/Sub로 L1 캐시 동기화를 처리합니다.

올리브영은 대규모 프로모션 트래픽에서 ElastiCache Network Bytes Out이 포화되는 문제를 겪었고, Caffeine L1 캐시를 추가하여 Redis 네트워크 I/O를 줄였습니다.

출처: 카카오페이 — 분산 시스템에서 로컬 캐시 활용하기, 올리브영 — 로컬 캐시와 Redis로 대규모 증정 행사 관리 최적화

현업 사례

AWS 공식 벤치마크

30,000 QPS 달성 시나리오에서 RDS 단독 대비 RDS + ElastiCache 조합이 55% 비용 절감, 80배 빠른 읽기 성능을 달성했습니다. ElastiCache 노드 1개가 초당 250,000건 이상 처리 가능하므로, Read Replica 4대를 Redis 1대로 대체할 수 있었습니다.

출처: AWS Database Blog — Optimize cost and boost performance of RDS for MySQL using ElastiCache for Redis

채널톡 (channel.io)

분산 캐시 도입으로 RDB 조회를 1,500 TPS에서 100 TPS 미만으로 줄였습니다. 93% 감소. 캐시 히트율은 거의 100%에 도달했습니다. Probabilistic Early Expiration으로 TTL 만료 직전에 미리 캐시를 갱신하여 Cache Stampede를 방지했습니다.

출처: Channel.io — Distributed Cache 도입기: RDB 조회 90% 감소시키기

Kicker (독일 축구 미디어)

월 20억 페이지뷰, 연 15% 성장하는 트래픽에서 Redis Enterprise 도입 후 웹 서버 비용 40% 절감, DB 서버 비용 60% 절감을 달성했습니다. 기존 하드웨어를 완전히 퇴역시켰습니다.

출처: Redis Customer Case Study — Kicker

카카오톡

초당 400만 건 이상의 데이터 접근 요청을 처리합니다. 기존에 256대의 물리 서버에서 Memcached를 운영하다가, Kubernetes + Redis 캐시 팜 아키텍처로 전환했습니다. hostNetwork을 사용하여 Kubernetes Ingress/Service 레이어를 제거하고, Redis 노드가 직접 통신하도록 하여 네트워크 오버헤드를 최소화했습니다.

출처: 카카오 테크 — 카카오톡 캐싱 시스템의 진화, 카카오 테크 — 쿠버네티스에 레디스 캐시 클러스터 구축기

네이버페이

로컬 캐시 솔루션으로 Ehcache와 Caffeine을 비교 평가했습니다. Caffeine의 Window TinyLfu 캐시 축출 정책이 Ehcache의 LRU/LFU보다 벤치마크에서 우수했고, 읽기/쓰기 모두 Caffeine이 더 빨랐습니다.

출처: 네이버페이 — 니들이 Caffeine 맛을 알아?

1. Caffeine 캐시 설정

목표

• Spring Cache 추상화 활성화 (@EnableCaching)
• 캐시 대상별 독립 정책 (TTL, 최대 크기, 축출 전략)
• Caffeine recordStats()로 히트율 수집

현재 상태

Caffeine 의존성: O (build.gradle에 caffeine:3.2.0)
Spring Cache: X (@EnableCaching 미설정, CacheManager 미등록)
@Cacheable: X (어디에도 미사용)

TokenBlacklist는 Caffeine을 직접 사용(Cache<String, Boolean>)하지만,
Spring Cache 추상화(@Cacheable)를 쓰지 않는 수동 방식이었습니다.
이번 단계에서 Spring Cache 추상화를 도입하여 선언적 캐싱을 적용합니다.

캐싱 대상 분석

Lucene 전환에서 검색을 Lucene으로 전환했으므로, 포스팅 리스트는 Lucene이 MMapDirectory + OS page cache로 내부 캐싱합니다.
앱 레벨에서 캐싱할 대상은 3가지입니다:

포스팅 리스트 캐싱 — Lucene MMapDirectory가 OS page cache 활용, 별도 앱 캐시 불필요

게시글 상세 캐싱 설계 결정

문제: getPostAndIncrementView()는 조회와 동시에 viewCount를 증가시킵니다.
이 메서드에 @Cacheable을 걸면 캐시 히트 시 viewCount가 증가하지 않습니다.

선택지:

B안 (읽기/쓰기 분리) 채택:

// 읽기: 캐싱 대상
@Cacheable(value = "postDetail", key = "#id")
public Post findById(Long id) { ... }

// 쓰기: viewCount 증가만 (캐시와 무관)
public void incrementViewCount(Long id) { postRepository.incrementViewCount(id); }

컨트롤러에서 두 메서드를 조합:

Post post = postService.findByIdCached(id);  // 캐시 히트 가능
postService.incrementViewCount(id);           // 항상 DB 업데이트

캐시 정책 설계

W-TinyLFU: Caffeine의 기본 축출 정책. LRU + LFU를 결합하여 최근성과 빈도를 모두 고려합니다.
네이버페이 벤치마크에서 Ehcache(LRU)보다 Caffeine(W-TinyLFU)이 히트율과 처리속도 모두 우수했습니다.

TTL에 랜덤 편차(예: 기본 TTL +/- 10%)를 추가하면, 동일 시점에 대량의 캐시가 동시 만료되는 Cache Stampede를 방지할 수 있습니다. Instagram이 피드 캐싱에서 이 기법을 사용합니다.

캐시 크기 vs 히트율 트레이드오프

검색 쿼리는 롱테일(Zipf) 분포를 따르므로, 상위 1,000개 검색어만 캐싱해도 상당한 히트율을 달성할 수 있습니다.

구현

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public CacheManager cacheManager() {
        CaffeineCacheManager manager = new CaffeineCacheManager();

        // 1. 검색 결과 캐시 (검색어+페이지 → Page<Post>)
        manager.registerCustomCache("searchResults",
            Caffeine.newBuilder()
                .maximumSize(10_000)
                .expireAfterWrite(Duration.ofMinutes(5))
                .recordStats()
                .build());

        // 2. 자동완성 캐시 (prefix → title 목록)
        manager.registerCustomCache("autocomplete",
            Caffeine.newBuilder()
                .maximumSize(10_000)
                .expireAfterWrite(Duration.ofMinutes(10))
                .recordStats()
                .build());

        // 3. 게시글 상세 캐시 (postId → Post 엔티티)
        manager.registerCustomCache("postDetail",
            Caffeine.newBuilder()
                .maximumSize(50_000)
                .expireAfterAccess(Duration.ofMinutes(30))
                .recordStats()
                .build());

        return manager;
    }
}

2. 검색/자동완성 캐싱 (@Cacheable)

Cache-Aside 패턴

검색에서 가장 일반적인 캐싱 전략은 Cache-Aside(Lazy Loading)입니다. 애플리케이션이 캐시와 DB를 명시적으로 관리합니다.

출처: AWS — Database Caching Strategies Using Redis

캐시 적용

@Cacheable(value = "searchResults",
    key = "#keyword + ':' + #pageable.pageNumber + ':' + #pageable.pageSize")
public Page<Post> search(String keyword, Pageable pageable) {
    validatePageLimit(pageable, MAX_SEARCH_PAGE);
    try {
        return luceneSearchService.search(keyword, pageable);
    } catch (IOException e) {
        throw new UncheckedIOException(e);
    }
}

@Cacheable(value = "autocomplete", key = "#prefix")
public List<String> autocomplete(String prefix) {
    try {
        return luceneSearchService.autocomplete(prefix, 10);
    } catch (IOException e) {
        throw new UncheckedIOException(e);
    }
}

캐시 키 설계

주의: 검색 캐시 키에 pageSize도 포함해야 합니다. 같은 keyword + page=0이라도 size=10과 size=20은 다른 결과입니다.

@Cacheable과 @Transactional 충돌 주의

현재 PostService는 클래스 레벨에 @Transactional(readOnly = true)가 걸려있습니다.
@Cacheable은 AOP 프록시 기반이므로 같은 클래스 내 다른 메서드에서 호출하면 캐시가 동작하지 않습니다(self-invocation 문제).

현재 search()와 autocomplete()는 컨트롤러에서 직접 호출되므로 문제없습니다.
단, getPostAndIncrementView() 내부에서 캐시된 findById()를 호출하면 self-invocation이 되므로,
컨트롤러에서 분리 호출해야 합니다.

3. 캐시 무효화 (@CacheEvict)

무효화 전략

구현

// 게시글 수정 시 해당 캐시 즉시 제거
@CacheEvict(value = "postDetail", key = "#id")
@Transactional
public void updatePost(Long id, String title, String content, Long userId) {
    Post post = postRepository.findById(id)
            .orElseThrow(() -> new BusinessException(ErrorCode.POST_NOT_FOUND));
    if (!post.getAuthorId().equals(userId)) {
        throw new BusinessException(ErrorCode.ACCESS_DENIED);
    }
    post.update(title, content);
    indexSafely(post);
}

// 게시글 삭제 시 해당 캐시 즉시 제거
@CacheEvict(value = "postDetail", key = "#id")
@Transactional
public void deletePost(Long id, Long userId) {
    // ... 기존 로직
}

캐시 일관성과 허용 가능한 지연

• 검색 결과: 게시글 수정 후 최대 5분간 이전 검색 결과가 반환될 수 있습니다. 커뮤니티 서비스에서 허용 가능한 수준입니다 (Google 검색도 크롤링 갱신에 시간이 걸립니다).
• 자동완성: 새 게시글이 추가되어도 최대 10분간 자동완성에 나타나지 않을 수 있습니다. prefix 기반이므로 영향이 제한적입니다.
• 게시글 상세: @CacheEvict로 즉시 무효화. 수정/삭제 후 다음 요청에서 DB 최신 데이터를 반환합니다.

4. Cache Stampede 방지

문제

인기 검색어 “삼성전자”의 캐시가 TTL 만료되는 순간, 동시에 100개 요청이 모두 캐시 미스 → Lucene 검색 100회 + DB 조회 100회가 동시 발생합니다.

시간 T: "삼성전자" 캐시 만료
  ↓
동시 100개 요청 → 모두 캐시 미스 → Lucene 100회 + DB 100회
  ↓
JVM CPU 스파이크, DB 과부하

방지 방법

Caffeine의 내장 해결: refreshAfterWrite

Caffeine은 refreshAfterWrite를 설정하면 TTL 만료 전에 비동기로 캐시를 갱신합니다.
갱신 중에도 이전 값을 반환하므로 Stampede가 발생하지 않습니다.

// refreshAfterWrite: 3분 후 백그라운드 갱신 시작
// expireAfterWrite: 5분 후 강제 만료 (안전장치)
manager.registerCustomCache("searchResults",
    Caffeine.newBuilder()
        .maximumSize(10_000)
        .refreshAfterWrite(Duration.ofMinutes(3))   // 3분 후 비동기 갱신
        .expireAfterWrite(Duration.ofMinutes(5))     // 5분 후 강제 만료
        .recordStats()
        .buildAsync(key -> loadFromLucene(key))      // 비동기 로더
        .synchronous());

단, @Cacheable + CaffeineCacheManager 조합에서는 buildAsync 대신
CacheLoader를 별도 등록해야 합니다. 복잡도가 올라가므로:

실용적 선택: 단일 서버 환경에서는 Stampede 영향이 제한적입니다.
expireAfterWrite TTL만 설정하고, 부하 테스트에서 실제 문제가 관측되면 그때 refreshAfterWrite를 추가합니다.

5. 브라우저 캐싱 (Cache-Control)

서버 캐시(Caffeine) 외에 브라우저 캐싱도 적용하여 네트워크 요청 자체를 줄입니다.
CDN이 없는 단일 서버 환경에서도 브라우저가 캐시 역할을 합니다.

적용 대상

구현

// PostController: 자동완성 — 5분 브라우저 캐싱
@GetMapping("/autocomplete")
public ResponseEntity<List<String>> autocomplete(@RequestParam String prefix) {
    List<String> suggestions = postService.autocomplete(prefix);
    return ResponseEntity.ok()
        .cacheControl(CacheControl.maxAge(Duration.ofMinutes(5))
            .staleWhileRevalidate(Duration.ofSeconds(60)))
        .body(suggestions);
}

stale-while-revalidate 동작

6. 캐시 모니터링 (Actuator)

캐시를 도입하고 나면 “실제로 효과가 있는가”를 지속 측정해야 합니다.
히트율이 80% 미만이면 TTL, 키 설계, 최대 크기를 재검토합니다.

모니터링 지표

Caffeine recordStats + Actuator 노출

// CacheConfig에서 이미 recordStats() 설정
Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(Duration.ofMinutes(5))
    .recordStats()  // 히트율 등 통계 수집
    .build()

Spring Actuator 엔드포인트:

• /actuator/caches — 등록된 캐시 목록
• /actuator/metrics/cache.gets — 캐시 히트/미스 횟수
• /actuator/metrics/cache.evictions — 축출 횟수
• /actuator/metrics/cache.size — 현재 캐시 엔트리 수

Grafana 대시보드 연동

기존 Prometheus + Grafana 모니터링에 캐시 메트릭을 추가:

management:
  metrics:
    tags:
      application: wikiengine
  endpoints:
    web:
      exposure:
        include: caches, metrics, health, prometheus

Grafana에서 cache_gets_total{result="hit"} / cache_gets_total 비율을 대시보드에 추가하면
실시간 히트율을 모니터링할 수 있습니다.

부하 테스트 및 결과

측정 원칙

1. Before/After 동일 조건: 같은 k6 프로필(load), 같은 VU(100), 같은 duration(20분)
2. k6 InfluxDB 출력: --out influxdb=http://localhost:8086/k6 (Grafana k6 대시보드 연동)
3. Grafana 시간 범위 통일: 대시보드 캡처 시 동일 시간 범위로 맞추기

Before (캐시 없음 baseline)

측정일시: 2026-03-14 16:20~16:45 KST
테스트 환경: ARM 2코어 / 12GB RAM — Spring Boot JVM 1GB + MySQL InnoDB BP 2GB
k6 프로필: load (100 VU, 20분)

k6 콘솔 결과

k6 run --out influxdb=http://localhost:8086/k6 \
  -e PROFILE=load -e BASE_URL=https://api.studywithtymee.com \
  /home/rocky/k6/baseline-load-test.js

k6 Grafana 대시보드

시나리오별 (Grafana):

검색 빈도별 (Grafana):

네트워크 상세:

서버 Grafana

Spring Boot:

MySQL:

호스트:

이전 글 대비 성능 변화 — 왜 70배 느려졌는가

무엇이 바뀌었나

이전 글까지는 BM25 스코어링만 사용했습니다.
Lucene은 BM25 단독 스코어링에서 Block-Max WAND 최적화를 적용할 수 있어서,
posting list 전체를 순회하지 않고 top-k 결과를 빠르게 추출합니다.

검색 품질 고도화에서 검색 품질을 올리기 위해 3개의 추가 스코어링 요소를 도입했습니다:

왜 검색이 느려졌나

“대한민국” 같은 고빈도 토큰은 수만~수십만 건이 매칭됩니다.

이전 글 (BM25만):
  "대한민국" 검색 -> posting list 순회 + BM25 score만 계산
  -> WAND 최적화로 일부만 평가 -> ~25ms

검색 품질 고도화 후 (BM25 + FeatureField + RecencyDecay):
  "대한민국" 검색 -> posting list 순회 + BM25 score 계산
  + viewCount DocValues 읽기 (매칭 문서마다)
  + likeCount DocValues 읽기 (매칭 문서마다)
  + createdAt DocValues 읽기 + decay 계산 (매칭 문서마다)
  -> 복합 스코어링으로 WAND 최적화 제한 -> ~2,800ms

smoke(5 VU)에서 이를 확인할 수 있습니다:

5 VU에서는 검색만 2.8배 느려졌고, 나머지 API는 동일합니다.

왜 검색 외에 전부 느려졌나 (100 VU)

자동완성/목록/상세는 스코어링과 무관한데 62배/47배/25배 느려졌습니다.
이것은 검색 자체가 느려진 게 아니라, CPU 포화로 인한 cascade failure입니다.

원인 체인:

1. 품질 고도화 후 검색 = BM25 + DocValues 3회 -> 검색 1건당 CPU 시간 증가
2. 100 VU 동시 검색 -> 2코어 CPU 포화 (App CPU 80~100%)
3. CPU 대기열 형성 -> 모든 요청이 CPU 순번을 기다림
4. 자동완성/목록/상세도 CPU 대기열에 갇힘 -> 전체 응답시간 폭증
5. HikariCP 커넥션 대기 (Pending ~50) -> DB 접근도 병목
6. JVM 스레드 20 -> 100+ 폭증 -> 컨텍스트 스위칭 오버헤드 추가

이것은 이전 글에서 deep OFFSET이 CPU를 포화시켜 전체 API가 무너졌던 것과 동일한 패턴입니다.
단일 병목(이번엔 검색 스코어링)이 공유 자원(CPU)을 독점하면, 무관한 API까지 연쇄 지연됩니다.

왜 캐싱이 해답인가

검색 결과를 캐싱하면:

• 캐시 히트 시 Lucene 검색 + DocValues 읽기가 통째로 스킵됩니다
• CPU 사용이 0에 수렴 → 2코어로도 100 VU를 처리할 여유 확보
• cascade failure 해소 → 자동완성/목록/상세도 원래 속도로 복귀

검색 트래픽은 Zipf 분포를 따르므로, 상위 인기 검색어만 캐싱해도 히트율 80%+를 기대할 수 있습니다.
캐시 히트율 80% = 검색 CPU 부하 80% 감소 = cascade failure 임계점 이하로 복귀.

구현 확인

코드 변경 diff

/actuator/caches 응답

참고: 외부(Nginx) 경로는 403 Forbidden — 앱 서버에서 localhost:8080으로 직접 확인

캐시 히트/미스 응답시간 비교

검색은 Lucene BM25 + DocValues 3회 읽기가 통째로 스킵되어 극적인 차이.
자동완성은 원래 Lucene PrefixQuery 자체가 빨라서 차이가 작지만, 부하 테스트 시 CPU 포화 환경에서는 캐시 효과가 크게 나타납니다.

Cache-Control 헤더 확인

자동완성 API 응답에 Cache-Control: max-age=300, stale-while-revalidate=60 헤더가 포함되어, 브라우저가 5분간 캐시하고 만료 후 60초간 이전 응답을 반환하면서 백그라운드 갱신합니다.

After (캐시 적용 후 측정)

캐싱 구현 완료 후, Before와 동일한 조건으로 다시 측정합니다.

측정일시: 2026-03-14 19:20~19:40 KST
테스트 환경: Before와 동일 (ARM 2코어 / 12GB RAM)
k6 프로필: load (100 VU, 20분)

K6_INFLUXDB_PUSH_INTERVAL=10s k6 run --out influxdb=http://localhost:8086/k6 \
  -e PROFILE=load -e BASE_URL=https://api.studywithtymee.com \
  /home/rocky/k6/baseline-load-test.js

InfluxDB 쓰기 부하로 k6 Grafana 대시보드 데이터가 유실됨 (InfluxDB 128MB 메모리 제한).
k6 콘솔 결과 + Prometheus 기반 서버 Grafana로 비교.

k6 콘솔 결과

서버 Grafana (After)

Spring Boot:

Caffeine Cache:

MySQL:

호스트:

Before vs After 비교

k6 핵심 지표 비교표

서버 리소스 비교표

MySQL QPS가 150→200으로 증가한 이유: 캐싱으로 CPU 경합이 해소되면서 총 처리량이 29,867→41,858건(+40%)으로 늘어났습니다. 캐시 미스 요청 + 쓰기 요청(생성/좋아요)의 절대 수가 증가했기 때문에 QPS도 증가한 것입니다. 요청당 DB 접근 횟수는 캐시 히트에 의해 감소했지만, 전체 처리량 증가가 이를 상쇄했습니다. Slow Queries 누적값(8.34K→15.1K)도 같은 원인입니다.

캐시 효과 요약

postDetail 히트율이 40.5%인 이유: k6 부하 테스트가 1,477만 건 중 랜덤 postId를 조회하므로 캐시 재적중 확률이 낮습니다. 실제 운영에서는 Zipf 분포에 따라 인기 게시글에 트래픽이 집중되므로 히트율이 더 높을 것으로 예상됩니다.

cascade failure 해소

Before에서 검색 CPU 포화로 인해 검색과 무관한 API(자동완성, 목록, 상세)까지 전부 느려졌던 cascade failure가 완전히 해소되었습니다.

캐시로 검색 CPU 부하를 제거하자, 자동완성/목록/상세가 smoke 테스트(5 VU)와 거의 동일한 속도로 복귀했습니다. 이것이 캐싱의 진짜 효과 — 직접 캐싱된 API뿐 아니라, CPU 경합이 해소되면서 전체 API가 원래 성능을 되찾았습니다.

OOM 안전성 검증

Caffeine은 JVM 힙 안에서 동작하므로, 캐시가 힙을 잠식하면 OOM으로 서버가 죽을 수 있습니다. 부하 테스트(100 VU, 20분) 중 실측값으로 안전성을 확인했습니다.

searchResults의 엔트리 수가 ~4,000에서 안정된 이유: TTL 5분이므로 5분 이내에 들어온 고유 검색어 수만큼 쌓이고, 이전 엔트리는 만료되어 자연 축출됩니다. maximumSize(10,000)에 도달하기 전에 TTL이 먼저 동작하여 메모리가 자연스럽게 관리되고 있습니다.

Evictions 그래프에서 축출이 발생하는 건 캐시가 정상적으로 오래된 엔트리를 버리고 있다는 증거이며, 축출 빈도가 급증하지 않으므로 maximumSize가 적절하게 설정되어 있다고 판단할 수 있습니다.

근거: Grafana Caffeine Cache 패널 + JVM Heap 패널

알려진 한계와 주의사항

캐시 일관성 (Cache Consistency)

캐시를 도입하면 DB와 캐시 사이에 데이터 불일치가 발생할 수 있습니다. DB에는 최신 값이 반영됐는데 캐시에는 이전 값이 남아서, 사용자가 stale data를 보게 되는 문제입니다.

예를 들어 상품 가격을 10,000원에서 8,000원으로 수정하고 DB에 반영했는데, 캐시에 이전 데이터(10,000원)가 남아있으면 사용자는 여전히 10,000원을 봅니다. 결제까지 갔다가 가격이 달라지면 사용자 신뢰를 잃습니다.

캐시 무효화는 실무에서 가장 성가신 문제입니다. TTL을 짧게 잡으면 캐시 미스가 잦아져 DB 부하가 줄지 않고, 길게 잡으면 사용자가 오랫동안 stale data를 봅니다. 정답은 없고, 데이터의 성격에 따라 개발자가 적절한 수준을 판단해야 합니다. 이것이 도메인 지식이 필요한 이유입니다.

이 프로젝트에서의 판단:

• 검색 결과 캐시 (TTL 5분): 게시글 수정 후 최대 5분간 이전 결과가 반환될 수 있습니다. 커뮤니티 검색에서 허용 가능한 수준입니다 (Google 검색도 인덱스 갱신에 시간이 걸립니다)
• 게시글 상세 캐시 (즉시 무효화): 수정/삭제 시 @CacheEvict로 즉시 캐시를 제거합니다. 수정한 내용이 바로 반영되지 않으면 사용자 경험에 직접 영향을 줍니다
• 자동완성 캐시 (TTL 10분): 새 게시글이 추가되어도 10분간 자동완성에 나타나지 않을 수 있습니다. 자동완성은 “제안”이므로 즉각 반영이 필수는 아닙니다

Cache Stampede

TTL이 동시에 만료되면 대량의 요청이 동시에 DB로 몰립니다. (위 4번 섹션에서 상세 설명)

로컬 캐시와 OOM (Out of Memory)

Caffeine은 JVM 힙 메모리 안에서 동작하는 로컬 캐시입니다. 캐시 엔트리가 힙을 과도하게 차지하면 GC 압력이 증가하고, 최악의 경우 OOM으로 서버가 죽습니다. Redis(외부 프로세스)와 달리 앱과 캐시가 같은 메모리를 공유하기 때문에, 캐시가 커지면 앱이 쓸 메모리가 줄어드는 구조입니다.

이 프로젝트에서의 방어:

maximumSize를 설정하지 않으면 인기 검색어가 계속 쌓이면서 힙을 잠식합니다. 특히 검색 결과 캐시는 Page<Post> 객체(엔티티 리스트)를 통째로 저장하므로 엔트리당 크기가 큽니다. Caffeine의 W-TinyLFU 축출 정책이 maximumSize 초과 시 가장 가치 낮은 엔트리를 제거하여 메모리를 관리합니다.

모니터링에서 cache_size(현재 엔트리 수)와 cache_evictions_total(축출 횟수)을 함께 봐야 합니다. 축출이 빈번하면 maximumSize가 작은 것이고, cache_size가 maximumSize에 한참 못 미치면 메모리를 낭비하는 것입니다.

Cold Start

서버 재시작 시 Caffeine 캐시가 비어있으므로, 모든 요청이 DB를 직접 hit합니다. 트래픽이 많은 시점에 배포하면 일시적으로 DB 부하가 급증할 수 있습니다.

완화 방법:

• 배포 직후 인기 검색어 목록으로 캐시를 미리 채우는 Warm-Up 스크립트
• Blue-Green 배포로 트래픽을 점진적으로 전환

검토했지만 별도 적용하지 않은 항목

참고 자료

• Caffeine GitHub Wiki
• Baeldung — Spring Boot Caffeine Caching
• 네이버페이 — 니들이 Caffeine 맛을 알아?
• 카카오페이 — 분산 시스템에서 로컬 캐시 활용하기
• 올리브영 — 로컬 캐시와 Redis로 대규모 증정 행사 관리 최적화
• 채널톡 — Distributed Cache 도입기: RDB 조회 90% 감소시키기
• AWS — Database Caching Strategies Using Redis
• AWS Database Blog — RDS + ElastiCache 벤치마크
• Redis — Why Your Cache Hit Ratio Strategy Needs an Update
• 카카오 테크 — 카카오톡 캐싱 시스템의 진화
• Redis Customer Case Study — Kicker

Previous Post

In Search Quality Enhancement — Phrase Search, Community Ranking, and P@10/MAP Evaluation, we implemented phrase search with PhraseQuery(slop=2) and applied a combined ranking of BM25 + FeatureField(viewCount, likeCount) + RecencyDecay.

Previous Post Summary

In the previous post, we enhanced search quality.
We measured P@10/MAP across 15 test queries to quantitatively evaluate search quality.

The modest improvement is due to the nature of the initial data (wiki dump): most posts have viewCount=0 and likeCount=0.
As popularity signals accumulate during actual community operation, the difference is expected to grow.

Overview

Reference: Information Retrieval, Section 13.4 — Caching

Current Architecture

Architecture up to Search Quality Enhancement:

Current request flow:

• Search: Client → API Server → Lucene Search (in-JVM, SearcherManager acquire/release)
• Autocomplete: Client → API Server → Lucene PrefixQuery
• List: Client → API Server → MySQL SELECT (Deferred Join)
• Detail: Client → API Server → MySQL SELECT

Search/autocomplete is handled by Lucene within the JVM, so the bottleneck is JVM CPU/memory, not MySQL.
List/detail queries still hit MySQL directly. There is no caching layer.

Why Caching Is Needed

The nature of search queries: they are repetitive.

Search traffic follows a Zipf distribution. A small number of popular queries account for the majority of traffic. In Wikipedia’s case, the top 1% of articles account for about 80% of total page views.

This means Lucene is repeatedly executing the same search for the same query. If 100 users search for “South Korea,” the system repeats SearcherManager acquire → BM25 search → DB Post entity lookup 100 times. 99 of those are wasted.

Core problem: reducing load reduces cost.

After the Lucene migration, the search bottleneck has two components:

1. JVM CPU — Lucene BM25 search, SearcherManager acquire/release, index I/O
2. MySQL — Post entity lookup by search result Post IDs, list/detail queries

Caching search results skips both Lucene search and DB entity lookups. JVM CPU and DB load decrease simultaneously.

Speed improvement and cost reduction are not separate concerns but causally related. When cache returns a search result in 0.1ms, that request uses zero MySQL CPU. Using no CPU means the same instance can handle more requests, which means there’s no need to upgrade to a more expensive instance. In other words, faster speed naturally results in lower cost.

Goals for This Phase

Introduce Caffeine local cache (L1) to reduce Lucene + DB load from repeated requests by 80%+.

Caffeine dependency already exists: used for JWT blacklisting in TokenBlacklist.
Spring Cache abstraction (@Cacheable, CacheManager) was not yet applied.

Cost Analysis and Alternative Review

Cost Scenario Analysis

Based on actual AWS Seoul region pricing, assuming DB costs of approximately 200,000 KRW (~$150) per month.

Cost structure of a DB-centric architecture:

When traffic increases under the current architecture, there are only two options:

1. DB Scale-Up: Replace with a more expensive instance
2. Add Read Replica: Add read-only replicas

Both increase costs linearly.

AWS RDS MySQL actual prices for Seoul region:

Source: Holori RDS Calculator, DB Cost

In the AWS official benchmark to achieve 30,000 QPS:

• RDS only: db.r5.xlarge x1 + Read Replicas x4 = $1,740/mo
• RDS + ElastiCache: db.r5.xlarge x1 + ElastiCache cluster = $780/mo → 55% savings

Source: AWS Database Blog — Optimize cost and boost performance of RDS for MySQL using ElastiCache for Redis

Cost Comparison by Scenario

The key insight is not “adding cache increased costs” but rather “cache reduced DB load, allowing a lower DB spec, reducing total cost.”

For a single server with moderate traffic, Scenario D (Caffeine + CDN) is the most cost-effective. When scaling to multiple servers, Redis can be introduced at that point.

Alternative Review — Redis vs CDN vs Caffeine

Performance Comparison

DB also has its own memory cache called InnoDB Buffer Pool. When the Buffer Pool is warm, it returns data from memory without disk I/O, so simple SELECTs may not show dramatic differences from Redis. The difference becomes apparent with CPU-intensive queries (FULLTEXT search, complex JOINs, sorting) and high concurrency.

When to Use Which Cache

Multi-Layer Cache Architecture

In practice, companies don’t use just one cache. This is the architecture actually used by Korean companies like KakaoPay and Olive Young:

KakaoPay uses a 3-tier cache of L1(Caffeine) → L2(Redis) → DB, with Redis Pub/Sub for L1 cache synchronization.

Olive Young experienced ElastiCache Network Bytes Out saturation during large-scale promotions and added Caffeine L1 cache to reduce Redis network I/O.

Source: KakaoPay — Using Local Cache in Distributed Systems, Olive Young — Optimizing Large-Scale Promotions with Local Cache and Redis

Industry Case Studies

AWS Official Benchmark

In a 30,000 QPS scenario, RDS + ElastiCache achieved 55% cost savings and 80x faster read performance compared to RDS alone. A single ElastiCache node can process over 250,000 requests per second, replacing 4 Read Replicas with 1 Redis instance.

Source: AWS Database Blog — Optimize cost and boost performance of RDS for MySQL using ElastiCache for Redis

Channel.io

Introducing distributed cache reduced RDB queries from 1,500 TPS to under 100 TPS. 93% reduction. Cache hit rate reached nearly 100%. Probabilistic Early Expiration preemptively refreshes cache before TTL expiry to prevent Cache Stampede.

Source: Channel.io — Distributed Cache Introduction: Reducing RDB Queries by 90%

Kicker (German Football Media)

With 2 billion monthly page views and 15% annual traffic growth, deploying Redis Enterprise achieved 40% web server cost reduction and 60% DB server cost reduction. Legacy hardware was fully decommissioned.

Source: Redis Customer Case Study — Kicker

KakaoTalk

Handles over 4 million data access requests per second. Migrated from 256 physical servers running Memcached to a Kubernetes + Redis cache farm architecture. Uses hostNetwork to eliminate the Kubernetes Ingress/Service layer, allowing Redis nodes to communicate directly and minimizing network overhead.

Source: Kakao Tech — Evolution of KakaoTalk Caching System, Kakao Tech — Building Redis Cache Cluster on Kubernetes

NaverPay

Compared Ehcache and Caffeine as local cache solutions. Caffeine’s Window TinyLfu eviction policy outperformed Ehcache’s LRU/LFU in benchmarks, with Caffeine being faster in both reads and writes.

Source: NaverPay — Do You Know the Taste of Caffeine?

1. Caffeine Cache Configuration

Goal

• Enable Spring Cache abstraction (@EnableCaching)
• Independent policies per cache target (TTL, max size, eviction strategy)
• Collect hit rates with Caffeine recordStats()

Current State

Caffeine dependency: O (caffeine:3.2.0 in build.gradle)
Spring Cache: X (@EnableCaching not configured, CacheManager not registered)
@Cacheable: X (not used anywhere)

TokenBlacklist used Caffeine directly (Cache<String, Boolean>), but was a manual approach without Spring Cache abstraction (@Cacheable).
This phase introduces Spring Cache abstraction for declarative caching.

Caching Target Analysis

Since search was migrated to Lucene in the Lucene migration, posting lists are internally cached by Lucene via MMapDirectory + OS page cache.
There are 3 targets for app-level caching:

Posting list caching — Lucene MMapDirectory leverages OS page cache, no separate app cache needed

Post Detail Caching Design Decision

Problem: getPostAndIncrementView() increments viewCount simultaneously with retrieval.
Applying @Cacheable to this method would prevent viewCount from incrementing on cache hits.

Options:

Option B (Separate read/write) adopted:

// Read: caching target
@Cacheable(value = "postDetail", key = "#id")
public Post findById(Long id) { ... }

// Write: only increment viewCount (independent of cache)
public void incrementViewCount(Long id) { postRepository.incrementViewCount(id); }

Combining both methods in the controller:

Post post = postService.findByIdCached(id);  // Cache hit possible
postService.incrementViewCount(id);           // Always updates DB

Cache Policy Design

W-TinyLFU: Caffeine’s default eviction policy. Combines LRU + LFU to consider both recency and frequency.
In NaverPay’s benchmark, Caffeine (W-TinyLFU) outperformed Ehcache (LRU) in both hit rate and throughput.

Adding random jitter to TTL (e.g., base TTL +/- 10%) prevents Cache Stampede where many cache entries expire simultaneously. Instagram uses this technique for feed caching.

Cache Size vs Hit Rate Trade-off

Search queries follow a long-tail (Zipf) distribution, so caching just the top 1,000 queries can achieve significant hit rates.

Implementation

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public CacheManager cacheManager() {
        CaffeineCacheManager manager = new CaffeineCacheManager();

        // 1. Search results cache (keyword+page → Page<Post>)
        manager.registerCustomCache("searchResults",
            Caffeine.newBuilder()
                .maximumSize(10_000)
                .expireAfterWrite(Duration.ofMinutes(5))
                .recordStats()
                .build());

        // 2. Autocomplete cache (prefix → title list)
        manager.registerCustomCache("autocomplete",
            Caffeine.newBuilder()
                .maximumSize(10_000)
                .expireAfterWrite(Duration.ofMinutes(10))
                .recordStats()
                .build());

        // 3. Post detail cache (postId → Post entity)
        manager.registerCustomCache("postDetail",
            Caffeine.newBuilder()
                .maximumSize(50_000)
                .expireAfterAccess(Duration.ofMinutes(30))
                .recordStats()
                .build());

        return manager;
    }
}

2. Search/Autocomplete Caching (@Cacheable)

Cache-Aside Pattern

The most common caching strategy for search is Cache-Aside (Lazy Loading). The application explicitly manages the cache and DB.

Source: AWS — Database Caching Strategies Using Redis

Applying Cache

@Cacheable(value = "searchResults",
    key = "#keyword + ':' + #pageable.pageNumber + ':' + #pageable.pageSize")
public Page<Post> search(String keyword, Pageable pageable) {
    validatePageLimit(pageable, MAX_SEARCH_PAGE);
    try {
        return luceneSearchService.search(keyword, pageable);
    } catch (IOException e) {
        throw new UncheckedIOException(e);
    }
}

@Cacheable(value = "autocomplete", key = "#prefix")
public List<String> autocomplete(String prefix) {
    try {
        return luceneSearchService.autocomplete(prefix, 10);
    } catch (IOException e) {
        throw new UncheckedIOException(e);
    }
}

Cache Key Design

Note: The search cache key must include pageSize. Even with the same keyword + page=0, size=10 and size=20 produce different results.

@Cacheable and @Transactional Conflict Warning

Currently, PostService has class-level @Transactional(readOnly = true).
@Cacheable is AOP proxy-based, so calling from another method within the same class won’t trigger the cache (self-invocation problem).

Currently, search() and autocomplete() are called directly from the controller, so there’s no issue.
However, calling the cached findById() from within getPostAndIncrementView() would be self-invocation, so it must be called separately from the controller.

3. Cache Invalidation (@CacheEvict)

Invalidation Strategy

Implementation

// Immediately remove cache when post is updated
@CacheEvict(value = "postDetail", key = "#id")
@Transactional
public void updatePost(Long id, String title, String content, Long userId) {
    Post post = postRepository.findById(id)
            .orElseThrow(() -> new BusinessException(ErrorCode.POST_NOT_FOUND));
    if (!post.getAuthorId().equals(userId)) {
        throw new BusinessException(ErrorCode.ACCESS_DENIED);
    }
    post.update(title, content);
    indexSafely(post);
}

// Immediately remove cache when post is deleted
@CacheEvict(value = "postDetail", key = "#id")
@Transactional
public void deletePost(Long id, Long userId) {
    // ... existing logic
}

Cache Consistency and Acceptable Delay

• Search results: Previous search results may be returned for up to 5 minutes after a post update. This is acceptable for a community service (even Google search takes time for crawl updates).
• Autocomplete: New posts may not appear in autocomplete for up to 10 minutes. Impact is limited since it’s prefix-based.
• Post detail: Immediately invalidated with @CacheEvict. The next request after update/delete returns the latest DB data.

4. Cache Stampede Prevention

Problem

When the cache for the popular query “Samsung Electronics” expires by TTL, 100 simultaneous requests all hit cache miss → 100 Lucene searches + 100 DB queries execute concurrently.

Time T: "Samsung Electronics" cache expires
  ↓
100 simultaneous requests → all cache miss → 100 Lucene + 100 DB queries
  ↓
JVM CPU spike, DB overload

Prevention Methods

Caffeine’s Built-in Solution: refreshAfterWrite

Caffeine’s refreshAfterWrite asynchronously refreshes the cache before TTL expiry.
The previous value is returned during refresh, so Stampede doesn’t occur.

// refreshAfterWrite: background refresh starts after 3min
// expireAfterWrite: forced expiry after 5min (safety net)
manager.registerCustomCache("searchResults",
    Caffeine.newBuilder()
        .maximumSize(10_000)
        .refreshAfterWrite(Duration.ofMinutes(3))   // async refresh after 3min
        .expireAfterWrite(Duration.ofMinutes(5))     // forced expiry after 5min
        .recordStats()
        .buildAsync(key -> loadFromLucene(key))      // async loader
        .synchronous());

However, with @Cacheable + CaffeineCacheManager, a CacheLoader must be registered separately instead of buildAsync. This increases complexity:

Practical choice: In a single-server environment, Stampede impact is limited.
Configure only expireAfterWrite TTL, and add refreshAfterWrite if actual problems are observed during load testing.

5. Browser Caching (Cache-Control)

In addition to server cache (Caffeine), browser caching reduces network requests altogether.
Even in a single-server environment without CDN, the browser acts as a cache.

Targets

Implementation

// PostController: Autocomplete — 5min browser caching
@GetMapping("/autocomplete")
public ResponseEntity<List<String>> autocomplete(@RequestParam String prefix) {
    List<String> suggestions = postService.autocomplete(prefix);
    return ResponseEntity.ok()
        .cacheControl(CacheControl.maxAge(Duration.ofMinutes(5))
            .staleWhileRevalidate(Duration.ofSeconds(60)))
        .body(suggestions);
}

stale-while-revalidate Behavior

6. Cache Monitoring (Actuator)

After introducing caching, you must continuously measure “is it actually effective?”
If hit rate is below 80%, review TTL, key design, and max size.

Monitoring Metrics

Caffeine recordStats + Actuator Exposure

// recordStats() already configured in CacheConfig
Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(Duration.ofMinutes(5))
    .recordStats()  // Collect stats like hit rate
    .build()

Spring Actuator endpoints:

• /actuator/caches — List of registered caches
• /actuator/metrics/cache.gets — Cache hit/miss counts
• /actuator/metrics/cache.evictions — Eviction counts
• /actuator/metrics/cache.size — Current cache entry count

Grafana Dashboard Integration

Add cache metrics to existing Prometheus + Grafana monitoring:

management:
  metrics:
    tags:
      application: wikiengine
  endpoints:
    web:
      exposure:
        include: caches, metrics, health, prometheus

Adding the ratio of cache_gets_total{result="hit"} / cache_gets_total to a Grafana dashboard enables real-time hit rate monitoring.

Load Test and Results

Measurement Principles

1. Before/After same conditions: Same k6 profile (load), same VU (100), same duration (20min)
2. k6 InfluxDB output: --out influxdb=http://localhost:8086/k6 (Grafana k6 dashboard integration)
3. Grafana time range alignment: Align time ranges when capturing dashboards

Before (No Cache Baseline)

Measurement: 2026-03-14 16:20~16:45 KST
Test environment: ARM 2-core / 12GB RAM — Spring Boot JVM 1GB + MySQL InnoDB BP 2GB
k6 profile: load (100 VU, 20min)

k6 Console Results

k6 run --out influxdb=http://localhost:8086/k6 \
  -e PROFILE=load -e BASE_URL=https://api.studywithtymee.com \
  /home/rocky/k6/baseline-load-test.js

k6 Grafana Dashboard

By Scenario (Grafana):

By Search Frequency (Grafana):

Network Details:

Server Grafana

Spring Boot:

MySQL:

Host:

Previous Post Performance Change — Why It Got 70x Slower

What Changed

Up to the previous phase, only BM25 scoring was used.
Lucene can apply Block-Max WAND optimization with standalone BM25 scoring,
traversing only a portion of the posting list to quickly extract top-k results.

In Search Quality Enhancement, we introduced 3 additional scoring factors to improve search quality:

Why Search Got Slower

High-frequency tokens like “South Korea” match tens to hundreds of thousands of documents.

Previous phase (BM25 only):
  "South Korea" search → posting list traversal + BM25 score only
  → WAND optimization evaluates only a portion → ~25ms

After search quality enhancement (BM25 + FeatureField + RecencyDecay):
  "South Korea" search → posting list traversal + BM25 score
  + viewCount DocValues read (per matching doc)
  + likeCount DocValues read (per matching doc)
  + createdAt DocValues read + decay calculation (per matching doc)
  → WAND optimization limited by composite scoring → ~2,800ms

This is confirmed in smoke testing (5 VU):

At 5 VU, only search got 2.8x slower; all other APIs remained the same.

Why Everything Else Got Slower (100 VU)

Autocomplete/list/detail are unrelated to scoring, yet got 62x/47x/25x slower.
This is not search itself getting slower but a cascade failure due to CPU saturation.

Cause chain:

1. After quality enhancement, search = BM25 + 3 DocValues reads → CPU time per search increases
2. 100 VU concurrent search → 2-core CPU saturated (App CPU 80~100%)
3. CPU queue forms → all requests wait for CPU turns
4. Autocomplete/list/detail also trapped in CPU queue → overall response time explodes
5. HikariCP connection wait (Pending ~50) → DB access also bottlenecked
6. JVM threads 20 → 100+ surge → context switching overhead added

This is the same pattern as the previous phase where deep OFFSET saturated the CPU and collapsed all APIs.
When a single bottleneck (this time search scoring) monopolizes shared resources (CPU), unrelated APIs are cascading delayed.

Why Caching Is the Answer

Caching search results means:

• On cache hit, Lucene search + DocValues reads are entirely skipped
• CPU usage approaches zero → enough headroom to handle 100 VU with 2 cores
• Cascade failure resolved → autocomplete/list/detail return to original speed

Search traffic follows Zipf distribution, so caching only top popular queries can achieve 80%+ hit rate.
80% cache hit rate = 80% reduction in search CPU load = below cascade failure threshold.

Implementation Verification

Code Change Diff

/actuator/caches Response

Note: External (Nginx) path returns 403 Forbidden — verify directly via localhost:8080 on the app server

Cache Hit/Miss Response Time Comparison

Search shows dramatic improvement because Lucene BM25 + 3 DocValues reads are entirely skipped.
Autocomplete shows smaller improvement since Lucene PrefixQuery is already fast, but the cache effect is significant under CPU saturation in load testing.

Cache-Control Header Verification

The autocomplete API response includes Cache-Control: max-age=300, stale-while-revalidate=60 header, allowing the browser to cache for 5 minutes and return the previous response for 60 seconds after expiry while refreshing in the background.

After (Post-Cache Measurement)

After completing the caching implementation, we re-measured under the same conditions as Before.

Measurement: 2026-03-14 19:20~19:40 KST
Test environment: Same as Before (ARM 2-core / 12GB RAM)
k6 profile: load (100 VU, 20min)

K6_INFLUXDB_PUSH_INTERVAL=10s k6 run --out influxdb=http://localhost:8086/k6 \
  -e PROFILE=load -e BASE_URL=https://api.studywithtymee.com \
  /home/rocky/k6/baseline-load-test.js

InfluxDB write load caused k6 Grafana dashboard data loss (InfluxDB 128MB memory limit).
Comparison uses k6 console results + Prometheus-based server Grafana.

k6 Console Results

Server Grafana (After)

Spring Boot:

Caffeine Cache:

MySQL:

Host:

Before vs After Comparison

k6 Key Metrics Comparison

Server Resource Comparison

Why MySQL QPS increased from 150 to 200: Caching resolved CPU contention, increasing total throughput from 29,867 to 41,858 requests (+40%). The absolute number of cache-miss requests + write requests (create/like) increased, so QPS also increased. Per-request DB access decreased due to cache hits, but the overall throughput increase offset this. The cumulative Slow Queries (8.34K → 15.1K) has the same cause.

Cache Effect Summary

Why postDetail hit rate is 40.5%: The k6 load test queries random postIds from 14.77M records, so cache re-hit probability is low. In actual operation, traffic concentrates on popular posts following Zipf distribution, so the hit rate is expected to be much higher.

Cascade Failure Resolution

The cascade failure where CPU saturation from search caused all unrelated APIs (autocomplete, list, detail) to slow down in the Before scenario was completely resolved.

Once cache eliminated search CPU load, autocomplete/list/detail returned to nearly the same speed as smoke testing (5 VU). This is the real effect of caching — not only the directly cached APIs, but by resolving CPU contention, all APIs regained their original performance.

OOM Safety Verification

Caffeine operates within the JVM heap, so if the cache consumes too much heap, the server can die from OOM. Safety was verified with actual measurements during load testing (100 VU, 20min).

The reason searchResults entry count stabilized at ~4,000: With a 5min TTL, only unique queries received within 5 minutes accumulate, and older entries expire naturally. The TTL triggers before reaching maximumSize(10,000), naturally managing memory.

The fact that evictions are occurring in the Evictions graph is evidence that the cache is properly discarding old entries, and since the eviction rate isn’t spiking, maximumSize is appropriately configured.

Evidence: Grafana Caffeine Cache panel + JVM Heap panel

Known Limitations and Caveats

Cache Consistency

Introducing cache can cause data inconsistency between DB and cache. The DB has the latest value but the cache still holds the old value, causing users to see stale data.

For example, if a product price is changed from $100 to $80 and committed to DB, but the cache still holds the old data ($100), users still see $100. If they proceed to checkout and the price differs, user trust is lost.

Cache invalidation is the most troublesome problem in practice. Short TTL means frequent cache misses that don’t reduce DB load; long TTL means users see stale data for extended periods. There’s no perfect answer — the developer must judge the appropriate level based on the nature of the data. This is why domain knowledge is necessary.

Decisions in this project:

• Search results cache (TTL 5min): Previous results may be returned for up to 5 minutes after a post update. Acceptable for community search (even Google search takes time for index updates)
• Post detail cache (immediate invalidation): @CacheEvict immediately removes cache on update/delete. Users must see updated content immediately
• Autocomplete cache (TTL 10min): New posts may not appear in autocomplete for 10 minutes. Autocomplete is a “suggestion,” so immediate reflection isn’t essential

Cache Stampede

When TTL expires simultaneously, massive requests flood the DB. (Detailed explanation in Section 4 above)

Local Cache and OOM (Out of Memory)

Caffeine is a local cache operating within JVM heap memory. If cache entries consume too much heap, GC pressure increases, and in the worst case, the server dies from OOM. Unlike Redis (external process), the app and cache share the same memory, so as cache grows, the app’s available memory shrinks.

Defenses in this project:

Without maximumSize, popular search terms would accumulate and consume the heap. Search result cache stores Page<Post> objects (entity lists) entirely, so per-entry size is large. Caffeine’s W-TinyLFU eviction policy removes the lowest-value entries when maximumSize is exceeded.

In monitoring, cache_size (current entry count) and cache_evictions_total (eviction count) should be observed together. Frequent evictions mean maximumSize is too small; if cache_size is far below maximumSize, memory is being wasted.

Cold Start

When the server restarts, Caffeine cache is empty, so all requests hit the DB directly. Deploying during high-traffic periods can cause a temporary DB load spike.

Mitigation strategies:

• Warm-up script to pre-fill cache with popular search terms after deployment
• Blue-Green deployment for gradual traffic shifting

Items Reviewed But Not Applied

References

• Caffeine GitHub Wiki
• Baeldung — Spring Boot Caffeine Caching
• NaverPay — Do You Know the Taste of Caffeine?
• KakaoPay — Using Local Cache in Distributed Systems
• Olive Young — Optimizing Large-Scale Promotions with Local Cache and Redis
• Channel.io — Distributed Cache Introduction: Reducing RDB Queries by 90%
• AWS — Database Caching Strategies Using Redis
• AWS Database Blog — RDS + ElastiCache Benchmark
• Redis — Why Your Cache Hit Ratio Strategy Needs an Update
• Kakao Tech — Evolution of KakaoTalk Caching System
• Redis Customer Case Study — Kicker