Redis 알아보기

Jing9·2025년 8월 24일

들어가는 말

어느새 7주간의 첫 프로젝트를 마치고 벌써 두 번째 프로젝트를 준비하는 시간이 됐다.
~~이제 나는 강수한이 되어..~~
분수에 맞게 차근차근 해보도록 하겠다.

이번 프로젝트에서도 역시 백엔드를 맡았는데, 프로젝트 시작 전에 기술적으로 츄라이해 볼 만한 게 뭐가 있을까~ 하다가 redis를 이용한 캐싱이 어떨까! 했다.
아무래도 이번 주제가 핀테크이고, 아마 차팅 기능을 메인으로 할 것 같아서, 잦고 많은 요청을 처리하기 위해 도입해보면 좋겠다 싶었다.

Redis란?

Remote Dictionary Server 원격 딕셔너리 서버

이게 뭔말임?

쉽게 보면 redis는 DB다! 키-값 기반 데이터 저장소(NoSQL 기반이라는 뜻)!
기존 DB와 다른 점은 인-메모리 데이터 저장소로써, 디스크가 아닌 메모리에 데이터를 저장한다는 것이다.

위 두 가지로 얻는 장점들이 많다.

사용이 간단하다(SQL 쿼리문을 사용하지 않아도 된다)!
데이터 구조가 다양하다!
데이터 읽기 쓰기가 빠르다!

간단한 사용

먼저, 사용이 간단하다는 것에 대해서 알아보자.
JPA를 사용했을 때와 비교하면 코드 복잡도가 엄청 낮다!
물론, 당연히 Redis는 캐싱용도이므로 JPA와 직접적인 비교대상은 아니지만 참고용으로~!

@Service
public class RedisService {
    
    @Autowired
    private RedisTemplate<String, String> redisTemplate;
    
    // 쓰기 - 매우 간단!
    public void saveUser(String userId, String userName) {
        redisTemplate.opsForValue().set("user:" + userId, userName);
    }
    
    // 읽기 - 매우 간단!
    public String getUser(String userId) {
        return redisTemplate.opsForValue().get("user:" + userId);
    }
    
    // TTL과 함께 저장
    public void saveWithTTL(String key, String value, long seconds) {
        redisTemplate.opsForValue().set(key, value, Duration.ofSeconds(seconds));
    }
}

위 코드는 클OO이 만들어준 Redis 사용 예시 코드이다.
JPA는 Entity도 만들어줘야하고, Repository도 만들어줘야하고, Service단에서 고려도 해줘야하지만, Redis 사용 시에는 딸-깍이면 된다!

다양한 데이터 구조

Redis의 키-값 쌍에서 키는 무조건 String(문자열)이고, 값은 다양한 종류가 있다!

String: 단순한 값, JSON 객체
Hash: 객체의 여러 속성
List: 순서가 중요한 목록
Set: 중복 제거가 필요한 집합
Sorted Set: 점수/순위가 있는 데이터
HyperLogLog: 대용량 고유 개수 추정

기본적으로 String을 사용하되, 객체 저장에는 Hash를 사용하고, List는 deque과 같은 느낌으로 사용할 수 있다!

Set, Sorted Set은 각각 Java의 HashSet, TreeSet과 비슷하다.
다만, Sorted Set의 경우 값마다 점수를 부여해서 insert하여 점수에 따라 정렬된다.
Set, Sorted Set의 값들은 String만 가능하다.

HyperLogLog는 좀 특이한데, 대용량 데이터의 고유 개수를 메모리를 적게 사용하면서 추정하는 데이터 구조다.
아무래도 추정이다보니 약간의 오차(1% 내외)가 있지만 메모리를 매우 적게 사용한다!
정확한 값이 필요한 경우를 제외하고는 사용하기 좋을 것 같다.

차트 데이터에 활용

우리의 차트 데이터의 어떤 값을 redis에 저장하면 좋을까?
사실 어떤 값을 차팅할지도 정해지지 않았지만, 자주 조회될 것 같은 것들에 대해 고민해보았다.

1. 시계열 가격 변동

주식 차트, 시세 변동 등 일반적으로 시간에 따라 변동되는 값들을 캐싱한다고 가정하자. 어떤 타입으로 저장해야할까?
당연히 Sorted Set 되시겠다. 왜???? 정렬해야하니까~~

아까 Sorted Set에 값을 넣을 때 점수를 부여하고 이에 따라 정렬한다고 했는데, 그 점수를 시간으로 준다면?
시간 순으로 정렬되겠지!!!
이렇게 차트데이터를 시간 순으로 정렬해놓으면 많은 요청에도 바로바로 응답을 줄 수 있다!

2. 최근 거래 내역

최근 자신의 거래 내역을 저장한다면, 어떤 구조가 좋을까?
이건 당연한 정답이 있다기보단, 믿음의 Sorted Set, 전통의 List 사이에서 약간 고민이 된다.

당연히 삽입과 조회는 List가 빠를 수 밖에 없다. 그러나, Sorted Set은 범위 조회가 가능하다는 장점이 있었다!
시간을 점수화해서 Set에 넣기 때문에, 특정 시간의 내역들이 필요한 경우에는 무조건 Sorted Set을 사용해야 한다.

나중에 우리 서비스가 구체화되면 그때 아마 확정지을 수 있지 않을까 싶다.

맺는 말

첫 번째 프로젝트 시작할 때, STOMP 알아보기를 주제로 기술 블로그를 썼었는데 이번에도 첫 블로그는 알아보기로 가보았다.
아무래도 아직 프로젝트가 시작된 게 아니다 보니 고민거리가 많지 않기도 하고, 지금 공부를 해놔야 삽질을 비교적 덜 할 것 같다.(이래놓고 STOMP 삽질 열심히 했더랬지..)

이제 시작될 두 번째 프로젝트, 걱정 많이 되지만... 지금까지 그래왔듯 머리 박치기 해가며 열심히 해보자!!!

Jing9

이전 포스트

다시 연결한다 말할까~🎶

다음 포스트