2026年9月19日

RADAR：異常検知でグレー障害を検出する

リアルタイムの異常検知によって、サイレントな部分障害を数分でキャッチする方法と、同様のシステムをDatabricks上に構築する方法。

グレー障害は正常を示すダッシュボードをすり抜け、誰にも気づかれないうちに、顧客や収益に静かに悪影響を及ぼします。
RADARは、信頼性メトリクス、異常検知、アラート、根本原因分析という4つのステージからなる、メトリクスに依存しないパターンです。Databricksは自社システムでこれを運用し、90%以上の精度と95%高速化された検出スピードにより、これらの障害を数分で検知しています。
ネイティブコンポーネントとAIエージェントのフレームワークを使用することで、課金、コンバージョン、モデルのパフォーマンスなど、あらゆるメトリクスに対して同様のシステムをDatabricks上に構築できます。

最も深刻な被害をもたらす障害の一部は、監視システムが検知できないものです。すべてのヘルスチェックが正常を示している一方で、一部の顧客がひっそりとエラーに直面しています。これらの「グレー障害（gray failures）」は、誰かが状況を把握するまでの数時間、ユーザーと収益を流出させ続けます。本ブログ記事では、異常検知（anomaly detection）を使用してこれらを早期に発見する方法について説明します。DatabricksにおけるRADARと呼ばれるシステムでの取り組みと、ビジネスにとって最も重要なあらゆるメトリックに対して同様の仕組みを構築する方法を紹介します。本記事は、サービスの信頼性に責任を持つ人々（SRE、プラットフォームエンジニア、データエンジニア、オンコール担当者、および彼らを率いるエンジニアリングリーダー）に向けて書かれています。

すべてがグリーンなのに、何かがおかしいとき

平穏な水曜日を想像してください。顧客向けサービスの信頼性を維持することがあなたの仕事であり、壁のダッシュボードはすべてグリーン（CPUは正常、レイテンシも良好、サーバーは稼働中、データベースも接続済み）を示しています。チームが監視しているすべてのシグナルにおいて、システムは完璧に見えます。

しかし、実際はそうではありません。

9:30 — 定期デプロイにより、決済フローにわずかなバグが混入します。
9:35 — クレジットカードで支払う顧客の20人に1人が、ひっそりと決済に失敗します。数回再試行した後、彼らは諦めて離脱します。
12:40 — 最初のサポートチケットが届きます。単なるカード番号の入力ミスのように見えるため、誰も気に留めません。
14:20 — 同じ問題に関するチケットがさらに2件届きます。
14:25 — サポートリードがパターンを察知し、エスカレーションします。
16:00 — エンジニアがバグを特定し、修正プログラムをリリースします。

約7時間もの間、顧客が離脱し収益が流出しているにもかかわらず、監視システムはすべてが正常であると主張し続けていました。

グレー障害（gray failure）とは何か？

その水曜日の出来事は、教科書通りの「グレー障害」です。表面上はすべてが正常に見えますが、裏では特定のパーツがひっそりと動作を停止しており、アラートを発生させることなく顧客に悪影響を及ぼしています。

グレー障害を極めて厄介なものにしている要因は2つあります。

部分的であること。 全員ではなく、特定のクレジットカードの種類など、一部の層だけに発生します。すぐに検知できるようなサーバークラッシュはなく、大半のユーザーは問題ない一方で、特定のグループだけが常に失敗するという、曖昧で厄介な状態が生じます。
拡大すること。 最初は一握りの顧客への影響から始まり、それが広がっていきます。放置すると、さらに多くの人々が同じ問題に直面することになります。

壁の裏の煙のようなものだと考えてください。外からは家は問題ないように見えますが、中では被害が広がっており、放置する時間が長くなるほど、影響範囲（blast radius）は大きくなります。研究者たちもこの根本的な問題に名前をつけています。Microsoftの論文 Gray Failure: The Achilles’ Heel of Cloud-Scale Systems では、これを「差分観測可能性（differential observability）」と呼んでいます。これは、ユーザーが明らかに問題を経験しているにもかかわらず、障害検知器がそれを認識できない状態を指します。

