백엔드 데이터 인프라 보강편. 캐시 서버 한 대를 늘렸을 뿐인데 왜 캐시가 통째로 깨질까 — modulo 샤딩의 함정을 풀고, 해시 링·가상 노드로 이동을 최소화하는 일관된 해싱, 그리고 Redis Cluster가 그 대신 고정 슬롯을 택한 이유까지 정리한 학습 노트.
이 글은 백엔드 데이터 인프라 시리즈의 보강편이에요. 68편 Redis Cluster에서 16384개 슬롯으로 데이터를 샤딩하는 걸 봤죠. 그런데 그때 한 가지가 비어 있었어요 — "왜 굳이 슬롯을 쓸까, 그냥 hash(key) % 서버수 로 나누면 안 되나?" 이 질문의 답이 분산 캐시·샤딩의 기둥 개념인 일관된 해싱(Consistent Hashing)이에요. 이 글에서 풀어 가요.
서버를 늘렸을 뿐인데 왜 캐시가 통째로 깨질까
캐시를 여러 서버에 나눌 때 가장 먼저 떠오르는 방법은 나머지 연산이에요. hash(key) % N — 서버가 3대면 키를 0·1·2번으로 보내요. 단순하고 잘 동작해요. 평소엔.
문제는 서버를 한 대 추가하거나 뺄 때 터져요. N이 3에서 4로 바뀌면 % 3이 % 4로 바뀌고, 그러면 거의 모든 키의 목적지가 한꺼번에 달라져요. 캐시 입장에선 "내가 찾던 키가 죄다 엉뚱한 서버에 가 있다" — 대량 캐시 미스가 터지고, 그 미스가 전부 DB로 쏟아져요. 서버 한 대 늘리는 평범한 작업이 장애로 번지는 거죠.
비유하면 헬스장 사물함을 통째로 재배정하는 거예요. 사물함이 300개에서 400개로 늘었다고 모든 회원의 번호를 새로 뽑으면, 다들 어제 쓰던 사물함을 못 찾아 헤매요. 우리가 원하는 건 "새 사물함 100개만 나눠 주고 나머지는 그대로" 인데, modulo 방식은 그게 안 돼요.
해시 링 — 원으로 만들면 이동이 최소화된다
일관된 해싱의 아이디어는 단순해요. 해시 공간을 직선이 아니라 원(링)으로 보는 거예요.
0부터 2³²까지의 거대한 원을 그리고, 그 위에 서버도, 키도 같은 해시 함수로 점을 찍어요. 그리고 규칙은 하나 — "키는 자기 위치에서 시계 방향으로 처음 만나는 서버에 저장된다."
이렇게 하면 서버를 추가할 때 무슨 일이 생기는지 보세요. 새 서버는 링의 한 지점에 끼어들고, 그 지점과 바로 앞 서버 사이의 키들만 새 서버로 옮겨 가요. 나머지 키는 전혀 안 건드려요. 서버를 뺄 때도 마찬가지로, 그 서버가 맡던 구간만 다음 서버로 넘어가죠.
여기서 핵심 — modulo는 서버 수가 바뀌면 거의 전부 이동하는데, 일관된 해싱은 평균적으로 1/N 만큼만 이동해요. 헬스장으로 치면 "새로 늘린 구역의 사물함만 재배정" 인 셈이에요.
가상 노드 — 부하를 고르게 펴기
해시 링에 함정이 하나 있어요. 서버가 몇 대 안 되면 링 위에 점이 듬성듬성 찍혀서, 어떤 서버는 넓은 구간을, 어떤 서버는 좁은 구간을 맡게 돼요. 부하가 한쪽으로 쏠리는 거죠. 서버가 죽었을 때도 그 부하가 전부 바로 다음 한 서버로 몰려요.
해결책이 가상 노드(Virtual Node)예요. 서버 하나를 링 위에 점 하나로 두지 않고, "서버 A-1, A-2, A-3 …" 처럼 수십~수백 개의 가상 점으로 흩뿌려요. 그러면 각 서버가 링 곳곳의 작은 구간 여러 개를 맡게 되어 부하가 고르게 펴지고, 한 서버가 죽어도 그 부하가 여러 서버로 분산돼요. 실무의 일관된 해싱 구현은 대부분 이 가상 노드를 기본으로 깔고 있어요.
일관된 해싱의 가치는 한 줄이에요 — "서버 수가 바뀌어도 옮겨야 할 키를 최소로 줄인다." 분산 캐시·DB 샤딩·로드밸런서가 노드 증설/축소를 캐시 미스 폭발 없이 해내는 토대가 바로 이거예요.
Redis Cluster는 왜 일관된 해싱 대신 고정 슬롯을 쓸까
그럼 68편의 Redis Cluster는 왜 해시 링이 아니라 16384개 고정 슬롯을 쓸까요. 여기서 의문이 들 거예요 — 일관된 해싱이 그렇게 좋다면서요?
사실 슬롯 방식도 일관된 해싱과 같은 목표(이동 최소화)를 다른 방법으로 푸는 거예요. 차이는 제어권이에요.
- 해시 링은 키 이동이 자동이라 편하지만, "정확히 어느 키가 어디로 가는지" 를 운영자가 세밀하게 통제하긴 어려워요.
- 슬롯 방식은 16384개 슬롯을 노드에 명시적으로 배정해 둬요. 리샤딩할 때 "슬롯 100번부터 200번까지를 노드 B로" 처럼 슬롯 단위로 정확히 옮길 수 있어요. 어느 키가 어디 있는지 운영자가 또렷이 제어하죠.
즉 Redis는 "자동 편의" 대신 "명시적 제어"를 택한 거예요. 둘 다 "서버 수가 바뀌어도 전체를 재배치하지 않는다" 는 일관된 해싱의 정신을 공유해요. 개념의 뿌리를 알면 슬롯 방식이 왜 그렇게 설계됐는지가 보여요.
시험·면접 직전 압축 노트 — 일관된 해싱
hash(key) % Nmodulo 샤딩 = 서버 수 N 바뀌면 거의 모든 키 위치 변경 → 캐시 미스 폭발- 일관된 해싱 = 해시 공간을 원(링) 으로, 서버·키를 같은 공간에 배치
- 규칙 = 키는 시계 방향 첫 서버에 저장
- 서버 추가/삭제 시 이동량 = modulo는 거의 전부, 일관된 해싱은 평균 1/N만
- 가상 노드(Virtual Node) = 서버 하나를 링에 여러 점으로 흩뿌림 → 부하 균등 + 장애 부하 분산
- 가상 노드 없으면 = 구간 불균등 + 죽은 서버 부하가 다음 한 서버로 쏠림
- Redis Cluster의 16384 슬롯 = 일관된 해싱과 같은 목표(이동 최소화), 다른 방법(명시적 제어)
- 해시 링 = 자동·편의 / 슬롯 = 명시 배정·세밀한 리샤딩 제어
- 공통 정신 = "서버 수가 바뀌어도 전체를 재배치하지 않는다"
공식 문서: Redis — Partitioning에서 샤딩과 슬롯 재배치의 자세한 동작을 확인할 수 있어요.
시리즈 다른 편
같이 읽으면 좋은 글: