#chaos 失敗するにしても、きちんとした失敗をしなければなりません。劣化モードで足を引きずり、問題を隠そうと最善を尽くすことは、クラウド規模のシステムで大きな可用性の低下やパフォーマンスの異常を引き起こす重要な原因の1つであることがわかります。今日のHotOS'17の論文は、Microsoft Azureが経験した、このようなグレーな障害について述べた短いものです。 > クラウドの実務者は、グレー・フェイルと呼ばれる障害に悩まされることがよくあります。グレーな障害の例としては、深刻なパフォーマンスの低下、ランダムなパケットロス、不安定なI/O、メモリスラッシング、容量の圧迫、非致命的な例外などがあります。 ### A definition of gray failure まず、敵を理解する必要があります。グレー・フェイルの逸話は何年も前から知られていましたが、この言葉にはまだ正確な定義がありません。 ![[Pasted image 20210607170355.png]] あるシステムを故障検出器（上図ではオブザーバー）が監視しているとします。オブザーバーが障害を検出すると、リアクターがアクションを起こします（例えば、コンポーネントを再起動するなど）。一方、そのシステムを利用するあらゆる種類のクライアント（上図ではアプリ）がいます。これらのアプリは、システムとインタラクトすることで、システムの健全性について独自の観察を行います（レスポンスが遅いか、エラーが報告されているかなど）。クラウドシステムは、多くの異なる種類のアプリによって同時に使用される可能性があり、それぞれがシステムの健全性について独自の視点を持っています。 私たちは、グレーな障害をモデル化して定義することが、この問題に対処するための前提条件であると考えています。 > 我々は、グレー・フェイルをdifferential observabilityの一形態として定義します。より正確には、少なくとも1つのアプリがシステムの不調を観察し、観察者がシステムの健全性を観察した場合に、システムは灰色の障害を経験すると定義されます。 ![[Pasted image 20210607171947.png]] > 最初はシステムに小さな不具合（潜在的な故障）が発生し、それを抑制する傾向があります。次第にシステムは、外部からは見えるが観察者には見えない劣化モード（グレー故障）に移行していきます。最終的には、システムが停止するほどの劣化（完全な故障）になり、その時点で観察者も問題に気づくことになります。典型的な例は、メモリリークです。 断続的な動作不良を伴うグレーゾーンの故障では、このサイクルを何度も繰り返すことになります。 ![[Pasted image 20210607172055.png]] ### Gray failure examples ここでは、Azureの世界におけるグレーな障害の例を見て、この問題をもう少し具体的に考えてみましょう。 冗長性を高めると可用性が下がる？ データセンターのネットワークでは、故障したスイッチを迂回してルーティングすることができますが、一般的には、スイッチがランダムでサイレントなパケットドロップなどの断続的な故障を起こした場合、パケットを再ルーティングすることはできません。グレーの障害は、アプリケーションの不具合やレイテンシーの増加につながります。 > その結果、冗長性を高めるとかえって可用性が低下するケースも見受けられます。 テールレイテンシーと同様に、この現象が発生する確率は、あるリクエストを処理する際のファンアウトファクター（関係するサービスの数）によって指数関数的に増加します。n個のコアスイッチ（あるいは、リクエストを処理するために使用されるn個のリソース）がある場合、あるスイッチがリクエストによって通過する確率は、1 - ˶left ( ˶frac{n-1}{n} ˶right ) ^{m}で与えられ、mはファンアウトファクターです。 > この確率は、mが大きくなると急速に100%に近づきます。つまり、このようなリクエストは、高い確率ですべてのコアスイッチを巻き込むことになります。つまり、このようなリクエストには、すべてのコアスイッチが関わっている可能性が高いということです。 --- ## Abstract > Cloud scale provides the vast resources necessary to replace failed components, but this is useful only if those failures can be detected. For this reason, the major availability breakdowns and performance anomalies we see in cloud environments tend to be caused by subtle underlying faults, i.e., gray failure rather than fail-stop failure. In this paper, we discuss our experiences with gray failure in production cloud-scale systems to show its broad scope and consequences. We also argue that a key feature of gray failure is differential observability: that the system’s failure detectors may not notice problems even when applications are afflicted by them. This realization leads us to believe that, to best deal with them, we should focus on bridging the gap between different components’ perceptions of what constitutes failure. （以下、DeepL翻訳） クラウド・スケールは、故障したコンポーネントを交換するために必要な膨大なリソースを提供しますが、これは故障を検知できる場合にのみ有効です。このため、クラウド環境で見られる主要な可用性の障害やパフォーマンスの異常は、フェイルストップ障害というよりはむしろグレー・フェイルが原因であることが多い。本論文では、本番環境のクラウド・スケール・システムにおけるグレー故障の経験について議論し、その広範な範囲と結果を示します。また、グレー故障の主な特徴は、システムの故障検出器が、アプリケーションが故障に悩まされていても問題に気づかない可能性があるという、差分観測可能性であることを論じている。この認識は、グレー故障に最善の対処をするためには、何が故障を構成するかについての異なるコンポーネントの認識の間のギャップを埋めることに焦点を当てるべきであると考えています。 ## 1 INTRODUCTION クラウドには豊富な冗長コンポーネントがあり、障害を許容してシステムを継続的に稼働させる機会を多く提供している。しかし、この能力を最大限に活用するためには、システムがコンポーネントの障害を迅速かつ確実に検出できなければなりません。このため、クラウドの実務者は、グレー・フェイルの問題に頻繁に直面しています。グレー・フェイルとは、症状が非常に微妙であるため、迅速かつ確実な検出ができないコンポーネントのフェイルのことです。グレー・フェイルの例としては、深刻なパフォーマンス低下、ランダム・パケット・ロス、フレークI/O、メモリ・スラッシング、キャパシティ・プレッシャー、致命的ではない例外などが挙げられます。 クラウド・システムの規模と複雑さが増すにつれ、グレー・フェイルはより一般的になります。レアイベントの発生頻度は増加し、その影響は、マルチテナンシー環境で多様なワークロードを実行するクラウドコンポーネント間の複雑な相互作用、干渉、依存関係によって増幅されます。プロダクション・クラウド・システムでの経験から、ほとんどのクラウド・インシデントの背後にはグレー・フェイルがあることが明らかになっています。 開発者は一般的に、耐障害性が高く可用性の高いシステムを構築するために、再起動、障害検出、障害回復を導入するという一般的な慣行に従っています。しかし、このようなメカニズムはグレーな障害に対処するには不十分であり、場合によっては状況を悪化させることさえある。これらのメカニズムは、コンポーネントが正しいか停止しているかのどちらかであり（フェイルストップ）、再起動のような単純な機構によって回復できるという、過度に単純な故障モデルを想定しているために、しばしば失敗してしまいます。このように、グレー故障を理解し定義することは、利用可能性の高いクラウドシステムを構築するための鍵となる。 この論文では、文献ではほとんど見落とされているグレーフェイルの問題について詳細に議論する。また、グレー故障の特徴とクラウドシステムにもたらすリスクを理解するために、実世界の事例を紹介する。これらのデータポイントから、グレー故障を特徴づける初の試みを行う。 グレー故障のインスタンスが持つ主な特徴は、異なるエンティティによって異なる認識をされることであることを発見しました。具体的には、あるエンティティは障害の悪影響を受け、別のエンティティは障害を認識しません。例えば、システムのリクエスト処理モジュールがスタックしていて、ハートビートモジュールがスタックしていない場合、ハートビートに依存しているエラー処理モジュールはシステムが健全であると認識し、サービスを求めるクライアントは失敗したと認識することになる。別の例として、リンクが通常よりも大幅に低い帯域幅で動作している場合、接続性テストでは問題がないことがわかりますが、リンクを使用するアプリケーションではパフォーマンスが低下する可能性があります。 グレー障害に対処する 1 つの方法は、グレー障害に強いプロトコルを使用してグレー障害をマスクすることです。例として、ビザンチンフォールトトレラント(BFT)ステートマシン[6]がありますが、これは参加マシンの1/3以下の任意の故障を許容し、特殊なケースとしてグレー故障を許容します。しかし、Clementら[8]は、グレー故障が発生する一般的な方法である低速動作を伴う故障をBFTシステムに許容させることの難しさを示している。また、BFTは高いオーバーヘッドと複雑さのため、実運用システムではまだ使用されていないという逸話もあります。結局のところ、ほとんどの場合、グレー故障は任意ではなく、より効率的に対処することができます。 グレー故障を検出するのではなく、グレー故障をマスキングすることのより根本的な問題は、故障したコンポーネントが交換されず、その数が最終的に許容できる数を超えてしまう可能性があるということです。そこで我々は、グレー故障の基本的な特徴である微分観測性に対処することで、グレー故障の問題に正面から取り組むことを提唱します。そのための解決策として、以下のようなものがあります。 ## 5. RELATED WORK グレー故障の現象は新しいものではないので、当然のことながら、グレー故障の症状について言及した文献やシステムインシデントの報告 [3, 19] があります。例えば、Gray [11]は、ハイゼンバグ（調べようとすると消えてしまうように見えるバグ）について議論し、再実行などの対処法を提案しています。Gunawiら[13]は、パブリッククラウドサービスの障害報告を分析し、我々がグレー障害と分類するケースを示しています。Huang et al. [15]による大手クラウドサービスの障害に関する内部研究では、フェイルスロー障害について議論している。しかし、これらの研究はいずれもグレー故障に焦点を当てておらず、問題領域を定義しようともしていません。 コンポーネントの故障を許容するために、冗長性とレプリケーションを活用するための技術が無数に提案されているが、例えば、プリマライ/バックアップレプリケーション[2]、RAID[21]、Paxos[16]、チェーンレプリカテーション[23]などである。これらの技術の多くは、フェイルストップという単純な故障モデルを前提としています。フェイルストップとは異なり、グレー故障が発生しているコンポーネントは、一見まだ動作しているように見えますが、実際には深刻な問題が発生しています。このような不一致は、従来の技術に悪影響を与え、フォールトトレランスの異常を引き起こす可能性があります(§2)。§1で議論したようなビザンチン故障をマスクするように設計された技術であっても、グレー故障に対しては不十分であったり、非効率であったりすることがある。 いくつかの研究では、非同期の分散環境における故障検出器を改善する方法が提案されている。Falcon [18]は、システムの各層にまたがるスパイのネットワークを利用して、故障検出の信頼性を高めている。Pigeon [17]は不確実な障害情報をアプリケーションに公開して、アプリケーションが情報に基づいたリカバリアクションを取ることを可能にしている。しかし、これらの信頼性の高い故障検出器はすべてフェイルストップ故障のために設計されています。グレー故障の問題を軽減するためには、システムが従来の故障検出を超えて健康状態の監視にまで踏み込む必要があると主張しています。私たちが説明する差分観測可能性の特徴を利用して、グレー故障を確実に検出することができます。 システムの性能指標を収集し、統計的手法を適用して性能問題を診断または検出するために多くの研究が行われてきました [5, 7, 9, 10]。例えば、Cohenら[9]は、低レベルのパフォーマンスメトリクスと高レベルのサービスレベル目標(SLO)を相関させるために、ツリー拡張ナイーブベイズネットワークを提案しています。これらの研究は、特定のタイプのグレー故障に対処するのに役立つが、システム自体を見て、反応的に分析を行う傾向がある。また、グレー故障の中には、パフォーマンスに関係のないものも多く存在します。異なる主体からの多様な観測を活用して健全性の見方を完成させ、障害処理を積極的に強化することを提唱している。 ## 6. CONCLUSION クラウドシステムの大規模化が進むにつれ、見落とされていたグレー故障の問題は、高可用性を実現する上で大きな問題となっている。したがって、この問題領域を理解することが最も重要である。大手クラウドサービスでの経験をもとに、グレー故障問題を取り上げ、その定義を初めて試みた。この問題に対処するためには、グレー故障の重要な特徴である差分観測可能性を低減することが重要であることを論じている。