なぜ顧客からの報告を待つだけでは不十分なのか

ほとんどのチームは、あの水曜日のようにグレー障害に対処しています。つまり、顧客から報告があるのを待つのです。顧客からの報告は重要であり、実際のユーザーの不満を示すものですが、顧客を監視システム代わりにすべきではありません。報告だけに頼ることには、3つの問題があります。

手動であること。 大量のチケットの中から、誰かが同じ苦情に気づく必要があります。これは見落とされがちです。
遅延が発生すること。 状況を把握できるほど十分な数の苦情が集まるまでに、数時間から数日がかかってしまいます。
サイレントであること。 影響を受けた顧客のほとんどはチケットを起票せず、ただ離脱していきます。

解決策は、チケットを読むのをやめることではありません（それは続けてください）。常に稼働し、人間が見落とすものをキャッチする自動検知を追加することです。具体的には、通常よりもはるかに多くの顧客が同時に同じ問題に直面し始めた瞬間に作動する仕組みが必要です。

顧客からの報告のみ	自動検知の追加
手動 — 見落としやすい	人間が見落とすものをキャッチ
遅延 — 気づくまでに数日	迅速 — リアルタイムで検知
顧客が黙って離脱する	スパイクをフラグ付け — 多くのユーザーが同時に直面

RADARのご紹介

それが、RADAR（Reliability Anomaly Detection, Alerting, and Root-cause analysis：信頼性異常検知・アラート・根本原因分析）の背景にあるアイデアです。Databricksでは、グレー障害を数時間ではなく数分でキャッチするためにこれを構築しました。この名前はぴったりです。視界が悪いとき、何かが衝突するのを待つのではなく、早い段階で微弱なシグナルをスキャンするのです。

ここでは、特に有用なシグナルの1つである「ユーザーエラー」にこれを適用する方法を紹介します。

グレー障害は、一見ユーザーの過失のように見えるエラーの突然のスパイクとして現れることがよくあります。ある地域の多数のユーザーが、特定のタイプのクラスターを突然起動できなくなった状況を想像してください。各リクエストは INVALID_ARGUMENT で失敗します。これは、遠回しに「そちら側の問題です」と伝えているエラーです。

しかし、多くのユーザーが同時に同じ「ユーザー側の問題」とされるエラーに直面した場合、それはもはやユーザーのせいではありません。それは私たちの問題です。そのスパイクこそが、まさにRADARが検知するために構築されたパターンです。

RADARの4つのステージ

メトリックに依存しない異常検知：請求、コンバージョン、またはモデルのパフォーマンスに適用されたRADAR。

RADARは、その直感を4つのステージからなるパイプラインに変換します。

信頼性メトリック。 常に、発生しているエラーの数と、各エラーに直面した個別のユーザー数の2つを記録します。エラーコードとリージョンごとに分類します。これにより、サービスの健全性を示す豊富な時系列データが得られます。
異常検知。 これらの各時系列に対して異常検知を実行し、大量のしきい値を手動で調整することなく、システムが異常と思われるものをフラグ付けできるようにします。私たちは、過去14日間から「正常」な状態を学習する、SPOTと呼ばれる教師なしストリーミングモデルを使用しています。これは、手動のカットオフ値の代わりに、単一のリスクパラメータのみを必要とします。（SPOTは、Sifferらによる論文 Anomaly Detection in Streams with Extreme Value Theory、KDD 2017に基づいています。）
アラート。 異常が検知されると、アラートレイヤーが処理を引き継ぎます。アラートにコンテキストを付加（enrich）し、重要でないものをフィルタリングし、同じアラートの重複を排除（dedupe）することで、オンコール担当者が同じもののコピーに埋もれないようにします。その後、そのエラーに対応する適切なエンジニアリングチームにルーティングされたチケットを起票します。
根本原因分析。 すべてのチケットには、異常の詳細な分析結果と、AIアシスタントである AI/BI Genie を搭載したダッシュボードへのリンクが添付されています。オンコール担当者は、最小限の時間で、実際に何が破損したのかを特定する作業に直接取りかかることができます。

