[트러블 슈팅] 랭킹 조회에 로컬 캐시 적용하기

도입

[10분 테코톡] 📸소니의 Cache를 보고 프로젝트에 캐시를 적용해보고 싶었다. 그런데 어디에 적용할지 어떤 캐시를 사용할지 고민되었다. 참고로 웹 브라우저 캐시가 아닌 컴퓨터 운영체제에서의 캐시를 적용하고자 했다. 

 

원데이 히어로 프로젝트에서 히어로 점수를 기준으로 히어로 랭킹 조회하는 기능이 있다. 여기서 히어로란 프로젝트 내 도메인 용어로 단기 알바, 심부름 등을 해주는 사람을 뜻한다. 이러한 랭킹 조회에 로컬 캐시를 적용했고 이번 글에선 캐시 적용 과정에 대해서 이야기해 보겠다.

 

캐시란 무엇인가?

먼저 캐시에 대해서 소개하겠다. 캐시는 데이터나 값을 미리 복사해 놓는 임시 저장소이다. 캐시는 캐시의 접근 시간에 비해 원본 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용한다.

 

캐시는 모든 상황에서 사용할 수 있지 않다. 캐시를 사용하게 되면 반드시 데이터 정합성 문제가 발생한다. 즉, 캐시의 데이터가 데이터베이스의 데이터와 정보값이 다른 현상이 발생한다. 적절한 캐시 전략을 통해 캐시와 데이터 베이스 간의 데이터 불일치 문제를 극복할 수 있지만, 결국 실시간성을 어느 정도 포기해야 한다. 따라서 실시간성이 중요한 데이터라면 캐시를 사용하는 것은 캐싱 대상으로 부적합하다.

 

그리고 캐시는 반복적으로 동일한 결과를 반환하는 경우에 용이하다. 매번 다른 결과를 돌려줘야 하는 상황에 캐시를 적용한다면 오리혀 성능이 떨어진다. 캐시에 저장하거나 캐시를 확인하는 작업 때문에 부하가 생기기 때문이다. 

 

문제 상황

히어로를 랭킹 조회하는 쿼리를 살펴보면 users, user_regions, user_mission_categories, user_images, m_categories 이렇게 5개의 테이블을 조인하고 있다. 

 

다만 지역별, 카테고리 별로 순위를 집계하므로 request param에 따라 쿼리가 변하는 동적 쿼리이다. 프로젝트 내에 히어로 랭킹 조회하는 쿼리이고 request param에 따라 where 절이 달라진다.

select u.id, u.nickname, u.hero_score, ui.path 
from users u
join user_regions ur on ur.user_id = u.id
join user_mission_categories umc on umc.user_id = u.id
left join user_images ui on ui.user_id = u.id
join m_categories mc on mc.id = umc.mission_category_id
where ur.region_id = :지역 아이디 and umc.mission_category_id = :미션 카테고리 아이디
order by u.hero_score desc
limit 0, 20;

 

먼저 JMeter를 통해 히어로 랭킹 조회 API를 성능 테스트해 보았다. 테스트 전 m_categories 테이블에는 8개 그리고 나머지 테이블에는 10만 개의 더미 데이터를 넣어두었다.

 

100명의 유저가 100초 내에 유입되고 요청을 50번 반복한다고 한다고 했을 때 결과는 다음과 같다. 평균 응답시간은 208ms으로 나쁘지 않은 응답시간이라고 생각한다. 오류도 0%로 모든 요청이 DB 커넥션을 획득해 처리했다. 

 

JMeter로 성능 테스트

 

성능 테스트를 통해 히어로 랭킹 조회 API가 병목 지점이라고 보기 어려웠지만, 도메인 특성상 캐시 대상으로 적합하다고 판단했다. 대부분 서비스의 실시간 순위 조회를 보면 갱신 주기가 있다. 히어로 랭킹 조회 또한 일정한 갱신 주기를 가지면서 전체적인 흐름을 보여주면 된다. 

 

앞서 동적 쿼리라고 이야기했으므로 요청 값에 따라 항상 바뀌는 쿼리라면 캐싱하긴 어렵다. 하지만 들어올 수 있는 지역값과 카테고리값은 데이터베이스 내의 데이터로 한정되므로 반복적인 조회가 발생한다. 결국 히어로 랭킹은 항상 최신 데이터를 보여주지 않아도 되고 동일한 쿼리가 반복되므로 캐시 대상으로 적합하다.

어떤 캐시를 적용할까?

 

먼저 웹 브라우저의 캐시를 제외하고 고려하겠다. 캐시는 크게 로컬 캐시와 글로벌 캐시로 나뉜다. 

 

로컬 캐시는 로컬 서버의 리소스(Memory, Disk)를 사용하여 캐싱을 처리한다. 반면 글로벌 캐시는 캐시 저장소가 서버 외부에 존재하므로 결국 네트워크 I/O가 발생하여 로컬 캐시보다는 느리다.

 

하지만 다중 서버일 경우, 로컬 캐시는 데이터 정합성이 깨지는 문제가 발생한다. 캐시를 삭제하거나 변경할 경우 특정 서버에만 적용이 되는데, 이러한 문제는 모든 애플리케이션 서버의 캐시를 동기화하여 해결한다. 예를 들어, Redis의 pub/sub을 활용하여 동기화하는 방법이 있다. 로컬 캐시가 갱신되면 그러한 사실을 다른 모든 애플리케이션 서버에게 브로드캐스트 한다. 

 

물론 글로벌 캐시를 사용하면 모든 애플리케이션 서버가 하나의 캐시 스토리지를 바라보기 때문에 동기화할 필요가 없다. 

 

