TIL

5장 레디스를 캐시로 사용하기

레디스와 캐시

캐시란?

• 캐시란 데이터 원본보다 빠르고 효율적으로 엑세스할 수 있는 임시 데이터 저장소를 의미
• 애플리케이션이 다음 조건을 만족한다면 캐시 도입 후 성능을 효과적으로 개선할 수 있다.
  • 원본 저장소에서 데이터를 검색, 계산하는 시간이 오래 걸림
  • 캐시에서 데이터를 가져오는 것이 원본에서 가져오는 것보다 빨라야 한다.
  • 캐싱된 데이터는 잘 변하지 않는 데이터
  • 캐싱된 데이터는 자주 검색되는 데이터
• 캐시의 장점
  • 애플리케이션 응답 속도 단축
  • 원본 데이터 저장소 커넥션을 줄일 수 있다.
  • 캐시를 적절히 배치하여 애플리케이션 확장 또한 가능하다.
  • 애플리케이션 리소스를 줄일 수 있다.
  • 서비스 구성에 따라 원본 데이터 저장소에 장애가 발생해도 캐시를 이용할 수 있다.

캐시로서의 레디스

• 레디스는 사용이 간단
  • 키-값 형태
  • 다양한 자료 구조 제공
• 레디스는 데이터 검색, 반환이 상당히 빠르다.
  • 모든 데이터를 메모리에 저장 (인메모리 데이터 저장소)
  • 평균 읽기 및 쓰기 작업 속도가 1ms 미만
  • 초당 수백만 건 작업이 가능
• 레디스는 자체적으로 고가용성 솔루션
  • 레디스의 센티널 또는 클러스터 기능을 사용 가능
  • 마스터 노드 장애를 자동으로 감지해 페일오버를 발생시킴
  • 레디스 클러스터를 텅해 스케일 아웃 또한 쉽게 처리 가능

    캐싱 전략 - look aside

• 데이터를 읽을 때 주로 사용하는 일반적인 배치 방법
• 읽고자 하는 데이터를 캐시에서 먼저 찾고 캐시에 데이터가 있으면 바로 반환하는데 이를 ‘캐시 히트’라고 한다.
• 캐시에 데이터가 없으면 원본에서 찾고 이를 캐시에 저장한다.
  • lazy loading
• 장점은 레디스에 문제가 생기더라도 원본 저장소를 계속 이용하면서 서비스 장애로 이어지지 않는다는 점이다.
  • 원본 DB에 트래픽이 몰려 부하가 발생하고 성능이 느려질 수는 있어도 말이다.
• 캐시를 사용하고 있지 않다가 캐시를 배치하게 되면 초반에 대규모 캐시 미스가 일어나 (원본 조회 + 캐시 저장) 성능이 느려지게 된다.
  • 이럴 때 DB에서 캐시로 데이터를 미리 밀어넣는 ‘캐시 워밍’을 할 수도 있다.

캐싱 전략 - 쓰기 전략과 캐시의 일관성

• 캐시는 원본의 복사이기 때문에 캐시 불일치가 일어날 수 있다.
  • 원본과 캐시의 데이터가 불일치
  • ex) 원본 DB에 반영된 값을 캐시에도 반영하기 전에 캐시에서 이전 값을 읽어 버리는 경우
• write through
  • DB를 업데이트할 때마다 매번 캐시도 함께 업데이트 하는 방식
  • 캐시는 항상 최신 데이터를 가질 수 있지만 쓰기 시간이 많이 소요된다.
  • 이 방식을 사용한다면 데이터 저장 만료 시간을 사용할 것을 권장한다.
    • 다시 사용되지 않을 데이터도 무조건 캐시에 저장되기 때문
    • 캐시는 재사용될 만한 데이터에 적용하는 것이 좋다.
• cache invalidation
  • DB에 값을 업데이트할 때마다 캐시 데이터는 삭제하는 방식
• write behind (write back)
  • 쓰기가 빈번한 서비스에 고려할 수 있는 방식
  • 대량의 쓰기 작업 시 많은 디스크 I/O를 피하기 위해 캐시에 값을 먼저 업데이트
  • 이후 특정 시간 간격 등에 따라 비동기적으로 DB에 업데이트
  • 저장되는 데이터가 실시간으로 정확하지 않아도 되는 경우 유용하다.
    • ex) 유튜브 동영상 좋아요 수
  • 물론 캐시에 문제가 생기는 경우 그 동안의 데이터가 날아갈 수도 있는 위험성이 존재한다.

캐시에서의 데이터 흐름

• 기본적으로 캐시는 임시 저장소이기에 원본 저장소보단 적은 양을 보관하는 서브셋이다.
• 레디스는 특히 메모리에 모든 데이터를 저장하기에 훨씬 적은 양을 보관할 수밖에 없다.

만료 시간

• 레디스에선 만료 시간, TTL(Time To Live)를 설정할 수 있다.
  • 초 단위로 설정 가능
  • 만료 시 자동 삭제
• EXPIRE 커맨드로 만료 시간을 설정할 수 있다.
  • 후에 해당 아이템 데이터를 조작해도 만료 시간은 변하지 않는다.
  • 하지만 키를 덮어 쓸 땐 만료 시간은 사라진다.

> SET a 100
"OK"

> EXPIRE a 60
(integer) 1

> TTL a
(integer) 58

메모리 관리와 maxmemory-policy 설정

