[🔥TroubleShooting - MoodBuddy🔥] 조회 속도를 높이기 위한 캐싱, 과연 정답일까?

📌 프로젝트 소개

팀원 : PM(1) / Design(1) / Frontend(2) / Backend(3)
기간 : 2024.03 ~ 2025.03
링크 : https://github.com/M-ung/MoodBuddy_Server
서비스 내용 : 사용자가 작성한 일기를 바탕으로 감정 분석하는 웹 서비스
소통 : GitHub, Slack, Notion, Discord

---

🔥TroubleShooting🔥

Problems

처음 1차 개발 단계에서 서비스에 있어서 조회 기능들은 모두 Spring Data JPA를 활용해 DB에 접근하여 조회하는 방식으로 구현했다.

📍 일기 목록 조회 기능 (캐싱 X)

    @Override
    public PageCustom<DiaryResQueryDTO> getDiaries(final Long userId, Pageable pageable) {
        return diaryQueryRepository.findDiariesWithPageable(userId, pageable);
    }

하지만 1차 개발 이후, 단순히 조회 속도를 높이고 싶은 마음에 Redis 캐싱을 모든 조회 기능에 적용해서 리팩토링했다.

📍 일기 목록 조회 기능 (캐싱 O)

    @Override
    @Cacheable(
            cacheNames = "getDiaries",
            key = "'userId:'+#userId+'_'+'pageable.offset:'+#pageable.offset+'_'+'pageable.pageSize:'+#pageable.pageSize",
            unless = "#result == null"
    )
    public PageCustom<DiaryResQueryDTO> getDiaries(final Long userId, Pageable pageable) {
        return diaryQueryRepository.findDiariesWithPageable(userId, pageable);
    }

Redis 캐싱을 적용한 덕분에 조회 속도를 전보다 훨씬 향상시킬 수 있었다. 하지만 구현을 한 후 생각해 보니 아래와 같은 의문점들이 생겨났다.

1. 기획 특성상 무드버디는 개인적인 공간이다. 그런데 모든 조회 기능을 캐싱할 필요가 있을까?
2. 필터링 조회는 사용자가 입력한 조건이 매번 다르다. 그럼 캐싱이 불필요하지 않을까?
3. 현재 Redis의 TTL를 사용자마다 같게 해둔 상태이다. 그렇다면 캐시 스탬피드 현상이 발생하지 않을까?

---

How

1. 기획 특성상 무드버디는 개인적인 공간이다. 그런데 모든 조회 기능을 캐싱할 필요가 있을까?
전체 일기 조회 기능은 캐싱을 적용하지만, 나머지 감정 일기 조회, 필터링 일기 조회와 같이 매번 다르게 조회되는 경우는 캐싱을 제거할 예정이다.

2. 필터링 조회는 사용자가 입력한 조건이 매번 다르다. 그럼 캐싱이 불필요하지 않을까?
필터링 같은 경우는 사용자가 매번 다르게 조회할 가능성이 매우 크다. 그렇기 때문에 캐싱은 불필요하다고 판단된다.

3. 현재 Redis의 TTL를 사용자마다 같게 해둔 상태이다. 그렇다면 캐시 스탬피드 현상이 발생하지 않을까?
TTL을 사용자마다 같에 설정하여 캐시 스탬피드 현상이 발생할 가능성이 크다.

캐시 스탬피드 현상이란?
캐시 스탬피드는 캐시가 만료될 때, 여러 요청이 동시에 DB로 몰리면서 부하가 발생하는 현상을 말한다.
즉 쉽게 말하면, 캐시 만료 후 수많은 요청이 동시에 DB로 몰려 서버가 과부하되는 문제이다.

캐시 스탬피드 현상의 시나리오는 아래와 같다.
1. 캐시가 만료된다.
2. 모든 요청이 캐시를 찾지만, 데이터가 없다.
3. 동시에 모든 요청이 DB에서 데이터를 가져오려 한다.
4. DB 부하 급증한다.

이를 해결하기 위해 아래와 같은 방법들을 고려했다.

1. 스케줄러를 통해 캐시된 테이터가 제거될 때쯤에 갱신하는 방법
2. 캐시 만료 시간을 사용자마다 랜덤으로 배정하는 방법

1. 스케줄러를 통해 캐시된 테이터가 제거될 때쯤에 갱신하는 방법
스케줄러를 통해 매번 캐시된 데이터가 제거될 때쯤에 갱신하는 방식은 과한 방식이라고 판단했다.
그 이유는 만약 사용자가 장기간 접속하지 않은 사용자임에도 불구하고 계속 캐싱을 갱신해 주는건 불필요하다고 생각했다.

2. 캐시 만료 시간을 사용자마다 랜덤으로 배정하는 방법
캐시 만료 시간을 사용자마다 랜덤으로 배정해 주는건 좋은 방안이라고 생각했다. 이렇게 적용한다면 동시에 캐시 데이터를 갱싱할 일을 방지할 수 있기 때문이다.

