🎱 Redis를 도입해서 캐싱 작업을 진행해보자!!! [2탄]

🖤 Intro

오늘 볼 부분은 REDIS 캐싱을 설계하면서, 과연 캐싱해야 하는 값들을 “어떤”형태로 저장하는게 좋을지, 그리고 각각의 정보에 대한 TTL을 어느정도로 지정해야 사용자 경험을 확대시킬 수 있을지에 대한 고민을 담고 있다!

🩶 Start

🫨 고민… REDIS에 어떠한 형태로 값을 저장할 것인가?

우리는 결국 REDIS에 user의 정보에 해당하는 값들을 넣어두고 이를 요청에 넣어서 LLM한테 상품 추천을 받는 것이 목표이기 때문에, 해당 값들을 JSON으로 만들어서 저장 해두는 것이 여러모로 편하다.

이렇게 JSON 자체로 저장하기 위해서는 Config에 커스텀으로 직렬화 세팅을 해두는 것이 좋다.

그러나 JSON 직렬화의 경우는 치명적인 단점이 있다. Spring Data Redis에서는 저장의 단위가 JSON(객체 단위)이기 때문에 creditLeft 같은 필드 하나만 바꿀 때도 새로운 DTO를 만들어서 set 해야 한다.

즉, 만약 필드에서 update가 필요한 경우가 생기면 객체를 다시 만들어야 한다는 것이다. 내부적으로는 문자열 덮어쓰기 밖에 없기 때문이다!

여기서 문제가 생긴다… JSON으로 저장하면 우리가 요청 값을 넣을때 편리한 것은 알겠는데, 사실 우리의 경우, “관심사” 값을 매번 물어보고, 갱신하는 방식이라 저장된 객체 안에서 변동이 생기게 된다.

그래서 고민을 했는데, 변동이 많은 값은 Hash에 두고 덩어리 응답(JSON 스냅샷)은 JSON으로 저장하는 식의 혼합 전략을 사용하기도 한다!!!

또 다른 고민거리,,, 과연 캐싱의 TTL은 얼마로 잡아야 하는가? 그리고 DB를 덜 찌르면서도 잔액은 신선하게 가져가려면 어떻게 해야하는가?

여기서 또 다른 종류의 고민이 생겼다..

원래 생각했던 방향은, 초반에 채팅을 시작할 때, 우선 REDIS에 캐싱해둔 유저 정보가 있으면 DB를 거치지 않고 바로 REDIS에서 값을 가져온다.

취미(관심사)의 경우는 바뀌었다면 다음 응답에서 바뀐 값으로 DB와 REDIS를 전부 갱신해준다.

이렇게 할 경우, 변동이 확정인 관심사만 Hash로 저장하면 된다

그러나, 사실 우리 추천 서비스를 위해서는 잔액과 최근 구매한 상품에 대한 카테고리 정보도 REDIS에 같이 캐싱되는데, 이 정보들 변동성이 너무 크고, 순식간에 변한다.

예를 들어서, 초기 정보를 REDIS에 저장했어도 그 짧은 1~2분의 순간 안에 물건을 대량 구매해서 잔액이 크게 변동될 수도 있는 것이다!!!!

그러나 우리 추천 서비스의 경우, 사용자 잔액을 기반으로 상품 추천이 이뤄지고, 사실상 잔액과 추천된 상품이 맞지 않으면 추천 서비스의 매력도가 매우 많이 감소하고 사용자 경험도도 매우 떨어지기에…..이 부분에 대한 고민이 필요했다.

즉, “DB를 덜 찌르면서도 잔액은 신선하게”가 포인트인 것이다.

해결책 - 하이브리드 키 설계

이 부분은 키 설계 방식을 두 개로 나누고, 변동이 많은 요소만 TTL을 작게 설정하여 DB 조회 하는 방식으로 설계하면 고민점을 어느정도 해소할 수 있다.

변화가 적은 name, creditLimit을 JSON으로 묶어서 TTL을 1시간 ~ 1일 정도로 길게 설정하고, 변화가 상대적으로 많은 creditLeft와 hobbies의 TTL을 짧게 (5분) 설정하고, Hash로 저장되도록 하여 이벤트로 갱신되도록 하는 것이다 또한, 참고로 키를 생성할때 userId는 키에 넣을 것이므로 userId는 따로 value에 저장할 필요가 없다.

그러나, 여기까지 정해뒀는데 다시 고민점이 생겼다…

아니 그러면, 채팅방을 열어둔 채로 10분 정도가 지났는데 다시 추천해달라고 한다던가 하면 어떻게 해?

그러면 또 이런 문제가 존재한다. TTL을 5분 정도로 짧게 해뒀다고 하자. 그렇다면 사용자가 채팅방을 오래 켜 둔 상태에서 TTL 시간보다 많은 시간을 흘려보낸 다음에 다시 추천해달라고 하면 어떻게 해야할까?

