DB 소식
MongoDB 9.0 IWM, 과부하를 큐잉으로 완충…Load Shedding은 별도 선택
적격 Atlas 클러스터 기본 보호와 초과 작업 거부를 구분…증설·인덱스·재시도 설계는 여전히 필요
- MongoDB가 10월 8일 Intelligent Workload Management의 과부하 대응을 상세 설명했다.
- 기본 동작은 초과 요청 큐잉이며 Load Shedding을 켜면 애플리케이션이 거부 오류를 받을 수 있다.
- IWM은 처리 용량을 늘리는 기능이 아니다. 지원 클러스터와 드라이버 준비를 확인해야 한다.
트래픽이 갑자기 늘 때 DB가 먼저 느려지고 클라이언트 재시도가 다시 부하를 높이는 상황은 용량 증설만으로 즉시 해결되기 어렵다. MongoDB Intelligent Workload Management는 바로 이 과도기에서 작업을 어떻게 받아들이고 처리할지에 초점을 둔다.
기본 보호는 요청을 기다리게 한다
MongoDB는 IWM을 Atlas의 관리형 가용성 기능으로 소개했다. 일시적인 MongoDB 트래픽 급증에는 여분 요청을 큐에 넣고, 짧은 작업이 진행되도록 하면서 긴 작업을 보수적으로 관리한다. 공식 GA 안내일은 9월 29일이고 이번 상세 설명은 10월 8일이다. [S1] [S2]
큐잉은 작업량 자체를 없애는 것이 아니라 처리 시점을 조정한다. 따라서 서버가 안정적으로 버틴다고 모든 요청의 응답시간이 그대로 유지되는 것은 아니다. DB 생존 여부와 사용자가 경험하는 대기시간을 별도 지표로 보는 것이 기능 평가에 유리하다. [S1]
MongoDB Load Shedding은 기본 큐잉과 다르다
지속적인 과부하에는 선택형 Load Shedding으로 초과 작업을 거부할 수 있다. 기본 IWM은 적극적으로 작업을 거부하지 않는 반면, 이 기능을 켜면 거부가 애플리케이션에 과부하 오류로 보인다. 기능 이름만 보고 ‘성능 자동 개선’으로 이해하기보다 사용자 요청의 결과가 어떻게 바뀌는지 확인해야 한다. [S1]
도입 전에 오류를 받은 클라이언트가 무제한으로 즉시 재시도하는지 확인할 필요가 있다. 공식 문서는 Load Shedding을 사용할 때 지원되는 backpressure-aware 드라이버와 제한된 재시도·백오프를 요구한다. 기본 보호에는 애플리케이션 변경이나 드라이버 업그레이드가 필요 없다는 설명을 선택형 거부 기능에 그대로 적용하면 안 된다. [S1]
| 구분 | 기본 IWM | 선택형 Load Shedding |
|---|---|---|
| 초과 작업 | 큐잉 중심 | 조건에 따라 거부 |
| 사용자 측 영향 | 대기시간 증가 가능 | 과부하 오류 처리 필요 |
| 도입 점검 | 적격 클러스터·관측 | 지원 드라이버·재시도·오류 대응 추가 |
적격 Atlas와 M30+ 조건을 확인
IWM의 기본 보호는 MongoDB 9.0을 실행하는 적격 Atlas Dedicated Cluster에서 추가 비용 없이 활성화된다. Load Shedding은 적격 M30+ 전용 replica-set Atlas 클러스터에 추가 비용 없이 제공된다고 상세 글이 설명한다. 자체 운영 MongoDB나 모든 Atlas 구성을 동일 대상으로 단정해서는 안 된다. [S1]
MongoDB IWM 가격에서 ‘추가 비용 없음’은 이 기능의 요금 설명이다. 클러스터 사용료와 증설 비용까지 사라진다는 뜻은 아니다. 실제 적용 여부는 클러스터 버전·형태·등급을 확인하고 현재 공식 문서의 적격 조건과 대조해야 한다.
가용성 보호 뒤에도 용량 계획은 남는다
MongoDB는 IWM이 오토스케일링을 대체하지 않는다고 명시했다. 자동 증설이 켜져 있으면 새 용량이 준비될 때까지 부담을 관리하고, 꺼져 있으면 현재 마련된 용량 안에서 대응한다. 지속적으로 늘어나는 수요에는 여전히 인덱스와 쿼리·용량 계획이 필요하다. [S2]
운영자는 Atlas의 작업·연결 rate limiting 지표와 IWM 이벤트를 통해 큐잉·거부를 확인할 수 있다. Load Shedding 시험은 운영 클러스터에서 실행하지 말라는 안내도 있다. 신규 기능 확인을 위해 실제 사용자의 요청을 임의로 거부시키지 않도록 개발·시험 환경에서 클라이언트 반응부터 검증해야 한다. [S1]
MongoDB 9.0 성능 영향을 평가할 때는 단일 평균 지연만 비교하기보다 짧은 작업의 진행, 긴 작업의 대기, 오류·재시도량을 함께 보는 것이 좋다. IWM의 핵심 가치는 처리 능력을 무한히 늘리는 데 있지 않고 과부하를 관찰하고 대응할 수 있는 상태로 관리하는 데 있다.
