redis

redis

외부에 있는 key-value를 저장하는 서버 ( No-SQL )

• 인-메모리 (In-memory) 데이터베이스로 메모리를 저장소로 사용 -> 빠르다

휘발성이지만 별도로 보완책이 존재함

• value에 String, Set, Hash 등 다양한 종류의 타입을 지원한다.
• 복잡한 쿼리에 얽매이지 않는다.
• 한번에 하나의 일만 처리할 수 있다

데이터를 빠르게 저장하고 가져오는데 좋은 성능을 발휘하는 도구

사용예시

카운터 (Counter)로 사용하기

• 조회수, 방문자 등을 클라이언트에게 보여줘야 할 경우
  (DB에 직접 저장할 수 있지만, 1초에 너무 많은 업데이트가 필요한 경우
  많은 DB 리소스를 소모하여 처리가 안되거나 누락되기도 한다.)

• 좋아요/팔로우 등의 기능은 버튼을 누를 때마다 DB에 읽기/쓰기 연산이 이루어진다.
  다량의 insert/update는 RDB의 성능을 크게 저하시킴

모든 처리는 Redis를 이용해서 하고, 영속적인 저장이 필요할 때 데이터를 DB로 옮기면 된다.
데이터의 크기가 너무 크지 않을 때 Redis 사용을 고려해볼 수 있다.

캐싱 (Caching)

모든 유저에게 매번 데이터베이스를 읽어서 보여주는게 아닌, 미리 불러오기 (Load)해서
Redis에 저장을 해두고 사용

기본 흐름 구조

1. (선택) DB에서 필요한 데이터를 미리 Caching
2. 요청이 들어오면 Caching 되어 있는지 확인 (cache-key 이용)
   2-1. Caching 되어 있다면 바로 조회해서 처리 (Cache-Hit)
   2-2. Caching 되어 있지 않다면 (Cache Miss)

DB에서 데이터를 조회해서 Caching하고 요청을 처리한다는 흐름 구조이다.

➖ 캐싱이 의미가 없어지는 데이터는 Redis가 오히려 효율이 떨어진다.
➖ 결과 값이 계속 갱신되는 데이터 -> 캐시도 계속하여 변경 필요 -> 효율 하락
캐시에 저장할 데이터의 특성을 고려하는 것이 필요하다.

캐시 읽기 전략 (Read Cache Strategy)

• Look Aside (Cache Aside) 패턴

1. 요청이 들어와서 데이터를 찾을 때 캐시를 먼저 찾는다.
2. 만약 캐싱되지 않았다면 DB를 조회한다.
   가장 기본이 되는 캐시 전략
   캐시와 DB가 분산되어 운용되므로 Redis가 죽어도 서비스에 문제가 없음
   하지만, redis가 죽었을 때 요청이 한번에 DB로 몰리며 서비스 장애가 발생할 가능성이 있다.

• Read Through 패턴
  Look Aside와 비슷하지만 캐시만 바라보고 데이터를 조회하는 것이다.
  캐싱하는 로직은 직접 처리하지 않고 다른 라이브러리에게 위임
  즉, 자동으로 DB와의 데이터가 동기화가 이루어지도록 하는 방식
  캐싱을 적극적으로 이용할 수 있으나, Redis가 죽는 경우 서비스가 그대로 중지된다.

캐시 쓰기 전략 (Write Cache Strategy)

• Write Back (Write Behind) 패턴
  데이터를 저장할 때 바로 DB에 저장하는 것이 아닌 캐시에 모아 두었다가 한번에 저장
  (N개의 데이터를 하나씩 저장하는 것보다 bulk create하는 것이 더 빠르기 때문)
  ➖ 캐시에서 장애 발생 시 데이터 누락의 가능성이 있음

• Write Through 패턴
  데이터를 캐시에도 저장하고, DB에도 저장하는 방식
  캐시를 이용해서 DB를 동기화
  캐시의 데이터가 항상 최신 데이터로 유지된다.
  두번의 저장이 이루어지기 때문에 데이터 유실에 민감한 로직에서 사용한다. -> 속도가 다소 느리다.