프로젝트에 스프링 캐시를 도입하는 과정에서 어떤 방식으로 내부 구현이 되어 있는지 궁금해졌습니다. @Cacheable 어노테이션을 사용해서 캐시 조회 기능을 사용했을때 어떻게 동작하는지 위주로 분석해보겠습니다.캐시 호출 시 가장 먼저 동작하는 클래스는 CacheAspectSupport이다. 해당 클래스는 AOP를 사용해 스프링 캐시의 구체 기술을 쉽게 적용할 수 있도록 도와주는 역할을 수행한다. 해당 클래스 내의 execute() 메서드가 호출되면 findCacheValue()라는 내부 메서드가 호출되서 캐시값을 가져온다. findCacheValue() 메서드를 좀 더 자세히 살펴보자.  findCachedValue() 메서드 내부에 findInCaches()라는 메서드가 하나 더 있는걸 볼 수 있다. ..

서비스의 사용자가 늘어나면 트래픽의 총량이 늘어나고 DB에 저장되는 데이터의 양도 늘어납니다. 개발자 입장에서는 서비스가 잘 운영된다는 지표이므로 기쁜 일이지만, 그동안 발견하지 못했던 성능 문제들이 하나씩 발견되기도 합니다. 조회 성능을 향상시키는 방법에는 여러가지가 있습니다. 비효율적인 쿼리 개선, JPA 사용시 N+1문제 해결 그리고 인덱스 적용을 통해서도 조회 성능을 비약적으로 향상시킬 수 있습니다. 하지만 성능 문제가 발생하는 API의 특성에 따라서는 캐시라는 수단을 사용할 수도 있습니다. 이번 글에서는 서비스의 성능 문제를 해결하기 위해 캐시를 도입하고 부하 테스트를 통해 성능 개선의 정량적 지표를 도출한 과정을 공유하고자 합니다.성능 개선이 필요한 부분현재 개선 중인 프로젝트는 사용자가 장소..

Melly 서비스는 Redis 기반의 분산 캐시를 적용해 조회 성능을 최적화했습니다. 하지만 기존의 캐시 로직은 Standalone의 캐시 서버가 죽지 않는다는 이상적인 가정 하에서 잘 동작하는 시스템이었습니다. 이번 글에서는 Circuit Breaker와 Spring Actuator health check 설정을 통해 분산 서버 환경에서 가용성 있는 캐시 서버를 나름대로 구축해본 기록을 공유하고자 합니다.초기 문제 상황스프링은 @Cacheable 어노테이션을 사용해서 간편하게 캐시 기능을 사용할 수 있습니다. @Cacheable는 먼저 캐시를 조회한 뒤 데이터가 없다면 DB를 조회하는 Cache Aside 전략을 사용합니다. 하지만 만약 분산 캐시 서버가 장애로 인해 죽는다면 어떻게 동작할까요?  간단..