新製品・アップデートのご紹介MongoDB は、Voyage AI の買収を通じて、Atlas における生成 AI アプリケーションの精度と信頼性を強化します。詳しく見る >>
新着情報今すぐチェック!:AI 対応開発向け MongoDB MCP Server(パブリックプレビュー)ブログを読む >>
新着情報MongoDB 8.0:圧倒的な速度と性能を提供。詳しく見る >>
Blog home
arrow-left

インテリジェントなワークロード・マネージメント:重要な瞬間にクラスターの可用性を維持する

2026年10月8日 ・ 5 min read

最新のアプリケーションでは、トラフィックが急増したり、クエリによってリソースが過剰に消費されたりしても、可用性を維持する必要があります。MongoDB Atlas は高可用性を目的に設計されていますが、実際の可用性は単なるホストの障害への対応やレプリカセットの選挙以上ものになります。それはまた、需要が安全に処理できる範囲を超えたときにクラスターがどのように動作するかということにも関係しています。

先週、MongoDB 9.0 の一般提供(GA)として、インテリジェント・ワークロード・マネージメント(IWM)を知らせる。IWMは、過負荷下でもAtlasクラスターの応答性と予測可能性を維持するためのマネージド可用性機能です。IWMは一時的なスパイクをキューに入れ、短時間の実行中操作をスムーズに進行させ、長時間の実行中操作を安定させ、アプリケーションを変更することなくクラスターの健全性を保護します。

過負荷イベントは、インフラストラクチャが増やすよりも速く発生することがよくあります。オートスケーリングを有効にしても、追加のキャパシティーをプロビジョニングするには時間がかかります。トラフィックのスパイクが発生してから新しいキャパシティーがオンラインになるまでの間、すべてのリクエストが同じように処理され、クライアントが積極的にリトライすると、クラスターが不安定になる可能性があります。IWMは、クラスターの健全性を維持し、パフォーマンスを最適化し、予測不可能な停止時を制御可能で観測可能なイベントに変えることで、The Gapを埋めるようにビルドされています。

“

Coinbaseでは、取引量が数分で急増することがあり、カスタマーに影響が出ないよう、当社のシステムはリアルタイムで増やす必要があります。Intelligent Workload Managementにより、取引のピークウィンドウにクラスターが確実にレスポンスを維持できるという確信が持てます。

”
Krishnan Seshadrinathan, エンジニアリング担当VP, Coinbase

持続的な過負荷に対しては、カスタマーは必要に応じて Load Shedding を有効にし、過剰な操作を拒否することができます。IWMはスパイクが発生したり、キャパシティーが追加されたりする際の圧力の管理を支援しますが、キャパシティーを追加したり、オートスケーリングやキャパシティー計画を置き換えたりするものではありません。

図 1.Intelligent ワークロード マネージメント(IWM)は、クラスターの応答性と予測可能性を維持するために適応します。

MongoDB 9.0のインテリジェント・ワークロード・マネージメント(IWM)に関するインフォグラフィック。見出しは「Atlasは限界に達しても停止せず、適応する」。主な利点は、Atlasマネージドの過負荷保護、クラスタの応答性と予測可能性の維持、オートスケーリングまたは演算子アクションのための時間の確保、予測不可能な停止を制御可能で観測可能なイベントへの変換の4点です。

キャパシティーが追いつくまでのワークロードの圧力の管理

トラフィックの急増やリソース集約型の操作により、インフラストラクチャが増やすよりも速く需要が増加する可能性があります。オートスケーリングが有効になっている場合でも、追加のキャパシティーのプロビジョニングには時間がかかります。クライアントによる積極的な再試行は、クラスターがすでにビジー状態にあるときに負荷を増大させる可能性があります。

IWMは、その間のワークロードの圧力を管理するのに役立ちます。これはオートスケーリングの有無にかかわらず機能します。オートスケーリングを有効にする場合、IWMはキャパシティーがオンラインになったときにクラスターを安定させるのに役立ちます。オートスケーリングがない場合、IWMはクラスターのプロビジョニング済みキャパシティーでワークロードを管理します。持続的な需要や増加する需要に対しては、キャパシティーの追加が必要になる場合もあります。

IWMがワークロードの負荷にどう対応するか

クラスターが正常な状態であれば、IWMの存在を意識する必要はほとんどありません。クラスターが安全に処理できる範囲を超えた負荷が発生した場合、IWMは段階的に圧力をマネージドします。

  • 受信ワークを制限し、余剰リクエストをキューに入れます: デフォルトでは、IWMは余剰リクエストを積極的に拒否するのではなく、キューに入れます。これにより、一時的なスパイクを吸収できますが、リソースが制限されている間、キューに入れられたリクエストの完了に時間がかかる場合があります。キューイングはワークが処理されるタイミングを変更するものであり、アプリケーションが最終的にクラスターに要求するワークの量を変更するものではありません。
  • これは、短時間実行中の操作を円滑に進行させるのに役立ちます。一般的な読み取りや書き込み (write)のような短時間実行中の操作と、大規模なレポート作成・クエリのような長時間実行中の操作では、クラスターへの負荷が異なります。リソースが制限されている場合、IWMは長時間実行中の操作をより保守的に管理しながら、短時間実行中の操作を円滑に進行させます。
  • リソースのプレッシャーを管理するのに役立ちます: メモリの断片化、キャッシュの不均衡、ストレージの枯渇はすべて、健全なクラスターを不安定にする可能性があります。IWMは、不健全なパターンを検知するとクラスターのメモリとキャッシュのマネージメントを調整し、ストレージの使用率が危機的なレベルに達したときに、読み取りを許可したまま新しい書き込み (write)を一時停止できます。

