アラートの相関関係に基づく根本原因の追究とノイズの低減

アラートは、ソフトウェアエンジニアにとって最良の友にも最悪の友にもなり得ます。アラートが正確であれば、すぐに介入して問題のあるシステムを復旧させることができます。しかし、何十個ものアラートが一度に発せられると、どこから調査に着手すべきか、判断がかなり難しくなります。発生したアラートの理解やチーム間でのコミュニケーションなど、どこかしらの時点で頭を悩ませる負担となってしまいます。New Relicでは、関係性のあるアラートを相互に関連付けることですばやく根本原因を特定し、平均解決時間（MTTR）を短縮します。また、New Relicは製品としてアラートを関連づける機能を提供しています。

アラートの相関関係とは？

アラートの相関関係とは、関連するアラート同士をグループ化する戦略的アプローチです。New Relic Decisions（相関ルールとも呼ばれます）では、アラートを意味のあるグループに分類し、それぞれのグループにアラート間の関係性を確立します。

相関関係を利用する主なメリットは以下のとおりです。

• ノイズの軽減： 例えば、1 回の稼働停止によって発生するアラートの通知と承認の回数を減らします。
• 状況把握のサポート： 関連する情報をひとつの画面に集約します。雑多なアラートの中でも、本当に必要なシグナルを見逃しません。
• 部門間のコミュニケーションを改善： インシデントステータスのタイムラインと影響を受けたコンポーネントを示すビジュアルにより、言葉よりも効果的に説明ができます。
• 迅速な根本原因の特定： 相関関係に基づくインシデントの対応により、根本原因を特定する時間を短縮します。

New Relicでは、類似の、または関連するインシデント (Incident)を問題 (Issue)と関連付けます。New Relicのアラートライフサイクルについて詳しくは、こちらをご覧ください。

バーストアラートのパターンと相関関係の役立て方

一般的なアラート設定と、そのユースケースを以下に示します。New Relicの相関関係機能は、いくつかのルールをグローバルルールとして自動的に設定するため、デフォルトでも以下のシチュエーションにおける可視性の向上とMTTRの削減に役立ちます。

• 同じエンティティに関するアラート。エンジニアリングのベストプラクティスに従い、1つのエンティティで発生している異なる種類のアラートを関連づけることでさまざまなシナリオ違反を検出できます。

  例えば、トラフィックが急増すると、スループットの異常やリソース使用量の急増、データベースの過剰な負荷によって、リクエストのタイムアウトやさまざまなエラーを引き起こします。レスポンスタイムは遅くなり、Pub/Subのラグ、外形監視、Apdexスコア、レート制限違反などから追加のアラートが発火される可能性があります。たった1つのサービスに対して、短期間で大量のアラートを受信する場合があるのです。

  すべてのアラートは問題を特徴づけ、その影響を理解するのに役立ちますが、根本原因に近いものは一握りです。致命的なアラートを見逃したまま、リソース使用量のアラートに対処してしまうと、オンコールのエンジニアはリソースを誤って増やしてしまい、問題を解決できなくなる場合があります。このようなアラートをグループ化し、タイムラインに沿ってまとめて検証することは非常に重要で、別個の問題とみなす必要はありません。

  この場合は、デフォルトで有効になっているグローバルルール：同じ New Relic ターゲット名 (Same New Relic Target Name)によってほとんどがカバーされます。このルールは、同じエンティティ名のインシデントを関連付けます。

• 同じ種類のエンティティ間のアラート。データセンター規模のインシデントを関連付けるのに役立ちます。例えば、アトランタとロンドンで同時に外形監視モニターに障害が発生したとします。デフォルトのグローバルルール：同じ安全な資格情報、パブリックの場所、およびタイプ (Same Secure Credential, Public Location and Type)によって正確に状況が把握できます。

以下の画像は、複数の拠点で発生したSynthetic Monitorのインシデントが相関づけられていることを示しています。

類似の問題構造 (Similar Issue Structure)、同様の警告メッセージ (Similar Alert Message)など、その他のグローバルルールでもこのパターンに当てはまり、類似性に基づいているため、相関関係の深さに柔軟性があります。

• 同じソースから直接的または間接的に影響を受けるさまざまなエンティティへのアラート。これらのアラートは多くの場合、似たような症状と共通の属性を持っています。例えば、障害が発生した共通のサービスにリクエストを送るアプリケーションが、似たようなエラー率の増加パターンを示したとします。同様の警告メッセージ (Similar Alert Message)、同じ New Relic の状態とタイトル (Same New Relic Condition and Title)、同じ New Relic 条件とディープ リンク URL (Same New Relic Condition and Deep Link Url)といったグローバルルールが、こうした相関関係を検出するのに非常に効果的です。

• 関係性を持つエンティティ間のアラート。典型的なシナリオには、ホストとそのホスト上で動くアプリケーションがあります。インフラストラクチャのホストがダウンタイムに直面すると、ホストされているすべてのアプリケーションがアラートを生成する可能性があります。問題の追跡をアプリケーション自体に行うと、解決や復旧に時間がかかるだけです。当社では、カスタムルールを構築するか、トポロジ依存 (Topologically Dependent)を利用することを強くお勧めしています（この詳細については後述します）。以下は部門をまたがって発生しているインシデントとそのトポロジーマップの画像です。

もちろん、障害にはこうしたパターンが混在しているものもあります。すべての関連するインシデントを統合されたタイムラインで相関させて分析することで、散在するアラートを個別に追跡するよりも、はるかに速く根本原因を特定できます。

実際のシナリオ

