[Spring Cache] Caffeine 설정과 활용

Caffeine이란

Caffeine은 Java에서 가장 빠른 로컬 캐시 라이브러리다. Google Guava Cache의 후속작으로, 더 높은 적중률과 더 나은 성능을 제공한다. Spring Boot에서 로컬 캐시를 쓴다면 사실상 Caffeine이 표준이다.

왜 Caffeine이 빠른가? 내부적으로 W-TinyLFU라는 제거 알고리즘을 사용한다. 이건 LRU(최근 안 쓴 것 제거)와 LFU(적게 쓴 것 제거)의 장점을 결합한 것으로, 대부분의 워크로드에서 다른 캐시 대비 높은 적중률을 보인다. 별도 튜닝 없이도 좋은 성능을 낸다.

@Cacheable이 호출되면 요청이 어떤 레이어를 거쳐 Caffeine까지 도달하는지 흐름을 보면 이해가 쉽다.

• CacheManager : Spring Cache 추상화의 핵심 인터페이스. @Cacheable이 이걸 통해 캐시에 접근한다.
• SimpleCacheManager : CaffeineCache 목록을 직접 등록해서 관리하는 구현체.
• CaffeineCache : Spring의 Cache 인터페이스를 Caffeine으로 감싼 어댑터.
• Caffeine : 실제 캐시 인스턴스를 빌드하는 빌더. 여기서 TTL, 크기, 통계 등을 설정한다.

의존성 추가

implementation 'org.springframework.boot:spring-boot-starter-cache'
implementation 'com.github.ben-manes.caffeine:caffeine'

• spring-boot-starter-cache : Spring Cache 추상화 (@Cacheable 등)
• caffeine : 실제 캐시 구현체

Spring Boot는 classpath에 Caffeine이 있으면 자동으로 CaffeineCacheManager를 구성한다. 별도 설정 없이도 @Cacheable이 Caffeine 캐시를 사용한다.

application.yml로 설정하기

가장 간단한 설정 방법이다.

spring:
  cache:
    type: caffeine
    cache-names:
      - users
      - channels
      - notifications
    caffeine:
      spec: >
        maximumSize=100,
        expireAfterAccess=600s

spec에서 사용할 수 있는 주요 옵션은 다음과 같다.

두 정책이 캐시 항목의 생명주기에 어떻게 다르게 작용하는지 나란히 놓으면 차이가 명확하다.

• expireAfterWrite : 읽기가 발생해도 타이머는 저장 시점에 고정. 신선도 보장.
• expireAfterAccess : 읽을 때마다 타이머 리셋. 계속 읽히면 영원히 유지될 수 있다.

Java Config로 설정하기

캐시마다 다른 설정을 적용하고 싶으면 Java Config가 필요하다. application.yml의 spec은 모든 캐시에 동일하게 적용되기 때문이다.

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public CacheManager cacheManager() {
        SimpleCacheManager cacheManager = new SimpleCacheManager();
        cacheManager.setCaches(List.of(
            buildCache("users", 200, 600),
            buildCache("channels", 500, 300),
            buildCache("notifications", 100, 60)
        ));
        return cacheManager;
    }

    private CaffeineCache buildCache(String name, int maxSize, int ttlSeconds) {
        return new CaffeineCache(name,
            Caffeine.newBuilder()
                .maximumSize(maxSize)
                .expireAfterWrite(ttlSeconds, TimeUnit.SECONDS)
                .recordStats()
                .build()
        );
    }
}

이제 각 캐시가 독립적인 설정을 가진다.

TTL과 최대 크기 전략

캐시 설정에서 가장 중요한 두 가지 결정은 "얼마나 오래 유지할 것인가(TTL)"와 "몇 개까지 저장할 것인가(maximumSize)"다.

TTL 결정 기준

데이터가 오래돼도 괜찮은 정도로 TTL을 정한다.

• "사용자 목록이 10분 동안 안 바뀌어도 괜찮은가?" → 괜찮다면 TTL 10분
• "알림이 1분 동안 안 바뀌어도 괜찮은가?" → 좀 아쉽지만 허용 가능하면 TTL 1분
• "결제 잔액이 1초라도 틀리면 안 되는가?" → 캐시 X

TTL이 너무 짧으면 캐시의 의미가 없고 (적중률 낮음), 너무 길면 오래된 데이터를 보여줄 위험이 있다.

maximumSize 결정 기준

JVM 힙 메모리와 데이터 크기를 고려한다. List<UserDto> 100개가 각각 1KB면, 캐시 100항목은 ~100KB를 차지한다. JVM 힙이 512MB면 여유가 넉넉하지만, 캐시에 이미지 바이너리 같은 큰 데이터를 넣으면 금방 메모리가 부족해진다.

maximumSize를 초과하면 Caffeine이 W-TinyLFU 알고리즘에 따라 가장 덜 유용한 항목을 자동으로 제거한다. 개발자가 직접 제거 대상을 선정할 필요가 없다.

@CacheEvict 적용 패턴

캐시를 적용했으면, 데이터가 변경되는 모든 곳에 @CacheEvict를 빠짐없이 넣어야 한다. 이 시리즈에서 계속 강조한 점이다.

Discordit 미션을 예로 들면 이렇다.

// 조회 — 캐시 적용
@Cacheable("channels")
public List<ChannelDto> getChannelsByUserId(UUID userId) { ... }

// 변경 — 캐시 무효화
@CacheEvict(value = "channels", allEntries = true)
public ChannelDto createChannel(ChannelCreateRequest request) { ... }

@CacheEvict(value = "channels", allEntries = true)
public ChannelDto updateChannel(UUID channelId, ChannelUpdateRequest request) { ... }

@CacheEvict(value = "channels", allEntries = true)
public void deleteChannel(UUID channelId) { ... }

allEntries = true를 쓰는 이유는, 채널이 추가되면 어떤 사용자의 목록에 영향을 주는지 모르기 때문이다. 특정 키만 삭제하려면 영향을 받는 모든 사용자의 키를 알아야 하는데, 이는 복잡하다. allEntries = true가 더 안전하다.

Q&A