アプリケーションエラーのトラブルシューティング

アプリケーションに障害はつきものです。どんなに入念にテストされたアプリケーションでも、実際に運用が始まり、ユーザーが使い始めると予期しないエラーが発生することがあります。大事なことは、問題が起きたことを認識するだけではなく、なぜ問題が起きたのかその原因を突き止め、多くのユーザーに影響が広がる前に解決することです。

しかし、言うは易く行うは難しです。マイクロサービスやサードパーティの依存関係、そして絶え間ないコード変更の中で、根本原因を見つけるのはまるで動いている糸のもつれをほどくようなものです。チームが問題の解決に取り組んでいる間にも、ユーザーは離れていき、サポートチケットが増え続け、収益が失われるリスクも生じます。

こうした状況ではエラー分析が力を発揮します。エラー分析は、問題点の把握だけでなく、傾向や原因を探り、問題をすばやく対処するためのシステムとして機能します。本記事では、体系的なエラー分析の手法が、チームのダウンタイム削減やユーザー体験の向上にどのように役立つかを解説します。また、オブザーバビリティ（可観測性）によって推測作業を減らす方法や、New Relicなどのツールによってプロセス全体の効率、信頼性、拡張性を高める方法についても説明します。

エラー分析が重要な理由

最新のアプリケーションは複雑で、マイクロサービス、API、サードパーティインテグレーション、クラウドインフラストラクチャに基づいて構築されています。どこかに不具合が生じても、その影響が必ずしもすぐには明らかになるとは限りません。最初は一部のサービスで数回の500エラーが起きただけでも、トランザクションの失敗やユーザーの不満、収益の損失など、問題があっという間に大きくなってしまうことがあります。そして、その収益損失は急速に増大します。Forbesのレポートでは、大企業の場合、予定外のダウンタイムのコストは1分あたり約9,000ドルと推定されています。また、Atlassianによると、中規模企業でも、業種やデジタルサービスへの依存関係に応じて、1分あたり5,600ドルから9,000ドルのコストがかかる可能性があります。しかし、損失は金額だけにとどまりません。エラーが繰り返し発生したり長期間続いたりすると、ユーザーの信頼を損ねるだけでなく、サポートチームの負担も増加します。また、エンジニアが本来の開発業務から離れてインシデント対応を優先することになり、開発の進捗も遅れてしまいます。こうした事態が続くと、ブランドイメージにも悪い影響が及ぶ可能性があります。

このような理由から、エラー分析、ひいてはオブザーバビリティが重要になります。New Relicの2024年度オブザーバビリティ予測レポートによると、フルスタックオブザーバビリティに投資しているチームは、システム停止時の復旧が18%速いことがわかっています。企業はまた、最初からワークフローにオブザーバビリティを組み込むことで、ダウンタイムが最大79%削減され、システム停止コストが48%削減されると報告しています。

オブザーバビリティが全体像を把握するためのものなら、エラー分析はより細部に焦点を当てて詳しく調べるためのものです。どのような障害が、どこで、どのくらいの頻度で発生しているかを示し、散在するエラー信号を実用的な洞察に変換します。推測や個別の事例報告に頼るのではなく、パターンを追跡し、根本原因を特定して、自信を持って問題に対応できます。

エラー分析を適切に行うことで、事後対応のデバッグから、事前予防型のアプローチへと転換できます。つまり、サポートチケットや深夜対応が減ることで、ユーザー体験がより安定し、これら全てがビジネスの成果向上に直結します。

根本原因の特定における課題

ほとんどのエンジニアリングチームは、原因が判明するずっと前から、何か問題があることを認識しています。本番環境でエラーが発生した場合、修正作業よりも原因調査に時間がかかることは珍しくありません。以下に、代表的な問題点を示します。