그래서 이럴때 사용 가능한 방법이 바로 캐시 미스(Read-Through) 패턴이다.

캐시 미스(Read-Through) 패턴?

캐시 미스란, Redis에서 먼저 조회하되, 값이 없을 경우 DB에서 다시 “신선한 값”을 가져와서 세팅해서 반환하는 방시을 의미한다.

이렇게 진행해도, TTL이 존재하기 때문에 평소에도 DB 부하를 어느정도 방지 할 수 있다.

즉, 내가 내린 최종 전략을 정리하면 다음과 같다.

종류	key name	values	TTL	기타
snapshot	v1:snap:user:{userId}	{"name":"피용희","creditLimit":30000}	12h	Read-Through
balance	v1:bal:user:{userId}	balance(int)	3m	Read-Through
hobby	v1:hb:user:{userId}	hobby(String)	5m	Read-Through

스냅샷 JSON 직렬화를 위한 Config 설정

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory cf) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(cf);

        // Key는 String, Value는 JSON 직렬화
        var stringSer = new StringRedisSerializer();
        var jsonSer   = new GenericJackson2JsonRedisSerializer();

        template.setKeySerializer(stringSer);
        template.setValueSerializer(jsonSer);
        template.setHashKeySerializer(stringSer);
        template.setHashValueSerializer(jsonSer);

        template.afterPropertiesSet();
        return template;
    }
}

이렇게 Config에 직렬화를 정의해야 하는 이유는, Spring Boot 기본 RedisTemplate<String, Object> 는 JdkSerializationRedisSerializer를 쓰는데, 이 때문에 Redis에 바이트 배열(이상한 바이너리)로 저장이 되기 때문이다.

그래서 GenericJackson2JsonRedisSerializer를 이용해서 JdkSerializationRedisSerializer가 아닌, 우리가 원하는 Json 방식으로 문제 없이 저장되도록 구성할 수 있다.

본격적으로 캐싱을 시작해보자!

연동까지 완료 되었으니, 이제 서버에서 > 레디스로 캐싱하는 단계를 진행해야 한다.

나의 경우, 요소마다 TTL을 다르게 설정했기 때문에 세부적인 설정이 필요하다. 즉, JSON 직렬화 + 항목 종류별 서로 다른 TTL + 커밋 이후 캐싱 일관성을 지켜야 하는 것인데, 그러므로 RedisTemplate + 전용 캐시 컴포넌트 분리로 만드는 것이 좋다.

나의 경우는 이미 RedisTemplate를 통해 JSON 직렬화를 설정해 둔 상태이므로, 캐시 스펙만 짜두면 된다.

/*
REDIS 캐싱을 위한 TTL 설정 값

키 예시 : v1:snap:user:123, v1:bal:user:123, v1:hb:user:123
 */
@Getter
@RequiredArgsConstructor
public enum CacheSpec {
    // 1) 사용자 스냅샷(JSON)
    SNAPSHOT("v1:snap", Duration.ofHours(12)),
    // 2) 잔액(String) - 3분
    BALANCE("v1:bal", Duration.ofMinutes(3)),
    // 3) 취미(List<String> or Set<String>) - 5분
    HOBBIES("v1:hb", Duration.ofMinutes(5));

    private final String prefix; //키 네임 스페이스
    private final Duration ttl;
}

또한, 서비스 단에서 최대한 간결하게 캐싱을 사용하기 위해서 레디스를 사용하기 위한 유틸 클래스가 필요하다.

이 유틸 클래스는, 레디스를 사용하는 서비스 단에서 일관적으로 사용하도록 하기 위해 정의해둔다.

@Component
@RequiredArgsConstructor
public class CacheStore {
    // 정의해둔 REDIS TEMPLATE를 가져옴
    private final RedisTemplate<String, Object> redis;

    // 키를 한 곳에서 만든다.
    private String key(CacheSpec spec, Object userId){
        return spec.getPrefix() + ":user:" + userId;
    }

    // put 첫번째는 그 스펙(CacheSpec)에 정해둔 기본 TTL
    // put 두번째는 정의한 ttl을 사용하고 싶을때 사용한다.
    public void put(CacheSpec spec, Object userId, Object value) {
        put(spec, userId, value, spec.getTtl());
    }

    public void put(CacheSpec spec, Object userId, Object value, Duration ttl) {
        redis.opsForValue().set(key(spec, userId), value, ttl);
    }

    // redis는 Object만 반환하기 때문에 DTO를 꺼내 쓰려면 캐스팅이 필수이다.
    // 그래서 redis.opsForValue().get(...)의 값은 항상 Object이기 때문에 이걸 정의해서 서비스 단에서 캐스팅을 하지 않도록 해야 한다.
    @SuppressWarnings("unchecked")
    public <T> T get(CacheSpec spec, Object userId, Class<T> type) {
        Object raw = redis.opsForValue().get(key(spec, userId));
        return type.cast(raw); //typecast를 한 번 해주기 때문에, 잘못된 타입일경우 ClassCastException가 발생한다.
    }

