MongoDB에서 sharding은 어떻게 동작하나요?

Question

Accepted Answer

**sharding**은 MongoDB의 **수평적 확장** 방법입니다 — 데이터를 여러 서버(**shard**)에 분산하여 데이터베이스가 단일 서버가 처리할 수 있는 것을 넘어선 데이터셋과 처리량을 다룰 수 있게 합니다. **shard key**로 데이터를 분할하며, MongoDB가 쿼리를 올바른 shard로 라우팅합니다.

## 왜 shard하나: 하나의 서버를 넘어 확장

```text
단일 서버는 한계(저장, RAM, 쓰기 처리량)가 있음. 데이터/부하가 하나의 서버(강력한
것이라도)가 처리할 수 있는 것을 초과하면, SHARDING이 이를 분산:
  → 데이터가 여러 SHARD에 분할됨 (각각 replica set)
  → 각 shard가 데이터의 SUBSET을 보유 → 결합된 용량이 수평적으로 확장
  → 거대한 데이터셋과 높은 쓰기 처리량 처리
```

## sharding 동작 방식

```text
sharded cluster는 세 부분으로 구성:
  SHARDS    → 각각 데이터의 일부를 보유 (각 shard는 그 자체로 replica set)
  mongos    → 쿼리 라우터(ROUTER) — 앱이 여기 연결; 쿼리를 올바른 shard로 라우팅
  CONFIG SERVERS → 메타데이터 저장 (어떤 데이터가 어떤 shard에 있는지)

데이터는 SHARD KEY로 CHUNK로 분할되어 shard에 분산됨.
MongoDB가 chunk를 shard 간에 자동으로 균형 조정.
```

## shard key — 가장 중요한 결정

```js
sh.shardCollection("mydb.orders", { customerId: 1 });   // customerId로 shard
```

```text
SHARD KEY는 데이터가 어떻게 분산되는지 결정 — 잘 선택하는 것이 결정적:
  ✓ 높은 카디널리티 (많은 고유 값) → 데이터가 고르게 퍼짐
  ✓ 읽기/쓰기의 고른 분산 → hot shard 없음
  ✓ 쿼리가 shard key를 포함 → 하나의 shard로 라우팅 (표적화, 빠름)
  ✗ 나쁜 shard key → 불균등 분산(hotspot), 또는 모든 shard를 치는 쿼리
    (scatter-gather, 느림) → 나쁜 확장. 나중에 바꾸기 어려움!
전략: ranged sharding, HASHED sharding(고른 분산), zoned sharding.
```

## 표적 vs scatter-gather 쿼리

```text
쿼리가 shard key 포함 → 특정 shard로 라우팅 → 빠름 (표적화)
쿼리가 shard key 없음 → 모든 shard를 쿼리해야 함 (scatter-gather) → 느림
→ 일반적인 쿼리 패턴을 중심으로 shard key 설계.
```

## 왜 중요한가

sharding은 **MongoDB를 매우 큰 데이터셋과 높은 처리량으로 확장**하는 데 중요한 지식이므로, 대규모 MongoDB 배포에 가치 있는 senior 수준 지식입니다.

핵심 가치는 **수평적 확장**입니다: 데이터나 부하가 단일 서버가 처리할 수 있는 것을 초과하면, sharding이 데이터를 여러 shard에 분산하여 수직적 확장(더 큰 서버)이 도달할 수 없는 거대한 데이터셋과 높은 쓰기 처리량을 처리하도록 용량을 수평적으로 확장합니다 — 대규모 시스템의 핵심 능력입니다.

**아키텍처**(각각 데이터 subset을 보유하는 shard, 쿼리를 지시하는 `mongos` 쿼리 라우터, 메타데이터를 저장하는 config server)를 이해하는 것이 기초입니다.

가장 결정적으로, **shard key**(데이터 분산을 결정하는 field)를 이해하는 것이 필수적인데, **가장 중대하고 바꾸기 어려운 sharding 결정**이기 때문입니다: 좋은 shard key(높은 카디널리티, 고른 분산, 쿼리 패턴과 정렬)는 데이터와 부하를 고르게 퍼뜨리고 표적 쿼리를 가능하게 하지만, 나쁜 것은 hotspot(불균등 부하), scatter-gather 쿼리(모든 shard를 침, 느림), 나쁜 확장을 초래합니다.

**표적 vs scatter-gather 쿼리**(shard key를 포함하는 쿼리는 특정 shard로 효율적으로 라우팅; 없는 것은 모든 shard를 침)를 이해하는 것은 쿼리 패턴을 중심으로 shard key를 설계하는 것을 강화합니다.

매우 큰 데이터로 확장하는 것이 고성장 애플리케이션의 실제 과제이고, sharding(MongoDB의 수평적 확장 메커니즘)이 신중한 이해를 요구하므로 — 특히 중대하고 바꾸기 어려운 shard key 결정과 그것이 분산 및 쿼리 효율에 미치는 영향 — sharding을 이해하는 것은 MongoDB를 확장하는 데 중요한 senior 수준 지식이며, 수평적 데이터베이스 확장에 대한 이해를 보여주는 주제이자 특히 shard-key 결정이 대규모 시스템을 다루는 senior 역할에 기대되는 깊고 중대한 MongoDB 확장 전문성을 반영하는 영역입니다.