redis

Redis 란??

• Remote Dictionary server
• 원격 / 딕셔너리 → hashmap / server

• In-memory Database

• NoSQL 디비 → NO!! 라는 이름 처럼 저희가 이제까지 사용해오던 RDBMS 의 SQL 과는 큰 차이가 존재합니다
• 바로바로 { key : value } 형태로 데이터가 저장된다는 것입니다.
• redis 에서 지원하는 여러가지 데이터 타입이 존재합니다. ✨ (얘가 아쥬 중요하다고.. )



• 마치 거대한 JSON object 같이 생각할 수 있습니다

• 오픈 소스 제품입니다. ( 상업용 지원도 하고 있습니다 )

• 다양한 자료구조로 데이터를 저장합니다.

• 기본적으로 Single Thread 로 동작합니다
• Redis 의 자료구조는 atomic 하기 때문에, Redis 자체가 atomic 을 보장해줍니다. 🤔
• Redis 4.0 이후부터 , 기본적으로는 싱글 스레드 모델을 사용하다가, 필요하면 선택적으로 멀티스레드 모델을 사용한다고 합니다

어디에 쓰이죠?

• DB : 전통적인 디스크 기반의 db 에 대한 대체제로도 사용될 수 있습니다. 비동기적 디스크 영속화가 가능하긴 하지만 레디스는 스피드를 위해 내구성을 버린다…라고 생각할 수 있습니다.

• 메시지 큐 : 블록킹 기반으로 동작하는 List 자료구조는 “큐"로 사용될 수 있습니다. 이는 latency 가 낮아, 실시간 어플리케이션에서 사용되곤 하니다.

• 메모리 캐시 : 키 방출 정책(LRU- 최근에 가장 적게 사용된, LFU - 가장 적게 사용된. 등등)을 적절하게 설정할 수 있어, redis 를 캐시 서버로 많이 사용하곤 합니다.

그래서..어디에?

• 인증 토큰 (또는 세션) 저장 🐳
• access token 은 삭제가 불가능하기 때문에 보통, 짧은 시간의 만료시간을 주게 됩니다. 하지만 때로는 유효시간이 긴 토큰이 필요하기 때문에 refresh token 이라는 것을 사용합니다. 보통 발급된 refresh token 의 경우는 로그인 성공시에 함께 발급하며, 이를 서버의 저장소에 저장하여 관리하게 됩니다.
• 로그아웃시 refresh token 역시 삭제합니다.
• 이러한 refresh token 을 관리하는데 jwt 를 사용하는 것 같습니다

• 자주 조회되는 게시글들 에 대한 캐싱 🐳
• 물론 이 때는, “캐시를 사용해서 이점을 얻을 수 있는 경우" 들이어야 합니다
• 즉 db 에 직접 접근할 때 보다 빠른 속도를 갖는 경우
주로,
• 같은 데이터에 대해 반복적인 접근을 하는 경우
• 잘 변하지 않는 데이터를 캐싱할 수록 효과적

• Pub/Sub system 🐳
• 이벤트 발행 주체 (publisher) 가 , 특정 Channel 에 이벤트를 전송
• 특정 channel 을 구독하는 Subscriber 는, 퍼블리셔와 상관없이 이벤트를 받을 수 있다.



• Redis 의 Lists 자료구조는 메시징 큐로 사용하기에 적절하다고 합니다.
• web socket + redis 를 이용해 볼 수 있을 것 같습니다

PUB/SUB 에 대한 redis 외의 대안?

• RabbitMQ

• kafka

