지역 전체 조회 로컬 캐시 적용

[Combi153]

지역 전체 조회 api 요청 시 3518 개의 행정구역에 대한 Area 데이터가 반환됩니다.

Area 데이터는 다음과 같은 특징을 갖습니다.

• 데이터의 변화 주기가 길다. 즉, 한번 저장하면 변화할 가능성이 적다.
• 여러 사용자가 동일한 데이터를 조회할 일이 빈번하다.

따라서 캐시를 적용하려고 합니다.

Local Cache vs Global Cache

Caching 은 Local Cache 와 Global Cache로 나뉩니다.

두 Cache 방법은 아래와 같은 특징을 갖습니다.

Local Cache

• WAS의 메모리에 데이터를 저장한다.
• 별도의 infrastructure 가 필요하지 않다.
• 서버를 scale out 할 경우, 서버마다 캐싱된 데이터가 달라질 수 있다.
• 캐싱 데이터가 크다면 메모리 사용량이 많아진다.

Global Cache

• Redis 등을 활용한 방법이다.
• WAS를 scale out 하더라도, 캐싱 데이터가 동일하다. 즉 확장에 유리하다.
• 별도의 infrastructure가 필요하다.
• 네트워크 비용이 발생하기 때문에 LocalCache 보다 느리다.

지역 조회 API 를 위해 infra를 새로 구축하는 것은 과도합니다. 따라서 Local Cache를 적용하고자 했습니다.

Local Cache 방법

Spring의 Cache Abstraction

Spring의 공식문서를 살펴보면, Spring은 개발자가 특정 기술에 종속되지 않고 캐시를 구현할 수 있도록 추상화된 인터페이스 등을 제공합니다.

implementation 'org.springframework.boot:spring-boot-starter-cache'

spring-boot-starter-cache 의존성을 추가해서 사용하면 됩니다!

EhCache vs Caffeine

여러 캐시 라이브러리 중 EhCache 와 Caffeine를 살펴보았습니다.

EhCache 는 오랜 기간 많은 사람들에게 사용된 강자이고, Caffeine은 새롭게 떠오른 강자입니다.

이중 Caffeine을 선택했습니다.

이유는 다음과 같습니다.

• EhCache에 비해 Caffeine이 적용하기 편하다.
• EhCache는 xml 파일을 사용해, 불편하다.
• Caffeine의 성능이 더 우수하다. (참고)[https://github.com/ben-manes/caffeine/wiki/Benchmarks]

Caffeine Cache 적용

Caffeine을 사용하기 위해 의존성을 추가합니다.

implementation 'com.github.ben-manes.caffeine:caffeine'

@configuration 을 통해 CaffeineCache를 포함한 CacheManager를 Bean 으로 등록합니다.

AreaService 에서 readAll 메서드를 실행 시 데이터를 캐시합니다.(@Cacheable)

만약 새로운 Area 데이터가 생성될 경우 캐시를 삭제합니다.(@CacheEvict)

적용 후

기존에 조회 요청 처리 시간은 100 ~ 120ms 걸렸습니다.
캐싱 이후 14 ~ 18ms 로 단축 되었습니다!

[greeng00se]

하루만에 잘 알아보고 정리해주셨군요 👍 블로깅 기대해도 될까요?