[Redis] 5장. 레디스를 캐시, 세션으로 사용하기

TL;DR

• 레디스는 캐시, 세션 용도로 사용되며 캐시는 데이터 저장소의 서브 셋, 세션은 정해진 시간동안 저장되는 정보라는 차이점이 있다.
• 레디스는 평균 읽기 및 쓰기 작업 속도가 1ms이기 때문에 성능 개선이가능하며, 데이터베이스 커넥션 I/O 를 줄여 CPU, 메모리 리소스를 줄일 수 있다.
• 장애 대응 기능을 갖춘 고가용성 솔루션이며, 스케일 아웃을 지원한다.

캐시

• 데이터의 원본보다 더 빠르고 효율적으로 액세스할 수 있는 임시 데이터 저장소

효과적인 케이스

• 원본 데이터 저장소에서 원하는 데이터를 찾기 위해 검색하는 시간이 오래 걸리거나, 매번 계산을 통해 데이터를 가져오는 것
• 쓰기보다 읽기에 특화된 데이터인 경우
  • 캐시에 저장된 데이터가 잘 변하지 않는 데이터인 경우
  • 캐시에 저장되는 데이터가 자주 검색되는 데이터인 경우

캐싱 전략

• 캐시를 어떻게 배치해서 애플리케이션에 사용할 것인지 전략을 세운다.

읽기 전략 - look aside

 

• 가장 일반적인 배치 전략
• 레디스를 곁에 두고 데이터가 먼저 캐시에 있는지 확인하고 캐시 히트 발생하면 데이터 읽음
• 캐시 미스일 때는 데이터를 캐시에 저장
• 데이터가 없을 때만 레디스에 데이터가 저장되기 때문에(필요할 때 저장) Lazy Loading 방식이라고 불린다.

장점

• 레디스에 문제 생겼을 때 데이터베이스에서 가져오도록 구현하면 되어서 서비스 장애 대응이 가능하다
  
  • 다만 서비스 장애시 모든 커넥션이 DB로 쏠릴 것이므로 부하가 발생해 성능에 영향을 미칠 수 있다.

주의

• 사용 중인 서비스에 처음 레디스를 도입할 때 이 방식을 사용하면 Cache warming 해주는 것이 좋다. 그렇지 않으면 모든 데이터가 레디스에 업근할 것이고 캐시 미스가 일어나 성능에 영향을 미칠 수 있다.
  • 예매 서비스 개발할 때, 상품 오픈 전 데이터베이스에 저장된 데이터를 레디스에 캐시 워밍

Cache incosistency

- 데이터의 원본 데이터베이스만 저장되면 데이터 간 불일치가 발생할 수 있다.

- 쓰기 전략을 잘 활용해야한다.

 

쓰기 전략

1. Write Through

 

• 데이터베이스 전 항상 업데이트 하는 방식
• 단점
  • 매번 2개의 저장소에 저장되어야 하기 때문에 시간이 많이 소요될 수 있다.
  • 리소스 낭비가 발생할 수 있다. (다시 사용되지 않는 데이터도 저장) -> 만료 기간 설정 필수

2. Cache Invalidation

- 데이터베이스 값 업데이트 할 때 캐시는 삭제

- 삭제하는 것이 새로운 데이터 저장하는 것보다 리소스 적게 사용하기 때문에 write through 단점 보완

 

3. Write Behind(write back)

• 쓰기가 빈번하게 발생한는 서비스일 떄 고려해볼 수 있음
• 데이터베이스에 대량의 쓰기 작업이 발생할 수 있을 때 데이터를 모아놓고 비동기적으로 데이터베이스에 업데이트하는 방식
• 실시간 집계가 필요하지 않는 경우 주기를 정해놓고 업데이트
  • 페이스북 좋아요 모아놓고 5분 후에 한 번에 업데이트
• 단점
  • 데이터가 날아갈 수 있는 위험성을 감수해야한다. 

 

Time To Live 

• 메모리는 데이터베이스의 서브셋이며 따라서 데이터를 언젠가는 삭제해야한다. 
• 레디스에서는 초 단위로 표현되며, 시간 지난 후 자동 삭제된다

커맨드

EXPRIRE 만료 시간 설정 (PEXPIRE: 밀리세컨드)

TTL 만료 시간 확인 

 

키 만료 방식

