레디스

박준수·2023년 1월 15일

[실리콘벨리 프로젝트]

목록 보기

6/12

Redis란

Remote(원격)에 위치하고 프로세스로 존재하는 In-Memory 기반의 Dictionary(key-value) 구조 데이터 관리 Server 시스템이다.

key-value 구조이므로 데이터의 고속 읽기와 쓰기에 최적화 되어 있다.
Redis는 인 메모리(In-Memory) 솔루션으로도 분류되기도 하는데, 다양한 데이터 구조체를 지원함으로써 DB, Cache, Message Queue, Shared Memory 용도로 사용될 수 있다.

여기서 인 메모리란

예를 들어...

in-memory DB는 disk-based DB와 달리 말 그대로 메모리에 데이터를 저장한다.

장점 : in-memroy DB는 애초에 메모리에 모든 데이터가 있기 때문에 지연이 적다.

단점 : in-memory DB는 기본적으로 영속성(persistence)을 보장하지 않는다.

in-memory DB는 메모리에 데이터를 저장하기 때문에 저장 공간이 한정되어있다.

결론 : 반드시 영속성이 필요하지 않고, 저장 공간이 많이 필요한 것도 아니라면 in-memory DB는 매우 유용하다.

Look aside Cache 패턴

—> 우리 프로젝트에서는 이미지를 보네면 s3가 ai한테 url을 보네고 ai가 인식된 클래스넘버를 반환해주고 데이터베이스에 있는 클래스 넘버와 비교를 하여 같은 넘버의 데이터를 반환

—> 클래스 넘버에 따른 상품 데이터를 데이터베이스에서 쿼리로 비교를 해서 얻어오는 방식이 아니라 redis(캐시)로 key-value방식으로 사용할 수 있지 않을까?

Write Back 패턴

주로 쓰기 작업이 굉장히 많아서, INSERT 쿼리를 일일이 날리지 않고 한꺼번에 배치 처리를 하기 위해 사용한다.

예) insert를 1개씩 500번 수행하는 것보다 500개를 한번에 삽입하는 동작이 훨씬 빠르기 때문에 write back 방식은 빠른 속도로 서비스가 가능하다.

이외에도 Redis를 주로 사용하는 곳은 다음과 같다.

인증 토큰 등을 저장(Strings or Hash)
Ranking 보드로 사용(Sorted-Set)
유저 API Limit
잡큐(list)

프로젝트 응용

시도의 흐름

처음에는 query문이 없고 parameter값으로 이미지를 받는 AI 예측 API에 Redis를 적용시켜 보려고 했다.

Redis의 Key값이 일정하게 나오는 현상이 있어서 Key값을 다르게 해보려고 했다.

Key값을 이미지 이름으로 하자니 받아오는 이미지 이름을 전부 같고, 바뀐 이미지 이름은 난수로 지정해 전부 달라서 다음번에 같은 id값이 들어왔을 때 cache를 찾지 못할 것 같다고 생각했다.

그래서 id값을 key값으로 해서 반환해보려 함 → 캐싱 이름은 성곡적으로 반환했지만 하나의 캐시가 생기면 그 캐시가 없어 질 때 까지 똑같은 Body값만 반환했다.

그래서 리스트변수를 만들어 그곳에 id값을 집어넣은 후 리스트의 길이로 id값이 있는지 없는지 판단해보려 했다.

한 번 캐시가 만들어져서 영속성으로 만들면 그 값을 계속 나오지만 다른 id값이 추출되는 이미지를 넣었을 때 그 전 캐시가 반복되거나, 캐시적용이 안되는 모습이었다.

그냥 원래처럼 db에 의해 조회해서 나타내는 것과 db에 조회하는

것 보다 먼저 캐싱하지만 이중for문을 사용하는 것이 시간단축이 될까 라고 생각하였다.

결론은 unique한 key값이 없는 API에서 계속 key값을 만드려고 하니 오류가 꼬리에 꼬리를 물어서 key값이 정확히 있는 query문이 있는 API에 적용해보려 하였다.

역시 key값이 있는 query문을 통한 API는 성공적으로 적용되었다.