Redis란
NoSQL 중 하나로 key/value 형태의 값을 저장하는 인메모리 DB이다.
Redis 특징과 사용 시 주의사항
1) 싱글 쓰레드
1번에 1개의 명령어만 실행할 수 있다. 저장된 모든 키를 보여주는 명령어인 keys나 모든 데이터를 삭제하는 flushall 등은 운영 중에는 사용하면 속도가 느려지므로 절대 사용해서는 안된다.
keys 대신 scan을 사용하자.
2) 인메모리 DB
인메모리 DB이므로 빠른 속도가 강점이지만 큰 용량의 데이터를 담기에는 공간 제약이 크다. 실시간 처리는 레디스에서 하고 보관은 디스크 기반 스토리지에서 하는 구조가 성능과 효율이 좋다.
3) 시스템 데이터량에 맞게 메모리 용량을 설정해야 한다.
4) 컬렉션 당 데이터 사이즈는 100만 건 10초, 1000만 건 100초로 늘어나므로 1만 건 미만으로 관리하는 것이 좋다.
5) slave 복구 팁
slave는 master의 데이터 저장을 보조하는데 master가 죽었다가 살아났을 때 자신의 정보를 모두 삭제하고 그 데이터를 그대로 복제한다. 아무것도 없는 master를 그대로 연결하면 slave에 남은 데이터를 master로 되살릴 수 없다. 이를 막기 위해 복구할 데이터를 가진 시스템에 "Slave of no one" 명령어를 줘서 slave를 master로 승격시켜야 한다.
6) 동시접속자나 처리 속도를 높이기 위해 master는 write only, slave는 read only로 사용하면 좋다.
7) 레디스 메모리 max 도달 시 LRU(가장 오랫동안 참조되지 않은 것, Least Recently Used)을 삭제하거나 LFU(가장 적게 사용되는 것, Least Frequently Used)을 삭제하거나 TTL이 짧은 것을 삭제하는 등 메모리를 관리할 수 있다.
*TTL: 남은 expire 시간으로 expire 시간 초과 시 데이터를 삭제한다.
Redis Sentinel이란?
장애 발생 시 운영 서비스에 영향이 없도록 마스터 노드와 리플리카 노드를 계속 모니터링하면서, 장애 상황이 발생하면 리플리카 노드를 마스터로 승격시키기 위해 Auto Failover를 진행하게 해주는 서비스이다.
Redis Sentinel 동작 방식 및 구성 방법
Redis Sentinel은 Redis 상태 체크 시 다수결에 의해 결정되기 때문에 홀수로 구성해야 한다.
예를들어 Redis Sentinel-1이 Redis-master가 응답이 없다고(SDown) Redis Sentinel-2,Redis Sentinel-3에게 알린다. 만약 2,3 중 하나라도 응답에 성공했다면 Redis-master 상태를 정상으로 판단한다.
쿼럼이 3일 때, 만약, 2,3 모두 응답 실패 시 장애로 판단하고(ODown) failover를 시작한다. (쿼럼이 2라면 2, 3 중 하나만 응답 실패 시 장애로 판단)
- failover 시 복제서버 후보 선정 기준
-센티넬은 1차 복제 중에서만 마스터 후보에 오를 수 있다. (복제 서버의 복제 서버는 불가)
-1차 복제 서버 중 replica-priority 값이 가장 작은 서버가 마스터에 선정된다.
-0으로도 설정될 순 있지만, 이 경우에는 마스터로 승격이 안된다.
-값이 같다면 엔진에서 선택하게 된다. - 쿼럼의 정족수 셋팅
-쿼럼: 센티널 서버 몇 대가 SDown 상태로 판단할 때 Redis-master를 ODown으로 판단할 것인가에 대한 수이다. 수를 만족하는 경우 failover를 시작한다.
-쿼럼값이 1인 경우 오탐으로 failover가 시작될 수 있으므로 2로 설정(센티널은 3으로)하는 것이 좋다. (센티널이 5이면 쿼럼은 3으로)
-만약 쿼럼값이 2이고 센티넬도 2라면 센티넬 서버 1대가 장애 시 failover는 정족수를 채우지 못해 발생하지 않을 수 있다.
Redis Sentinel 구성, Redis 사용 시 주의사항
1) Failover Timeout 시간 만큼 데이터의 쓰기가 실패하게 된다. 데이터량에 따른 최적의 Failover Timeout 값을 찾고 sentinel.conf에 적용하는 것이 좋다. 쓰기 실패에 대비해서 장애 발생 시 db에서 데이터를 가져와서 리턴할 수 있도록 한다.
2) slave가 master보다 먼저 다운되고 master가 다운되는 경우 slave가 먼저 올라오면 master로 전환되지 않는다. slave의 conf에 복제서버라고 설정이 되어 있고 센티넬에서도 복제라고 인식하고 있기 때문에 slave conf에서 slaveof 삭제 후 구동해야 한다.
3) slave가 master가 되었을 때 클라이언트는 새로운 master의 포트를 알지 못하기 때문에 사전에 클라이언트의 master/slave 연결 포트를 정의하고 서버에서 로드밸런싱해서 master/slave로 연결시켜야 한다.
4) 기본적인 것이지만 Redis 메모리 사용량을 초과하도록 방치하면 안된다.
5) 부하를 분산하기 위해 Redis master는 Write-only로, Slave는 Read-only로 잘 구분해서 사용하자.
6) 최대 데이터량을 예측하고 필요 시 클러스터링과 샤딩을 검토하자.
7) 캐시 데이터가 잘못 캐시되어 올바르지 않은 데이터가 fetch 될 수 있으므로 Redis와 캐싱하고자 하는 데이터 저장소의 데이터가 일치하는지 모니터링하자.
*참고 자료
https://bryan.wiki/244
https://mozi.tistory.com/378
https://mangkyu.tistory.com/97
https://zdnet.co.kr/view/?no=20131119174125
https://waspro.tistory.com/697