원데이히어로 프로젝트는 로컬 캐시를 사용했다. 글로벌 캐시를 도입할 경우, Redis와 Memcached를 사용해야 한다. 나는 새로운 기술 도입으로 인한 추가적인 비용과 늘어나는 관리 포인트를 우려했다. 그리고 우리 프로젝트는 모놀리식이었고 하나의 WAS만 사용했다. 또한 추후 다중 서버로 scale-out 할 가능성이 낮았다. 결국 글로벌 캐시는 오버 스펙이라 판단해 로컬 캐시를 선택했다.

 

마지막으로 어떤 로컬 캐시를 써야 할까? 결론부터 이야기하자면, Caffeine 캐시를 사용했다. 

 

스프링에선 캐시를 CacheManager라는 인터페이스로 추상화하여 제공해 준다. 확인해 보면 여러 구현체가 존재하는 것을 알 수 있다. 참고로 나는 미리 Caffeine 캐시 라이브러리의 의존성을 추가해 놨기 때문에 CaffeineCacheManager 클래스가 존재한다.

CacheManager 구현체

  

로컬 캐시는 대표적으로 ConcurrentHashMap, EhCache, Caffeine Cache이 있다. 

 

ConcurrentHashMap은 스레드 세이프하고 스프링 캐시에서 default 한 캐시이다. 하지만 개별적으로 캐시 정책을 설정할 수 없다.

 

반면 EhCache는 개별적으로 캐시 정책을 설정할 수 있다. 그리고 Terracotta라는 분산 캐시 서버를 활용하면 다중 서버에서 캐시 동기화, 복제를 수행할 수 있다. EhCache를 분산 캐시로 활용하기에 대한 참고 자료

 

마지막으로 Caffeine Cache도 개별적으로 캐시 정책을 설정할 수 있다. 그리고 벤치마크를 보면 읽기와 쓰기에서 모두 빠른 것을 확인할 수 있다. Caffeine Cache의 벤치마크

 

Read(100%) 벤치마크

Write(100%) 벤치마크

 

일정 시간마다 랭킹을 갱신해야 하므로 TTL 설정이 필요했다. 따라서 먼저 ConcurrentHashMap은 제외했다. 그리고 다중 서버가 아니니 분산 캐시가 필요하지 않았다. 결국 속도가 빠른 Caffeine 캐시를 사용하기로 결정했다. 

 

적용

 

먼저 스프링 캐시와 Caffeine Cache 라이브러리에 대한 의존성을 추가한다. 빌드 툴은 Gradle이다.

 

dependencies {
    // Spring Caching
    implementation 'org.springframework.boot:spring-boot-starter-cache'
    implementation 'com.github.ben-manes.caffeine:caffeine'
}

 

다음으로 스프링 설정 클래스에 캐시 매니저를 빈으로 등록해 준다.

 

expireAfterWrite를 사용하여 캐시에 저장된 엔트리를 1시간 뒤 자동으로 삭제되도록 했다. 

maximumSize를 사용하여 캐시에 저장될 수 있는 최대 엔트리의 개수를 1000개로 설정했다. 문서에 따르면 사이즈가 최댓값에 가까워질 경우 다시 사용될 가능성이 적은 엔트리를 제거한다고 한다. 

@EnableCaching
@Configuration
public class SpringCachingConfiguration {

    private static final Long ONE_HOUR = 1L;
    private static final Long MAX_SIZE = 1000L;
    private static final String CACHE_NAME = "heroesRank";

    @Bean
    public CacheManager cacheManager() {
        SimpleCacheManager simpleCacheManager = new SimpleCacheManager();
        simpleCacheManager.setCaches(List.of(new CaffeineCache(CACHE_NAME, Caffeine.newBuilder()
            .recordStats()
            .expireAfterWrite(ONE_HOUR, TimeUnit.HOURS)
            .maximumSize(MAX_SIZE)
            .build())));

        return simpleCacheManager;
    }
}

 

 

설정이 끝났다면 캐싱할 부분에 @Cacheable 어노테이션을 붙이고 사용할 캐시의 이름을 넣어준다. 로직에 대한 설명은 캐시와 관련 없으니 넘어가겠다.

 

    @Cacheable(cacheNames = "heroesRank")
    public Slice<HeroRankResponse> findHeroesRank(
        HeroRankServiceRequest request,
        Pageable pageable
    ) {
        var categoryId = Optional.ofNullable(request.missionCategoryCode())
            .map(MissionCategoryCode::getCategoryId)
            .orElse(null);
        var region = regionReader.findByDong(request.regionName());

        var heroesRank = userReader.findHeroesRank(region.getId(), categoryId, pageable);

        var heroRankResponses = addRank(heroesRank, pageable);
        return SliceResultConverter.consume(heroRankResponses, pageable);
    }

 

 

그리고 캐시를 적용한 서비스를 배포하기 전 캐시 워밍업(Cache warm-up) 작업을 수행해야 한다. 캐시 워밍업이란 미리 캐시로 데이터베이스의 데이터를 밀어 넣는 작업을 말한다. 서비스 초반 대량의 Cache Miss에 따른 데이터베이스 조회가 발생할 여지가 있기 때문이다.

후기

 

캐시의 크기를 1000으로 설정했지만 당장은 크기의 적절성에 대해 판단을 못하겠다. 아마 캐시에 대한 공부 부족이라 생각된다.

 

이 글을 적으면서 캐시에 대한 여러 자료를 찾아봤는데, 공부할 게 방대하다고 느꼈다. 일단 정말 간단한 정책만 설정했는데 나중에 캐시 정책에 대해서 좀 더 공부한 뒤 세밀하게 정책을 설정해봐야 겠다.