MongoDB 9.0 のオブザーバビリティ機能: 調査時間を削減し、問題解決を迅速化

スタックのあらゆるレイヤーで最新のアプリケーションがテレメトリを生成しますが、何が変化したのか、そしてその理由を理解することは、依然として困難な場合が少なくありません。 データベースのシグナルは別々のワークフローに分散していることが多く、そのためチームはダッシュボードを切り替え、関連のないデータを相関させ、運用状況の全体像を把握できないままパフォーマンスの問題をつなぎ合わせることになります。

MongoDB 9.0 により、データベースの挙動の把握が容易になり、トラブルシューティングを迅速化できます。今回、問題の検知から診断までをより迅速に進められるようチームを支援する、3 つのオブザーバビリティ強化機能を紹介します。

• OpenTelemetryの機能強化により、Atlasのメトリクス、ログ、イベントを、エンジニアリングチームがすでに使用しているオブザーバビリティツールに取り込めます。

• ヘルスとパフォーマンスをクラスター単位でより明確に表示する、再設計されたメトリクス UI。

• 書き込み操作に対応した クエリシェイプインサイト により、クエリレベルの診断が読み取りだけでなく書き込みにも拡張されます。

これらのオブザーバビリティ機能を組み合わせることで、チームは答えを探す時間を減らし、問題の解決、パフォーマンスの最適化、信頼性の高いアプリケーションの維持により多くの時間を費やせます。

MongoDB Atlas のテレメトリをオブザーバビリティスタックに統合

重要なデータベースのコンテキストが別々のシステムに存在する場合、トラブルシューティングではツールを切り替え、何が変化したのかを手動で突き合わせる必要が生じることがあります。MongoDB Atlas は、チームがすでに利用しているオブザーバビリティワークフローにデータベーステレメトリを統合することで、そのギャップを解消します。新たに導入された Atlas イベント統合により、チームは運用コンテキストに関する新しい情報源を活用できるようになります。

Atlas イベント統合により、お客様はクラスターの変更、ユーザーマネージメントの更新、ネットワークアクセスの変更、プロジェクトや組織の構成変更などを含む Atlas アクティビティフィードのイベントを、OpenTelemetry 互換の宛先やその他のサポート対象統合サービスへエクスポートできます。これらのイベントを既存のオブザーバビリティデータと併せて確認できるようにすることで、チームは何かが変更されたという事実だけでなく、具体的な変更点を的確に把握できます。

MongoDB Atlas のメトリクスおよびログ統合と組み合わせることで、チームはパフォーマンスの問題と、その要因となった可能性のある運用アクティビティとの相関関係を特定できます。たとえば、レイテンシの急増を直近の構成変更、アクセス権の更新、スケーリングイベントと並べて確認できるため、チームは表面的な事象から根本原因へとより迅速にたどり着くことができます。

メトリクス、ログ、イベントを組み合わせることで、データベースの操作をより包括的に把握できます。 その結果、オブザーバビリティの連携が強化され、チームはトラブルシューティングを迅速化し、運用の複雑さを軽減するとともに、確信を持って問題を解決するために必要なコンテキストを得られます。

クラスターの健全性を直感的に把握

外部連携により、チームはAtlasをより広範なオブザーバビリティ戦略に組み込むことができます。 新しいメトリクス UIにより、Atlas でクラスターの健全性を直接把握しやすくなります。

刷新された UI により、これまで分断されていたメトリクスワークフローが、クラスターメトリクスを一元的に確認できる単一の統合ビューへと刷新されます。メトリクスは、より明瞭なクラスターレベルのビューで表示され、調査対象のシステムに集中できるよう支援するノードセレクターも備えています。

これは、対応時間が限られているインシデント対応時において極めて重要です。プラットフォームエンジニア、SRE、DBA は、クラスターの挙動を把握するために複数のページを行き来する必要がなくなります。アプリケーション開発者やエンジニアリングリーダーは、オブザーバビリティの専門知識を持っていなくても、アプリケーションの異常を関連する Atlas のシグナルに直接結びつけることができます。一貫したワークフローにより、双方のチームが情報探索に費やす時間を削減し、問題の診断により多くの時間を集中できるようになります。

