そのAPMは本番規模に耐えられる？ 大規模環境で確認したい「7つの要件」：アプリケーション監視の主要5ツールも整理

システムの規模や複雑さが増したとき、APMツールにはどのような問題が生じる可能性があるのか。New Relicは大規模環境でAPMツールを選ぶ際の7つの要件と評価方法をブログ記事で示した。

[＠IT]

　アプリケーションの性能や障害を監視するAPM（アプリケーション性能監視）ツール。選定や運用に当たって考慮したい点の一つが、自社で運用するシステムの規模や複雑さに対応できるかどうかだ。APMツールのどのような点を確認すればいいのか。オブザーバビリティー（可観測性）ツールを提供するNew Relicが2026年9月3日（米国時間）に公開したブログ記事を基に見てみよう。

大規模環境のAPMに求められる「7つの要件」

　APMツールを選ぶ際のポイントの一つとして挙げられるのが、システムの規模や複雑さが増したときの対応力だ。マイクロサービスや分散システム、ハイブリッドクラウド、「Kubernetes」などによってシステムが複雑化すると、それまで問題なく使えていたAPMツールが運用規模に追い付かなくなることがあるとNew Relicは指摘している。

　例えば、20のサービスを扱えていたツールが、規模の拡大に伴って必要なトレースをサンプリングで取りこぼす。アラートの数が担当者のトリアージ能力を超えて増える。数分で終わっていた根本原因分析に複数のチームを集め、それぞれが全体像を把握していないサービス群をまたいでリクエストを追跡しなければならなくなる。APMツールが運用規模に追い付かなくなることで、こうした問題が発生する可能性がある。

　New Relicは、エンタープライズ向けAPMは一般的なAPMを単純に大規模化したものではなく、求められる要件そのものが異なるとして、次の7点を挙げている。

1. 大規模な分散トレーシング
   • リクエストが通過する全てのマイクロサービスを端から端まで可視化し、インシデントの説明に必要なトレースをサンプリングで捨てない
2. フルスタックの網羅
   • アプリケーション、インフラ、ログ、リアルユーザーモニタリングを、別々のダッシュボードではなく相関の取れた1つのビューにまとめる
3. AIと機械学習による根本原因分析と予測分析
   • 数百のサービスを運用する規模では、MTTR（平均修復時間）を短く抑えられるほど迅速に、人手でイベントを関連付けることはできない
4. 「OpenTelemetry」のサポート
   • プロプライエタリのエージェントはロックインを生む。OpenTelemetry対応は「あればよい」ではなく前提条件となる
5. マルチクラウドとハイブリッドへの対応
   • 「Amazon Web Services」（AWS）、「Microsoft Azure」「Google Cloud Platform」（GCP）、オンプレミス、Kubernetes、サーバレスを同時に監視できる必要がある
6. SLO（サービスレベル目標）とエラーバジェットの管理
   • 単に稼働率を見るだけではなく、可用性の約束を追跡してアラートを出す
7. 透明性のある価格
   • エンタープライズのテレメトリー量では、ホスト単位や製品単位の課金は予測が難しい。請求が届く前に金額を見積もれることが求められる

主要5ツールを6つの観点で整理

　ブログ記事では、エンタープライズ向けAPMの主な選択肢として5つのツールが挙げられている。分散トレーシング、AI／AIOps、OpenTelemetryへの対応、マルチクラウド対応、価格モデル、コンプライアンスの6つの観点で整理している。違いが表れるのは、計測の柔軟性、AIがどこまで担うか、規模が拡大したときの価格、他のオブザーバビリティー基盤との接続性だという。

New Relic

　フルスタックの分散トレーシングとサンプリング損失の少なさをうたう。根本原因分析と異常検知を内蔵し、OpenTelemetryデータのネイティブ取り込みに対応する。価格はデータ取り込み量に基づく従量課金制。

Dynatrace

　自動化されたAI支援の分散トレーシングを備え、AIエンジン「Davis AI」による根本原因分析を強みとする。OpenTelemetryに対応するが、一部に独自方式との重複がある。価格は使用量ベース。

AppDynamics

　ビジネストランザクションを軸にした分散トレーシングと異常検知の「Cognition Engine」を備える。OpenTelemetryに対応。ライセンスはコア単位またはユーザー単位。

Datadog

　フルスタックの分散トレーシングと幅広い連携が特徴で、異常検知の「Watchdog」を持つ。OpenTelemetrデータのネイティブ取り込みに対応。価格はホスト単位の料金に使用量ベースの追加料金が加わる。

AWS X-Ray、Amazon CloudWatch

　AWSにネイティブな分散トレーシングを提供する。異常検知は基本的な機能にとどまり、OpenTelemetryへの対応は部分的。価格はAWS内での従量課金。

評価はサンドボックスではなく「本番規模」で

　では、こうした要件を満たしているかどうかを、実際にどう見極めればいいのか。New Relicは、APMツールの評価でよくある失敗として、合成データを使ったサンドボックスだけで検証することを挙げている。システムの規模や複雑さが増したときに生じる問題を見極めるには、実際のテレメトリー量やサービス数など、本番に近い条件で評価する必要があるという。

　特に確認すべきなのが、大量のデータを扱ったときにも必要なトレースを維持できるかどうかだ。負荷が高まった際に、障害原因の特定に必要なトレースまでサンプリングによって失われれば、分散トレーシングを導入していても十分な調査ができなくなる。

　AIによる根本原因分析についても、用意されたデモだけで性能を判断すべきではないという。New Relicは、実際に発生したインシデントを使い、単に「何かが変化した」と検知するだけなのか、それとも障害の根本原因まで特定できるのかを確かめることを勧めている。

　コストについても、自社の実際のデータ量を基に試算することが重要だ。テレメトリーの取り込み量が増えた場合に料金がどの程度変化するのかを確認し、大規模環境でも維持できる価格になるかを見極める。この他、OpenTelemetryで収集したデータを独自エージェントなしで取り込めるかどうか、必要なセキュリティ要件や認証を満たしているかどうか、ログ管理やインフラ監視など既存の監視ツールをどこまで統合できるかも評価項目になる。