Spring Cacheable의 동작 원리

Cacheable 이란

Spring에서는 간단하게 어노테이션을 기반으로 캐싱 전략을 사용할 수 있는 기능을 제공한다.

각 캐시 벤더사에서 제공하는 CacheManager를 빈으로 등록하고 원하는 메서드에 어노테이션을 달면 다양한 캐시 저장소를 동일한 인터페이스를 통해 사용할 수 있다.

간단한 사용 방법

Redis를 사용하는 간단한 사용 방법을 소개한다. 먼저, Spring Data Redis에 대한 의존성을 추가한다.

implementation 'org.springframework.boot:spring-boot-starter-data-redis'

 

그리고 아래와 같이 Configuration에 Redis와 연결을 위한 RedisConnectionFactory와 RedisCacheManager의 빈을 등록한다.

@Configuration
@EnableCaching
public class CacheConfig {
  @Value("${spring.data.redis.host}")
  private String host;

  @Value("${spring.data.redis.port}")
  private int port;
  
  @Bean
  public RedisConnectionFactory redisConnectionFactory() {
    return new LettuceConnectionFactory(new RedisStandaloneConfiguration(host, port),
        LettuceClientConfiguration.builder()
            .commandTimeout(Duration.ofSeconds(10))
            .shutdownTimeout(Duration.ofSeconds(30))
            .build());
  }
  
  @Bean
  public RedisCacheManager redisCacheManager(RedisConnectionFactory redisConnectionFactory) {

    RedisCacheConfiguration redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig()
        .serializeKeysWith(RedisSerializationContext.SerializationPair
            .fromSerializer(new StringRedisSerializer()))
        .serializeValuesWith(RedisSerializationContext.SerializationPair
            .fromSerializer(new JdkSerializationRedisSerializer()));

    return RedisCacheManager.RedisCacheManagerBuilder.fromConnectionFactory(redisConnectionFactory)
        .withCacheConfiguration("postByAuthor",
            redisCacheConfiguration.entryTtl(Duration.ofSeconds((long) 60 * 60 * 24)))
        .build();
  }
}

 

캐싱을 적용하고자 하는 메서드에 @Cacheable 어노테이션을 붙이면 캐시 저장소에 데이터가 있다면 가져와 반환하고, 만약 캐시 저장소에 데이터가 없다면 메서드 원본 로직을 수행한 후 결과값을 캐시에 저장하고 반환하게 될 것이다.

  @Cacheable(cacheManager = "redisCacheManager", cacheNames = "postByAuthor")
  public List<Post> getPostsByAuthor(Long authorId) {
    List<Post> list = postJpaRepository.findAllByAuthorId(authorId);
    return list.isEmpty() ? null : list;
  }

제공하는 어노테이션

스프링 프레임워크에서는 기본적으로 아래와 같은 다양한 어노테이션을 제공한다.

@EnableCaching

• Spring Cache의 어노테이션을 사용하기 위해서 설정 클래스에 이 어노테이션을 달아주어야 한다.
• 이 어노테이션을 달 때 CacheManager 빈을 함께 등록해주면 된다.
  • 외부 캐시 서버를 사용하거나 여러 개의 캐시 저장소를 사용하는 등의 추가 커스터마이징을 진행할 경우 설정 클래스에 cacheManager 빈을 등록해야 한다.
  • 따로 cacheManager를 빈을 등록하지 않으면 ConcurrentHashMap 기반 로컬 캐시 저장소를 사용하게 된다.

@Cacheable

• 메서드의 반환값을 캐시 아이템에 저장한다.
• 캐시에 데이터가 존재하면, 캐시의 데이터를 반환한다. 만약 캐시에 데이터가 없으면, 메서드 로직 수행 후 반환값을 캐시에 추가한다.

🚨 주의

• key, keyGenerator 는 함께 쓰일 수 없다.
• cacheManager, cacheResolver는 함께 쓰일 수 없다.

Attribute Description

