MongoDB 9.0 과부하 대응, 큐잉과 Load Shedding을 구분해야 하는 이유
Intelligent Workload Management의 적용 조건과 애플리케이션이 준비할 재시도·관측 지점
접속자가 급증했을 때 데이터베이스가 모든 요청을 즉시 실행하려 하면 운영자는 응답 지연과 자원 압력을 함께 마주할 수 있다. 이때 요청을 기다리게 할 것인지, 일부를 거절할 것인지는 사용자 경험에도 영향을 준다. MongoDB의 새 가용성 기능을 읽는 핵심은 ‘자동으로 해결된다’는 기대보다 이 동작 차이를 이해하는 데 있다.
MongoDB Intelligent Workload Management가 맡는 역할
MongoDB는 2026년 10월 8일 IWM의 동작을 소개했다. MongoDB 과부하 상황에서 보호 기능으로 요청 압력을 관리하고, 자동 확장으로 새 용량이 준비될 때까지 클러스터 상태를 유지하도록 돕는다는 설명이다. 회사는 이 기능이 용량 추가나 오토스케일링·용량계획을 대신하지 않는다고 명시했다. [1]
MongoDB 트래픽 급증 대응에서 가용성과 처리 속도는 구분해야 한다. Atlas 성능을 검토할 때도 기능 이름만으로 응답시간 단축을 기대하기보다, 어떤 요청이 지연되거나 거절되는지와 업무에 미치는 영향을 함께 확인하는 것이 좋다.
MongoDB 큐잉과 Load Shedding은 어떻게 다른가
MongoDB 9.0 성능 영향을 판단할 때 먼저 볼 것은 압력 관리 방식이다. 기본 큐잉은 초과 요청을 대기시키므로 제약 상황에서 완료가 늦어질 수 있다. 선택형 MongoDB Load Shedding을 켜면 지속 과부하에서 초과 작업을 거절하고, 애플리케이션이 과부하 오류를 보게 된다. [1]
| 행동 | 앱에서 확인할 지점 | 판단 질문 |
|---|---|---|
| 큐잉 | 대기·완료 지연 | 업무의 허용 대기시간 안에 끝나는가? |
| Load Shedding | 거절 오류·재시도 | 오류를 구분하고 부하를 줄이며 재시도하는가? |
큐잉이 있다고 작업량이 줄어드는 것은 아니다. 지연을 받아들일 수 없는 업무라면 애플리케이션의 타임아웃과 사용자가 기다릴 수 있는 범위까지 포함해 검증해야 한다. 이 표는 공식 동작을 바탕으로 정리한 운영 점검 기준이다.
MongoDB IWM 지원 클러스터와 가격
공식 문서에 따르면 IWM은 MongoDB 9.0 이상 Atlas Dedicated Cluster에 적용되며 Free·Flex는 지원하지 않는다. 다만 보호 기능의 조합은 티어와 토폴로지에 따라 다르다. [2]
| 클러스터 구성 | Ingress 큐잉 | 선택형 Load Shedding |
|---|---|---|
| M10·M20 | 미적용 | 미지원 |
| M30+ 복제 세트 | 적용 | 켜면 적용 |
| M30+ 샤딩 | 미적용 | 미지원 |
MongoDB IWM 가격에 대해서는 소개 글이 적격 클러스터의 기본 보호와 적격 M30+ 전용 복제 세트의 Load Shedding을 추가 비용 없이 제공한다고 설명한다. 클러스터 자체의 이용 요금이 없다는 뜻은 아니다. [1]
전용 클러스터라는 이름만 확인하고 모든 보호 기능을 같게 기대하면 안 된다. 운영 설정에는 버전, 티어, 복제 세트·샤딩 여부와 실제 적용 기능을 함께 기록하자.
MongoDB Load Shedding 사용법: 클라이언트부터 검증
Load Shedding은 M30+ 복제 세트의 MongoDB 9.0 이상에서 설정할 수 있다. 9.0에서 Atlas Managed의 실효 상태는 Disabled라고 안내돼 있다. 설정은 Atlas UI 또는 Administration API 경로를 사용하며, 적용 전에 지원 드라이버와 오류 처리를 확인해야 한다. [2]
공식 오류 문서는 SystemOverloadedError만으로 안전한 재시도를 판단할 수 없다고 설명한다. RetryableError는 실행되지 않아 재시도 가능한 작업을, NoWritesPerformed는 쓰기 전 거절됐음을 나타낸다. 지원 클라이언트는 재시도 가능한 오류에 지수 백오프와 지터를 적용하며, 앱은 재시도 기간을 정해야 한다. [3]
모든 실패를 즉시 반복하면 보호 기능의 목적과 어긋날 수 있다. 팀은 쓰기 작업의 중복 가능성, 사용자의 재요청, 백그라운드 작업의 재예약까지 나누어 검토하자. 원문 드라이버 표에서 현재 사용하는 라이브러리의 최소 지원 버전을 확인하는 단계도 필요하다.
도입 테스트는 거절을 정상적으로 처리하는지 확인하는 것
MongoDB는 Load Shedding 테스트를 개발·테스트 클러스터의 클라이언트 동작 검증에 사용하고 운영 클러스터에서 실행하지 말라고 안내했다. Operation Rate Limiting, Connection Rate Limiting과 Activity Feed 등에서 큐잉·거절·이벤트를 확인할 수 있다. [1]
첫 도입은 정상 부하에서의 성공만 확인하는 작업이 아니다. 압력이 높아졌을 때 어떤 업무를 기다리게 하고, 무엇을 중단하며, 어느 시점에 용량을 늘릴지까지 연결해야 한다. 이런 기록을 남겨야 보호 기능을 실제 서비스의 운영 기준으로 사용할 수 있다.