레디스에서 만료 시간 지났다고 바로 삭제되는 건 아니다.

 

Passive

클라이언트가 키에 다시 접근하려고 시도할 때

다시 접근하지 않을 경우 삭제되지 않음

Active

TTL 값이 있는 키 중 20개를 랜덤하게 뽑고 메모리에서 삭제

1초에 10번 20개의 키를 랜덤하게 뽑아 TTL 확인 후 만료되면 삭제

 

 

메모리 관리와 삭제 정책(Maxmemory-policy)

TTL 설정해도 메모리는 제한적이기 때문에 부족하고 가득찰 수 있다. 그 때 전략도 고려한다.

최대 저장 용량은 maxmemory 설정한다

Noeviction

• 임의로 데이터를 축출하지 않는 방식이다. 데이터를 애플리케이션에서 관리할 때 사용. (삭제는 우리가 판단) 
• 그냥 에러를 반환한다. -> 관리자가 데이터를 직접 지워야한다. 
• 캐시 용도로 사용할 떄 권장하지 않는다. 

 

Least-Recently Used Eviction

• 최근에 사용되지 않은 데이터부터 삭제하는 정책
• 근사 알고리즘. 정확하게 찾아내는 것이 CPU, 메모리 낭비이기 때문에 근사치로 찾는다.
• 알고리즘
  • Volatile-LRU
    • 만료시간이 있는 키만 대상
    • 모든 키에 만료기간 없으면 장애 유발할 수 있음
  • Allkeys-LRU
    • 모든 키가 대상

Least-Frequently Used Eviction

• 데이터가 가득 찼을 때 자주 사용되지 않은 데이터부터 삭제하는 정책
• 근사 알고리즘. 정확하게 찾아내는 것이 CPU, 메모리 낭비이기 때문에 근사치로 찾는다.
• 알고리즘
  • Volatile-LFU
  • Allkeys-LFU

 

Random Eviction

• 랜덤 방식이며 키 값 계산하지 않아도 되어서 부하 줄일 수 잇는 방법 (다만 부하 목적으로 사용하는 건 올바르지 못함. 오히려 사용되는 데이터가 날아가면 성능 저하가 생김)
• 설정
  • Volatile-Random
  • Allkeys-Random

 

Volatile-TTL

• 만료 시간이 가장 작은 키를 삭제
• 삭제 예정인 키 미리 삭제, 마찬가지로 근사 알고리즘

 

 

Cache Stampede 

• 스탬피드(stampede)란 치타나 사자, 호랑이에 쫓긴 놀란 짐승들이 일정한 방향으로 도망가는 모습을 가리키는 뜻인데, 여러 애플리케이션에서 쓰던 키가 만료되었을 때 동시에 데이터베이스에 접근하는 것을 말한다
• 애플리케이션들은 duplicate read를 할 것이고, 읽어온 데이터를 다시 레디스에 쓰기 때문에 duplicate write 도 발생한다.
• 계단식 실패 Cascading Failure 라고도 부른다.

캐시 스탬피드 현상을 막기 위한 방법들

적절한 만료 시간 설정

• 만료 시간을 너무 짧게 설정하지 않는 것.
• 여러 애플리케이션에서 한꺼번에 접근해야 하는 데이터이면 만료 시간을 충분히 깊게 설정해주기

 

선 계산

• 애플리케이션에서 계산 데이터를 데이터를 만료 전에 갱신해주면 불필요한 부하를 줄일 수 있다. 
• 만료 시간보다 갭을 줘서 갱신한다. 

 

PER(Probabilistic Early Recomputation) 알고리즘

• 캐시 값이 만료되기 전에 언제 데이터베이스 접근해서 데이터 가져오는지 계산할 수 있음

 

세션 스토어로서의 레디스

세션?

서비스를 사용하는 클라이언트의 상태 정보

쇼핑몰 사이트에서 유저가 장바구니에 어떤 물건을 담았는지, 최근 담은 아이템은 어떤 것인지 등

 

서버 종속 막기 위한 세션

- 어떤 웹 서버에 연결되어도 동일한 세션 데이터 접근할 있도록해 트래픽을 효율적으로 분산시킬 수 있음

- 데이터 일관성도 고려하지 않아도 됨

 

캐시와 세션의 차이

 

- 세션은 로그인 했을 때 세션 데이터 가져오고, 로그아웃 하면 데이터베이스에 저장한다.