조용한 개발 노트

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

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경5편에서 Graceful Shutdown이 왜 필수인지 살펴봤다.이번 편에서는 종료 과정에서 가장 민감하고, 가장 자주 문제를 일으키는 대상인 트랜잭션을 다룬다.종료 중 트랜잭션 문제는 왜 위험한가트랜잭션 문제는 로그로 잘 드러나지 않는다.대부분 이런 형태로 발견된다.정산 금액이 맞지 않는다중복 처리된 데이터가 있다간헐적으로 누락되는 이벤트가 있다그리고 공통된 설명이 붙는다.“재현이 안 된다”종료 시점의 트랜잭션 문제는 타이밍 문제이기 때문에, 로컬이나 테스트 환경에서는 거의 드러나지 않는다.Pod 종료 중에도 요청은 처리되고 있다가장 먼저 바로잡아야 할 오해가 있다.Pod가 Terminating 상태라고 해서, 트랜잭션이 자동으로 ..

트래픽이 많은 서비스를 운영하다 보면, 다음과 같은 상황을 자주 마주하게 됩니다.DB 모니터링 지표는 정상이고쿼리도 특별히 느리지 않은데API 응답은 점점 느려지거나 타임아웃이 발생한다이럴 때 가장 많이 나오는 말은 보통 이겁니다.“DB는 멀쩡한데요?”이 글에서는 이 현상을 DB 성능 문제가 아니라 DB Connection Pool이라는 동시성 경계 관점에서 설명합니다.DB는 느린데만 문제가 되는 게 아니다DB 문제가 항상 “쿼리가 느려진다”로 나타나는 것은 아닙니다.실무에서 더 자주 문제 되는 패턴은 이것입니다.DB는 일정한 속도로 응답하고 있는데애플리케이션 쪽에서 대기 시간이 발생한다이때의 병목은 쿼리 실행 시간이 아니라 DB에 접근하기 전 단계에 존재합니다.바로 Connection Pool입니다.C..