조용한 개발 노트

지금까지의 편들은 모두 하나의 사실로 수렴합니다.네트워크 지연은 운영 중에만 생기는 문제가 아니라, 설계에서 이미 결정된다는 점입니다.지연을 완전히 제거할 수는 없습니다.하지만 지연이 장애로 번지지 않게 설계하는 것은 가능합니다.이 마지막 편에서는 네트워크 지연을 전제로 한 설계에서 무엇을 미리 결정해야 하는지를 정리합니다.1. “빠름”이 아니라 “지연 가능성”을 기준으로 설계한다설계 단계에서 흔히 묻는 질문은 이것입니다.“평균 응답 시간은 얼마나 나올까?”하지만 더 중요한 질문은 다음입니다.“이 요청이 느려질 수 있는 지점은 어디인가?”DNS, 연결 생성, TLS, 로드 밸런서, 큐잉.요청 경로를 단계별로 나누고, 각 단계가 느려졌을 때의 영향을 먼저 상상해야 합니다.2. 요청 경로를 짧게 유지한다요청..

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는 이 한계를 구조적으로 ..

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)이라고 부른다.암시적 기본..

Kafka 시리즈의 마지막이다. 지금까지 우리는 Kafka의 설계 의도부터 Consumer Group, Offset, Exactly-once, 스토리지, OS, 관측, Kubernetes까지 한 바퀴를 돌았다.그럼에도 현장에서 가장 많이 듣는 말은 이것이다.“Kafka를 도입했는데, 오히려 장애가 더 늘어났다.”이 문장의 핵심은 Kafka가 아니다. 기대와 현실의 불일치다.이유 1. Kafka를 메시지 큐로 기대했다Kafka는 메시지를 전달하는 시스템이 아니라 이벤트를 기록하는 로그다.그럼에도 많은 설계는 다음을 전제로 한다.한 번만 처리될 것이다처리되면 사라질 것이다브로커가 상태를 관리해줄 것이다이 기대는 Kafka의 로그 모델과 충돌한다. 결과는 중복 처리, 오프셋 혼란, 리밸런스 폭증이다.이유 2...

9편에서 Kafka의 관측이 어려운 이유와 Consumer Lag이 왜 자주 오해되는지를 살펴봤다. 이제 많은 팀이 실제로 부딪히는 환경으로 들어가 보자.“Kafka를 Kubernetes에 올렸더니, 예전보다 장애가 더 잦아졌다.”이 문제는 Kafka나 Kubernetes 중 하나가 나빠서가 아니다. 상태를 가진 시스템(stateful system)을 무상태 플랫폼(stateless-first)에 올렸기 때문이다.Kubernetes는 본질적으로 무상태를 전제로 한다Kubernetes의 설계 전제는 명확하다.Pod는 언제든지 죽을 수 있다다시 뜨면 새 인스턴스다상태는 외부에 있어야 한다이 전제는 웹 서버나 API 서버에는 매우 잘 맞는다. 하지만 Kafka는 다르다.Kafka는 디스크에 상태를 가진 시스템..

8편에서 Kafka 성능 문제의 상당수가 JVM이 아니라 OS·운영 환경에서 발생한다는 이야기를 했다. 그런데 현장에서 가장 자주 마주치는 질문은 이거다.“Lag이 늘었는데, 어디가 문제지?”Kafka에서 관측이 어려운 이유는 도구가 부족해서가 아니다. 지표가 무엇을 의미하는지 오해하기 쉽기 때문이다.Consumer Lag은 무엇을 말해주는 지표인가Consumer Lag은 단순히 말하면 브로커에 쌓인 데이터와 소비자가 읽은 위치의 차이다.Lag = 아직 읽지 않은 메시지 수Lag = 처리 대기 중인 작업량여기까지는 맞다. 하지만 많은 오해는 여기서 시작된다.Lag이 크다고 반드시 장애는 아니다Kafka의 로그 모델을 떠올려보자.데이터는 삭제되지 않는다소비자는 자기 속도로 읽는다이 구조에서는 Lag이 일시..

6편에서 Exactly-once가 성립하는 조건과 한계를 살펴봤다. 이제 Kafka의 또 다른 오해로 넘어가 보자.“Kafka는 디스크에 쓰는데, 왜 이렇게 빠르지?”이 질문에 대한 답은 Kafka의 스토리지 구조가 아니라 운영체제와 IO를 바라보는 관점에 있다.Kafka는 디스크를 느리다고 가정하지 않는다많은 시스템은 디스크를 “느리고 비싼 자원”으로 취급한다. 그래서 캐시-락-복잡한 메모리 구조를 앞에 둔다.Kafka는 반대로 생각한다.디스크는 순차 쓰기라면 충분히 빠르다.이 전제가 Kafka의 모든 스토리지 설계를 결정한다.Append-only Log의 힘Kafka의 Partition은 append-only log다.항상 파일의 끝에만 쓴다중간 수정이 없다삭제는 즉시 하지 않는다이 구조 덕분에 랜덤..

5편에서 Offset Commit이 “처리 완료”가 아니라 “읽기 위치”일 뿐이라는 이야기를 했다. 그러면 자연스럽게 이런 기대가 등장한다.“그럼 Exactly-once를 쓰면 되는 거 아닌가?”Kafka의 Exactly-once Semantics(EOS)는 많은 오해를 낳는 개념이다. 이유는 간단하다. Exactly-once는 만능이 아니며, 매우 좁은 조건에서만 성립하기 때문이다.Kafka가 말하는 Exactly-once의 정확한 의미Kafka 공식 문서에서 말하는 Exactly-once는 흔히 기대하는 의미와 다르다.Kafka의 EOS는 다음을 의미한다.“Kafka 내부에서, 입력 레코드 하나가 출력 레코드 하나로 정확히 한 번 반영된다.”여기서 중요한 전제는 Kafka 내부다. DB, 외부 API..