cacheNames	캐시 이름
value	cacheNames의 Alias
key	SpEL 표현식을 작성해 캐시 키를 동적 생성하도록 한다.
keyGenerator	사용할 KeyGenerator를 지정할 수 있다.
condition	SpEL 표현식으로 조건을 작성하여 true일 경우에만 캐싱이 적용되도록 한다.
unless	SpEL 표현식으로 조건을 작성하여 true일 경우에 캐싱이 적용되지 않도록 한다.
cacheManager	사용할 CacheManager를 지정할 수 있다.
cacheResolver	사용할 CacheResolver를 지정할 수 있다.
sync	여러 스레드가 동일한 키에 대한 값을 로드하려고 할 경우, 기본 메서드의 호출을 동기화

@CacheEvict

• 오래되거나 사용하지 않는 데이터를 제거할 때, 데이터가 변경될 때 캐시 아이템을 제거하기 위해 활용한다.
• 메서드가 트리거로 동작하므로 반환 값이 무시되어 void 메서드에도 사용할 수 있다.

Attribute Description

cacheNames	캐시 이름
value	cacheNames의 Alias
key	SpEL 표현식을 작성해 캐시 키를 동적 생성하도록 한다.
condition	SpEL 표현식으로 조건을 작성하여 true일 경우에만 캐싱이 적용되도록 한다.
unless	SpEL 표현식으로 조건을 작성하여 true일 경우에 캐싱이 적용되지 않도록 한다.
cacheManager	사용할 CacheManager를 지정할 수 있다.
cacheResolver	사용할 CacheResolver를 지정할 수 있다.
allEntries	캐시에 저장된 값을 모두 제거할지에 대한 여부
beforeInvocation	메서드 수행 전 캐시 데이터 제거를 수행할 지에 대한 여부

@CachePut

• 캐시에 값을 저장하는 용도로만 사용되며, 항상 메서드 로직을 수행하고 캐시 아이템을 저장한다.

Attribute Description

cacheNames	캐시 이름
value	cacheNames의 Alias
key	SpEL 표현식을 작성해 캐시 키를 동적 생성하도록 한다.
condition	SpEL 표현식으로 조건을 작성하여 true일 경우에만 캐싱이 적용되도록 한다.
unless	SpEL 표현식으로 조건을 작성하여 true일 경우에 캐싱이 적용되지 않도록 한다.
cacheManager	사용할 CacheManager를 지정할 수 있다.
cacheResolver	사용할 CacheResolver를 지정할 수 있다.

@Caching

• 동일한 캐시 어노테이션을 여러 개 선언하고 싶은 경우 사용한다.
• 조건이나 키 표현 방식에 따라 여러 동작을 수행해야 하는 경우 유용하다.

Attribute Description

cacheable	여러 개의 Cacheable 어노테이션 입력
evict	여러 개의 CacheEvict 어노테이션 입력
put	여러 개의 CachePut 어노테이션 입력

@CacheConfig

• 클래스 수준의 어노테이션으로 cacheNames, KeyGenerator 등을 설정하여 공유할 수 있도록 한다.
• 클래스 내부 캐시 연산 시 이 설정값을 기본으로 가지게 된다.
• 메서드 레벨에서 재정의하면 덮어쓰여진다.

Attribute Description

cacheNames	캐시 이름
keyGenerator	사용할 KeyGenerator를 지정할 수 있다.
cacheManager	사용할 CacheManager를 지정할 수 있다.
cacheResolver	사용할 CacheResolver를 지정할 수 있다.

 

내부 동작 원리

전체적인 동작을 그림으로 나타내면 아래와 같다. AOP에 의해 Cacheable이 달린 클래스는 프록시 클래스가 되고, 이 클래스에 의해 CacheInterceptor의 invoke 메서드가 호출된다. 이 메서드 내부에서 실제 Cache Server에 요청을 보내기 위한 다양한 클래스의 메서드가 호출될 것이다.

Configuration으로 필요한 빈 등록

@EnableCaching 어노테이션을 붙이면 CachingConfigurationSelector 클래스를 통해 Configuration이 등록된다. 이 때 @EnableCaching 에서 설정한 AdviceMode에 따라 PROXY, ASPECTJ 중 하나로 동작하기 위해 각각 Configuration 목록이 제공된다.

 

