샤딩이란 무엇일까?

데이터베이스를 확장하는 방법에는 여러 가지가 있습니다. 대표적으로 레플리케이션, 파티셔닝, 그리고 샤딩이 존재합니다.
또한 데이터베이스의 성능을 개선하기 위한 방법으로는 인덱싱, 캐싱과 같은 기법들이 사용됩니다.

이 중 샤딩은 가장 마지막에 고려되는 확장 전략으로 알려져 있습니다. 그 이유는 샤딩이 단순한 성능 최적화가 아니라,
데이터 구조와 애플리케이션 설계 전반에 영향을 미치는 고위험한 선택이기 때문입니다.
하지만 그만큼, 기존 방식으로는 감당할 수 없는 규모의 트래픽과 데이터를 처리해야 하는 상황에서는
가장 강력한 확장 수단이 되기도 합니다.
이 글에서는 샤딩이 무엇인지 어떤 샤딩 전략들이 존재하는지 그리고 샤딩을 언제 사용하는 것이 적절한지를 중심으로 정리해보겠습니다.

샤딩은 무엇일까?

일단 샤딩이라는 단어 자체에 집중할 필요가 있습니다.

샤딩(Sharding)은 거대한 데이터베이스나 네트워크 시스템을 '샤드(Shard, 조각)'라는 여러 개의 작은 단위로 나누어
분산 저장하고 처리하는 데이터 분산 기법을 의미합니다. 이 정의만 놓고 보면, 샤딩은 단순히 데이터베이스를 확장하는 기술이라기보다는
데이터를 조각 단위로 쪼개어 책임을 분산시키는 구조로 이해할 수 있습니다.

데이터베이스 시스템마다 이 개념을 부르는 용어는 조금씩 다릅니다. MongoDB에서는 이러한 단위를 샤드(shard)라고 부르고,
Couchbase는 버킷(bucket)이라는 용어를 사용합니다. 또한 Apache Cassandra에서는 이를 노드(node)라는 개념으로 표현합니다.

용어는 서로 다르지만, 핵심 개념은 동일합니다.
모두 성능과 확장성을 확보하기 위해 데이터를 더 작은 단위로 나누고, 이를 여러 시스템에 분산하여 처리하는 방식을 취하고 있습니다.

즉, 샤드, 버킷, 노드라는 표현은 구현과 맥락에 따라 달라질 뿐,
"데이터를 나누어 분산 처리한다"는 동일한 문제를 해결하기 위한 서로 다른 표현이라고 볼 수 있습니다.

그렇다면 어떻게 데이터베이스를 나눌 수 있을까요?

데이터를 나누는 방식에는 크게 세 가지 접근 방법이 있습니다.
첫째, 데이터의 값 범위(range) 를 기준으로 나누는 방법입니다.
둘째, 특정 키 또는 해시 값을 기준으로 데이터를 분산시키는 방법입니다. 
셋째, 테이블 단위로 데이터를 분리하는 방법입니다.

이 세 가지 방식은 모두 데이터를 여러 단위로 나누는 공통된 목적을 가지지만,
데이터 분포 방식과 접근 패턴, 그리고 확장 시 발생하는 특성에는 차이가 있습니다.

데이터의 값 범위(range) 를 기준으로 나누는 방법

이 방식에는 분명한 전제조건가 존재합니다.
바로 데이터에 대해 명확한 범위를 정의할 수 있어야 한다는 점입니다. 예를 들어 숫자, 날짜와 같이 크고 작음이 비교 가능한 값이라면
범위를 기준으로 데이터를 나누는 것이 가능합니다.
반대로, 테이블의 값들이 범위로 구분될 수 없거나 범위를 나누는 기준 자체가 모호한 경우라면 이 방식은 사용할 수 없습니다.

예를 들어, 날짜를 기준으로 범위를 나눈다면 1월부터 3월까지의 데이터, 4월부터 6월까지의 데이터,
그리고 7월부터 12월까지의 데이터를 각각 나누어 저장하는 방식이 가능합니다.

이처럼 값의 크기나 순서가 명확한 컬럼이라면 범위를 기준으로 데이터를 분리하여 관리할 수 있습니다.

이 방식의 가장 치명적인 문제는 특정 샤드 DB만 지속적으로 사용된다는 점입니다.
왜 이것이 치명적인 문제일까요? 이를 이해하기 위해, 샤딩을 왜 사용하는지부터 다시 생각해볼 필요가 있습니다.

샤딩의 목적은 단순히 데이터를 나누는 데 있는 것이 아니라,
데이터와 트래픽을 여러 노드에 분산시켜 사용량을 고르게 만드는 것에 있습니다.

하지만 범위 기반 샤딩에서 특정 범위의 데이터만 지속적으로 조회되거나 갱신된다면,
실제로는 일부 샤드 DB만 집중적으로 사용되고 나머지 샤드들은 거의 활용되지 않는 상황이 발생할 수 있습니다.

이러한 구조에서는 샤딩을 통해 기대했던 부하 분산 효과를 얻기 어렵고,
결과적으로 샤딩 설계가 목적에 맞지 않게 동작하고 있다고 볼 수 있습니다.

특정 키 또는 해시 값을 기준으로 데이터를 분산시키는 방법

