はじめに
アプリケーションのデプロイ直後にエラーが急増、ログとメトリクスを行き来しながら原因を探す…
障害対応で一番つらいのは、この「何から見ればいいのか分からない」初動調査ではないでしょうか。
今回は、New Relicに組み込まれたAIエージェント「New Relic Autopilot」を使って、わざと劣化させたアプリの障害対応がどこまで楽になるのか試してみました。 日本語で話しかけるだけで、どこまで原因に近づけるのかをご覧ください。
New Relic Autopilotとは？
「New Relic Autopilot」（旧称 SRE Agent）は、New Relicのテレメトリーデータ、AI推論、運用ワークフローを組み合わせて、問題を調査するNew Relic作成のAIエージェントです。 主に次のようなことができます。
| 機能 | 内容 |
|---|---|
| アラートのトリアージ（優先度の見極め） | 発生したアラートを過去の傾向と比べて評価 |
| 変更の影響確認 | デプロイ後の性能劣化やエラーの増加を特定 |
| 根本原因の調査 | トレース・ログ・メトリクスから原因を調査 |
| 修復の提案 | ロールバックなどの対応案を提案（実行の判断は人間） |
| Slackのコラボレーション | SlackでNew Relicアプリをメンションし、スレッドを離れずにアラートを調査 |
画面右上の「Ask AI」ボタン（下図の赤枠）からAIパネル（チャット）を開くだけで使えます。
また、Autopilotをワークフローに接続すると、発生したIssueを自動的に分析してくれます。
検証手順
検証シナリオと前提
AWS上のECSで動かしているデモアプリ（Java / Python / Node.js / PostgreSQL on RDS）を使い、次の流れで検証しました。
- 性能劣化を仕込んだv2をデプロイ（Pythonで接続を使い捨てにして、DB接続数を枯渇させる作り）
- 発生したアラートを起点にAutopilotに調査を依頼
- v1へロールバックし、回復をAutopilotに確認
前提条件
- APMエージェントが導入済みのアプリ
- Autopilotの有効化には、Advanced Compute Capacity Unit（aCCU）（Autopilotなどの利用に必要な課金単位）と管理者による設定が必要（無料プランおよび旧製品ベース課金では利用不可）
Step 1：アラート発生！AIに「何が起きている？」と聞いてみる
v2をデプロイして数分後、Criticalアラートが発火しました。
アラートは複数並びますが、どれが本筋か見分けるのは大変です。
そこでAutopilotに「直近でエラーレートが急に上がっているサービスはありますか？」と日本語で聞いてみました。
Autopilotはnr-demo-pythonを名指しし、エラーレートが通常0.06%前後から最大80%に、レスポンスタイムも平均394msから最大1,316msに悪化していると回答。「直前のデプロイ・変更を確認する」「接続プール枯渇の可能性を調べる」といった次の一手まで示してくれました。
また、回答画面の「Show reasoning」を展開すれば、AIが調べた手順も確認できます。
「何から調べればいいか」が一発で絞れるのは、初動でとても助かります。
Step 2：Errors Inboxの「Explain this error」で原因を読み解く
次に、WORKSPACEの「APM & Services」> 対象アプリ名（ここではnr-demo-python）> TRIAGEの「Errors（errors inbox）」で該当のエラーグループを開き、スタックトレースの横にある「Explain this error」をクリックします。
ボタンを押すだけで、AIがスタックトレースを解析します。なお、この機能はAutopilotではなく、New Relic AIの機能です。回答者の表示も「Ask AI」でした。
AIは「psycopg2のOperationalErrorで、DBの最大接続数に達して新規接続が拒否されている」と根本原因を特定し、接続プーリングの導入などの解決策を提示しました。画面に表示された原文（Root Cause）は次のとおりです。
The stack trace indicates an
OperationalErrororiginating from thepsycopg2library, which is used to connect to a PostgreSQL database. (中略) This suggests that the database has reached its maximum number of allowed connections, preventing new connections from being established.
仕込んだ劣化（接続の使い捨て）と、方向性がぴたりと一致していますね。
ちなみにこの回答は、検証時点では英語で返ってきました。日本語で読みたい場合は、続けてチャットに「日本語で回答して」と聞き直すのがおすすめです。
Step 3：「デプロイ前後の変化は？」をグラフで見る
「原因はデプロイかも」と当たりを付けたので、チャットでそのまま聞きます。NRQLは書きません。
Autopilotは、Change Tracking（デプロイなどの変更履歴を記録する機能）のデプロイイベントを基に、デプロイ直後からレスポンスタイムが約3.6倍に悪化し、エラー率が0.6%から78%に跳ね上がったことを、グラフ付きで日本語で説明してくれました。
ここまでの操作は、チャットでの質問2回とボタン1回だけです。ログとメトリクスとデプロイ履歴を見比べる作業が、これだけで済みました。
Step 4：ロールバック後の回復もAIに確認
原因がデプロイと分かったので、v1へロールバックしました。APMの画面でもレスポンスタイム・エラー率が正常値に戻っています。
最後にAutopilotに「nr-demo-pythonの状態は回復しましたか？」と聞くと、「回復済み」とした上で、劣化開始から自動解決までのタイムラインとメトリクス比較表をレポート形式でまとめてくれました。
レポートのタイムライン（UTC）は、v2デプロイ（07:45）→アラート発火（07:52）→ロールバック（09:11）→自動解決（09:23）でした。
ロールバックから約12分で解決したことになります。
これは障害報告書の下書きとして、そのまま使えそうな出来です。
実際にやってみた感想・ハマりどころ
- 原因の提示はあくまで「可能性」。公式ドキュメントにも提案内容は必ず人間が確認するよう明記されているため、「Show reasoning」で調査手順を確かめつつ、ログやメトリクスで裏取りする
- Autopilotの利用には「aCCU」などの前提があり、全アカウントで使えるわけではない
- Change Trackingでデプロイ時にDeployment Marker（グラフ上にデプロイ時刻を示す印）を登録しておくと、AIが「デプロイ前後」で分析しやすい
まとめ
この記事では、New RelicのAIエージェント「New Relic Autopilot」を使い、障害の検知から原因の当たり付け、復旧確認までを試してみました。
- 初動が速くなる：「どこがおかしい？」をAIに聞けば、怪しいサービスと次の一手が返ってくる
- スタックトレースが読めなくても大丈夫：「Explain this error」で原因と対策案が分かる
- NRQLを書かずに分析できる：デプロイ前後の比較もチャットで完結する
- 報告まで楽になる：回復確認のレポートがそのまま下書きになる
次回はAutopilotをワークフローに接続し、ユーザーが質問をしなくても障害が発生したら自動的に原因特定を実施する「Workflow Automation」を試してみます。
お楽しみに！
SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。
詳しくは以下をご参照のほどよろしくお願いいたします。
