조용한 개발 노트

확장성의 해답처럼 보이는 선택트래픽과 데이터가 증가하면, 시스템은 결국 하나의 한계에 도달한다.이때 가장 자연스럽게 떠오르는 해법이 Sharding과 Partitioning이다.데이터를 나누면:부하가 분산되고처리량이 증가하며확장이 쉬워질 것처럼 보인다하지만 데이터를 나누는 순간, 시스템은 새로운 종류의 복잡성을 떠안는다.Sharding과 Partitioning은 무엇이 다른가두 용어는 종종 혼용되지만, 의미는 다르다.Partitioning데이터를 여러 조각으로 나눔하나의 논리적 시스템 안에서 관리ShardingPartition을 서로 다른 노드에 배치독립적인 장애 도메인 생성Partitioning이 구조적 분리라면, Sharding은 운영적 분리다.Shard Key가 모든 것을 결정한다Sharding 설..

MongoDB를 두고 이런 평가를 자주 본다.“쓰기에는 강한데, 설계가 어렵다.” “확장은 쉬운데, 운영은 복잡하다.”이 평가는 절반만 맞다.MongoDB의 복잡함은 구현이 어설퍼서가 아니라, 처음부터 풀고자 한 문제가 달랐기 때문이다.이 마지막 글에서는 MongoDB 전반을 관통하는 설계 선택의 방향을 정리한다.MongoDB의 출발점은 “관계”가 아니었다MongoDB는 관계형 모델의 연장선에서 출발하지 않았다.대신, 다음 질문을 출발점으로 삼았다.“이 요청은 어떤 데이터를 항상 함께 사용하나?”이 질문은 Document 모델, Embedded 구조, Join 회피로 이어졌다.결과적으로 MongoDB는 관계를 재구성하는 DB가 아니라, 요청 단위 데이터를 빠르게 다루는 DB가 되었다.일관성보다 “접근 경..

MongoDB를 이야기할 때 빠지지 않고 등장하는 표현이 있다.“수평 확장에 강하다.”하지만 이 표현은 MongoDB의 설계를 절반만 설명한다.MongoDB는 “필요하면 Scale-out 할 수 있는 DB”가 아니라, 처음부터 Scale-out을 전제로 설계된 DB다.이 글에서는 MongoDB 공식 문서를 기준으로, MongoDB가 왜 Sharding을 선택적 기능이 아니라 설계의 출발점으로 삼았는지를 정리한다.Scale-up의 한계전통적인 데이터베이스 확장은 다음 경로를 따른다.CPU를 더 좋은 것으로 교체메모리를 늘림스토리지를 확장이 방식은 단순하고 효과적이지만, 명확한 한계를 가진다.비용이 선형적으로 증가하지 않는다하드웨어 상한이 존재한다단일 장애 지점이 남는다MongoDB는 이 한계를 구조적으로 ..