• 키 만료 시간을 설정하더라도 너무 많은 키가 저장되면 메모리가 가득찰 수도 있다.
• maxmemory 설정과 maxmemory-policy 설정값을 통해 메모리를 관리할 수 있다.
• Noeviction
  • maxmemory-policy의 기본값
  • 레디스에 데이터가 가득 차도 데이터를 삭제하지 않는다.
  • 메모리가 가득 차면 에러를 반환한다.
  • 장애로 이어질 수 있기에 권장하지 않는다.
• LRU eviction
  • 데이터가 가득 차면 가장 최근에 사용되지 않은 데이터부터 삭제하는 정책
  • volatile-lru
    • 만료 시간이 설정된 키에 한해서만 LRU 방식으로 키를 삭제
    • 특정 키를 삭제하면 안되는 상황에 적절할 수 있다.
    • 하지만 모든 키에 만료 시간이 없다면 Noeviction과 동일하기에 장애로 이어질 수 있다.
  • allkeys-LRU
    • 공식 문서에 의하면 잘 모르겠다면 이 설정값을 권장한다.
    • 모든 키에 대해 LRU 알고리즘으로 키를 삭제
• LFU eviction
  • 데이터가 가득 차면 가장 자주 사용되지 않은 데이터부터 삭제하는 정책
  • 키가 오래 사용 되지 않았더라도 과거에 자주 액세스 했더라면 우선순위가 높아져 삭제 되지 않는다.
  • volatile-lfu
    • 만료 시간이 설정된 키에 한해서 LFU 방식으로 키를 삭제
  • allkeys-lfu
    • 모든 키에 대해서 LFU 알고리즘으로 데이터를 삭제

RANDOM eviction

• 레디스에 저장된 키 중 하나를 임의로 골라 삭제한다.
• 삭제될 키값을 계산하는 알고리즘을 사용하지 않아 레디스 부하를 줄일 수 있다.
• 랜덤 삭제이기 때문에 액세스 가능성이 높은 데이터를 삭제해 버릴 수도 있다.
• 이 설정 또한 volatile-random과 allkeys-random 설정이 존재한다.
• volatile-ttl
  • 만료 시간이 가장 작은 키를 삭제

캐시 스탬피드 현상

• 대규모 트래픽 환경에서 만료 시간을 어떻게 설정하냐에 따라 캐시 스탬피드와 같은 문제가 발생할 수 있다.
• 캐시 스탬피드 현상 예
  1. 애플리케이션1, 2가 look aside 방식으로 레디스를 사용
  2. 특정 키가 만료
  3. 서버들이 한꺼번에 원본 저장소에서 데이터를 읽고 레디스에 쓰게 되는데 중복 쓰기가 발생하게 된다.
     • 캐시하는 데이터가 무거운 쿼리를 사용해야 한다면 이는 곧 서비스 이슈로 이어질 수 있다.
• 캐시 스탬피드를 줄이기 위한 방법
  • 만료 시간을 너무 짧지 않게 설정
  • 키가 만료되기 전에 이 값을 미리 갱신하여 서버들이 한꺼번에 값을 계산하지 않도록 하기
  • PER 알고리즘
    • 캐시 스탬피드를 줄일 수 있는 알고리즘
    • currentTime - (timeToCompute * beta * log(rand())) > expiry
      • currentTime: 남은 만료 시간
      • timeToCompute: 캐시 값 계산 시간
      • beta: 기본적으로 1, 0보다 크게 설정 가능
      • rand(): 0과 1 사이 랜덤 반환 함수
      • expiry: 키를 재설정할 때 새로 넣어줄 만료 시간
    • 위 조건문이 true를 반환하는 애플리케이션은 데이터를 다시 계산한다.
    • 만료 시간이 가까워질수록 true를 반환할 확률이 증가한다.

세션 스토어로서의 레디스

세션이란

• 세션이란 서비스를 사용하는 클라이언트의 상태 정보를 의미한다.
  • 로그인 정보, 활동 정보 등을 저장
• 세션 스토어는 빠른 응답 속도가 필수적이다.
  • 유저가 로그인해 있는 동안 세션 데이터를 끊임 없이 읽고 쓰기 때문
• 레디스는 키-값 형식으로 사용이 간단하며 사용자 데이터를 저장하기에 용이하다.

세션 스토어가 필요한 이유

• 웹 서버가 하나라면 별도의 세션 스토어는 필요 없다.
  • 서버 내의 저장소를 사용
• 하지만 웹 서버가 여러 대로 늘어난다면 세션 스토어를 서버 외부에 둘 필요가 있다.
  • sticky session 방법을 쓸 수도 있지만 트래픽을 분산시킬 수 없는 상황이 발생할 수 있다.
  • all-to-all 방법을 쓸 수도 있지만 세션이 복사돼 저장되면서 불필요한 네트워크 트래픽이 발생한다.
  • DB를 세션 스토어로 사용하면 응답 속도가 느려져 서비스의 전반적인 응답 속도를 저하시킬 수 있다.
• 레디스를 세션 스토어로 사용하면 앞선 무든 이슈를 해결할 수 있다.
  • hash 자료 구조는 세션 데이터를 저장하기에 알맞다.

> HMSET usersession:1 Name Garimoo IP 10:20:104:30 Hits 1
OK
> HINCRBY usersession:1 Hits 1
1) "2"

캐시와 세션의 차이

• 레디스를 캐시로 사용
  • 캐시는 DB의 완전한 서브셋으로 동작
  • 캐시에 저장된 데이터는 여러 사용자가 함께 사용한다.
• 레디스를 세션 스토어로 사용
  • 데이터를 사용자 간 공유하지 않는다.
  • 데이터를 DB가 아닌 세션 스토어에만 저장한다.
  • 세션 스토어에 장애가 발생하면 데이터가 손실된 가능성이 있으므로 더 신중한 운영이 필요하다.