これらの保護は、過負荷時にクラスターの健全性を維持するのに役立ちます。これらは、キャパシティーを無制限にしたり、適切なインデックスの作成、キャパシティー計画、またはオートスケーリングに取って代わったりするものではありません。

デフォルトの保護機能と任意のロードシェディング

IWMのデフォルト保護は、MongoDB 9.0を実行中の対象の専用Atlasクラスターで追加コストなしで有効になります。アプリケーションの変更やドライバーのアップグレードは不要です。デフォルトでは、IWMは過剰なワークロードを積極的に拒否することなくオーバーロードを管理します。

負荷遮断(Load Shedding)は、持続的なオーバーロードに対する個別の任意コントロールです。有効にすると、過剰な操作が拒否される場合があり、その拒否はアプリケーションにオーバーロードエラーとして表示されます。負荷遮断(Load Shedding)は、MongoDB 9.0を実行中の対象のM30以上の専用レプリカセットAtlasクラスターで追加料金なしで利用できます。

デフォルトのIWM保護は、任意のMongoDBドライバーで機能します。ロード・シェディングを有効にする場合は、サポートされているバックプレッシャー対応ドライバーを使用して、アプリケーションが過負荷信号を解釈し、バックオフを伴う制限付き再試行を応用できるようにしてください。ロード・シェディングを有効にする前に、サポートされているドライバーのマトリックスを確認してください。

図 2. デフォルト(キューイング)と Load Shedding 設定の違い。

IWMモードの比較。左側がデフォルトのキューイング(低摩擦のアップグレード、正常な劣化、最適な出発点)、右側がオプトインのロードシェディング(境界付きのレイテンシとスループット、アプリケーションから可視化される動作、準備が必要)です。

Observability(オブザーバビリティ)によるIWMインターベンションの理解

Atlasで、キューに入った操作や拒否された操作、あるいはコネクションについて、操作レート制限メトリクスとコネクションレート制限メトリクスをレビューしてください。「負荷制限(Load Shedding)」が有効になっている場合、拒否された「操作」が「操作のレート制限」に表示されます。IWMの関連アクティビティをトラックするためにIWMアラートの条件を設定またはレビューし、アクティビティフィードでIWM関連のイベントを確認してください。これらのAtlasサーフェスを連携させると、プレッシャーが継続しているかどうかを評価し、ワークロードのパスワードなしを検討するか、キャパシティーを追加するかを判断するのに役立ちます。 AtlasでのIWMの可観測性について詳しく学ぶ。

任意のLoad Sheddingの利用を検討しているチーム向けに、Atlasでは本番環境でこの機能を適用する前に、ドライバーの互換性、アプリケーションによる過負荷エラーの処理、運用の可視性を検証するためのテストを提供しています。アクティブなテストまたは開発クラスターでテストすると、Atlasは負荷に関係なく、わずかな割合の操作をランダムに拒否します。チームは拒否された操作をメトリクスのチャートで追跡し、テスト終了後に結果をレビューできます。テスト中にアプリケーションが過負荷エラーに遭遇する可能性があるため、チームはクライアントの動作を検証する目的のみにこれらのテストを使用してください。チームは本番クラスターでテストを実行しないでください。 Load Shedding のテスト方法について学ぶ。

IWMの動作と過負荷への対応方法の詳細については、IWMのドキュメントをご覧ください。

入門

  1. クラスターがMongoDB 9.0を実行中の専用Atlasクラスターであることを確認してください。

  2. 継続的な過負荷中にオートスケーリングでキャパシティーを追加するかどうかを決定します。IWMは、追加のキャパシティーがオンラインになる間の圧力管理をサポートしますが、オートスケーリングやキャパシティー計画を置き換えるものではありません。

  3. ロードシェディングを有効にする場合は、サポートされているドライバーのマトリックスを確認し、アプリケーションがバックオフを使用した境界付きリトライを使用していることを確認してください。

  4. Atlasの可観測性ダッシュボードをレビューし、IWMがいつ介入するか、どのワークロードが影響を受けるかを理解します。

megaphone
次のステップ

過負荷イベント発生時に、クラスターをより予測可能な状態に保つ準備はできましたか?IWMのドキュメントを読むか、Atlasのオートスケーリングについて調べるか、またはMongoDB Atlasにサインアップして、今すぐ構築を始めましょう。 

MongoDB リソース
MongoDB 製品|Atlas Learning Hub|MongoDB University|ドキュメント|MongoDB イベント