Redis 3 클러스터 운영 메모

Redis 3.0 cluster 모드 운영 시작한지 석달. 장단점 메모.

우리 구성: 6노드 (마스터 3 + 슬레이브 3). 3노드씩 다른 서버에 분산. 해시슬롯 16384개를 마스터 3개가 나눠 가짐.

셋업

redis-trib.rb create --replicas 1 \
  10.0.1.11:6379 10.0.1.12:6379 10.0.1.13:6379 \
  10.0.1.11:6380 10.0.1.12:6380 10.0.1.13:6380

예전엔 redis-trib.rb (ruby) 로만 가능했는데 곧 redis-cli에 cluster 명령 통합될거라고 함.

클라이언트. redis-py의 경우 redis-py-cluster 별도 라이브러리 써야 함. MOVED 응답 받으면 클라이언트가 다른 노드로 재전송. 일반 redis-py로는 cluster 못 씀.

제약사항:

• multi-key 연산은 모든 키가 같은 슬롯에 있을 때만 동작. MSET key1 v1 key2 v2 에서 key1/key2가 다른 마스터면 에러
• hash tag로 같은 슬롯에 묶을 수 있음: user:{123}:profile 과 user:{123}:settings 는 {123} 기반으로 같은 슬롯
• Lua 스크립트도 같은 슬롯 키만 가능
• SELECT (DB 선택) 안됨. 0번 DB만 씀

장애 시나리오 경험담: 마스터 노드 하나가 메모리 부족으로 죽음. Redis sentinel 기반이 아니라 cluster 모드는 노드들끼리 gossip protocol로 감시. cluster-node-timeout (우리 설정 15초) 지나면 슬레이브가 마스터로 승격. 대충 20초 정도의 다운타임.

클라이언트 앱에서 이 기간 동안 에러를 어떻게 처리할지가 포인트. 우리는 재시도 로직을 래퍼에 넣어놔서 사용자 체감은 거의 없었음. 다만 재시도는 "읽기" 에만 적용. 쓰기는 retry하면 중복될 수 있으니 조심.

아쉬운 점: 샤드 리밸런싱이 아직 손이 많이 감. 자동 rebalance가 기본 활성화 아님. redis-trib.rb reshard 수동 실행. 클러스터 노드 추가/제거도 운영 절차 나름 복잡. AWS ElastiCache 쓸까 이런 고민도 함.