[Develop] Redis 캐시로 사용하기

본 포스팅은 아래 유튜브 영상을 정리한 내용입니다.

• https://www.youtube.com/watch?v=92NizoBL4uA&t

정리

- 캐시란?

데이터의 원래 소스보다 더 빠르고 효율적으로 액세스할 수 있는 임시 데이터 저장소
언제 사용하는게 좋을까?:

• 같은 데이터에 반복적으로 액세스할 때 (데이터의 재사용 횟수가 한 번 이상일 때)
• 변하지 않는 데이터

레디스는 캐시로 사용하기 좋은 솔루션입니다.
레디스 특징:

• 단순한 key-value 구조
• In-memory 데이터 저장소(RAM) -> 빠른 성능(초당 작업속도 < 1ms, 초당 수백만 건의 작업 가능)

- 캐싱 전략

레디스를 캐시로 사용할 때, 배치 전략:

• 캐싱 전략
• 데이터 유형, 데이터 액세스 패턴을 고려하여 선택해야 함

읽기 전략: Look-Aside

캐시에서 먼저 조회하고 없다면 db에서 찾는 방식. 이후 redis 업데이트.

- 장) 예외가 발생하지 않는다.

- 단) 커넥션이 redis와 db가 연결되어 있어, db에 많은 부하가 올 수 있음.

- 해결법) Cache Warming을 해서 미리 캐시에 db값들을 업데이트함.

쓰기 전략: Write-Around / Write-Through

- Write-Around: DB에만 저장하는 것

• 장) 상대적으로 빠름
• 단) 읽기일 때, 지연, miss 확률 높음

- Write-Trough: cache + DB에 모두 저장하는 것

• 장) miss확률 낮음.
• 단) 리소스 낭비

- Redis Data Types

Redis는 자체적으로 다양한 자료구조를 제공한다.

- List -> Queue로 사용하기 적절

- HyperLogLogs -> 굉장히 많은 데이터를 사용할 때 사용. 중복되지 않는 값의 개수를 카운트할 때 사용.

- Streams -> Log 저장할 때 좋음

COUNTING 상황 시

• Strings
  • 단순 증감 연산
  • INCR / INCRBY / INCREBYFLOAT / HINCRBY / HINCRBYFLOAT /ZINCRBY
• BITS
  • 데이터 저장공간 절약
  • 정수로 된 데이터만 카운팅 가능
• HyperLogLogs
  • 대용량 데이터를 카운팅할 때 적절 (오차 0.81%)
  • set과 비슷하지만 저장되는 용량은 매우 작음
  • 저장된 데이터는 다시 확인할 수 없음

MESSAGING 상황 시

• Lists
  • Blocking 기능을 이용해 Event Queue로 사용 가능
  • 키가 있을 때만 데이터 저장 가능 - LPUSHX /RPUSHX (이미 캐시되어 있는 피드에만 신규 트윗을 저장)
• Streams
  • 로그를 저장하기 가장 적절한 자료구조
  • append-only
  • 시간 범위로 검색 / 신규 추가 데이터 수신 / 소비자별 다른 데이터 수신(소비자 그룹)
  Redis에서 데이터 영구 저장 방법
  • Redis는 In-memory 데이터 스토어
    • 서버 재시작 시 모든 데이터 유실AOF(Append Only Files) / RDB
  • AOF: 데이터 변경 커맨드 그대로 저장
  • RDB: 당시 메모리를 snapshot으로 저장
  • 백업은 필요하지만 어느 정도 데이터 손실이 발생해도 괜찮은 경우? -> RDB
  • 장애 상황 직전까지의 모든 데이터가 보장되어야 할 경우 -> AOF
  • 제일 강력한 내구성이 필요한 경우 -> RDB + AOF

Redis 아키텍쳐 선택 노하우 (Replication vs Sentinel vs Cluster)

• sentinal: 일반 노드들을 모니터링
• cluster: 최소 3대의 마스터 필요.

Replication

• 단순한 복제 연결
• 비동기식 복제
• HA 기능이 없으므로 장애 상황 시 수동 복구

Sentinel 노드

• 마스터 노드가 죽으면 자동으로 페일오버가 가능하도록 함

Cluster 구성

아키텍쳐 선택 기준

 

운영 시 꿀팁

- Redis는 Single Thread로 동작 (키를 보여주는 커맨드)