💡 [NHN FORWARD 2021] Redis 야무지게 사용하기 를 시청하며 정리한 내용입니다.

What is Redis?

전세계에서 가장 유명한 Caching 솔루션
대부분 cache 용도로 Redis 를 사용한다.

• Redis 좀 더 알아보기
  Remote dictionary server (외부 HashMap 서버)
  Single Thread 서버이다. → 시간 복잡도 고려 필요 (O(N) X)

1. Redis 를 cache 로 사용하는 방법

cache ?

• cache 란 사용자의 입장에서 데이터의 원래 소스보다 더 빠르고 효율적으로 엑세스 할 수 있는 임시 데이터 저장소를 뜻한다.
• 대부분의 어플리케이션에서 속도 향상을 위해 cache 를 사용한다. 따라서 cache 에 접근하는 것이 원본에 접근하는 것보다 쉽고 빨라야 한다.

Q. cache 는 언제 사용하는 것이 좋을까?

A. 동일한 데이터에 대해 반복적으로 액세스 하는 상황이 많을 때 !

의미있는 cache

1. 데이터의 재사용 횟수가 한 번 이상일 경우
2. 잘 변하지 않는 데이터일수록 cache 를 사용할 때 더 효율적

Redis as a cache

• 단순한 key-value 구조 : 사용이 간편하고 데이터 저장이 쉽다.
• in-memory 데이터 저장소 (RAM)
  • 빠른 성능 : 평균 작업 속도 < 1 ms, 초당 수백만 건의 작업 가능

캐싱 전략(Caching Strategies)

데이터의 유형과 해당 데이터에 대한 액세스 패턴을 잘 고려해서 선택해야 한다.

1. look-aside

데이터를 읽는 작업이 많을 때 사용한다. (가장 일반적으로 사용하는 방법)

1️⃣ 어플리케이션이 데이터를 찾을 때 cache 에 먼저 확인한다.

2️⃣ cache 에 데이터가 있을 경우, cache 에서 데이터를 가지고 오는 작업을 반복한다.

3️⃣ 만약 redis 에 찾는 키가 없다면 어플리케이션은 DB 에 접근해서 데이터를 가져온 뒤 다시 redis 에 저장하는 과정을 거친다.

⇒ cache 는 찾는 데이터가 없을 때에만 입력되기 때문에 Lazy Loading (지연로딩) 이라고도 부른다.

장점	단점
• 이 구조는 redis 가 다운되더라도 바로 장애로 이어지지 않고 DB 에서 데이터를 가져올 수 있다.	• cache 로 붙어있던 커넥션이 많이 있었다면, 그 커넥션이 모두 DB 에 붙기 때문에 DB 에 갑자기 많은 부하가 몰릴 수 있다.
	• 이런 경우에 cache 를 새로 투입하거나 DB 에만 새로운 데이터를 저장했다면 처음에 캐시 미스가 엄청 발생해서 성능에 저하가 올 수 있다.

⇒ DB 에서 cache 로 데이터를 밀어 넣어주는 작업 : Cache Warming 을 통해 방지 가능

ex) 티켓링크에서 상품 오픈 전 상품의 정보를 미리 DB 에서 cache 로 올려주는 작업을 매번 한다.

2. write-around

DB 에만 데이터를 저장한다.

1️⃣ 모든 데이터를 DB 에 저장한다.

2️⃣ 캐시 미스가 발생한 경우에만 DB 에서 데이터를 꺼내 cache 로 끌어 온다.

장점	단점
?	• cache 내의 데이터와 DB 내의 데이터가 다를 수 있다.

3. write-through

DB 에 데이터를 저장할 때, cache 에도 함께 저장한다.

장점	단점
• cache 에 항상 최신 데이터가 담겨있다.	• 저장할때마다 두 단계를 거쳐야하기 때문에 상대적으로 느리다.
	• 저장하는 데이터가 재사용되지 않을 수도 있는데 무조건 캐시에 넣어버려서 일종의 리소스 낭비가 될 수 있다.

• 따라서, 데이터를 저장할 때에는 expire time 을 설정해주는 것이 좋다.
  

expire time ?
몇 분, 혹은 몇 시간동안만 데이터를 보관하겠다는 의미

2. Redis 데이터 타입