依存関係の多いシステムほど、解決が難しいインシデントが発生する傾向にあるため、相関関係は本当に役に立ちます。当社のプラットフォームにおいてもNew Relicの相関機能の多くを使用しています。以下の図は、当社の相関関係の一部を表しています。2つのサービス（ingest-serviceとevaluator）が、別のサービスであるDepotにリクエストを送っています。各サービスはそれぞれストアを所有しています。

したがって、ボトルネックは依存関係のあるどのサービス（Depot、アップストリームの依存関係、もしくはサイドの依存関係）からも発生する可能性があります。特定のサービスから発するアラートがあったとしても、そのサービス自体が根本的な問題を引き起こしたとは限りません。私たちのチームは既知の障害パターンについてよく知っていますが、それだけではいくつかのアラートが目に入るだけで、具体的な問題を特定するには不十分です。まずはこれらの障害パターンと、タイムラインおよび発生したさまざまなアラートを合致させる必要があります。

当社の各サービスには複数の有効なアラート条件（使用量、レスポンスタイム、エラー率など）があるため、同じエンティティの相関パターン（上記セクションの最初のパターン）も利用してインシデント同士を関連付け、単一ビューに表示します。

アラートの取り込み手順は、意思決定ツリーと似ており、ランブックに必要不可欠です。以下に簡単なフローを示します（色のついたボックスは、ケースを説明する特定の障害パターンを意味します）。

各ステップは、問題のビジュアルタイムライン（下図参照）と影響を受けたエンティティマップから回答を得ることができます。

以下は、複数のコンポーネントがリソースと雑多なアラートをトリガーした障害を示しています。Depotデータベースとingest-serviceのデータベースの両方がアラートを発動しましたが、どちらも「破損したログ」のアラートは表示されていません。Depotサービスとデータベースの接続違反は、その依存するingest-serviceとストアからの致命的なアラートの前に発生したため、Depot DBが主要なボトルネックであることを迅速に特定し、49のインシデントの中から解決の範囲を絞り込むことができました。さまざまなコンポーネントから、早い段階でアラートが交互に配置されたにもかかわらず、タイムラインのマッチングのおかげで、遠回りせずに根本原因の発見と復旧ができました。

発生した一連の事象を理解するため、インシデントのタイムラインを可視化します。

上記はあくまで単一のシステムの場合です。より大規模で、複数の部門にまたがるシステム障害の場合、コミュニケーションが重要になります。相関関係が示す事実は、言葉を尽くして説明するよりも分かりやすく、大きな意味を持ちます。チームを超えて相関関係のルールを定義するのは難しいですが、典型的な障害に対するサービスの境界線から始めることで、徐々に達成することができます。

適切なカバレッジと精度を実現する相関関係の設定方法

慎重に相関関係の設定を行うことで、上記のようなシステムレベルでのインシデントの相関づけを可能にし、インシデントのパターンを体系的に照合する手順を確立することができるようになります。以下に、相関関係を設定する方法についていくつかご紹介します。

切り分けとタグ付けのカスタマイズを行うフィルターを追加する

システム内の依存関係は、必ずしもすべての関連インシデントをまとめてグループ化しなければならないわけではありません。例えば、異なる通知設定をしているチーム間でシステムを管理している場合や、複数の場所で発生した障害を個別に対応しなければならない場合もあります。

不要な相関関係を避けるため、ほとんどの場合、フィルターを使用します。具体的な要件はユーザーによって大きく異なるため、多くの場合、ある一定レベルの切り分けが必要です。例えば、異なるチーム間、アラートの優先度、地域、サブシステム、クラスタなどです。

タイミングウィンドウ

関連付けを停止するタイミングを守らないと、問題 (Issue)が不必要に長く発生したままになり、複数のインシデントが意図せず組み合わさってしまう可能性があります。特に、最優先のインシデントにおいては、全くの偶然による相関関係を避ける上でこのウィンドウが役に立ちます。

アラートの境界線をルールのタイミングウィンドウに組み込むことは、多くの場合、必要不可欠です。エラーやダウンタイムは、どれくらいのスピードでシステムに広がっていますか？ 例えば、通常10分以内に広がる障害パターンの場合、タイミングウィンドウのルールを20分以内に設定することで、偶然発生したアラートがグループ化されるのを防ぐことができます。根本原因を追跡するには、最初にグループ化されたアラートで十分です。

ルールを一般化して症状を把握する

システムの異なる部分で似たような症状が見られる場合、似たようなアラート条件が設定されているはずです。一般化することで、類似のアラートを体系的にグループ化し、障害における特定の症状を明らかにできます。例えば、サービス間でエラー関連のアラートを監視するために正規表現の一致を使用することで、似たタイトルや条件、その他の重要な属性をカバーできます。以下は、「エラー」パターンを取得するための簡単なルール表記です。

最後に、仮説に基づく設定を本番環境に適用させる前に検証する方法をご紹介します。相関関係では、シミュレーションを使用して相関率の測定とインシデントの例を表示することができます。シミュレーションは、なぜ関連付けが行われたのか、または行われなかったのか、トラブルシューティングする際にも参照します。相関関係の精度は、アラートの粒度と応答の効率性のバランスを取るうえで重要です。想定外の事態や手間がかかることを避けるため、検証を適用することをお勧めします。

まとめ

アラートがバーストした際に、複雑な状況を解決する手段があると非常に助かります。相関関係は、アラート間の関係性を確立したり、実証したりするのに優れたツールで、ノイズの中から有用なシグナルを見つけ、根本原因をいち早く特定するのに役立ちます。その強力な機能をお客様の経験と融合させることで、根本原因の特定にかかる道筋を大幅に短縮し、MTTRを削減することができます。相関関係ツールをぜひご活用ください。これこそがまさにオブザーバビリティの力です。