@EnableCaching 에서는 Spring AOP에서 기본적으로 사용하는 PROXY 방식을 기본으로 사용하지만 ASPECTJ 방식이 필요한 경우가 간간히 존재한다. 예를 들자면, Spring AOP는 프록시 클래스를 기반으로 동작하는데 같은 클래스의 메서드를 내부적으로 호출할 경우 프록시 클래스를 거치지 않기 때문에 AOP 로직이 적용되지 않는다. ASPECTJ 방식을 사용하면 weaving 방식으로 클래스파일(.class) 자체에 AOP 로직을 적용하므로 이러한 문제가 발생하지 않는다. weaving 방식에는 수행 시점에 따라 compile-time, post-compile, load-time로 나뉜다. 보통 post-compile 방식은 서드파티 라이브러리에 weaving하기 위해 사용되므로, 내부 호출 문제 해결을 위해서는 나머지 두 방식이 사용된다. 만약 compile-time에 weaving이 되도록 하려면 gradle, maven에서 AspectJ를 지원하는 모듈을 임포트하고 AdviceMode를 ASPECJ로 설정하면 된다. 혹은 load-time에 weaving이 되도록 하려면 AspectJ agent를 실행 옵션으로 등록하고 @EnableLoadTimeWeaving 어노테이션을 붙이면 된다.

 

PROXY 방식을 사용하면 등록되는 ProxyCachingConfiguration 클래스의 내부에서는 아래와 같이 세가지 빈을 등록한다.

• BeanFactoryCacheOperationSourceAdvisor
  • Spring Cache에서 AOP로 동작하기 위해 포인트컷과 어드바이스를 등록하는 어드바이저이다.
  • @EnableCaching 에서 설정한 여러 개의 어드바이스가 특정 조인 포인트에 적용될 경우 어떤 순서로 적용해야 할 지 지정하는 order 속성을 advisor 등록 시에 사용한다.
• AnnotationCacheOperationSource
  • 포인트컷으로 등록되는 CacheOperationSourcePointcut 클래스에서 Spring Cache 어노테이션이 붙어있는지 검사하기 위해 내부적으로 가지는 클래스이다.
  • SpringCacheAnnotationParser를 통해 어노테이션을 검사하여 AOP 적용 대상인지 확인한다.
  • 접근 제어자에 관계없이 모두 탐색한다.
• CacheInterceptor
  • 포인트컷에 적용될 invoke 메서드를 정의한다.
  • 실질적인 로직이 작성된 CacheAspectSupport 를 상속받기 때문에, 구체적인 로직은 상위 클래스인 CacheAspectSupport 클래스에게 넘겨 처리한다.

ProxyCachingConfiguration 내부에서 빈을 등록하는 코드는 아래와 같이 작성되어 있다.

@Bean(
  name = {"org.springframework.cache.config.internalCacheAdvisor"}
)
@Role(2)
public BeanFactoryCacheOperationSourceAdvisor cacheAdvisor(CacheOperationSource cacheOperationSource, CacheInterceptor cacheInterceptor) {
  BeanFactoryCacheOperationSourceAdvisor advisor = new BeanFactoryCacheOperationSourceAdvisor();
  advisor.setCacheOperationSource(cacheOperationSource);
  advisor.setAdvice(cacheInterceptor);
  if (this.enableCaching != null) {
    advisor.setOrder((Integer)this.enableCaching.getNumber("order"));
  }
  return advisor;
}

@Bean
@Role(2)
public CacheOperationSource cacheOperationSource() {
  return new AnnotationCacheOperationSource(false);
}

@Bean
@Role(2)
public CacheInterceptor cacheInterceptor(CacheOperationSource cacheOperationSource) {
  CacheInterceptor interceptor = new CacheInterceptor();
	interceptor.configure(this.errorHandler, this.keyGenerator, this.cacheResolver, this.cacheManager);
  interceptor.setCacheOperationSource(cacheOperationSource);
  return interceptor;
}