• Strings : set 커맨드를 이용해 저장된 데이터는 모두 String 형태로 들어간다.
• Bitmaps : string 의 변형, bit 단위의 연산이 가능하다.
• Lists : 데이터를 순서대로 저장 == 큐로 사용하기 적절하다.
• Hashes : 하나의 키 안에 또다시 여러 개의 필드와 벨류 쌍으로 데이터를 저장한다.
• Sets : 중복되지 않은 문자열의 집합
• Sorted Sets : set 처럼 중복되지 않은 모든 값을 score 라는 숫자 값으로 저장한다. 저장될 때부터 score 순으로 정렬되며, score 가 같을 때에는 사전순으로 정렬된다.
• HyperLogLogs : 굉장히 많은 데이터를 다룰 때 주로 쓰며 중복되지 않는 값의 개수를 카운트할 때 사용한다. → 먼소리임?
• Streams : log 를 저장하기 가장 좋은 자료구조이다.

Best Practice - Counting

Strings	Bits	HyperLogLogs
• 단순 증감 연산	• 데이터 저장공간 절약	• 모든 string 데이터 값을 유니크하게 구분할 수 있다.
• INCR (increment) / INCRBY (increment by)	• 정수로 된 데이터만 카운팅 가능	• 대용량의 데이터를 카운팅 할 때 적절
		• 저장되는 데이터 개수에 상관없이 모두 12KB 로 고정 → 용량이 매우 작음
		• 한 번 저장된 데이터는 다시 불러올 수 없다. (경우에 따라 데이터 보호 가능) ex) 검색 엔진에서 검색된 유니크한 단어가 몇 개인지

Best Practice - Messaging

Lists	Streams
• 메세지 큐로 사용하기 적절	• 로그를 저장하기 가장 적절한 자료구조
• 자체적인 Blocking 기능 → 불필요한 polling 을 막을 수 있다, Event Queue 로 사용	• 실제 서버에 로그가 쌓이는 것처럼 append-only 방식으로 저장, 중간에 데이터가 바뀌지 않는다.
	• 카프카의 개념을 많이 차용

ex) 인스타, 페이스북, 트위터에는 유저별로 타임라인이 존재하고, 그 타임라인에는 내가 팔로우한 사람들의 데이터가 뜬다. 트위터에서는 각 유저의 타임라인에 보일 트윗을 캐싱하기 위해 redis 의 list 를 사용하는데, 이 때 RPUSHX 커맨드를 사용한다. 이를 이용해 트위터를 자주 이용하던 유저의 타임라인에만 새로운 데이터를 미리 캐시해 놓을 수 있으며 자주 사용하지 않는 유저는 caching key 자체가 존재하지 않기 때문에 이 유저들을 위한 데이터를 미리 쌓아두는 것과 같은 비효율적인 작업을 방지할 수 있게 된다.

3. Redis 에서 데이터를 영구 저장하기(RDB vs AOF)

Redis 는 in-memory 데이터 스토어

• 모든 데이터가 메모리에 저장되어있기 때문에, 서버나 redis 인스턴스가 재시작되면 모든 데이터 유실
• 복제 구조로 되어있어도 데이터 유실에서 안전하지 않다.

Redis Persistence Option

1. AOF (Append Only File)

• 데이터를 변경하는 커멘드가 들어오면 커맨드를 그대로 모두 저장한다. (redis 프로토콜 형태로 저장)
• 데이터가 추가되기만 해서 대부분 RDB 파일보다 사이즈가 커진다. → 주기적으로 압축해서 재작성되는 과정을 거쳐야 한다.

2. RDB

• 스냅샷 방식으로 동작 → 저장 당시의 메모리에 있는 데이터를 그대로 스냅샷으로 찍어서 저장한다. (바이너리 파일 형태로 저장)

AOF 와 RDB 모두 커맨드를 이용해 직접 파일을 생성하거나 원하는 시점에 자동으로 파일이 생성되도록 할 수 있다.

	자동	수동
AOF	redis.conf 파일에서 auto-aof-rewrite-percentage 옵션(크기 기준)	BGREWRITEAOF 커맨드 이용 → CLI 창에서 수동으로 AOF 파일 재작성
RDB	redis.conf 파일에서 SAVE 옵션(시간 기준)	BGSAVE 커맨드 이용 → CLI 창에서 수동으로 RDB 파일 저장 (SAVE 커맨드는 절대 사용 X)

