# Gray Failure: The Achilles' Heel of Cloud-Scale Systems > [!abstract] 概要 > クラウドは障害コンポーネントを置き換えるために必要な豊富なリソースを提供するが、これが有用なのはその障害が検知できる場合に限る。このため、クラウド環境で見られる主要な可用性障害や性能異常は、微妙な潜在的障害——すなわち fail-stop 障害ではなくグレイ障害——によって引き起こされる傾向がある。本論文では、クラウド規模システムにおけるグレイ障害の実体験を論じ、その広範な範囲と影響を明らかにする。また、グレイ障害の核心的特性が差分可観測性(differential observability)——システムの障害検知器がアプリに影響を与えている問題を見逃す可能性があること——にあると主張する。この認識から、グレイ障害に最も効果的に対処するには、異なるコンポーネント間の障害認識ギャップを埋めることに注力すべきだと信じるに至った。 ## 論文情報 - **タイトル**: Gray Failure: The Achilles' Heel of Cloud-Scale Systems - **著者・所属**: - [[Peng Huang]]([[Microsoft Research]] / [[Johns Hopkins University]]) - [[Chuanxiong Guo]]([[Microsoft Research]]) - [[Lidong Zhou]]([[Microsoft Research]]) - [[Jacob R. Lorch]]([[Microsoft Research]]) - [[Yingnong Dang]]([[Microsoft Azure]]) - [[Murali Chintalapati]]([[Microsoft Azure]]) - [[Randolph Yao]]([[Microsoft Azure]]) - **媒体**: HotOS '17(16th Workshop on Hot Topics in Operating Systems) - **開催地**: Whistler, BC, Canada - **発表日**: 2017年5月8〜10日 - **DOI**: 10.1145/3102980.3103005 - **論文数**: 6 ページ ## 概要 [[Microsoft Azure]] での実インシデント体験から、クラウド規模システムでの可用性問題の大半がグレイ障害(subtle failures)によるものであることを示す。グレイ障害の例として、深刻な性能劣化・ランダムパケットロス・不安定な I/O・メモリスラッシング・容量プレッシャー・非致命的な例外を挙げる。クラウドの規模と複雑さが増すにつれてグレイ障害は頻発し、複雑な相互作用によってその影響は増幅される。 **Figure 1: Clos ネットワークにおけるグレイ障害** ![[_attachments/Huang-et-al.-2017---Gray-failure---The-achilles-heel-of-cloud-scale-systems/fig01-clos-network-gray-failure.png]] (図1. 典型的な Clos ネットワーク構成。コアスイッチ r1〜r4・アグリゲーション層・ToR 層・サーバ群 A/B/C からなる。r1(×印)がグレイ障害状態のとき、ルーティングプロトコルは再ルーティングしないため、高ファンアウトのワークロードはほぼ全リクエストで影響を受ける。Source: Figure 1.) ## 問題設定 - **対象**: クラウド規模の分散システムにおける障害検知・可用性維持 - **問題**: fail-stop を前提とした従来のフォールトトレランス機構がグレイ障害に対して機能しないだけでなく、状況を悪化させることがある - **観察**: Azure での実インシデントから、大半の可用性問題がグレイ障害によって引き起こされている - **目的**: グレイ障害を定義し、その特性を理解し、対処の方向性を示す ## グレイ障害の実例(Azure) ### 2.1 高冗長性が可用性を損なう Clos ネットワーク(図1)では冗長性によりスイッチ停止を耐えられるが、コアスイッチがグレイ障害(ランダムパケットロス)を起こすと問題が生じる。ルーティングプロトコルはスイッチが停止していないため再ルーティングしない。 ファンアウト係数 m のワークロードがコアスイッチ n 台のうち少なくとも 1 台を使う確率は $1 - \left(\frac{n-1}{n}\right)^m$ であり、m が大きくなると 100% に近づく。つまり、コアスイッチ数が多いほど少なくとも 1 台がグレイ障害を起こす確率も上がるという**逆説**が生じる。高冗長性が可用性を下げる典型例だ。 ### 2.2 障害検知器の死角 VM が内部でネットワーク接続障害(ドライババグ)を経験しているにも関わらず、リモートの障害検知器(コンピュートマネージャ)はローカル RPC 経由のハートビートしか観測しないため問題を検知しない。利用者が報告するまで復旧が始まらない。 **Figure 3: グレイ障害発生前後のインVM 性能カウンタとコンピュートマネージャ観測** ![[_attachments/Huang-et-al.-2017---Gray-failure---The-achilles-heel-of-cloud-scale-systems/fig03-performance-counters-gray-failure-event.png]] (図3. 左上: ディスク読み書きバイト数/秒、右上: ネットワーク入出力(VM 移行後に急落)、左下: CPU 使用率、右下: コンピュートマネージャの観測(緑点=健全、赤点=異常と判定)。赤点はすべてユーザー起動のリブートであり、根本原因は長時間検知されない。差分可観測性の典型例。Source: Figure 3.) ### 2.3 復旧が障害を拡大する Azure Storage で容量制約を抱えるデータサーバをストレージマネージャが検知できず(バグによるリソース報告誤り)、書き込みリクエストを継続して送り込んでデータサーバがクラッシュ→リブートを繰り返す。障害検知器は「修復不能」と判断してデータサーバを切り離すが、それが他サーバへの容量プレッシャーを増やし連鎖障害を引き起こした。 **Figure 4: ストレージサービス健全性のコンピュート視点(t1〜t2 の機会窓)** ![[_attachments/Huang-et-al.-2017---Gray-failure---The-achilles-heel-of-cloud-scale-systems/fig04-storage-health-t1-t2-window.png]] (図4. 縦軸: リモート I/O 例外が発生している VM 数/分。t1 でコンピュートが I/O 例外の増加を観測し、t2 でストレージが問題を検知して対応を開始する。t1〜t2 の窓は連鎖障害を防ぐ機会窓だが、差分可観測性により t1 での早期介入ができない。Source: Figure 4.) ### 2.4 責任の押し付け合い VM の仮想ディスクへのアクセス障害をコンピュートスタック側の障害として誤帰属する問題。ストレージ/ネットワークのグレイ障害の根本原因が不明なまま、各チームが他チームを非難し合う状況が生じた。 ## グレイ障害のモデルと定義 **Figure 2: グレイ障害を特性化する抽象モデル** ![[_attachments/Huang-et-al.-2017---Gray-failure---The-achilles-heel-of-cloud-scale-systems/fig02-abstract-model-differential-observability.png]] (図2. 2 つの論理エンティティ: システム(サービス提供者)とアプリ(サービス利用者)。システム内の Observer がシステムコアに probe を送りレポートを受け取り、Reactor が復旧アクションを実施。アプリはシステムを独自に観測し、Observer との観測差が生じたときグレイ障害となる。Source: Figure 2.) ### 3.1 用語 - **System**: サービスを提供するエンティティ(分散ストレージ、データセンターネットワーク等) - **App**: System を利用するエンティティ(Web アプリ、ユーザー、オペレータ、または別の System) - **Observer**: System 内でヘルス情報を能動・受動的に収集する主体 - **Reactor**: Observer の観測に基づき復旧アクションを実施する主体 ### 3.2 差分可観測性(Differential Observability) App は端点間メトリクス(クエリレイテンシ、リモート I/O 状態等)から独自のヘルス観測を行う。**グレイ障害の定義**: 少なくとも 1 つの App が System を不健全と観測しているが、Observer は System を健全と観測している状態。 | | $A_i^{\text{good}}$(App が健全と観測) | $A_i^{\text{bad}}$(App が障害と観測) | |---|---|---| | $S^{\text{good}}$(Observer が健全と観測) | ➊ 正常 | ➋ **グレイ障害** | | $S^{\text{bad}}$(Observer が障害と観測) | ➌ 良い方向の差分 | ➍ 通常障害(クラッシュ等) | ケース ➋ がグレイ障害: ユーザーが苦しんでいるが Reactor は呼ばれない。ケース ➌ は Observer が先回りで検知する良い方向の差分可観測性。ケース ➍ は fail-stop 障害に相当。 ### 3.3 時間的進展 グレイ障害の典型的な時間軸: ①潜在障害(Observer もアプリも問題を感じない ➊)→②グレイ障害(アプリは劣化を検知するが Observer は健全と見る ➋)→③完全障害(Observer も検知 ➍)。この推移は ➊→➋→➍ と進む。断続的な誤動作を伴うグレイ障害ではこの遷移を繰り返す。メモリリークが典型例。 ## 解決の方向性 ### 4.1 観測ギャップを埋める ハートビートのような単一障害検知から**多次元ヘルス監視**へ移行する。人体の状態評価が心拍だけでなく体温・血圧も必要なように、VM の接続性問題には在VM 性能カウンタの活用が有効(§2.2 の問題に対応)。 ### 4.2 アプリ視点の近似 マルチテナントクラウドでは全アプリの観測を完全に追うことは非現実的だが、近似は可能。例: Pingmesh のようにサーバ間レイテンシと到達可能性をプローブして共通アプリの観測を模倣する。ただし、劣化したシステムへの過度なプロービングが逆効果となりうる点に注意。 ### 4.3 規模の力を活用する グレイ障害はしばしば Observer の局所的な観測によるもので、多数のコンポーネントの観測を集約・推論することで検知が可能になる。各コンポーネントは部分的な視点しか持たないため、内因性グレイ障害は分散的にしか検知できない。VM 仮想ディスク障害イベントをクラスタ・ネットワークトポロジ情報とマッピングする手法も有効。 > [!note] Observer から遠すぎる集約は sys 側のフォールトトレランス機構によって差分可観測性が遅く現れる。**独立した平面(システムの境界外かつ Observer/Reactor に接続)** での集約・推論が望ましい。 ### 4.4 時間パターンを活用する グレイ障害発現前の潜在障害(Observer が障害と宣言するほどでない minor faults)の時間パターンを学習し、早期警告を出す。§2.3 の例では t1(コンピュートが I/O 例外増加を観測)〜t2(ストレージが問題を検知)の窓が介入機会だった。ただし良性の潜在障害が多いため、偽陽性に注意が必要。 ## 強み / 弱点・課題 **強み**: - Azure 本番環境での実インシデントに基づく議論であり、観察の説得力が高い - 差分可観測性という普遍的な定式化により、多種多様なグレイ障害を統一的に扱える - 解決の方向性として 4 つの独立したアプローチを提示 **弱点・課題**: - HotOS 論文として 6 ページのため、提案は方向性の提示にとどまり具体的な実装・評価はない - 「観測ギャップを埋める」アプローチは、より多くのプロービングが劣化システムに与える負荷という新たなグレイ障害リスクを孕む - Byzantine 障害耐性(BFT)との境界が明確でなく、遅い動作(slow operation)を BFT でどこまで扱えるかの議論が不完全 - 定義はシングルシステム・シングルオブザーバを前提とし、分散型観測プレーンの詳細は将来課題として残される