참고사이트: https://architecturenotes.co/redis/
1. 위 사이트의 내용을 번역하고 필요 내용은 찾아 정리하였습니다.
2. 영어로 자연스레 통용되는 것들은 영어와 한국어를 병행 표기하였습니다.
3. 그림은 저작권 문제가 있어, 따로 첨부하진 않았지만 이해를 돕기 위해 참고하여 새로 만들어 업로드 하였습니다.
📣 이전 내용과 다르게 Redis를 좀 더 깊게 이해하기 위한 포스팅 입니다. 최대한 풀어내려 노력하였지만 이해가 가지 않으시거나 잘못된 내용이 있다면 언제든 피드백 해주세요!😉
✅ Configuration(환경)에서 다룰 것
- Single Redis Instance
- Redis HA : 어떤 설정이 Redis를 강력한 무기로 만들었는가.
- Redis Sentinel
- Redis Cluster
1. Single Redis Instance
- 사용자는 Redis를 설치하고 Redis instance를 운영하면 끝이난다.
Q. Redis는 cache에서 일을 수행하는데, 어떻게 데이터의 영속성을 보장하는 것일까?
- Redis에 보내지는 명령어는 메모리에서 우선 처리된다.
그 후, 만약 영속성이 필요하다면 일정 간격으로 forked(분기된) 프로세스가 영속성을 가지는 RDB snapshot의 형태나 AOF(append-only files)로 저장시킨다.
- restart될 때, RDB snapshot이나 AOF의 파일을 읽어와 로드하여 Redis는 최신정보를 유지할 수 있고, client의 요청에 대응할 수 있다.
Q. Redis 자체가 실패할 경우에는 어떻게 대응하는 것일까? Secondary Instance
앞선 포스트에서 Redis를 강력한 무기로 만든 것이 바로 HA setup이라고 했었다.
- Redis의 강력한 setup 중 하나는 secondary deployment를 복제하여 둔다는 것이다.
- 데이터가 main instance에 쓰일 때, 해당 명령어의 복사본을 secondary instance에 저장하기 위해 복제 클라이언트 출력 버퍼로 보낸다.
- Secondary instance는 향상된 속도로 데이터를 읽을 수 있도록 도와주며, main이 idle 상태에 빠졌을 때 대응하기 위한 방법이기도 하다.
HA란?
- High Availability의 준말로, 작동 성능의 정도를 나타내는 말이며 보통, 가동시간(uptime)을 의미한다.
- 시스템이 빠르게 회복가능한 정도를 의미하기도하는데, 이는 신뢰성과도 연관된다.
- 데이터가 primary에서 secondary로 전송될 때, 데이터는 손실되지 않으면서도 자동적으로 실패를 감지하여 빠르게 회복할 수 있도록 한다.
⩗ 2차 저장소의 개수 제한은 없다. 이는 Redis의 읽기 성능을 향상시킨다. 여기서의 읽기 성능이란, fault tolerance가 강하다는 것이다
2. ✨ Redis Replication ✨
- Main instance는 복제 ID와 offset을 가지고 있다.
Replication ID, offset
offset 값은 main Redis가 deployment(배포)될 때마다 일어난다 - 두 요소는 복제가 계속될 수 있는 시점을 찾는데도 도움이 되며, secondary instance와 primary instance 간 동기화가 잘 이루어지고 있는지에 관해서도 확인할 수 있다.
😥 이게 무슨 말이지?? 차근차근 살펴보도록 하자.
Q. Offset의 역할은?
Primary instance와 Secondary instance 사이 같은 replication ID를 가지고 있다고 할 경우 offset이 다르다는 것은 동기화가 필요하다는 것을 알려준다.
- Main instance와 Secondary instance 사이 replication Id는 같으나 offset이 차이가 있는 것은 아직 동기화되지 않은 명령어들이 남아있다는 뜻이다.
- 만약 두 instance 사이 동기화가 잘 이루어지고 있지 않다면, 동기화를 위한 작업이 필요하다.
- RDB snapshot이나, 복제본을 보내어 동기화를 하는 등 primary instance와 secondary instance 사이 차이를 없애기 위한 작업이 발생한다.
Q. Replication ID는 뭘까?
- Redis instance가 Primary로 승격되거나 Primary로서 다시 처음부터 시작하게 된다면, 새로운 replication ID가 부여된다.
Q. Offset만으로 충분하지 않을까? 왜 Replication ID는 필요한 것일까?
- 새로 승격된 secondary instance가 앞선 primary instance를 추론하는데 사용된다.
- 공유한 공통 조상에 대해 추론하여 부분 동기화를 진행할 수 있다.
- 새로 승격된 primary instance가 이전 복제 ID를 기억하기 때문에 동기화를 수행할 수 있다.
Q. Replication ID로도 복제 시점을 추론할 수 없다면?
- 복제 ID가 완전히 다르고 강등된(이전에 Primary 였으나, 이번 배포에서 secondary 역할을 수행하는) Secondary의 이전 복제 ID를 알지못한다면 어떻게 될까?
- 값비싼 전체 동기화를 수행해야할 수 있다.
- 값비싼 동기화라는 것은 주기적으로 이루어지는 복제가 아닌 Redis의 데이터 영속성이나 High availability(fault tolerance)를 보장하기 위한 전체 동기화 과정이 자체적으로 이루어질 수 있다는 것을 의미한다.
3. Redis Sentinel - 분산 시스템에서의 Redis
- Sentinel이란 분산 시스템이다.
- Redis는 분산 환경에서 이식성이 좋아 Memcached 보다 더 선호되는 방식이라고 한다. (이전포스트 참고)
1) Sentinel이 가지고 있는 몇 가지 책임감
- 모니터링: 현재 main과 secondary instances가 잘 작동하고 있는지, 작동한다면 응답을 잘 하는지 확인한다.
- 알림: 만약 어떤 일이 발생한다면 Main이나 Secondary instances에 경고를 보낼 수 있도록 감시하는 역할을 하는 것이다.
- 구성관리: 다른 시스템 Zookeeper 및 Consul과 마찬가지로 현재 기본 인스턴스가 무엇인지를 알려준다.
- 자동장애조치: 현재 Primary instance를 더이상 사용할 수 없다는 것을 동의하는 여러 Sentinel processes이 있다면 장애 조치에 대응할 수 있는 방법을 제공한다.
정족수(Quorom): 동의를 얻기위해 필요한 최소한의 Sentinel 수
2) Sentinel을 사용할 때의 몇 가지 권장사항
- 가능하다면 애플리케이션 서버가 운영중인 곳에서 함께 Sentinel node를 만드는 것이 좋다.
- 네트워크 부재와 같은 현상이 일어날 경우 Sentinel node가 감시자의 역할을 할 수 없을 수 있다.
- 몇 개의 Sentinel을 운영하는 것이 좋을까?
| 서버의 수 | 정족수 | 허용된 실패 수 |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 4 | 3 |
- 위 표에서도 알 수 있듯, Sentinel은 동의를 얻기 위해 필요한 최소한의 Sentinel 수(정족수)를 가지고 있다.
3) Redis에 대해 짚고 넘어갈 것
✅ Sentinel 섹션에서 Redis에 관해 짚고 넘어가는 것이 있어 몇 가지 추가 정리를 하겠습니다.
- Redis의 복제는 비동기식이고, 승인을 독립적으로 추진하여 적어도 하나의 Secondary instance에서 승인을 확인하지 않으면 기본 인스턴스가 쓰기 수락을 중지한다.
4. Redis Cluster
❓ '그래도 캐시 메모리가 한정적인데 이를 저장소로 쓴다는 건 좀 무리가 있지않을까?' 라는 의문에 대답을 할 수 있는 섹션입니다. Redis는 수평적 확장을 허용하기 때문에 이를 염두해두고 Redis Cluster와 관련한 다음 내용을 읽는다면 개념을 이해하는 데 도움이 될 것입니다.
1) Scale-out 과 Scale-up
- Scale-out: 값싼 서버의 수를 늘려 시스템 성장에 대응하는 방식 (=수평)
- Scale-up: 서버의 성능을 높여 시스템 성장에 대응하는 방식 (=수직)
2) Redis - 수평적 확장
- Redis 클러스터는 Scale-out 방식을 채택한다.
- Redis는 Hashslot을 채택하여 클러스터 환경에서 데이터가 매핑될 수 있도록 한다.
- 16K hashslot을 이용하여 데이터가 cluster 사이에 적절히 분배될 수 있도록 돕는다.
- 이는 가동 중지 시간과 최소한의 성능 저하를 막을 수 있다.
클러스터가 늘어날 때, 새로운 해시번호를 부여하는 것이 아니라 전체 해시 슬롯을 이동하기만 하면 되므로 가동 중지 시간(downtime)과 성능저하를 막을 수 있는 것이다.
3) 챙겨가면 좋을 용어
- Shading: 여러 시스템에 저장 중인 데이터를 분산하여 저장하는 것
- 클러스터의 각 Redis instance는 전체 데이터의 조각으로 간주하고 Secondary instance에 저장 중인 데이터를 분산하여 저장한다.
5. Redis의 지속성 모델
- Redis는 캐시를 사용하여 저장하기 때문에, 지속성이 필요한 데이터인지 아닌지의 여부에 따라서, Disk-based DB에 따로 데이터를 저장할지의 여부를 선택할 수 있다.
이는 개발자가 데이터의 특성과 서버의 특성을 잘 파악하여 결정하여야한다.
1) RDB Files
- Redis는 Snapshot을 찍는다. Snapshot을 통해 자신이 복귀할 지점이나 데이터의 손실을 방지할 수 있다.
- 문제는 snapshot 사이의 데이터들을 복구할 길이 없다는 것이다.
snapshot이 사진이라고 생각한다면, 사진은 영상이 아니기 때문에 중간에 일어난 일에 대해 손실이 일어날 수 있다고 생각하니 이해가 더 쉬웠습니다.
- AOF 보다는 RDB가 메모리에 로드되는 속도가 더 빠르다.
2) AOF (Append Only File)
- 서버 시작 시, 다시 재생될 서버가 수신하는 모든 쓰기 작업을 기록하여 원본 데이터 세트를 재구성한다.
- snapshot보다는 내구성측면(snapshot 사이의 정보 손실과 같은)에서 장점이 있다.
- 작업이 발생하면, 로그에 버퍼링된다.
- 단점은, 압축되지 않아 RDB(Redis DataBase)보다 훨씬 더 많은 디스크를 사용할 수 있다는 것이다.
Q. 둘다 쓰면서 장점을 극대화하자!
- AOF와 RDB는 Redis instance에서 같이 쓰일 수 있다.
- tradeoff(하나를 주면 하나를 빼앗기는 것) 측면에서 본다면 durability(지속성) 측면에서는 장점이 될 수 있지만 speed 측면에서는 단점이 될 수 있다.
- 무엇이 장점일지는 Redis setup(설치) 단계에서 선택하면 될 것이다.
그러나 Redis를 재시작해야한다는 측면에서 보자면, 스피드에서 다소 손해를 보더라도 지속성을 택하는 것이 이로울 수 있다는 저자의 개인적 의견이 있었다.
6. Forking
- Redis에서 이해해야할 중요한 개념은 HA와 Persistence이다.
- Redis의 훌륭한 측면 중 하나는 forking의 속도를 높이는 것과 copy-on-write를 데이터의 영속성을 위해 성능적 측면에서 훌륭하게 해낸다는 것이다.
Forking: 운영체제에서 자신을 복사하여 새로운 프로세스를 만들어내는 것을 의미한다. 새로운 process ID를 부여하고 다른 정보를 추가하여 생성한다. forked process는 child로 간주한다.
- Redis 역시, 복사를 해야할 경우 memory를 공유하는 child process를 fork 한다.
- child process Redis는 snapshot process를 생성하여 snapshot을 찍어 메모리의 내용을 복제할 수 있도록 돕는다.
- 새로 써인 페이지에(메모리의 일부에) 변화가 있었다면 child process가 변화를 알아차리지 못할 수 있다. 이 때, snapshot을 이용하여 일부의 변화를 캐치하여 반영할 수 있는 것이다.
