티스토리 뷰
회사에서 캐시 구조에 대해서 리팩토링을 진행하는 과정에서 EhCache Self-Invocation 문제로 인해 캐시가 정상적으로 동작하지 않았던 사례에 대해서 포스팅하려고 한다.
이 문제가 무엇인지 예제를 통해서 간단하게 살펴보려고 한다.
@Cacheable(value = "testCache")
public String cache() {
log.error("[Info] Create Data!!!");
return "hello, ch4njun";
}
public String test() {
log.error("[Info] test call!");
return cache();
}
위와 같은 구성이 있을 때 test() 의 내부에서 @Cacheable 어노테이션이 붙어있는 cache() 메서드를 호출한다. 그리고 이 test() 메서드와 cache() 메서드가 동일한 클래스에 있다면 이러한 구성을 Self-Invocation 이라고 한다.
이 경우 @Cacheable 어노테이션이 제대로 동작하지 않고 결과적으로 캐시가 되지 않는 문제가 발생한다.
그럼 왜 이런 문제가 발생할까?
바로 @Cacheable 어노테이션이 Spring AOP 를 기반으로 동작하기 때문이다. 즉, Self-Invocation 문제는 @Cacheable 어노테이션 자체의 문제가 아니라 Spring AOP 문제라는 것이다.
그렇기 때문에 Spring AOP 를 기반으로 하는 다른 모든 기능들에서도 이와같은 문제가 발생할 수 있다.
Spring AOP 에서 Self-Invocation 문제가 발생하는 이유에 대해서 살펴보자.
출처 : https://gmoon92.github.io/spring/aop/2019/04/01/spring-aop-mechanism-with-self-invocation.html
Self Invocation은 왜 발생할까?
Moon
gmoon92.github.io
Spring AOP 는 인터페이스 구현 여부에 따라서 JDK Dynamic Proxy 와 CGLIB 을 사용해 AOP 를 적용한다. (Spring Boot 에서는 기본적으로 모든 상황에서 CGLIB 을 사용한다)
이렇게 프록시 객체가 생성되면 외부 호출이 발생했을 때 기존 객체 대신 프록시 객체가 해당 호출을 받게된다.
프록시 객체가 해당 메서드 앞뒤에 부가적인 기능(횡단 관심사)를 실행한 후 기존 객체의 메서드를 호출하게 되는 매커니즘으로 동작하게 되는데, 이때 이미 기존객체로 들어와서 거기서 내부 호출이 발생하는 부분에 대해서는 프록시 객체를 거치지 않게된다.
결과적으로 Self-Invocation 으로 호출된 메서드는 AOP 가 정상적으로 적용되지 않는 것이다.
해결방안
1. AopContext
@Cacheable(value = "testCache")
public String cache() {
log.error("[Info] Create Data!!!");
return "hello, ch4njun";
}
public String test() {
log.error("[Info] test call!");
// 호출된 Proxy 객체를 활용
return ((AspectTestService) AopContext.currentProxy()).cache();
}
AopContext.currentProxy() 메서드는 현재 Proxy 객체를 반환해주는데 이를 통해 내부 메서드를 호출한다면 Self-Invocation 문제를 해결할 수 있다.
그러면 this.cache() 가 아니라 ${ ProxyObject }.cache() 가 호출되고 AOP가 정상적으로 적용된다.
주의해야할 점은 AopContext.currentProxy() 메서드를 사용하기 위해선 expose-proxy 옵션을 활성화해줘야 한다는 것이다. Spring Boot 에서는 @EnableAspectJAutoProxy(exposeProxy = true) 를 통해 해당 옵션을 활성화할 수 있다.
2. IoC 컨테이너의 Bean 활용
IoC 컨테이너에 등록된 자기 자신의 Bean 을 활용해 해결하는 방법이다.
// 자기 자신의 Bean 을 주입받는다.
@Resource(name="aspectTestService")
AspectTestService self;
@Cacheable(value = "testCache")
public String cache() {
log.error("[Info] Create Data!!!");
return "hello, ch4njun";
}
public String test() {
log.error("[Info] test call!");
// DI 된 자기자신의 Bean 을 사용한 내부호출
return self.cache();
}
@Resource 이외에도 @Autowired, @Inject 와 같은 방법으로 자기자신의 Bean 을 주입받을 수 있다.
3. AspectJ Weaving
마지막으로 Spring AOP 의 Weaving 방식을 AspectJ Weaving 방식으로 변경하는 것이다. 이 방법이 Spring 에서 권장하는 해결방법이다.
AspectJ Weaving 방식은 Spring AOP 와 달리 바이트 코드를 직접 조작하는 방식이기 때문에 Proxy 객체로 인한 Self-Invocation 문제가 발생하지 않는다.
이러한 문제를 해결하기 위해 나는 애초에 내부호출이 발생하지 않는 구조로 리팩토링 하는 방법을 선택했다. 때마침 공통코드가 존재했고 해당 공통코드를 Provider 로 분리하면서 자연스럽게 내부호출이 발생하지 않도록 수정한 것이다.
그 후 nGrinder 라는 오픈소스 성능테스트 도구를 통해 테스트한 결과 약 20~30%의 성능 향상을 확인할 수 있었다.
https://ch4njun.tistory.com/266
[Concept] API 성능테스트 (feat. nGrinder 를 이용한 성능 테스트)
성능테스트란? 쉽게 말하면 내가 만든 웹 서버(API)가 얼마나 많은 사용자들을 감당할 수 있는지 테스트하는 것을 말한다. 이외에도 두 가지 설계에 대해서 어떤 설계가 더 좋은 성능을 내는지 확
ch4njun.tistory.com
'Back-End > Spring Boot' 카테고리의 다른 글
[Spring] @Transactional 파보기 (Feat. Transaction Propagation 활용 사례소개) (1) | 2023.01.25 |
---|---|
[WebFlux] SSE 구현 예시 (0) | 2021.12.23 |
Java & Spring 에서 비동기는 어떻게 발전되었을까? (0) | 2021.12.23 |