エラーは発生源から遠く離れた場所で発生する：
フロントエンドでは500エラーが表示される場合でも、実際の問題はバックエンドサービスや下流の依存関係に埋もれている可能性があります。エラーを報告しているサービスが必ずしも問題の原因であるとは限りません。システムを完全に可視化できなければ、エンジニアは間違った問題に追われ、根本的な問題を解決する代わりに症状の解明に時間を費やすことになります。
連携不足のツールが多すぎる：
チームが、異なるシステムに存在するメトリクス、ログ、トレース、アラート、導入履歴、インシデントレポートなどのダッシュボードを切り替えることがよくあります。各ツールから断片的な答えが見つかっても、全体をまとめて把握できる場所はありません。ツールが分散していると、有益な情報が断片化してパターンを把握しづらくなり、トリアージサイクルも長引いてしまいます。
ログとトレースにコンテキストがない：
適切なログやトレースが見つかったとしても、何がそれをトリガーしたのかが明確でない場合があります。ユーザーID、最近の導入、リクエストパス、または機能フラグなどの重要なコンテキストが、これらのログに含まれないことがよくあります。こういったコンテキストがなければ、実際には大きな問題の一部であるエラーも、個別のものとして見えてしまう恐れがあります。
手動デバッグは拡張できない：
小規模なチームやモノリシックなシステム（全機能一体型のシステム）の場合、直感に基づくデバッグが有効な場合があります。しかし、複雑な相互依存関係を持つ数十のマイクロサービスを実行している場合、直感や社内の知識は役に立ちません。誤差の許容範囲は小さくなり、影響範囲が大きくなります。
時間は刻々と過ぎていく：
エラーの調査に費やされる時間は、単なるエンジニアリングコストではなく、ビジネスコストでもあります。ダウンタイムの1分ごとに、トランザクションの損失、ユーザーの不満、SLAの逼迫が発生します。たとえ問題が解決したとしても、根本的な原因が明確でなければ、問題が再発する可能性があります。

これらの課題から明らかなのは、コンテキスト、相関関係、可視性を組み合わせたエラー分析に集中的に取り組まない限り、常に問題解決が後手に回ってしまうということです。

New Relicでのエラートラブルシューティングの簡素化

根本原因の解決には、単にデータを集めるだけでなく、検出から原因の理解までにかかる時間や手間を減らすことが重要です。エラーの原因を迅速に特定することで、チームはより早くシステムの信頼性を回復し、繰り返し発生する問題も防ぐことができます。

New Relicは、エラー、トレース、ログといった重要なシグナルを連携させ、素早い調査と確実な診断ができるワークフローを構築することで、これらの課題解決をサポートしています。このワークフローには、プラットフォーム上のさまざまなツールが活用されています。そのツールの一部をご紹介します。

Errors inbox

高速で変化する環境では、散在するエラーアラートによってチームの対応が遅れてしまうことがあります。Errors Inboxは、APM、ブラウザ、モバイル、サーバーレスワークロード全体のエラーを単一の構造化されたビューに統合することで、この問題に対処します。同様のエラーは自動的にグループ化されて不要な情報が減り、スタックトレースやユーザーへの影響度、デプロイメントマーカーなどのメタデータが表示されることで、即座にコンテキストを把握できます。ワークロード、バージョン、環境ごとの組み込みフィルターにより、チームはデグレードを迅速に特定できます。また、対応状況管理機能、SlackやJiraとの連携などのコラボレーション機能により、チーム間での情報共有と迅速な問題解決が可能です。以下の画像は、「Ad Service」の一般的なErrors inboxのUIです。エラーの傾向と特定の例外を示しています。

エラー追跡によるシステム停止への対応の詳細については、こちらの当社ウェブページをご覧ください。

Distributed Tracing

複雑な分散システムでは、エラーが表示された場所と発生した場所が離れていることがよくあります。Distributed tracingは、マイクロサービス、バックエンド、外部APIまでリクエストの流れを完全にキャプチャするため、チームは障害やレイテンシ急増の発生箇所を正確に特定できます。エラーが発生しているトレース情報に絞り込むと、障害が発生した特定のサービスや処理を特定し、HTTPステータスコードなどのメタデータも確認できます。これにより、他の場所で症状が出現した場合でも、根本原因に直接対処できます。以下の画像は、New Relicの「Ad Service」アプリケーションにおけるDistributed tracingのUIです。

特定のトレースグループをさらに掘り下げて、トレースの詳細や関連するログを確認することができます。次の画像は、New Relicのサンプルトレースに関連するログを示しています。

New RelicのDistributed tracing UIの説明や使い方については、こちらの当社ウェブページをご覧ください。

Logs in Context