✨ 새로운 방안 ✨
무드버디는 사용자만의 공간이다. 그렇기 때문에 사용자가 일기를 작성, 수정, 삭제하는 일이 없다면 일기 목록들은 항상 똑같다. 그렇기 때문에 스케줄러로 캐시 데이터를 갱신하지 않고 TTL을 길게 유지한 후 일기 저장, 수정, 삭제할 때마다 캐시 데이터를 갱신하는 방법이다.
또 혹시라도 발생할 수 있는 캐시 스탬피드 현상을 방지하고자 TTL 시간을 랜덤으로 배정하는 것이다.

---

Process

먼저 매번 조건이 달라지는 일기 조회 기능에는 캐싱 적용을 제거했다.

    @Override
    public PageCustom<DiaryResQueryDTO> getDiariesByEmotion(final Long userId, DiaryEmotion diaryEmotion, Pageable pageable) {
        return diaryQueryRepository.findDiariesByEmotionWithPageable(userId, diaryEmotion, pageable);
    }

    @Override
    public PageCustom<DiaryResQueryDTO> getDiariesByFilter(final Long userId, DiaryReqFilterDTO requestDTO, Pageable pageable) {
        return diaryQueryRepository.findDiariesByFilterWithPageable(userId, requestDTO, pageable);
    }

그리고 날짜 순으로 오래된 순, 최신 순으로 일기가 캐싱 조회될 수 있게 아래와 같이 구현했다.

    @Override
    @Cacheable(
            cacheNames = "diaries",
            key = "'userId:' + #userId + '_sort:' + #isAscending + '_page:' + #pageable.pageNumber + '_size:' + #pageable.pageSize",
            unless = "#result == null"
    )
    public PageCustom<DiaryResQueryDTO> getDiaries(final Long userId, boolean isAscending, Pageable pageable) {
        return diaryQueryRepository.findDiariesWithPageable(userId, isAscending, pageable);
    }

그리고 일기 저장, 수정, 삭제 시 캐시 데이터를 초기화하고 첫 페이지만 캐시에 갱신될 수 있도록 구현했다.

@Service
@RequiredArgsConstructor
public class RedisServiceImpl implements RedisService {
    private final RedisTemplate<String, String> redisTemplate;
    private final DiaryQueryService diaryQueryService;
    private static final String DIARIES_CACHE_PREFIX = "diaries::userId:";
    private static final String DIARY_COUNT_CACHE_PREFIX = "diary_count:userId:";
    private static final int PAGE_SIZE = 20;

    @Override
    public void deleteDiaryCaches(Long userId) {
        deleteCacheByUserIdAndCacheName(userId);
        deleteCountCacheByUserId(userId);
        cacheFirstPage(userId);
    }

    private void deleteCacheByUserIdAndCacheName(Long userId) {
        var pattern = DIARIES_CACHE_PREFIX + userId + "*";
        var keys = redisTemplate.keys(pattern);
        if (keys != null && !keys.isEmpty()) {
            redisTemplate.delete(keys);
        }
    }

    private void deleteCountCacheByUserId(Long userId) {
        String pattern = DIARY_COUNT_CACHE_PREFIX + userId;
        var keys = redisTemplate.keys(pattern);
        if (keys != null && !keys.isEmpty()) {
            redisTemplate.delete(keys);
        }
    }

    private void cacheFirstPage(Long userId) {
        diaryQueryService.refreshDiariesCache(userId, false, PageRequest.of(0, PAGE_SIZE));
    }
}

또 모든 사용자가 TTL이 같으면 캐시 스탬피드 현상이 일어날 수 있기 때문에, 캐시 데이터를 저장할 때 TTL을 24시간을 기준으로 랜덤 저장할 수 있게 했다.

    @Bean
    public RedisCacheManager cacheManager(RedisConnectionFactory cf) {
        Map<String, RedisCacheConfiguration> cacheConfigurations = new HashMap<>();
        int randomTTL = 24 + (int) (Math.random() * 5);
        cacheConfigurations.put("diaries", defaultCacheConfiguration().entryTtl(Duration.ofHours(randomTTL)));
        return RedisCacheManager.builder(cf)
                .cacheDefaults(defaultCacheConfiguration())
                .withInitialCacheConfigurations(cacheConfigurations)
                .build();
    }

---

Result

정상적으로 조회 및 캐시에 저장되는 걸 확인할 수 있다.

---

Thoughts

캐싱 조회만 하면 속도가 빨라지고 속도를 개선만 한다면 이것이 정답이라고 생각했다.

하지만 단순히 캐시에 데이터를 저장하고 조회하는 건 "캐시 스탬피드 현상"과 같은 문제를 초례할 수 있기 때문에 캐시 데이터를 저장할 때 신중해야 한다는 걸 배울 수 있었다.

또 모든 데이터를 캐시에 저장하기보단 상황에 따라 캐싱 적용이 필요할지 안 할지 판단하는 것이 중요하다는 걸 배웠다.

성능만 중요시하는 개발자가 아닌, 상황에 따라 설계를 할 수 있는 개발자로 성장해야겠다고 다짐했다.

---