AOF vs RDB 선택 기준

• 우선 redis 를 캐시로만 사용한다면, 둘 다 쓸 필요가 없다.

1. 백업은 필요하지만 어느 정도의 데이터 손실이 발생해도 괜찮은 경우

• RDB 단독 사용
• redis.conf 파일에서 SAVE 옵션을 적절히 사용
  ex) SAVE 900 1 → 900 초 동안 한 개 이상의 키가 변경되었을 때 RDB 파일을 재작성해라.

2. 장애 상황 직전까지의 모든 데이터가 보장되어야 할 경우

• AOF 사용
• APPENDFSYNC 옵션이 everysec 인 경우 최대 1초 사이의 데이터 유실 가능(기본 설정)

3. 제일 강력한 내구성이 필요한 경우

• RDB & AOF 동시 사용

4. Redis 아키텍처

Replication (복제)	Sentinel	Cluster
• 마스터와 리플리카만 존재하는 간단한 구조	• 마스터와 리플리카 노드 외에 센티널 노드가 필요하다.	• 센티널은 일반 노드들을 모니터링하는 역할을 한다.
	• 최소 세대의 마스터가 필요하며 샤딩 기능을 제공한다.

1. Replication 구성

• 단순한 복제 연결
• 모든 redis 의 구조에서 복제는 비동기식으로 동작한다. → 마스터에서 복제본에 데이터가 잘 전달됐는지 매번 확인하고 기다리지 않는다.
• 이 구조는 HA (High Availability) 기능이 없기 때문에 마스터에 장애가 발생하면 수동으로 변경해줘야 하는 작업들이 많다.
  (리플리카 노드에 직접 접속해서 복제를 끊어야 하고, 어플리케이션에서도 연결 설정을 변경하여 배포하는 작업이 필요하다.)

• HA (High Availability) 기능 ?
  자동 페일오버(장애 극복 기능)

2. Sentienl 구성

• 자동 페일오버 가능한 HA 구성(High Availability)
• 센티널 노드는 일반적인 다른 노드를 계속 모니터링 → 마스터가 죽으면 자동으로 페일오버를 발생시켜 기존의 리플리카 노드가 마스터가 된다. 이때 어플리케이션에서는 연결 정보를 변경할 필요가 없다. 어플리케이션은 센티널 노드만 알고 있으면 되고, 센티널이 변경된 마스터 정보로 바로 연결시켜 준다.
• 이 구조를 사용하기 위해서는 센티널 프로세스를 추가로 띄워야 하는데, 센티널은 항상 세대 이상의 홀수로 존재해야 한다.

3. Cluster 구성

• 스케일 아웃과 HA 구성 (High Availability)
• 데이터가 여러 마스터 노드에 자동으로 분할되어 저장되는 샤딩 기능(스케일 아웃)을 제공한다.
• 모든 노드가 서로 감시하고 있다가 마스터가 비정상 상태일 때 자동으로 페일오버를 진행한다.
• 최소 세대 이상의 마스터 노드가 필요하고, 리플리카 노드를 하나씩 추가하는 게 일반적인 구조이다.

5. Redis 운영 팁과 장애 포인트

redis 는 싱글 스레드로 동작한다.

한 사용자가 오래 걸리는 커맨드를 실행한다면 병목현상이 발생할 수 있다.

사용하면 안되는 커맨드

• keys → scan 으로 대체
• Hash 나 Sorted Set 등 자료구조
  • hgetall → hscan
  • del → unlink

변경하면 장애를 막을 수 있는 기본 설정값

• STOP-WRITES-ON-BGSAVE-ERROR = NO
  • RDB 파일 저장 실패 시 redis 로의 모든 write 불가능
• MAXMEMORY-POLICY = ALLKEYS-LRU
  • redis 를 캐시로 사용할 때 expire time 설정 권장
  • 메모리가 가득 찼을 때 MAXMEMORY-POLICY 정책에 의해 키 관리 : ALLKEYS-LRU → 모든 key 에 대해 lru 방식(가장 최근에 사용하지 않았던 key 부터 삭제한다)으로 key 를 삭제하겠다는 것을 의미

ref. https://www.youtube.com/watch?v=92NizoBL4uA