어노테이션 동작 흐름

Spring Cache 어노테이션이 달린 메서드가 호출되면, Spring AOP에 의해 프록시 클래스에서 CacheInterceptor#invoke를 호출하게 된다. CacheInterceptor는 캐싱 로직을 담당하는 CacheAspectSupport#execute 를 호출하여 다음과 같은 순서로 어노테이션을 처리한다.

1. CacheEvict(beforeInvoaction = true)
2. Cacheable (get)
3. 원본 메서드 invoke
4. Cacheable (save) / CachePut
5. CacheEvict(beforeInvoaction = false)

아래는 CacheAspectSupport의 코드로, 1~5의 과정이 실제로 어떻게 수행되는지 확인할 수 있다.

@Nullable
private Object execute(CacheOperationInvoker invoker, Method method, CacheOperationContexts contexts) {
    if (contexts.isSynchronized()) {
        // Special handling of synchronized invocation
        return executeSynchronized(invoker, method, contexts);
    }

    // 1) beforeInvocation이 true인 Evict 연산 수행
    // Process any early evictions
    processCacheEvicts(contexts.get(CacheEvictOperation.class), true,
            CacheOperationExpressionEvaluator.NO_RESULT);

    // Check if we have a cached value matching the conditions
    // 2) Cacheable에 의한 캐시 조회 연산 수행
    Object cacheHit = findCachedValue(invoker, method, contexts);
    if (cacheHit == null || cacheHit instanceof Cache.ValueWrapper) {
        // 3 ~ 5) 나머지 작업은 아래 메서드 내부에서 수행
        return evaluate(cacheHit, invoker, method, contexts);
    }
    return cacheHit;
}

// ...

@Nullable
private Object evaluate(@Nullable Object cacheHit, CacheOperationInvoker invoker, Method method,
        CacheOperationContexts contexts) {

    // Re-invocation in reactive pipeline after late cache hit determination?
    if (contexts.processed) {
        return cacheHit;
    }

    Object cacheValue;
    Object returnValue;

    if (cacheHit != null && !hasCachePut(contexts)) {
        // If there are no put requests, just use the cache hit
        cacheValue = unwrapCacheValue(cacheHit);
        returnValue = wrapCacheValue(method, cacheValue);
    }
    else {
    	// 3) 원본 메서드 수행
        // Invoke the method if we don't have a cache hit
        returnValue = invokeOperation(invoker);
        cacheValue = unwrapReturnValue(returnValue);
    }

    // Collect puts from any @Cacheable miss, if no cached value is found
    List<CachePutRequest> cachePutRequests = new ArrayList<>(1);
    if (cacheHit == null) {
        collectPutRequests(contexts.get(CacheableOperation.class), cacheValue, cachePutRequests);
    }

    // Collect any explicit @CachePuts
    collectPutRequests(contexts.get(CachePutOperation.class), cacheValue, cachePutRequests);

    // Process any collected put requests, either from @CachePut or a @Cacheable miss
    for (CachePutRequest cachePutRequest : cachePutRequests) {
        // 4) Cacheable에서 캐시 조회에 실패했거나 CachePut 어노테이션에 의한 캐시 저장 연산 수행
        Object returnOverride = cachePutRequest.apply(cacheValue);
        if (returnOverride != null) {
            returnValue = returnOverride;
        }
    }

    // Process any late evictions
    // 5) beforeInvocation이 false인 Evict 연산 수행
    Object returnOverride = processCacheEvicts(
            contexts.get(CacheEvictOperation.class), false, returnValue);
    if (returnOverride != null) {
        returnValue = returnOverride;
    }

    // Mark as processed for re-invocation after late cache hit determination
    contexts.processed = true;

    return returnValue;
}

캐시 요청

그렇다면 어노테이션을 통해 실제 캐시에 어떻게 요청이 들어갈까? 실제 캐시 요청을 보내는 로직은 Cache 인터페이스의 구현체에 작성되어 있다.

