이전 포스트
✅ 내가 캐싱을 적용할 곳
나는 마이페이지와 게시글에 캐싱을 적용할 생각이다. 이유는 다음과 같다.
📒 마이페이지
마이페이지 조회가 빈번하게 일어난다.
내가 개발하고 있는 서비스(운동 기록 플랫폼)의 특성 상, 마이 페이지에 캘린더 렌더링 형태로 운동 기록이 존재하며, 운동 기록 조회가 자주 일어난다.
하지만, 수정은 자주 일어나지 않는다.
대부분의 사람은 하루에 한 번 운동을 한다. 따라서 일반적으로 수정(update)이 발생하는 횟수는 1일 1회이거나 운동을 하지 않는 날에는 수정이 발생하지 않는다.
📒 게시글
게시글도 마찬가지다. 한 번 작성한 게시글은 수정하는 일이 잘 없는 반면, 조회는 빈번하게 일어난다.
따라서, 위의 경우에 캐싱으로 성능 향상을 가져올 수 있다.
♻️ Spring에서의 캐시 적용
스프링에서는 캐시 추상화를 지원해준다. 따라서 복잡한 로직 없이 편리하게 캐싱을 적용할 수 있다.
@EnableCaching
@EnableCaching을 사용하면 캐싱 기능을 활성화시킬 수 있다. 이렇게 하면, CachManager Bean을 호출하여 Cache 어노테이션이 붙은 Bean들을 스프링이 관리해준다.
@EnableCaching
@SpringBootApplication
public class FlyAwayApplication {
public static void main(String[] args) {
SpringApplication.run(FlyAwayApplication.class, args);
}
}CacheManager Bean 등록
CacheManager를 통해 TTL, CacheName 설정, 캐싱 전략 등을 세울 수 있다.
여기에서 삽질한 부분이 있는데, 다음 글에서 확인할 수 있습니다.
Spring Redis 역직렬화 삽질기
캐싱할 데이터 지정
@Cacheable: 캐시가 존재할 경우 캐시 데이터 반환, 없으면 DB 조회 후 등록한다.
아래와 같이 cachNames와 key를 지정하면, redis key가cacheNames::key형식으로 저장된다.
그리고 다음과 같이 @CacheEvict를 통해 update가 생길 경우 캐시를 삭제하도록 한다.
캐시 적용 후 쿼리 확인
먼저 최초 마이페이지 조회 시, 다음과 같이 profile 타입의 key가 redis에 잘 저장된다.
그리고 캐시를 적용하기 전에는 회원 정보 호출 시 쿼리가 나갔지만, 이후에는 TTL이 만료되기 전까지 DB(disk)에 접근하지 않는 걸 확인할 수 있다.
캐시 적용 전
캐시 적용 후
📊 캐시 적용 전/후 성능 비교
이번엔 실제 운영환경에서 얼만큼 차이가 나는지 확인해보자.
나는 nGrinder로 성능 테스트를 진행했으며, 여러 테스트 지표 중 TPS를 통해 성능을 비교해보자.
TPS란?
초당 트랜잭션 개수로써, 시스템 성능을 확인할 수 있는 대표적인 지표이다.
캐시 적용 전 TPS
캐시 적용 전에도 TPS는 지속적으로 증가하지만, 평균 220을 기록했다.
캐시 적용 후 TPS
캐시 적용 후, 눈에 띄게 TPS가 상승한 것을 확인할 수 있다. 평균 1000 TPS를 기록했으며, 약 5배의 성능 개선이다.
물론 복잡한 시나리오가 아닌 비교적 단순한 조회 성능 테스트이지만, 동일한 조건에서 진행했기 때문에 확실히 의미있는 수치이다.
Reference
https://medium.com/javarevisited/spring-caching-with-redis-dc1e3bdcc552
다음 포스트
