파티셔닝과 파일 스토리지
- 10.1 Range partitioning
- 10.2 Hash partitioning
- 10.3 Blob storage architecture
데이터가 단일 머신에 안 담기면 파티셔닝(sharding) — 여러 노드에 나누는 거야. 그리고 파일 스토리지는 이 파티셔닝과 복제 패턴이 실전에서 어떻게 조합되는지 보여주는 완벽한 쇼케이스지.
파티셔닝은 공짜가 아니야. 요청을 올바른 노드로 보내는 게이트웨이 서비스, 여러 파티션에 걸친 집계, 분산 트랜잭션, 핫스팟, 리밸런싱 — 복잡성의 대가가 상당해. 두 가지 전략이 있는데, **범위 파티셔닝(range partitioning)**은 키의 사전순 범위로 나눠. 파티션이 정렬된 채로 저장되니까 범위 스캔이 빨라. 근데 키 분포가 균일하지 않으면 핫스팟이 생겨 — 날짜 기준이면 현재 날짜 파티션에 요청이 몰리잖아. 리밸런싱은 정적(처음에 많이 만들어두고 노드 추가 시 이전)과 동적(커지면 분할, 작아지면 병합) 두 가지가 있어.
**해시 파티셔닝(hash partitioning)**은 키를 해시 함수로 돌려서 파티션을 결정해. 분포가 균등해지지. hash(key) mod N이 가장 단순하지만 파티션 추가 시 대규모 셔플링이 발생해. 이상적으로는 파티션 추가 시 K/N개의 키만 이동해야 하잖아 — 이 속성을 가진 게 **일관된 해싱(consistent hashing)**이야. 키와 파티션 식별자를 **원형(circle)**에 배치하고, 각 키를 시계 방향으로 가장 가까운 파티션에 배정하는 거지. 새 파티션이 추가되면 그 파티션으로 매핑되는 키만 재배정돼. 해시의 단점은 정렬 순서가 사라져서 범위 스캔이 비효율적이라는 거야. 범위 스캔이 많으면 range, 포인트 쿼리가 많으면 hash — 워크로드에 따라 골라야 해.
이제 이 패턴들이 실전에서 어떻게 조합되는지 보자. AWS S3나 Azure Blob Storage 같은 관리형 파일 스토어가 바로 그 예야. 저자가 Azure Storage 아키텍처를 구체적으로 설명하는데, 세 레이어로 구성돼. 맨 아래 Stream Layer는 분산 추가 전용(append-only) 파일 시스템이야. 데이터가 "익스텐트(extent)" 단위로 chain replication으로 동기 복제돼. 그 위에 Partition Layer가 고수준 파일 연산을 저수준 스트림 연산으로 변환하지 — 파티션 매니저가 모든 파일 인덱스를 범위 파티셔닝으로 관리하고, 핫 파티션은 분할, 콜드 파티션은 병합해. 계정 간 비동기 복제로 재해 복구도 지원하고. 맨 위에 Front-end Layer는 상태 없는 리버스 프록시로 인증과 라우팅을 담당해. chain replication, 파티셔닝, 컨트롤/데이터 플레인 분리가 다 적용된 거야.
정리
10장 읽고 기억할 거 세 가지:
- Range vs Hash — 범위 스캔이 많으면 range, 포인트 쿼리가 많으면 hash. range는 핫스팟에 취약하고 hash는 범위 스캔이 안 돼
- 일관된 해싱은 파티션 추가/제거 시 최소한의 키만 재배정해서 셔플링 비용을 줄여
- Azure Storage는 Stream(복제) + Partition(인덱싱) + Front-end(프록시) 세 레이어야 — 이 책에서 배운 패턴들의 실전 조합이지