図 1. 再設計されたAtlas メトリクス UIは、簡素化されたナビゲーション、クラスター レベルのメトリクス、ノード選択コントロールを備え、クラスターのパフォーマンスと健全性を統合的に表示します。

新しい UI は、今後のメトリクス対象範囲の拡大と、より信頼性の高いサービス提供に向けた強固な基盤となるよう設計されています。従来の画面への既存リンクはリダイレクトによって引き続き機能し、サードパーティ統合、Atlas Admin API のメトリクスエンドポイントとなる接続されたデバイス、アラート配信、請求、Performance Advisor や Query Insights を含む周辺ワークフローが今回の UI 刷新によって変更されることはありません。

クエリシェイプインサイトで書き込みにも対応

アプリケーションのパフォーマンスは、読み取りと書き込みの両方に左右されます。読み取りの可視化が極めて重要である一方、非効率な書き込み操作もレイテンシを悪化させ、過剰なリソースを消費し、インフラストラクチャーコストを押し上げる要因となります。MongoDB 9.0 以降を実行している Atlas クラスターでは、クエリシェイプインサイトが insert、update、delete 操作に対応し、クエリパターンがワークロードのパフォーマンスに与える影響をチームが包括的に把握できるようになります。

書き込みのサポートにより、チームは以下の対応が可能になります：

• インデックスが設定されていないフィルターや大規模なアップデートなど、非効率なアップデート操作と削除操作を特定します。

• Docs Matched、Docs Modified、Docs Upserted、Docs Inserted、Docs Deleted などのメトリクスを使用して、書き込みの影響を分析します。

• Keys Inserted や Keys Deleted を含む、書き込み関連のインデックスアクティビティを精査する。

• CPU時間やその他のパフォーマンスメトリクスを使用して、リソースの使用状況を把握し、不要なインフラストラクチャコストを削減します。

• レプリカセットとシャーディングされたクラスター全体で、クエリの動作をフィルターして調査してください。

MongoDB 9.0 以降では、クエリシェイプインサイトは読み取り・書き込み操作に対して、軽量な 1% のランダムサンプリングを使用します。これにより、低いオーバーヘッドで本番環境ワークロードの可視性を確保できます。表示される合計値はサンプリングされた操作（実際のワークロードの約 1%）のみを反映したものであり、全体の処理量ではない点にご注意ください。実行頻度の低いクエリシェイプは表示されない場合があります。

クエリシェイプインサイトは、具体的な値を除去したクエリの構造そのものを捉えて操作をシェイプごとにグループ化するため、数千件におよぶ個別のクエリを少数のシェイプへと集約して可視化できます。チームは、繰り返し発生するワークロードパターンを特定し、パフォーマンス低下の原因となっているクエリを突き止め、インデックス作成やアプリケーション変更による効果を客観的に検証できます。

MongoDB 8.0 以降を実行している専有 Atlas クラスターで利用可能なクエリシェイプインサイトでは、ワークロードの挙動をより包括的に把握でき、MongoDB 9.0 では読み取りと書き込みの両方をより迅速に最適化できます。

チームの運用手法に即したオブザーバビリティ

アプリケーションの分散化が進み、運用環境が複雑化するにつれて、チームには単なる可視性だけでなく、明確なコンテキストをも提供するオブザーバビリティツールが不可欠になります。

MongoDB 9.0 は、データベーステレメトリの既存ワークフローへの統合、MongoDB Atlas 内でのパフォーマンス調査の簡素化、そしてアプリケーション性能に直結するクエリパターンの詳細な把握を支援します。

Atlas のメトリクス、ログ、イベントを全社的なオブザーバビリティプラットフォームへ転送する場合でも、Atlas 上で直接クラスターの健全性を調査する場合でも、あるいはクエリシェイプインサイトを活用して読み取り・書き込みワークロードを最適化する場合でも、目指すゴールは共通しています。それは、チームが問題の検知から原因の究明、そして具体的な対策の実行に至るまでの時間を短縮することです。オブザーバビリティとは、単にシグナルを収集することではなく、それらのシグナルを実行可能な運用のインサイトへと昇華させることに他なりません。