티스토리 뷰
이번주차는 6장과 7장이었다.
7장은 추가 문서로 나중에 다시 쓰겠다.(6장만 이번주 하는 줄 착각했다..ㅎ)
6장 - 파티셔닝
왜 파티셔닝하나
복제가 같은 데이터를 여러 노드에 복사하는 것이라면, 파티셔닝은 데이터를 쪼개서 노드마다 다른 조각을 두는 것.
목적은 확장성. 실제 시스템에서는 복제와 파티셔닝을 결합해서 쓴다. (각 파티션을 다시 여러 노드에 복재해 장애 내성까지 확보한다.)
핵심 목표: 부하를 고르게 분산하는 것. 이게 깨지면 skew(쏠림) 이며, 부하가 몰린 파티션은 hot spot.
기본키 기준 파티셔닝 (키-값 데이터를 나누는 방식)
해시 방식의 절충안이 복합 키
ex) 카산드라는 키의 앞부분으로 해시 분산, 뒷부분으로 파티션 안에서 정렬을 유지한다. (한 사용자의 이벤트를 시간순으로 하면 범위 스캔으로 풀림)
해시로도 못 막는 것 - 단일 hot key.
ex) 특정 유명인의 게시글에 팔로워가 몰리는 상황.
해시를 해도 그 키는 한 파티션에 묶이게 된다.
이는 애플리케이션이 키에 랜덤 prefix/suffix를 붙여 인위적으로 쪼개는 식으로 대응해야한다.
(tradeoff <-> 읽을 때 여러 키를 합쳐야 한다.)
보조 인덱스 파티셔닝
보조 인덱스는 PK가 아닌 값으로 검색을 위한 것이다. 이 인덱스도 파티셔닝되면 나눠지게 된다.
로컬 인덱스는 쓰기를 한 곳에 모아 쓰기 증폭을 줄이는 대신 읽기를 분산해서 가져와야된다.
글로벌 인덱스는 읽기를 모으는 대신 쓰기를 증폭시킨다.
- 점선은 쓰기 흐름. 문서 893 저장할 때 따라가는 경로 (파티션 0으로도 가야됨)
리밸런싱
데이터,노드가 변하면 파티션을 재배치해야 한다.
1. 부하가 다시 고르게 분산된다.
2. 옮기는 데이터가 최소이다.
3. 리밸런싱 중에도 서비스가 계속되는 것.
특징
- 해시 mod N은 쓰면 안된다.
- N이 바뀌면 모든 키의 소속이 바뀌어 이동 비용이 크다.
- 고정 개수 파티션
- 노드 수보다 훨씬 많은 파티션을 미리 만들어 노드당 여러 개를 할당
- 장점
- 이동 최소: 노드 추가/제거 시 파티션 통째로 이사. 키 재해싱 x
- 운영 단순: 키 -> 파티션 매핑 불변.
- 이종 노드 대응: 성능 좋은 서버엔 파티션 많이, 약한 서버엔 적게 할당 가능.
- 동적 파티셔닝
- 파티션이 너무 커지면 split, 작아지면 merge.
- 초기 빈 DB의 단일 파티션 쏠림을 막으려면 pre-splitting(사전 분할)을 씀.
- pre-splitting: 첫 데이터 들어오기 전에 파티션 경계를 미리 그어두는 것.
- 노드 수 비례
- 노드 당 고정 개수의 파티션.
- 노드를 추가하면 기존 파티션을 무작위로 쪼개 가져간다.
- 장점
- 파티션 크기 안정: 노드 늘면 파티션도 늘어 -> 파티션당 데이터량 일정 유지
- 데이터 양 예측 불필요: 고정 개수는 처음에 파티션 몇 개 할 건지 잘 정해야 함. 이거는 노드 수에 자동 연동
- 확장 자연스러움: 노드 추가 = 새 노드가 기존 파티션 몇 개를 무작위로 쪼개 가져감.
요청 라우팅
이 키는 어디에 있나를 클라이언트가 알아야된다.
세가지 접근
1. 아무 노드에나 보내면 그 노드가 적절한 노드로 포워딩
2. 라우팅 계층을 둔다.
3. 클라이언트가 직접 파티션 배치를 앎.
보통 배치 정보 합의를 위해 Zookeeper같은 코디네이션 서비스를 쓰거나,
gossip 프로토콜로 노드끼리 상태를 퍼트린다.(카산드라)
gossip 프로토콜: 노드끼리 소문내서 클러스터 매핑 공유, 중앙 조정자 없이 라우팅 함.
느낀점
핫스팟 키 부분이 흥미로웠다.
DB단이 아니더라도 서버단에서도 충분히 일어날 수 있는 일인데
랜덤으로 prefix/suffix 로 추가하는 것이 간단하고 이해가 바로 됐다.
또한 복합키를 통해 분산과 정렬 이점을 챙기는 방법도 처음 알게 되었다.
이번 장은 아는 DB 지식을 조합하여 해결할 수 있다는 것을 느끼게 한 장이었다.