• 이 때 차이점은
• 1️⃣  kafka 의 경우 프로듀서가 생산한 이벤트가 , 토픽의 파티션에 분산되어 “저장" 된다는 것 이다.
• redis 의 채널은 “이벤트를 저장하지 않는다”. 즉 pub/sub 메시지들이 큐잉 되지 않으며, 영속화 되지도 않는다.
• 만약 채널에 이벤트가 도착했을 때, 해당 채널에 대한 구독자가 존재하지 않으면, 이벤트는 사라져버린다.
• 그러니 도중에 새로운 구독자가 생기더라도, 이전의 이벤트들을 받아볼 수도 없다.
• 심지어 subscriber 가 메시지 읽는 것을 실패했다면, 해당 구독자는 다시 이 메시지를 받아 볼 수도 없다 ㅠ0ㅠ —> Redis 에 도입된 Stream 데이터 타입은 영속화 시키는것도 지원한다고 함.
• 2️⃣  이 외에도, redis 에는 “그룹" 이라는 개념이 없어서, 서버가 여러개 존재하는 경우에 대한 문제도 (redis 에서 문제 ) 존재하는데 이거는 궁금하면 찾아봅시다! 링크

캐시 라는 역할로서 redis 에 대한 다른 대안?

• Memcached : 역시 인메모리 key-value 저장소로, 캐싱을 위해 사용되는 애입니다.
• redis 가 갖는 이점 : 사실 위에서 별로 언급 하지 않았지만 ( 아직 자료구조들은 직접 사용해본게 아니라 아직 잘 모르겠슴당) redis 는 다양한 자료구조를 지원하는 것이 큰 장점이라고 합니다.
• 반면 memcached 의 경우 String 만을 지원합니다.
• memcached 는 멀티스레딩을 제공합니다
 

캐싱 메커니즘으로서 사용시

• 설정 : 캐시매니저 등록

• 코드 내에서는 어노테이션을 사용하는 정도

@CacheEvict(key = .., value = ,cacheManager = )

최종 의견

• 자주 보는 페이지 등에 대하여 캐시 용도로서 사용하는 것은 시도해 보면 좋을 것 같습니다
• 캐싱 메커니즘은 스프링 내에서 설정가능한 것이 아니고 redis 에서 설정을 변경해야합니다. 캐싱 메커니즘과 관련된 설정을 변경하며 개선해보는 것도 좋을 것 같습니다
• 성능 개선과 관련하여 수치( 조회시간, 수치의 의미적 한계는 있으나 cache hit ratio 등 )로서 보여줄 것도 생기지 않을까 기대하고 있습니다

• pub/sub 로서 사용하기에는 너무 좋은 대안(kafka - 좋다고 생각하는 이유 : 데이터를 저장하기 때문에, 나중에라도 다시 발행가능(?) 한 것으로 알고 있음 ) 이 존재하는 것 같고, 어려움이 많을 것 같습니다

(번외..) Spring Cache abstraction

Integration

Spring provides a JMS integration framework that simplifies the use of the JMS API in much the same way as Spring's integration does for the JDBC API. JMS can be roughly divided into two areas of functionality, namely the production and consumption of messages. The JmsTemplate class is used for message production and synchronous message reception.

https://docs.spring.io/spring-framework/docs/current/reference/html/integration.html#cache-store-configuration-jdk

피드백

🙀 캐싱

• 페이지보다는 카테고리 ( 변하지 않는 데이터 )

• 캐싱이 생각보다 위험하다
• 자주 변경되는 데이터에 대하여 캐싱하면 위험할 수도!
• ex) 본인과 관련된 리뷰들을 가져오는데 있어 로그인하는 동안 캐시된 리뷰들을 사용하자 라고 생각하였는데..→ 여러 곳에서 로그인해서 이상한 짓을 하면 예상하지 못한결과!! 가 나올 수 있다고 한다!!
• 이런식으로 자주 불러올 데이터라 예상하고 캐시를 적용하기 전에 고려해볼 것으로는 ㅡ “캐시적중률” 있는것 같다. 캐시적중률이 높은 것이 캐싱하기에 적합한 대상이 된다. 캐싱 적중률이 낮다면 캐시를 사용할 이유가 없다. 실제 서비스가 올라가 캐시가 필요하다고 판단될경우 도입을 생각해보는게 더 적절한 부분 이었던것같다.
• 참고 https://aws.amazon.com/ko/builders-library/caching-challenges-and-strategies/