The Abstention Protocol: RCA for Clos Fabrics
本論文は、ノイズの多いテレメトリ環境において安定、説明可能、かつ単調な故障帰属を実現するために、不安定なスコアベースの融合を決定論的なPAMスタイルの棄却代数へと置き換えた、大規模Closファブリック向けのプロダクション・ルートコーズ解析システムであるCoreSecを紹介するものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
現代のクラウドコンピューティングという、巨大で脈動するアーキテクチャの中で、データは単一のパイプを通るのではなく、広大で多層的な接続のウェブを通じて流れています。すべての建物がローカルな近隣スイッチに接続され、そのスイッチがさらにディストリクト・ハブに接続され、最終的に中央のスパイン（背骨）へとつながる都市を想像してみてください。この「クロス・ファブリック（Clos fabric）」として知られる構造により、数百万台のサーバーが驚異的な速度と冗長性を持って互いに通信することができます。もし一つの経路が遮断されても、トラフィックは単に別の経路を見つけ出します。この設計のおかげで、システムは極めて高い回復力を備えています。ケーブルの緩み、照明のちらつき、あるいは一時的なソフトウェアの不具合といった、日々発生する何千もの微細でランダムな不具合を、平均的なユーザーが気づくことなく吸収できるのです。しかし、この絶え間ないバックグラウンド・ノイズは、システムを維持するエンジニアにとって深刻な問題を引き起こします。特定のサービスが顧客に対して停止したとき、システムは何百もの警告を発して点灯します。課題は、壊れた部品を見つけることではなく、それら多くの壊れた部品のうち、どれが実際に特定の障害を引き起こしたのかを突き止めることなのです。
長年、このパズルを解くための標準的な方法は、あらゆる警告信号に対してスコアを割り当てることでした。ケーブルにエラーカウントが高ければ、高いスコアを与え、スイッチが再起動すれば、スコアを与えます。システムはこれらのスコアを加算し、合計が最も高かったエンティティをトラブルの原因として責めました。この手法はネットワークが静かな時には十分に機能しましたが、ハイパースケール環境においてはしばしば失敗しました。常にバックグラウンド・ノイズが存在するため、システムは何も本当に問題がない場合でも「犯人」を見つけ出してしまったり、スコアが僅差すぎて判断がつかないために誤ったデバイスを責めてしまったりすることが頻繁にありました。エンジニアたちは、ある種のエラーを捉えるためにこれらのスコアを微調整しようとすると、図らずも別のエラーを捉える能力を損なってしまうという事実に直面しました。その結果、自動化された修正策が誤報によってトリガーされ、状況を改善するどころか悪化させてしまうという、不確実性のサイクルが生じていました。
これを解決するために、マイクロソフトのチームは、意思決定の根本的なロジックを変更した「CoreSec」と呼ばれる新しいシステムを開発しました。この新システムは、スコアを加算する代わりに、調査を、セキュリティシステムが人物の身元を確認する際のような、一連の厳格で独立したチェックとして扱います。高度なセキュリティを備えたビルでは、警備員がパスワード、指紋、そしてカードキーを要求することがあります。パスワードが欠けている場合、警備員は推測することなく、単に入館を拒否し、プロセスを停止します。CoreSecはこの「棄権（abstention）」のロジックをネットワーク障害に適用します。システムは異なる種類のデータに対して特定の役割を割り当てます。一部の信号は必須です。もし重要な証拠が欠落していたり、古くなっていたりする場合、システムは判断を下すことを拒否します。また、他の信号はそれ単体で十分な根拠となります。もし特定かつ否定できないエラーが見つかった場合、システムは探索を停止し、即座に原因を特定します。
このシステムは、個々のサーバーを接続するケーブルから、ファブリック全体を保持する巨大なスパイン・スイッチに至るまで、ネットワークの異なるレイヤーを対象とした5つの異なる調査を並行して実行します。各調査は、特定の原因に対して投票するための独自のルールセットを使用します。証拠が明確であれば投票し、証拠が欠落しているか矛盾している場合は、棄権します。これは極めて重要な転換です。旧システムでは、コンピュータは答えが分からない場合でも、無理に勝者を決めなければなりませんでした。新システムでは、「無知であることを認めること」が有効かつ有用な結果となります。システムが棄権するとき、それは人間であるエンジニアに対し、「まだ確信が持てません」と伝え、どのようなデータが不足していたかの明確な要約と共にケースを引き継ぎます。これにより、システムが自信満々に間違った推測を行い、不要で潜在的に有害な自動修復をトリガーしてしまうことを防いでいます。
これら5つの並行調査が完了すると、次に第2層のロジックが介入し、それらの結果を統合します。このロジックは、ネットワークの物理的な形状を理解しています。例えば、単一のスイッチが故障した場合、それは数台のサーバーに影響を与えるかもしれませんが、より高次のハブが故障した場合、それは多くのスイッチが同時に不調であるかのように見せる波及効果を引き起こすことを知っています。システムは単純でハードウェアに組み込まれたルールを使用して、どのレイヤーが真に責任を持っているかを判断します。例えば、高レベルのスイッチが疑われる場合、システムはその下に接続されている小さなスイッチの少なくとも3分の2が問題を示しているかどうかを確認します。もしそうであれば、システムは高レベルのスイッチが根本原因であると結論付け、その下の個々のスイッチについては無視します。これにより、システムが症状に惑わされ、ネットワークの誤ったレベルを責めてしまうことを防ぎます。
Azureクラウドの60以上のリージョンにこのシステムを導入した結果は、驚くべきものでした。3年間の間に、システムは70万件以上のインシデントを処理しました。健全なデバイスを誤って責めてしまう誤報の発生率は、20%近くから1%未満に低下しました。同時に、人間の助けを借りずに問題を正しく特定できた回数は大幅に増加しました。おそらく最も重要なことは、インシデントごとに競合するデータを手動で確認し、整理するためにエンジニアが費やしていた3人分のフルタイムの業務を排除したことです。かつてはこれらの結び目を解くために何時間も費やしていたエンジニアたちは、今では、システムが何を見つけ、何が決断できなかったのか、そして次にどこを見るべきかを明確に示した、構造化されたレポートを受け取っています。
CoreSecの成功は、その「推測を拒む姿勢」にあります。データの融合をスコアリング・ゲームではなく、構成の問題として扱うことで、システムは以前は不可能だったレベルの安定性を実現しました。ネットワークの進化に伴って挙動が変わる可能性のある複雑な機械学習モデルには依存していません。代わりに、異なるハードウェア、異なるトラフィックパターン、異なるデータセンター設計においても、再調整を必要とせずに機能することが証明された、固定された論理ルールを使用しています。このシステムは、ノイズが多く不完全な情報が飛び交う世界において、最も強力なツールとは、しばしば「分からない」と言い、より良い証拠を待つ能力であることを示しました。このアプローチは、根本原因分析を確率のゲームから、信頼可能で説明可能なプロセスへと変貌させ、クラウドがより大きく、より複雑になり続ける中で、その安定性を維持することを可能にしています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。