Redis의 경우에도 Cache 인터페이스의 구현체인 RedisCache 클래스를 제공한다. 간단하게 put 메서드만 살펴보면, Spring Data Redis 내부적으로 캐시에 요청을 보내는 CacheWriter의 메서드를 호출함을 확인할 수 있다. 결국 Redis에 TCP 요청으로 set 명령을 보내는 작업이 수행된다.

public class RedisCache extends AbstractValueAdaptingCache {
	// ...
	@Override
	public void put(Object key, @Nullable Object value) {

		Object cacheValue = processAndCheckValue(value);

		byte[] binaryKey = createAndConvertCacheKey(key);
		byte[] binaryValue = serializeCacheValue(cacheValue);

		Duration timeToLive = getTimeToLive(key, value);
		// CacheWriter를 통해 Redis에 삽입 요청을 보낸다.
		getCacheWriter().put(getName(), binaryKey, binaryValue, timeToLive);
	}
	// ...
}

 

 

실제 캐시 저장소에 요청을 보내는 Cache 구현체의 메서드는 CacheAspectSupport가 내부적으로 호출해야 할 것이다. 아래는 findCachedValue 메서드 내부적으로 호출되는 findInCaches라는 내부 메서드로, AbstractCacheInvoker의 doRetrieve 메서드 혹은 doGet 메서드를 호출하고 있다.  Cache 구현체의 메서드는 AbstractCacheInvoker의 doGet, doRetrieve, doPut, doClear 같은 메서드들에서 호출된다.

public abstract class CacheAspectSupport extends AbstractCacheInvoker
		implements BeanFactoryAware, InitializingBean, SmartInitializingSingleton {
    
	// ...

	private Object findInCaches(CacheOperationContext context, Object key,
			CacheOperationInvoker invoker, Method method, CacheOperationContexts contexts) {

		for (Cache cache : context.getCaches()) {
			if (CompletableFuture.class.isAssignableFrom(context.getMethod().getReturnType())) {
				CompletableFuture<?> result = doRetrieve(cache, key);
				if (result != null) {
					return result.exceptionally(ex -> {
						getErrorHandler().handleCacheGetError((RuntimeException) ex, cache, key);
						return null;
					}).thenCompose(value -> (CompletableFuture<?>) evaluate(
							(value != null ? CompletableFuture.completedFuture(unwrapCacheValue(value)) : null),
							invoker, method, contexts));
				}
				else {
					continue;
				}
			}
			if (this.reactiveCachingHandler != null) {
				Object returnValue = this.reactiveCachingHandler.findInCaches(
						context, cache, key, invoker, method, contexts);
				if (returnValue != ReactiveCachingHandler.NOT_HANDLED) {
					return returnValue;
				}
			}
			// 가장 기본적인 동기 방식의 메서드가 호출된다.
			Cache.ValueWrapper result = doGet(cache, key);
			if (result != null) {
				return result;
			}
		}
		return null;
	}
    
	// ...
}

 

public abstract class AbstractCacheInvoker {
	// ...
	@Nullable
	protected <T> T doGet(Cache cache, Object key, Callable<T> valueLoader) {
		try {
			// Cache 구현체의 메서드 호출
			return cache.get(key, valueLoader);
		}
		catch (Cache.ValueRetrievalException ex) {
			throw ex;
		}
		catch (RuntimeException ex) {
			getErrorHandler().handleCacheGetError(ex, cache, key);
			try {
				return valueLoader.call();
			}
			catch (Exception ex2) {
				throw new RuntimeException(ex2);
			}
		}
	}
	// doPut, doClear 등의 메서드가 존재한다...
}

 

마무리

지금까지 Spring Cacheable의 내부 동작 원리에 대해 살펴보았다. Spring AOP를 기반으로 동작하기 때문에 내부적으로 어떻게 동작하는지 모른다면 디버깅할 때 헤맬 수 있다. 비록 간단한 연산만 가능하지만 이렇게 추상화되어 있는 어노테이션 덕분에 캐시 솔루션을 교체할 때 캐시 적용 코드를 하나하나 변경하지 않고 빈 설정만 변경하여 쉽게 교체할 수 있다.