우리는 왜 Caffeine Cache를 사용했을까?

[sangwonsheep]

캐시를 사용하게 된 이유

현재 우리 서비스는 MySQL, MongoDB를 사용 중이다.
MongoDB에 추천용 집계 데이터를 쌓고 있고, 그 외의 데이터는 모두 MySQL에 쌓고 있다.

캐시를 도입하기 전에는 api 모듈에서 랭킹 모듈로 api 요청을 보낸다.
그러면 랭킹 모듈에서는 매 번 MongoDB에서 추천 데이터를 추출하여 api 모듈로 보내준다.

이렇게 요청마다 매 번 DB에서 데이터를 꺼내서 주는 방식은 부하가 커질 수도 있다.
그 전에 가장 중요한 것은 추천 시스템인데 실시간으로 변경되는 것을 보여주는 것은 초기 기획과 맞지 않는다고 판단하였다.
그렇다면, 실시간으로 보여주지 말고 특정 시간마다 업데이트를 하는 방식으로 바꾸어보자.

특정 시간마다 보여주려면 2가지 방식이 떠오른다.
스케줄링 vs 캐싱
스케줄링은 api 요청이 올 때마다 돌리는 것이 아닌 따로 자동으로 시간마다 돌아가는 것이기 때문에 이 상황에 맞지 않는다고 생각한다.
api 요청이 오면, 그 때마다 데이터를 반환해주어야 하는데 스케줄링을 걸어도 해당 메서드를 사용하면 db에서 데이터를 가져올 것이다.

그렇기 때문에 캐싱을 사용하게 되었다.
캐싱을 사용하게 되면서 매 번 DB에 접근하지 않아도 되기 때문에 자동적으로 성능까지 좋아지는 효과를 얻게 되었다.

글로벌 캐시 vs 로컬 캐시

글로벌 캐시의 경우 따로 캐시 서버를 두고, 여러 서버에서 해당 서버에 접근하여 사용할 수 있다.
MySQL 서버가 다운되더라도, 글로벌 캐시에 캐싱해둔 데이터를 이용하여 데이터를 보여줄 수 있다는 장점이 있다.

그럼에도 불구하고, 우리가 로컬 캐시를 채택한 이유는 무엇인가?
우선, Redis를 이용하여 글로벌 캐시를 이용하기 위해서는 해당 기술에 대해서 알고 있어야 한다.
팀원 모두가 Redis를 사용해보지 못했고, 프로젝트가 얼마 남지 않은 시점이었다.
또한 분산 환경이 아니기 때문에 글로벌 캐시를 이용하지 않아도 로컬 캐시만으로 충분하다고 생각하여 로컬 캐시를 선택하게 되었다.

물론, 글로벌 캐시보다 메모리에 위치하는 로컬 캐시가 속도도 더 빠를 것이다.

로컬 캐시 비교

로컬 캐시를 사용하게 되었는데, 그러면 어떤 캐시를 사용할 것인가?
많이 사용하는 캐시는 Ehcache, Guava Cache, Caffeine Cache가 있다.

1. Ehcache

• Spring에서 간단하게 사용할 수 있는 대표적인 Java 기반 오픈 소스 캐시 라이브러리

2. Guava Cache

• 구글에서 제공하는 자바 캐시 라이브러리

3. Caffeine Cache

• 깃허브에서 소개하는 고성능의 최적의 캐싱 라이브러리
• Guava 캐시와 ConCurrentHashMap을 개선한 ConcurrentLinkedHashMap을 바탕으로 구현된 캐시

Caffeine Cache 선택 이유

• Guava의 경우 구현이 복잡해보여 선택하지 않았습니다.
• Ehcache의 구현이 가장 편리하였지만, Caffeine Cache의 구현도 크게 어렵지 않았습니다.
• 구현의 난이도는 비슷하기 때문에 Ehcache와 Caffeine Cache를 비교해보았습니다.

Caffeine Cache

Compute Benchmark

Read Benchmark

Read, Write Benchmark

Write Benchmark

모든 부분에서 Caffeine Cache 성능이 우수하기 때문에 선택하게 되었습니다.
구현의 난이도도 쉽고, 성능도 가장 좋기 때문에 사용하게 되었습니다.

참고

• 로컬 캐시 선택하기 - Uplus Tech Blog
• 네이버페이 백엔드 개발자의 Ehcache vs Caffeine Cache
• Ehcache vs Caffeine vs Redis