특정 키 또는 해시 값을 기준으로 데이터를 분산시키는 방법은 앞서 살펴본 범위 기반 방식과는 접근 방식이 다릅니다.
이 방식을 이해하기 위해서는 먼저 데이터가 어떤 기준으로, 어떤 규칙에 따라 분산되는지부터 살펴볼 필요가 있습니다.

특정 키 또는 해시 값을 기준으로 데이터를 분산한다는 말은,
사람이 범위를 직접 나누는 것이 아니라, 규칙에 따라 자동으로 나뉜다는 뜻입니다.

그 규칙은 보통 다음의 세 단계로 이루어집니다.

기준이 되는 값: Shard Key

가장 먼저 필요한 것은 샤드 키(Shard Key) 입니다.

user_id
order_id
account_id

위 와 같이 항상 존재하며, 조회에 자주 사용되는 값을 의미합니다.
이 값은 곧 이 데이터가 어느 샤드에 저장될지 결정하는 기준이 됩니다.

해시 함수 적용

선택한 샤드 키에 해시 함수(hash function) 를 적용합니다.

hash(user_id) → 847392

 

해시 함수의 역할은 입력값을 고르게 분산된 숫자 값으로 변환하는 것입니다.
이 과정에서 데이터가 가지던 순서 개념은 사라지게 됩니다.

분산 방식: 나머지 연산

해시 결과를 샤드의 개수로 나누어 실제 저장될 샤드를 결정합니다.

shard_index = hash(user_id) % shard_count

예를 들어 샤드가 4개라면, 계산 결과는 0 ~ 3 중 하나가 됩니다.

0 → Shard A 1 → Shard B 2 → Shard C 3 → Shard D

이 규칙 하나만으로도 모든 데이터의 저장 위치가 자동으로 결정됩니다.

키 자체 대신 키의 해시를 사용하면 효율적인 범위 쿼리를 수행할 수 없습니다. 인접한 키는 서로 다른 파티션에 흩어져 있을 수 있으며 자연스러운 정렬 순서가 손실됩니다. 해시 기반 샤딩은 핫스팟을 줄이지만 핫스팟을 제거할 수는 없습니다. 예를 들어, 소셜 미디어 웹사이트에서 유명 사용자가 콘텐츠를 게시하면 동일한 키에 대량의 쓰기를 생성할 수 있습니다.

테이블 단위로 데이터를 분리하는 방법

앞서 살펴본 방식들과 비교하면 다소 직관적이고 단순한 접근에 가깝습니다.
이 방식은 특정 키나 규칙에 따라 데이터를 자동으로 분산시키는 것이 아니라, 테이블 자체를 기준으로 데이터베이스를 분리합니다.
즉, 어떤 데이터가 어디에 저장될지에 대한 판단이 명확한 규칙이 아니라 설계 단계에서 이미 고정됩니다.
이로 인해 구조를 이해하기는 쉽지만, 데이터 증가나 접근 패턴 변화에 유연하게 대응하기 어렵다는 한계를 가집니다.

샤딩을 언제 사용하는 것이 적절한지

지금까지 샤딩의 종류에 대해 대략적으로 살펴보았습니다. 그렇다면, 샤딩은 과연 언제 사용하는 것이 적절할까요?
기본적으로 데이터베이스를 확장하는 가장 흔한 이유는 읽기 성능을 개선하기 위함입니다.
이 경우에는 레플리케이션이나 캐싱과 같은 방식만으로도 충분한 효과를 얻을 수 있습니다.

하지만 샤딩은 읽기 성능뿐만 아니라 쓰기 성능까지 함께 확장해야 하는 상황에서 고려되는 선택지입니다.
데이터 자체를 여러 데이터베이스로 분산시키기 때문에, 단일 데이터베이스로는 감당하기 어려운 쓰기 트래픽을
병렬로 처리할 수 있기 때문입니다.

다만, 샤딩은 데이터베이스가 여러 개로 분리되어 동작하는 구조이기 때문에
그만큼 운영 비용과 리소스 소모가 증가합니다. 단순히 성능을 조금 더 끌어올리기 위한 선택이라기보다는,
기존 구조로는 더 이상 확장이 어려운 시점에서의 구조적 결단에 가깝습니다.

결론

지금까지 샤딩에 대해 간략하게 살펴보았습니다. 글을 정리하면서 다시 생각해보니, 앞에서 예시로 들었던 날짜 기반 분산 방식은 샤딩의 목적과 완전히 맞는 예시는 아니었다고 느꼈습니다. 샤딩은 단순히 데이터를 나누는 것이 아니라, 쓰기 트래픽과 데이터 자체를 분산시켜 처리량의 한계를 넘기기 위한 선택입니다. 하지만 날짜를 기준으로 데이터를 나누게 되면, 특정 시점에는 항상 하나의 데이터베이스만 집중적으로 사용되게 됩니다. 이는 결국 쓰기 성능은 크게 개선되지 않은 상태에서 읽기 성능만 부분적으로 향상되는 구조에 가깝습니다. 그렇다면 이런 상황에서는 샤딩보다는 레플리케이션이나 캐싱과 같은 다른 기술을 먼저 고려하는 편이 더 합리적인 선택일 수 있습니다. 이러한 점에서 샤딩은 "성능을 조금 더 끌어올리기 위한 기술"이라기보다는, 기존 구조로는 더 이상 감당할 수 없는 규모에 도달했을 때 선택하는 마지막 확장 전략에 가깝다고 생각합니다.

출처
https://blog.bytebytego.com/p/must-know-message-broker-patterns-4c4