ログだけでは、全体像の一部しかわかりません。Logs in contextを使用すると、New RelicはAPM summary、Errors Inbox、Distributed traces、Infrastructure monitoringなどの関連するUI上で、関連するログに絞り込んで表示します。有効にすると、APM、インフラストラクチャ、またはOpenTelemetryエージェントは、ログに主要なメタデータ（trace.id、span.id、hostname、entity.guidなど）を自動的に追加します。これにより、IDを手動でクエリしたり相互参照したりすることなく、特定のトレースまたはエラー中に発生したログを正確に表示できるようになります。

実際には、失敗したトランザクションを調査しているときに、そのトランザクションに関連したログが、詳細なコンテキストとともに即座に表示されることがあります。これにより、トリアージにかかる時間が短縮され、根本原因の特定も迅速に行えるようになります。Logs in contextを使うことで、アプリやホストの問題の根本原因をどのように特定できるか、この短い動画でぜひご確認ください（約4分）。

積極的なエラー管理戦略

適切なツールを用意することは、必要な要素の一部にすぎません。インシデントを予防し、インシデントが発生したときに効果的に対応するには、チームの信頼性へのアプローチを変える必要があります。重要なのは、オブザーバビリティを危機の際に頼りにするだけでなく、日常的な活動に取り入れることです。

チームが信頼性の目標を追跡する方法からインシデントを確認する方法まで、予防的なエラー管理は習慣から始まります。以下に、その基盤を構築する上で役立ついくつかの戦略を示します。

SLIとエラーバジェットで信頼性を定義する
エラー率、レイテンシ、アップタイムなどの信頼性に関する明確なサービスレベルインジケーター（SLI）を設定します。これらのSLIは、対応優先順位を判断する前に、許容される障害の程度を示すエラーバジェットを考慮する必要があります。これにより、チームは意識的にトレードオフを行い、パフォーマンスと安定性に関するビジネスの期待に沿って作業を調整できるようになります。
エラーを理解しやすくする
コンテキストのないエラーが表示されると、推測するしかありません。ユーザーID、リクエストパス、環境、機能フラグの状態などのカスタム属性を追加することで、素のシグナルを有用な情報に変えることができます。これらの属性はトレースとログ全体に自動的に表示されるため、根本原因の分析がより迅速かつ正確になります。
インテリジェントアラートの導入
アラートに静的な閾値を設定すると、ノイズになってしまったり、実際の問題を見逃したりしてしまうことがよくあります。その代わりに、異常検知やベースラインアラートを活用して、エラー率やレスポンスタイムに予期しない変化があった場合に通知を出しましょう。アラートは、単なる不規則な急増に反応するのではなく、ユーザー体験やSLIの低下に紐づけるのが理想的です。
一般的な障害への対応を自動化
デプロイのロールバックやサービスのクラッシュなどの既知のエラーシナリオについては、対応を自動化します。事前定義されたエラー条件によってトリガーされる再起動スクリプト、サーキットブレーカー、またはロールバックルーチンを実装します。自動化により問題解決の時間が大幅に短縮され、チームが複雑な問題に集中できるようになることが実証されています。
オブザーバビリティの設定を定期的に繰り返す
計装とアラートを生きた成果物として扱います。振り返りやスプリントレビューでは、アラートの発動頻度が高すぎたり、遅すぎたりしていませんか？ログやトレースから重要なコンテキストが欠落していませんか？といった質問をして、システムの進化に合わせて計装、ダッシュボード、アラートルールを調整します。

まとめ

エラーは避けられません。しかし、長時間のシステム停止や繰り返される障害、復旧の遅れは避けることができます。構造化されたエラー分析に投資することで、チームはより迅速に対応し、問題をより明確に把握し、深刻化する前に解決することができます。New Relicのようなツールは、エラー、トレース、ログを1つのワークフローに統合することで重要な役割を果たします。しかし、さらに重要なのは、そのデータをどのように活用するかです。傾向を追跡し、コンテキストを取り込み、洞察を共有し、効果的な方法を継続的に実践することによって、チームのレジリエンスが養われます。

予防的なエラー管理は単なる技術的な戦略ではありません。これが、現代のチームがユーザー体験を守り、安心してリリースを行い、実際の運用環境でも信頼性を保つシステムを作るための手法です。