New Relic 導入レビュー：監視基盤の統合とAIエージェントの活用

• 当時はアプリケーションメトリクスをGrafana、トレースをX-Ray、ログをOpenSearch / CloudWatch、AWSインフラをCloudWatchと、4つの基盤に分散して利用しており、システム障害時の調査経路が複雑化していました。それを解消するために複数のモニタリングツールが分散している状況の見直しを開始しました。

• 比較対象の製品を実プロダクトで検証し、最終的にプラットフォーム共通の選択肢としてNew Relicの採用を決定。プロダクトに対しては「Grafana + α」か New Relic を選択できる形式でスタートし、オブザーバビリティを積極活用したいプロダクトからミニマムスタートを進めています。

ツール導入前の課題

監視ツールの分散と学習コストの高さが、運用上のボトルネックになっていました。

• 監視ダッシュボードが活用されておらず、ツールの種類が多く学習コストが高かった
• 監視の際に見る場所が分散していた
  アプリケーションメトリクスは Grafana、トレースは X-Ray、ログは OpenSearch / CloudWatch、AWS インフラは CloudWatch
• 情報が分散しているため、システム障害時の調査が困難で必要な情報にすぐたどり着けなかった
• 学習コストの高さから担当者が使えるようになるまでの時間が長く、有効活用できていないプロダクトが多かった

どのような状態を目指していたか

「まずここを見ればシステムの状況が分かる」という単一のエントリポイントを用意することをゴールに、以下の状態を目指しました。

• 見る場所を 1 か所に集約する
• 学習コストを削減し、担当者が素早く使いこなせるようにする
• 情報到達速度を上げ、システム障害からの復旧時間を短縮する
• 全てのプロダクトで監視ダッシュボードが有効活用されている状態を実現する

• Datadog
• Grafana（+Prometheus / OpenSearch / Site24x7）
• New Relic

機能だけでなく、チームで継続して使えるかを重視しました。

• ダッシュボードを統合できるか（情報到達速度が向上するか）
• 既存機能（APM / ログ検索 / インフラメトリクスの確認 / アラート設定）を損なわず、かつプラスアルファの機能があるか
• コストに見合うか（利用費・運用コスト・移行コストを含む費用対効果）
• 使用感（UI/UX の快適さ・動作のスムーズさ）
• 権限管理（参照範囲の制御・ログのマスキング処理）

最終的には、障害調査のしやすさと運用コストのバランスでNew Relicを選びました。

• APM・ログ・トレース・インフラを 1 プラットフォームに統合でき、障害時に情報をたどる場所が 1 か所に集約できると判断した
• 他製品と比較して、フルユーザを絞りつつ無料ユーザを活用することで費用対効果が高いと試算できた
• Agent をサイドカーとして追加するだけで既存アプリへの改修が最小限で済む（実装コストが低い）
• コストが都度見直し（3 か月ごと）の課金モデルのため、突発的なコスト増への対応がしやすい
• New Relic エンジニアによる定期的な勉強会・オンボーディングサポートの存在

改善したかった課題はどれくらい解決されたか

監視データをNew Relicに集約したことで、障害調査の動線が大きく改善しました。

• 監視データがNew Relicに集約され、障害時の調査経路が APM → ログ → ブラウザで1画面内に収まるようになった
• アラート・ダッシュボードをTerraform管理に移行し、PRレビュー上で差分追跡できるようになった
• Change Trackingの導入により、デプロイ前後のメトリクス変化を即座に確認できるようになった

どのような成果が得られたか

導入後は、障害調査だけでなく、アラートやログ調査の運用も見直しやすくなりました。

• アラート条件やダッシュボードを継続的に見直すサイクルを作りやすくなった
• 業務例外とシステム起因のエラーを分けて扱えるようになり、不要な通知を減らせた
• ログとトレースを同じ流れで確認でき、原因調査の手順をチーム内でそろえやすくなった
• UI だけでは難しい集計や過去ログ取得は、NRQLやNerdGraph APIを使って補完できるようになった
• New Relic MCP ServerをAIエージェントに接続し、日次ログレポートの自動投稿にも取り組み始めた

アカウント設計・権限・セキュリティ

1AWSアカウントに複数プロダクト・複数環境が同居している場合、New Relicの「1NRアカウント=1AWSアカウント」を前提とした思想と噛み合わず、設計面で時間を要しました。

• 単一アカウントへ統一するか、プロダクト別に新規アカウントを切るか判断に時間がかかった
• 子アカウントの分け方（システム単位 / グループ単位 / プロダクト集合単位）にそれぞれトレードオフがあった
• 横断的な可視化とセキュリティ境界の両立が難しかった

AWS インテグレーション

AWS連携では、ログ取得方式とサーバレスサービスの扱いに検討時間が必要でした。

• AWSログの取得方法（logstash 経由 / Lambda 経由 / Firehose 経由）の選定が必要だった
• OpenSearch をなくすためには、AWSログの取り込み方針を先に決める必要があった
• API GatewayなどLambda以外のサーバレスサービスのトレースをどう追うかが課題だった
• New Relicを採用しても、既存共通基盤のAWSコスト按分は別問題として残った

アプリケーション・コンテナ実装

ECS Sidecarの管理と、既存ロギング実装との接続も論点になりました。

• ECS Sidecarをどこで管理するか（ECR 登録運用の検討）を決める必要があった
• Spring Bootのlogback実装見直しが必要だった
• New Relic Agent経由のログ送信で、logbackで付与した情報を取得できるか確認が必要だった

これからNew Relicを導入される方は、以下の観点を初期設計の段階で押さえておくと、運用に乗せやすくなります。現代のソフトウェアではオブザーバービリティツールの導入は必須と考えられます。

• アカウント設計（統一 / プロダクト別）の方針を最初に決めておく。後からアカウントを跨いだデータ集約は手間が大きい
• ログのマスキング/ドロップルールは導入時に設計する。PII を含む生ログを取り込んでしまうと後追いの整備が困難
• CloudWatchメトリクス取得方式（Pull / Metric Streams）は事前にコスト試算する。取得対象を絞り込まないと想定外の料金になる
• 最初からTerraformでIaC化することを推奨。後からIaC化するコストは高い
• 環境別のapp分離をローカル開発含めて初期に設計しておく
• 業務エラーと不具合を分けて通知設計する。Errors Inbox の信頼性は初期設計で決まる

監視データを集約した次のフェーズとして、AI エージェントによる運用自動化とSREプラクティスの充実化を見据えています。

• AIエージェントによる運用自動化の拡大（自律的なトリアージ・修正提案）
• SLOベースの監視への移行とエラー予算管理の運用化
• ビジネスメトリクスと技術メトリクスを1ダッシュボードで相関できる体制の構築
• Service Architecture Intelligence（Catalog / Maps / Teams / Scorecards）の活用：チーム・サービス単位の可視化と健全性スコアリング