    // DB에서 해당 데이터가 바뀌었거나 없어졌을 때, 캐시도 지워서 일관적으로 만들기 위함이다.
    // “TTL 만료”를 기다리지 않고 즉시 무효화할 때 사용한다.
    public void evict(CacheSpec spec, Object userId) {
        redis.delete(key(spec, userId));
    }

    // Read-Through: 캐시 미스 시 로더 실행 → 캐시에 저장 후 반환하도록 설정한다.
    public <T> T getOrLoad(CacheSpec spec, Object userId, Class<T> type, Supplier<T> loader) {
        // 1) 캐시 먼저 조회
        T cached = this.get(spec, userId, type);
        if (cached != null) {
            return cached;
        }

        // 2) 미스면 "로더" 실행 (여기서 DB 접근이 수행됨)
        // 여기서 Supplier<T>를 사용해서 조회 로직을 숨길 수 있다. 이를 통해 조회 로직이 서비스 단으로 새어나가지 않도록 한다.
        T loaded = loader.get();

        // 3) 값이 있으면 캐시에 넣고 반환 (키/TTL은 spec에서 가져옴)
        if (loaded != null) {
            this.put(spec, userId, loaded, spec.getTtl());
        }
        return loaded;
    }
}

redis.opsForValue()를 통해서 String 기반 연산자를 가져온다. 이를 통해서 redis의 기본 연산자들을 이용할 준비를 하는 것이다.

set(key(spec, userId), value, ttl)을 통해서 내가 원하는 key로 조합을 해서, 해당하는 value를 저장하면 redis에 저장이 가능한 것이다. 이를 put으로 정의해서 모든 곳에서 일관적으로 값을 저장할 수 있도록 구성했다.

getOrLoad은 redis에 값이 없으면 Supplier로 감싼 db 조회 로직을 실행하고, 있으면 바로 cache에 있는 값을 꺼낼 수 있게 하기 위한 로직이다. 이 로직이 바로 read-through를 위한 부분이다.

Supplier를 사용한 이유는 무엇인가?

이런 의문을 가질 수 있다. 그렇다면 왜 굳이 db를 불러오는 로직을 바로 넣지 않고, 이렇게 Supplier로 한 번 감싸는 방식으로 진행하는 것일까?

대표적인 이유는 “중복 로직”을 줄이기 위함이다.

Supplier를 이용해서 DB 조회 로직을 CacheStore에 고정하지 않고, 서비스 단에서 필요한 쿼리를 자유롭게 주입할 수 있게 하면서, CacheStore 내부 로직은 재사용 할 수 있도록 할 수 있기 위함인 것이다.

실제 Supplier를 이용해서 method를 정의하면 다음과 같이 사용할 수 있다.

public MemberCachingDto getSnapshot(Long memberId) {
        return cacheStore.getOrLoad(
                CacheSpec.SNAPSHOT,
                memberId,
                MemberCachingDto.class,
                () -> memberRepository.findDtoByMemberId(memberId)
        );
    }

이를 이용해서 레디스 캐싱을 위한 Service class를 구성해보자!

@Service
@RequiredArgsConstructor
@Transactional(readOnly = true) // 기본은 조회 트랜잭션
public class MemberService {
    private final MemberRepository memberRepository;
    private final CacheStore cacheStore;

    public int getBalance(Long memberId) {
        return cacheStore.getOrLoad(
                CacheSpec.BALANCE,
                memberId,
                Integer.class,
                // 캐시 미스일 때만 실행되는 DB 로딩 함수이다. 이를 Supplier를 사용하면 필요한 함수를 정의하면 된다.
                () -> memberRepository.findBalanceByMemberId(memberId)
        );
    }

    public String getHobby(Long memberId) {
        return cacheStore.getOrLoad(
                CacheSpec.HOBBIES,
                memberId,
                String.class,
                () -> memberRepository.findHobbyByMemberId(memberId)
        );
    }

    public MemberCachingDto getSnapshot(Long memberId) {
        return cacheStore.getOrLoad(
                CacheSpec.SNAPSHOT,
                memberId,
                MemberCachingDto.class,
                () -> memberRepository.findDtoByMemberId(memberId)
        );
    }
}

이렇게 정의하면, 각각 정의된 키 - 밸류 셋 마다 그 형태에 맞는 값을 캐시에서 불러오거나, 저장할 수 있다.

이를 실제로 어떻게 활용하는지는, 다음 포스팅에서 직접 Test Code를 살펴보며 알아보도록 하자.