샤딩 (Sharding)
쉽게 풀면
수백만 명의 전화번호가 담긴 두꺼운 전화번호부 한 권을 상상해보세요. 이 한 권을 통째로 들고 다니며 찾기는 힘드니, 이름의 첫 글자를 기준으로 "가~다", "라~바" 식으로 여러 권으로 나누어 서로 다른 책장에 꽂아 둔다고 해봅시다. 이렇게 하면 각 책장은 전체가 아니라 일부만 담당하므로 찾기도 빠르고, 여러 사람이 동시에 다른 책장에서 찾아도 서로 방해가 되지 않습니다. 샤딩은 데이터베이스에서 이와 똑같은 일을 합니다. 데이터를 특정 기준(예: 사용자 ID)으로 나누어 여러 서버(샤드)에 분산시킴으로써, 한 서버에 모든 데이터와 요청이 몰리지 않도록 하는 것입니다.
왜 중요한가
단일 서버가 처리할 수 있는 데이터 양과 요청 수에는 물리적 한계가 있기 때문에, 사용자 수가 급격히 늘어나는 대규모 서비스에서는 수직적 확장(더 좋은 서버로 교체)만으로는 한계에 부딪히게 됩니다. 샤딩은 데이터를 여러 서버에 나누어 수평적으로 확장할 수 있게 해주는 핵심 기법이기 때문에, 분산 시스템·데이터베이스 논문에서 확장성(scalability) 문제를 다룰 때 빠지지 않고 등장하며, 최근에는 블록체인의 처리량 개선을 위한 방법으로도 활발히 연구됩니다.
논문에서는 이렇게 쓰입니다
이 문장은 데이터를 특정 규칙에 따라 여러 서버로 쪼개 저장함으로써, 하나의 서버가 모든 요청을 처리하느라 과부하되는 문제를 줄였다는 뜻입니다.
블록체인 분야에서 모든 노드가 모든 거래를 검증해야 하는 병목을 샤딩으로 해소하려는 연구 사례로, 데이터베이스뿐 아니라 분산 합의 시스템에도 같은 원리가 적용됨을 보여줍니다.
샤드를 나누는 기준을 ID 해시가 아니라 지리적 위치로 삼은 사례로, 샤딩 기준을 어떻게 설계하느냐에 따라 얻을 수 있는 이점이 달라진다는 점을 보여줍니다.
조금 더 깊게 보면
샤딩을 설계할 때 핵심은 어떤 값을 기준으로 데이터를 나눌지 정하는 샤드 키(shard key)의 선택입니다. 해시 기반 샤딩은 데이터를 고르게 분산시키기 쉽지만 특정 범위의 데이터를 한 번에 조회하기 어렵고, 범위 기반 샤딩은 범위 조회는 쉽지만 특정 구간에 데이터가 몰리는 핫스팟이 생기기 쉽습니다. 또한 샤드 수를 늘리거나 줄이는 리샤딩(재분배) 과정에서 데이터 이동이 대규모로 발생할 수 있어, 이를 최소화하기 위한 일관 해싱(consistent hashing) 같은 기법이 함께 다뤄지는 경우가 많습니다.
주의할 점
샤딩 기준(샤드 키)을 잘못 정하면 특정 샤드에만 데이터와 요청이 몰리는 "핫스팟(hot partition)" 문제가 생길 수 있어, 로드밸런싱과 함께 설계해야 효과가 있습니다. 또한 여러 샤드에 걸친 데이터를 한 번에 조회하거나 수정하는 작업은 단일 서버일 때보다 복잡해진다는 점도 고려해야 합니다.