조용한 개발 노트

CAP 이론을 아는 것과, 선택하는 것은 다르다CAP 이론은 분산 시스템을 다루는 사람이라면 누구나 한 번쯤 접한다. Consistency, Availability, Partition tolerance 중 두 가지만 선택할 수 있다는 설명은 잘 알려져 있다.하지만 실제 시스템에서 중요한 질문은 이것이 아니다.지금 이 순간, 이 요청에 대해 무엇을 포기할 것인가이 글에서는 CAP을 이론으로 설명하지 않는다. 실제 시스템이 어떤 상황에서 어떤 선택을 강요받는지를 중심으로 살펴본다.Partition은 선택이 아니라 전제다CAP을 오해하게 만드는 가장 큰 이유는 Partition을 마치 선택지처럼 받아들이기 때문이다.현실의 분산 시스템에서 Partition은 다음과 같은 형태로 항상 발생한다.네트워크 지연패킷 ..

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

MongoDB를 분산 환경에서 쓴다는 말은, 대부분 Replica Set을 사용한다는 뜻이다.하지만 Replica Set에 대해 많은 오해가 함께 따라온다.“복제가 있으니 데이터는 안전하겠지.” “Primary만 바뀌면 자동으로 다 해결되겠지.”이 글에서는 MongoDB 공식 문서를 기준으로, Replica Set이 정확히 무엇을 보장하고, 어디까지는 보장하지 않는지를 경계 중심으로 정리한다.Replica Set의 기본 구조Replica Set은 하나의 Primary와 하나 이상의 Secondary로 구성된다.모든 쓰기는 Primary에서 수행된다Secondary는 Primary의 변경을 복제한다Primary 장애 시 자동 선출(Election)이 일어난다이 구조의 목적은 가용성과 내구성을 높이는 것이다..

MongoDB를 쓰다 보면 다른 데이터베이스에서는 거의 보지 못한 개념을 마주한다.Read Concern, Write Concern.이 둘은 단순한 옵션이 아니다. MongoDB가 정합성과 내구성의 판단을 시스템이 아닌 애플리케이션과 공유하기로 한 설계 선택을 가장 노골적으로 드러내는 인터페이스다.MongoDB는 “기본값”을 단순 상수로 두지 않는다많은 데이터베이스는 기본 Write Concern을 하나의 고정값으로 둔다.MongoDB는 그렇지 않다.MongoDB는 전역 기본값을 명시하지 않은 경우, Replica Set의 토폴로지를 보고 기본 Write Concern을 계산한다.이를 MongoDB 공식 문서에서는 Implicit Default Write Concern(IDWC)이라고 부른다.암시적 기본..

MongoDB를 오래 써본 사람일수록 이런 질문을 던진다.“왜 MongoDB는 처음부터 트랜잭션을 제공하지 않았을까?”이 질문에는 “기술력이 부족해서”라는 답이 붙기 쉽다. 하지만 실제 이유는 정반대다.MongoDB는 트랜잭션이 없는 구조를 전제로 최적화된 데이터베이스였고, 그 전제를 깨는 순간 전체 설계가 달라지기 때문이다.MongoDB가 처음부터 보장한 원자성MongoDB는 초기부터 다음 원자성을 강하게 보장해왔다.단일 Document 단위 원자성하나의 Document에 대한 쓰기는 항상 중간 상태 없이 적용되거나, 아예 적용되지 않는다.이 보장은 MongoDB 데이터 모델의 핵심 전제다.이 보장만으로 충분했던 이유MongoDB가 타깃으로 삼은 초기 워크로드는 다음과 같은 특성을 가졌다.요청 단위 데..