私たちが達成したこと

自社でRADARを運用したことで、これらのインシデントのあり方が変わりました。以前は、このようなインシデントを発見するために顧客からのチケットを待っていたため、数日間の遅延が発生していました。RADARの導入により、パターンを特定するための人員を必要とせず、90%以上の精度で、インシデント発見時間を95%削減することに成功しました。その結果、グレー障害の影響範囲を最小限に抑えることができています。

あらゆるメトリックにRADARを適用する

ここで最も重要なのは、RADARはメトリックの種類を問わないということです。私たちはたまたまユーザーエラーに適用していますが、数値がひっそりと異常値を示す可能性のあるあらゆる場所で、同じパターンが機能します。

金融サービス — 決済および取引の失敗、請求の異常、不正利用のシグナル
小売・Eコマース — 決済コンバージョン、カートエラー、配送時間
ヘルスケア・ライフサイエンス — 患者の受け入れ能力（スループット）、保険請求処理
あらゆるAI製品 — モデルが明らかに破綻する前に現れる、モデルのパフォーマンス低下やデータ分布のドリフト（data-distribution drift）

設定が異なるだけで、パターンは同じです。ひっそりと問題が発生する可能性のある場所ならどこでも、RADARを適用できます。

Databricks上で自ら構築する

最も素晴らしいニュースは、必要なすべての要素がすでにDatabricks上に揃っていることです。4つのステージをプラットフォームにマッピングすると、次のようになります。

信頼性メトリック — 低レイテンシの取り込みのためのZerobus、ガバナンスのためのUnity CatalogとMetric View、ストレージのためのDelta Lake
異常検知 — モデルトレーニングのためのMLflow、モデルエンドポイントを配信するためのModel Serving、定期的なジョブをオーケストレーションするためのWorkflows
アラート通知 — アラートをトリガーするためのDatabricks SQL Alerts
根本原因分析 — AI/BI GenieとAI/BI Dashboards

そして、これらすべてがDeclarative Asset Bundle（DAB）を介して単一のユニットとしてデプロイされます。

これらすべてのパーツを手動で連携させるのは面倒な作業です。そのため、そのプロセスを排除しました。社内のRADARシステム全体を、レシピのように機能する1つのMarkdownファイルという単一のスキャフォールド（足場）に凝縮しました。これにより、RADARの各パーツが特定のDatabricksコンポーネントにマッピングされます（収集と保存 → Deltaテーブル、異常検知 → ジョブ、アラートと重複排除 → チケット、可視化 → ダッシュボード）。

Declarative Asset Bundle

ここからが本番です。シグナルがどこにあろうと、独自のメトリクスを用意し、そのメトリクス、スキャフォールド、そして短いプロンプトをAIエージェントに渡すだけです。AIエージェントが、Databricks上でRADARシステム全体をリアルタイムで構築します。単一のプロンプトから構築する方法については、GitHubの手順に従ってください。

要点

持ち帰るべきポイントは次の2つです。

深刻化する前にグレー障害を検知する。 ダッシュボードが正常（グリーン）を示していても、顧客に問題が発生していないとは限りません。リアルタイムの異常検知を追加し、一部のサイレントな障害が数日ではなく数分で表面化するようにしましょう。
重視するあらゆるメトリクスに対して、Databricks上にRADARを構築する。 スキャフォールド、デモ、プロンプトはすべて公開されています。これらから始めてみてください。

GitHubでRADARのスキャフォールドを入手する

なぜなら、最善の結果とは、怒っている顧客に対して迅速に対応することではなく、顧客がインシデントに気づくこと自体をなくすことだからです。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事