데이터베이스는 시스템이 성장하면서 흔히 병목이 됩니다. 이를 확장하려면 replication(읽기 확장과 가용성을 위한 사본), sharding(여러 서버에 데이터 분할), 캐싱, 적절한 데이터베이스 유형 선택 같은 기법이 필요합니다.
REPLICATION → 여러 서버에 데이터베이스 사본 유지:
→ PRIMARY(쓰기) + REPLICA(사본):
- 읽기 확장 → 읽기를 replica로 보냄 (primary 경감) → 더 많은 읽기 처리
- 가용성 → primary 실패 시 replica가 인계 (failover)
⚠️ replication lag → replica가 약간 뒤처질 수 있음 (읽기에 eventual consistency)
→ 읽기 중심 워크로드와 가용성에 훌륭 (대부분 앱은 읽기 중심)
SHARDING → 여러 데이터베이스 서버에 데이터를 분할(partition) (각각 SUBSET 보유):
→ SHARD KEY(예: 사용자 ID)로 분산 → 각 shard가 데이터/부하의 일부 처리
→ 쓰기와 저장소를 수평으로 확장 (단일 서버 용량을 넘어)
⚠️ 복잡: 좋은 shard key 선택(고른 분산), 교차 shard 쿼리가 어려움,
리밸런싱 → 상당한 복잡성
→ 데이터/쓰기량이 단일 서버를 초과할 때 (대규모)
✓ 캐싱 → 쿼리 결과 / hot 데이터 캐시 (Redis) → DB 부하 큰 감소 (종종
첫 번째이자 가장 영향력 있는 단계)
✓ 인덱싱 & 쿼리 최적화 → 쿼리를 효율적으로 (확장 전에)
✓ 읽기/쓰기 분리; 커넥션 풀링; 비정규화 (읽기 성능 위해)
✓ 적절한 데이터베이스 선택 (일부는 수평 확장이 더 쉬움 — NoSQL)
✓ 수직 확장 (더 큰 DB 서버) → 단순한 첫 단계지만 제한적
데이터베이스를 어떻게 확장하는지 이해하는 것은 가치가 있습니다. 시스템이 성장하면서 데이터베이스가 흔히 병목이 되므로 이를 확장하는 것이 핵심적이고 흔한 시스템 디자인 과제이고, 이것이 중요한 지식이 되기 때문입니다.
시스템이 확장되면서 데이터베이스가 자주 제한 요인이 되므로(단일 데이터베이스는 일정량의 부하와 데이터만 처리 가능), 데이터베이스 확장은 핵심 관심사가 됩니다.
replication — 사본 유지(쓰기를 위한 primary와 replica)로 읽기 확장(읽기를 replica로 보내 primary를 경감, 대부분 앱이 읽기 중심이므로 가치 있음)과 가용성(장애 시 replica가 인계)을 가능하게 함 — 을 이해하는 것은 근본적이고 널리 쓰이는 기법이며, replication lag(replica 읽기의 eventual consistency)이라는 주의점도 함께 이해해야 합니다.
sharding — 여러 서버에 데이터 분할(각각 subset 보유, shard key로 분산)하여 단일 서버를 넘어 쓰기와 저장소를 수평 확장 — 을 이해하는 것은 매우 큰 규모에 필수적이며, 그 상당한 복잡성(좋은 shard key 선택, 어려운 교차 shard 쿼리, 리밸런싱)도 함께 이해해야 합니다.
기타 기법 — 캐싱(종종 첫 번째이자 가장 영향력 있는 단계로, 데이터베이스 부하를 극적으로 감소), 인덱싱과 쿼리 최적화(확장 전 쿼리 효율화), 읽기/쓰기 분리, 비정규화, 수평 확장 가능한 데이터베이스 선택, 단순한 첫 단계로서의 수직 확장 — 을 이해하면 전체 도구 세트를 얻으며, 캐싱과 최적화가 종종 sharding의 복잡성에 앞선다는 중요한 실용 지혜를 갖습니다.
데이터베이스는 흔히 확장 병목이고 이를 확장하는 것(읽기/가용성을 위한 replication, 쓰기/저장소를 위한 sharding, 캐싱, 최적화)이 핵심적이고 흔한 과제이며, 이러한 기법과 트레이드오프를 이해하는 것이 확장 가능한 시스템 설계에 중요하므로, 데이터베이스를 어떻게 확장하는지 이해하는 것은 가치 있고 실용적으로 중요한 시스템 디자인 지식입니다 — 핵심적이고 흔한 병목을 다루고, 실제 시스템 확장의 중심이며, 성장하는 시스템이 불가피하게 필요로 하는 데이터베이스 확장을 다루기 위해 replication, sharding, 캐싱, 최적화의 이해를 요구합니다.