조용한 개발 노트

확장성의 해답처럼 보이는 선택트래픽과 데이터가 증가하면, 시스템은 결국 하나의 한계에 도달한다.이때 가장 자연스럽게 떠오르는 해법이 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는 이 한계를 구조적으로 ..

MongoDB를 쓰다 보면 인덱스에 대해 이런 인상을 받기 쉽다.“분명 인덱스를 타는데, 생각보다 느리다.”이 느낌은 착각이 아니다. MongoDB 인덱스는 같은 B-Tree 구조를 쓰더라도 인덱스가 끝나는 지점이 다르다.이 글에서는 MongoDB 공식 문서를 기준으로, 인덱스 사용 여부와 Document 접근 여부가 왜 성능을 갈라놓는지 구조적으로 정리한다.MongoDB 인덱스도 B-Tree다먼저 분명히 짚고 가자.MongoDB의 기본 인덱스 역시 B-Tree 계열 구조를 사용한다.따라서 정렬, 범위 조회, 탐색 비용 같은 기본 성질은 관계형 데이터베이스와 동일하다.차이는 인덱스가 무엇을 가리키고, 쿼리가 어디까지로 끝나는가에서 시작된다.MongoDB 쿼리의 실제 실행 경로MongoDB에서 쿼리는 항상..

MongoDB를 운영해 본 팀에서 자주 나오는 말이 있다.“쓰기 트래픽이 늘어도 생각보다 잘 버틴다.”이 체감의 핵심에는 MongoDB의 동시성 제어 모델이 있다. 정확히 말하면, MongoDB는 “락이 없다”기보다는 락의 범위를 극도로 좁힌다.동시성 문제의 본질동시성 문제는 결국 이 질문으로 수렴한다.“누가, 어디까지 동시에 바꿀 수 있는가?”관계형 데이터베이스에서는 이 질문에 대한 답이 비교적 넓다.행 단위 락범위 락인덱스 간 간접 충돌이 구조에서는 의도하지 않게 넓은 영역이 잠길 수 있다.MongoDB의 선택: Document 단위MongoDB는 동시성 제어의 기준 단위를 Document로 한정한다.즉, 하나의 Document에 대한 변경은 해당 Document 안에서만 조율된다.다른 Documen..

MongoDB를 써본 개발자들이 공통으로 느끼는 인상이 있다.“대량 쓰기나 잦은 업데이트에서도 생각보다 잘 버틴다.”이 체감은 우연이 아니다. MongoDB의 Document 모델은 쓰기 경로를 단순화하는 방향으로 설계되었다.이 글에서는 MongoDB 공식 문서를 기준으로, Document 모델이 왜 쓰기에 강한지, 그 내부 구조적 이유를 정리한다.쓰기 성능은 ‘몇 번 만지느냐’의 문제다데이터베이스에서 쓰기 비용은 대체로 다음 질문으로 환원된다.몇 개의 레코드를 수정하는가?몇 개의 구조를 동시에 갱신하는가?얼마나 넓은 범위를 잠그는가?MongoDB는 이 질문들에 대해 가능한 한 단순한 답을 택한다.“하나의 문서만 수정한다.”Document 단위 원자성이 주는 이점MongoDB에서 쓰기의 기본 단위는 Do..

MongoDB를 설명할 때 흔히 이렇게 말한다.“관계형 데이터베이스가 아니다.”하지만 이 설명은 MongoDB를 이해하는 데 거의 도움이 되지 않는다. 중요한 질문은 이것이다.“MongoDB는 무엇을 포기했고, 무엇을 얻으려 했을까?”이 글에서는 MongoDB 공식 문서를 기준으로, MongoDB가 왜 관계형 모델을 버리고 Document 모델을 선택했는지를 내부 구조 관점에서 정리한다.관계형 모델이 전제로 하는 것관계형 데이터베이스는 다음 가정을 전제로 설계되었다.데이터는 정규화된다중복은 피해야 한다Join으로 관계를 복원한다이 모델은 데이터 정합성과 무결성을 유지하는 데 매우 강력하다.하지만 이 강점은 특정 환경에서 비용으로 바뀐다.Join은 언제 비용이 될까Join은 논리적으로 우아하지만, 실행 관..

2편에서 Kafka가 Pull 모델을 선택한 이유를 살펴봤다. 이제 Kafka를 Kafka답게 만드는 또 하나의 핵심 질문으로 넘어가자.“Kafka는 어떻게 많은 데이터를 빠르게 처리하면서도, 순서를 보장할 수 있을까?”그 답이 바로 Partition이다.Partition은 단순한 분할이 아니다Topic을 여러 개의 Partition으로 나눈다고 하면, 흔히 이렇게 이해한다.“데이터를 쪼개서 병렬로 처리하겠다는 거구나.”반은 맞고, 반은 틀리다. Partition은 단순한 성능 최적화 수단이 아니다.Kafka가 순서(ordering)와 확장성(scalability)을 동시에 만족시키기 위해 선택한 최소 단위다.Kafka에서 순서는 어디까지 보장되는가Kafka 공식 문서는 순서 보장에 대해 매우 명확하게 ..

Linux 공식문서로 다시 이해하는 JVM 서버 실행 환경9편에서 우리는 서버의 모든 입출력이 파일 디스크립터 위에서 동작한다는 사실을 살펴봤다.이번 편에서는 그 수많은 파일 디스크립터를 어떻게 효율적으로 감시하고 처리하는지, 즉 현대 서버의 심장부라 할 수 있는 epoll을 다룬다.서버가 해야 하는 가장 어려운 일네트워크 서버의 핵심 과제는 단순해 보인다.요청이 오면 처리하고응답을 보낸다하지만 실제로 서버가 마주하는 질문은 훨씬 복잡하다.“수천, 수만 개의 연결 중에서 지금 당장 처리해야 할 소켓은 무엇인가”이 질문에 답하지 못하면, 서버는 확장될 수 없다.select - 가장 단순하지만 가장 먼저 한계에 부딪힌 방식초기의 Linux 서버는 select를 사용했다.select의 방식은 직관적이다.모든 ..

Kubernetes 공식문서로 다시 이해하는 Spring 서버 실행 환경1편부터 11편까지 우리는 Kubernetes를 “사용법”이 아니라 실행 환경의 규칙으로 바라봤다.마지막 편에서는 그 규칙들이 무엇을 의미하는지, 그리고 Spring 서버를 운영하는 우리의 책임이 어디까지인지 정리한다.서버리스는 아니지만, 서버도 아니다Kubernetes 위의 Spring 서버는 종종 두 극단 사이에서 오해된다.서버리스처럼 신경 쓸 게 없다기존 서버와 똑같이 운영하면 된다둘 다 틀렸다.Kubernetes는 서버를 감춰주지 않는다.대신, 서버의 생명주기를 더 자주, 더 명확하게 드러낸다.시작과 종료, 재시작, 축출, 스케일링이 모두 일상적인 이벤트가 된다.Kubernetes는 문제를 해결해주지 않는다많은 사람들이 Kub..