MongoDB 9.0 IWM, 과부하 요청을 기다리게 하거나 거부하는 조건

MongoDB 트래픽 급증, 스케일업을 기다리는 동안의 보호

MongoDB는 2026년 9월 29일 MongoDB 9.0의 Intelligent Workload Management 정식 출시를 알렸고, 10월 8일 상세 설명을 공개했다. 회사는 IWM을 수요 급증에서 추가 용량이 준비될 때까지 클러스터 압력을 관리하는 가용성 기능으로 설명한다. 용량을 추가하거나 오토스케일링·용량계획을 대체하는 기능은 아니다. [S1] [S4]

따라서 Atlas 성능을 평가할 때 CPU나 처리량 한 항목만 봐서는 부족하다. 요청 대기, 응답 시간, 오류, 재시도와 실제 처리 완료를 함께 비교하는 편이 좋다. DB가 안정적으로 응답하는 것과 개별 작업이 목표 시간 안에 끝나는 것은 서로 다른 운영 목표다.

MongoDB 큐잉과 MongoDB Load Shedding은 결과가 다르다

큐잉은 초과 요청을 기다리게 하며 요청이 요구하는 총 작업량을 없애지 않는다. Load Shedding은 선택형 보호다. 지원 클러스터에서 활성화하면 지속적인 과부하 중 각 mongod의 유입 큐가 가득 찼을 때 새 연산을 과부하 오류로 거부한다. 공식 문서의 기본 설정은 Atlas Managed이며, MongoDB 9.0에서 이 설정의 유효 상태는 Disabled다. IWM의 기본 보호와 Load Shedding 활성화를 같은 것으로 취급하지 않아야 한다. [S2]

이 차이는 사용자 경험에도 영향을 준다. 대기는 작업 완료가 늦어지는 형태로 나타날 수 있고, 거부는 애플리케이션의 오류 처리 경로를 사용하게 한다. 어느 쪽이 적합한지는 서비스의 지연 허용 범위와 실패 처리 정책을 함께 보고 판단해야 한다. ‘거부를 줄이는 것’만으로 가용성 목표를 정의하면 무한히 기다리는 작업을 놓칠 수 있다.

MongoDB IWM 지원 클러스터: 등급과 토폴로지가 기준

공식 문서에서 IWM은 MongoDB 9.0 이상 Dedicated 클러스터에 적용되며 Free·Flex에는 제공되지 않는다. 다만 모든 Dedicated 클러스터가 같은 보호를 받는 것은 아니다. 아래 표는 이 기사에서 다루는 MongoDB 9.0 이상 조건을 구분한 것이다. [S2]

MongoDB Load Shedding 사용법: 재시도 준비가 먼저

MongoDB Load Shedding 사용법에서 중요한 점은 스위치보다 오류 해석이다. 공식 문서는 SystemOverloadedError 라벨만으로 재시도가 안전하다고 판단할 수 없다고 설명한다. RetryableError는 연산이 실행되지 않았고 재시도가 안전하다는 신호이며, NoWritesPerformed는 쓰기 전에 거부됐다는 의미다. [S3]

문서의 backpressure-aware 최소 버전에는 PyMongo 4.18, Node.js Driver 7.6, Go Driver 2.9가 포함된다. 이 목록은 전체 드라이버 표의 일부다. 실제 사용 언어의 공식 지원표를 확인해야 하며, 드라이버가 재시도 가능 오류를 처리하더라도 애플리케이션은 언제 재시도를 끝낼지 결정해야 한다. [S3]

MongoDB IWM 가격·성능 영향, 무엇을 측정해야 하나

MongoDB IWM 가격에 관해 회사는 적격 클러스터의 기본 보호와 적격 M30+ Dedicated Replica Set의 Load Shedding에 추가 요금이 없다고 설명한다. Atlas 클러스터 자체가 무료라는 뜻은 아니다. MongoDB 9.0 성능 영향을 모든 서비스에 적용할 수 있는 단일 개선율로 제시할 근거도 없다. [S1] [S2]

평가할 때는 같은 테스트 부하에서 대기한 요청, 거부한 요청, 최종 완료한 작업과 응답 시간 분포를 대조한다. 배치와 사용자 요청이 섞이는 서비스라면 각각 나눠 살펴본다. 기본 보호, Load Shedding, 용량 변경을 동시에 바꾸기보다 어떤 변화가 어떤 결과를 만들었는지 구분할 수 있도록 검증을 설계하는 편이 유용하다.