계정 키를 해싱해 DB를 나눴는데 한 샤드에 부하가 몰립니다. 샤드를 추가하면 해결되며 기존 데이터는 어떻게 옮기나요?
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
해시 샤딩은 키를 저장 단위에 분배하지만 실제 요청량과 작업 비용까지 균등하게 만들지는 않습니다. 계정 수가 같아도 한 계정이 모든 요청을 만들 수 있습니다. 샤드별 키 수와 요청량·CPU·디스크·락 대기·상위 키 비중을 따로 보고 핫 샤드와 단일 핫키를 구분하겠습니다.
증설의 범위
hash(key) mod N은 N이 바뀌면 많은 키의 목적지가 달라집니다. 일관된 해싱은 이동량을 줄이고 논리 bucket과 물리 샤드 매핑은 라우팅 안정성을 높이지만, 데이터 복사와 변경 추적을 없애지 않습니다. 단일 핫키는 샤드를 추가해도 한 목적지에 남습니다. 읽기는 캐시·replica로 나눌 수 있지만 잔액 같은 쓰기는 순서·원자성이 필요합니다.
운영 중 이동
일관된 snapshot을 대상에 복사하고 이후 변경 로그를 따라잡게 한 뒤 라우팅과 쓰기 소유권을 전환합니다. 짧은 쓰기 중단이 가능하면 진행 중 작업을 끝내고 검증한 뒤 전환하는 단순한 방식이 안전합니다. 무중단이면 세대·펜싱 토큰으로 옛 라우팅의 늦은 쓰기를 저장소가 거절하게 합니다.
건수·체크섬·버전 범위와 로그 끝을 확인한 뒤 complete로 올립니다. rollback 때 대상의 성공 쓰기를 원본에 반영한 뒤 권위를 다시 넘길지, 되돌리지 않고 원본을 읽기 전용으로 유지하며 전진 복구할지도 정합니다. 검증은 이전 라우팅 요청·재시도·프로세스 정지·롤백을 주입하고 데이터 대사와 늦은 쓰기 거부를 봅니다. 안전한 증설은 키 배치보다 누가 지금 쓸 수 있는지를 정하는 문제입니다.
이동 기준점과 새 쓰기를 연결합니다
스냅샷을 복사하기 전에 그 스냅샷 이후 변경을 놓치지 않을 로그 위치를 확보해야 합니다. 복사 중 주문이 수정되면 대상은 스냅샷의 옛 행을 받은 뒤 그 다음 로그를 적용합니다. 로그를 너무 일찍 읽고 나중에 도착한 스냅샷이 덮지 않도록 적용 순서나 행 버전을 관리합니다. 건수가 같아도 값과 삭제 상태가 다를 수 있어 체크섬·버전·삭제 표식과 업무 불변식을 함께 대조합니다.
전환할 때 라우터의 캐시가 모두 동시에 바뀌지 않습니다. 옛 샤드는 이전 세대의 쓰기를 거절하거나 새 위치로 안내하고, 신규 샤드는 자신이 현재 권위 세대인지 저장 경계에서 확인합니다. 라우팅 변경만으로 진행 중 트랜잭션과 늦은 재시도가 사라지지는 않습니다. 대상에 새 쓰기가 들어간 뒤 되돌리려면 그 쓰기까지 원본에 반영하거나 새 권위 전환을 수행해야 합니다.
가상 노드는 여러 작은 범위를 분산해 노드별 편중을 줄이지만 한 키 자체의 부하는 쪼개지 못합니다. 인기 문서 읽기는 복제할 수 있어도 한 계정 잔액의 조건부 갱신은 동일 권위 경계가 필요합니다. 분할할 수 있는 누적 통계와 분할하면 원자성이 깨지는 상태를 구분하고, 이동 대역폭이 정상 요청의 지연 예산을 침범하지 않도록 복사 속도를 제한하겠습니다.
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- 키 수와 요청 부하를 구분한다.
- 해싱 방식이 이동을 줄일 뿐 없애지 않음을 설명한다.
- 중단·무중단 전환을 비교한다.
- snapshot·로그·펜싱·rollback을 검증한다.
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- 키 개수가 균등하면 부하도 균등하다고 말한다.
- 일관된 해싱이면 이동이 없다고 말한다.
- 라우팅 변경 뒤 이전 요청이 사라진다고 가정한다.
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.