[Backend/Redis] Redis 야무지게 사용하기

 해당 포스트 내용은 아래 강의 내용을 정리/요약한 내용입니다.

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

 

 

1. Redis 캐시로 사용하기

1.1. 캐시(Cache)란?

 사용자의 입장에서 데이터의 원래 소스보다 더 빠르고 효율적으로 액세스 할 수 있는 임시 데이터 저장소. 속도 향상을 위해 사용. (원본에 접근하는 것보다 빠르게 접근 가능하도록 함)

1.2. Redis를 캐시로 사용할 때의 장점

• 단순한 key-value 구조로 어떤 데이터라도 쉽게 저장 가능.
• In-memory Data Store(모든 데이터를 메모리에 올려둠)로 빠른 처리 속도를 가짐

1.3. 캐싱 전략

[Read 전략] Look-Aside (Lazy Loading)

• 데이터를 찾을 때 우선 cache를 확인하고, 찾는 데이터가 없다면(cache miss가 발생한다면) DB에 접근해서 해당 데이터를 cache에 저장한다
• 장점: DB에서 데이터를 가져올 수 있기 때문에 redis가 다운되더라도 바로 장애로 이어지지 않는다
• 단점: cache를 새로 투입하거나 DB에만 새로운 데이터를 저장한 경우, cache miss가 너무 많이 발생하여 성능에 저하가 올 수 있음 -> cache warming(미리 DB에서 cache로 데이터를 밀어 넣어주는 작업)으로 해결

[Write 전략] Write-Around

• 일단 모든 데이터를 DB에 저장하고 cache miss가 발생한 경우만 cache에서 데이터를 끌어온다
• 단점: cache 내 데이터와 DB 내 데이터가 다를 수 있음

[Write 전략] Write-Through

• DB에 데이터를 저장할 때 cache에도 함께 저장한다
• 장점: cache가 항상 최신 정보를 가짐
• 단점1: 저장할 때마다 두 단계 스텝을 거쳐야 하기 대문에 상대적으로 느림
• 단점2: 저장하는 데이터가 재사용되지 않을 수 있는데 무조건 캐시에 넣기 때문에 리소스 낭비에 해당 -> expire time을 설정하여 일정 시간 동안만 데이터를 보관 (이 값을 어떻게 관리하는지가 장애 포인트가 될 수 있음)

 

2. Redis 데이터 타입

• String (Set command를 이용해 저장되는 데이터는 모두 String 형태로 들어감)
• Bitmaps (String의 변형, bit 단위 연산이 가능)
• Lists (queue로 사용하기 적절)
• Hashes (하나의 key 안에 다시 여러개의 field와 value 쌍으로 데이터를 저장)
• Sets (중복되지 않은 문자열의 집합)
• Sorted Sets (set처럼 중복되지 않은 값을 저장하지만, 모든 값을 score라는 숫자 값을 기준으로 정렬, score가 같을 때는 사전 순으로 정렬)
• Hyper LogLogs (많은 양의 데이터를 다룰 때 사용. 중복되지 않는 값의 개수를 count 할 때 사용. 저장된 데이터를 다시 불러와서 확인할 수 없다는 특징이 있음)
• Streams (log를 저장하기 좋은 자료 구조, 모든 데이터는 append-only 방식으로 저장되며, 중간에 데이터가 바뀌지 않음) 

 

3. Redis에서 데이터를 영구 저장하려면? 

 Redis는 In-memory Data Store로, 모든 데이터가 메모리에 저장되어 있기 때문에 서버나 레디스 인스턴스가 재시작되면 모든 데이터가 유실됨. 데이터 유실에 있어 안전하지 않은 특징 때문에, Redis를 cache 이외의 용도로 사용한다면 적절한 데이터의 백업이 필요하고, 따라서 데이터를 영구 저장하는 두 가지 방법을 제공

• AOF (Append Only File) : 데이터를 변경하는 command가 들어오면, command를 그대로 모두 저장. append only,로 동작하기 때문에 데이터가 추가되기만 해서 대부분 RDB 파일보다 커지게 됨
• RDB : 저장 당시의 메모리에 있는 데이터 그대로를 사진 찍듯 찍어서 파일로 저장 (snapshoot 방식)

 Redis를 cache로만 사용한다면, 굳이 영구저장 기능이 필요하지 않음. 그렇지 않은 경우 선택 기준은 아래와 같음

• 백업이 필요하지만, 어느 정도 데이터 손실은 감수할 수 있어 → RDB 사용
• 장애 상황 직전까지의 모든 데이터가 보장되어야 해 → AOF 사용
• 가장 강력한 내구성이 필요해 → RDB, AOF를 동시에 사용

 

4. Redis 아키텍처 선택 노하우 (Replication vs Sentinel vs Cluster)

 

4.1. 각 Architecture의 구성과 특징

Replication 구성

•  구조: master와 replica만 존재하는 간단한 구조
• 특징: 단순히 복제만 연결된 상태. 비동기식 복제 (master에서 복제본에 데이터가 잘 전달되었는지 매번 확인하고 기다리지 않음)
• 단점: HA 기능(자동 failover)이 없으므로 master에 장애가 발생하면 수동으로 변경해야 할 작업이 많음 (replica 노드에 직접 접속해서 복제 끊기, 애플리케이션에서 연결 설정 변경해서 배포)

Sentinel 구성

• 구조: master와 replica 노드 위에 추가로 sentinel 노드를 필요로 함
• sentinel: 일반 노드들을 모니터링하는 역할. 모니터링하다가 master가 죽으면 자동으로 failover를 발생시켜 기존의 replica 노드가 master가 된다.
• 장점: 애플리케이션에서는 sentinel 노드만 알고 있으면 됨. (sentinel이 master가 변경되면 바로 master 정보로 연결해줌)
• sentinel은 항상 3대 이상의 홀수로 존재해야 함 

Cluster 구성

• 구조: 최소 3대의 master가 필요
• shading 기능을 제공 (데이터가 여러 master 노드에 자동으로 분할되어 저장)
• 모든 노드가 서로를 감시하고 있다가, master가 비정상 상태일 대 자동으로 failover 진행

4.2. Architecture 선택 기준

• HA(자동 failover) 기능이 필요하다 → Sentinel 구성 사용
• HA 기능과 Shading 기능이 모두 필요하다 → Cluster 구성 사용
• 복제 기능이 필요하다 → Replication 구성 사용
• 모두 필요하지 않다 → Stand-Alone (master 하나를 띄운 구조