カスケード障害とは何ですか？

複雑なコンピュータシステムでは、小さなエラーのリスクが常に存在します。場合によっては、これらのエラーは静かに存在し、すぐにすべてが正常に戻ります。他の時には、エラーが関連する別の問題を引き起こし、それが元のエラーやシステムの別の部分の追加のエラーにフィードバックされます。正のフィードバックメカニズムにより増加する失敗のドミノ効果が、カスケード障害と呼ばれるものです。

フィードバックメカニズム

スタンドアロンのエラーは、フィードバックループに寄与するエラーよりもシステムに対する脅威がはるかに少ないです。このようなフィードバックループでは、分散ソフトウェアシステムは、まず比較的小さなキャパシティの削減、エラーの急増、またはレイテンシの増加を経験するかもしれません。他の部分が元の問題に応じて修正しようとすると、逆にそれを悪化させる結果になります。

例えば、協力して作業するサーバー群の中の1つのサーバーが過剰な負荷を受けて故障することがあります。通常は、近隣のサーバーに小さな過剰負荷をオフロードし、バックアップとして機能しながら自分の負荷を維持します。しかし、この2台目のサーバーは、最初のサーバーが完全に故障した後、2つの全体の負荷を処理できず、同様に故障します。

過剰な負荷は、近隣のサーバー群を渡り続け、ますます大きな過剰負荷を生み出し、最終的にシステム全体が崩壊します。この種のカスケード障害は、以下で述べる過負荷と近接ベースのフェイルオーバーのフィードバックトリガーの混合です。

カスケード障害のフィードバックトリガー

いくつかのトリガーが、典型的なカスケード障害の原因となります。これらは、個々にまたは相互に関係している場合があります。

もしあなたのシステムがカスケード障害を経験したことがないなら、偽の安心感に陥らないでください。いつでも、システムが限界を超えて動作しようとし、予期しない問題が発生する可能性があります。

これらのトリガーのいくつかは、システムの適切な構造と管理を通じて回避可能です。その他は本質的に回避不可能ですが、重大な問題を引き起こす前にそれらがどのように機能するかを学ぶことで、準備し、軽減することができます。

例えば、負荷の急増はシステム運用の一部として予想されるものであり、カスケード障害の最も一般的なフィードバックトリガーです。これを合理的に止めることはできませんが、システムがそれにどう反応するかを管理できます。タスクスケジューリングシステムとロードバランサーは、通常うまく機能する特定の方法で典型的な負荷を管理しますが、異常な負荷にも備えておく必要があります。負荷が平均を超えると、カスケード障害を防ぐために新しい戦術を実施する必要があるかもしれません。

カスケード障害からの回復

トリガーの種類に関係なく、カスケード障害からの回復はほぼ常に非常に困難です。しばしば、システムは完全なシャットダウンを必要とします。なぜなら、それは手動介入なしでは再安定化できなくなるからです。

なぜそれがそんなに難しいのか？

もしあなたのシステムにカスケード障害のための適切な条件が含まれている場合、あなたはおそらくそれに気づいておらず、イベントは警告なしにほぼ瞬時に発生します。そして、一度それが始まると、遅らせたり止めたりするチャンスはほとんどありません。システムの状態は通常、自己修復なしにどんどん悪化します。

多くのチームは、システムを回復するために容量を追加しようとする本能を持っています。しかし、これもまた、障害の正のフィードバックに寄与する可能性が高いです。新しい健全なインスタンスを追加すると、すぐに他の故障インスタンスからの過剰負荷に直面します。そのような大きな負荷は新しいインスタンスを飽和させ、助ける機会を奪い、十分なサービス容量に達する可能性を排除します。

事前にシステムを設定して、すべてのリクエストを健全なインスタンスだけに送信しないようにすることで、この種の問題を防ぐことができ、カスケード障害を遅らせたり止めたりできるかもしれません。しかし、そのような予見がない場合、カスケード障害から回復する唯一の方法は、全サービスを停止し、負荷を再導入することです。

障害に対処するための戦術

もしあなたのシステムがすでにカスケード障害を経験している場合、完全なシステムシャットダウンに頼る前に、即座に対処するためにいくつかの手順を踏むことができます。まず、過負荷の容量がアイドルリソースによるものでないことを確認します。アイドルリソースをアクティブタスクに追加することで、負荷がそれほど大きくない場合にはシステムを迅速に回復できます。

すべてのリソースが積極的に参加している場合、ヘルスチェックの動作を変更することでスパイラルを止めることができます。システムがタスクの健康をチェックすると、多くのタスクが不健康で他のタスクが再起動していることがわかります。したがって、通常は残りの健康なインスタンスに不均衡な負荷を送信します。

このような自己健康チェックの一時的な無効化または動作の変更は、システムの再安定化に役立つかもしれません。1つのオプションは、システムが完全に応答しないタスクと一時的に応答しないタスクを区別できるようにし、後者を負荷分配に含めることです。

カスケード障害に対するより過激な対応は、トラフィックを削減し、劣化モードに入ることです。この戦術は、機能するためにはいくつかの攻撃性が必要であり、トラフィックを通常のレートの1%程度に大幅に削減する必要があります。サーバーが回復するにつれて、より多くのトラフィックが徐々に通過できるようになります。負荷が通常のレベルに戻ると、キャッシュが温まり、接続が確立されますが、ユーザーには非常に悪い体験を伴います。

この方法でトラフィックを削減することは、基本的な問題を修復するのと同時に実施する必要があります。そうでないと、回復が完了し、トラフィックが通常に戻るとすぐに二次的なカスケード障害が発生する可能性があります。コンピュータがメモリ不足になったり、システムに十分な容量がなかった場合は、トラフィックを再導入する前に、必ずメモリやタスクを追加してください。

さらに、さまざまな種類のトラフィックを区別できるシステムは、優先度の低いトラフィックや悪いトラフィックを具体的に排除できます。これはシステムの機能の一部である必要がありますが、トラフィックの優先順位を付けることで、悪影響を軽減することができます。

同様に、重要度の低い負荷バッチを区別することで、最小限の悪影響を伴うタスクの負荷を軽減できます。統計収集、データコピー、インデックス更新などのソースを一時停止することは、回復に寄与することができます。

これらすべての戦略がカスケード障害を止めるのに失敗した場合、完全なシステムシャットダウンが唯一の残されたオプションである可能性が高いです。

カスケード障害を未然に防ぐ

過負荷サーバーを防ぐ

過負荷が最も一般的なトリガーであるため、過負荷防止に焦点を当てることは、カスケード障害を回避する上で大きな役割を果たします。過負荷を避けるために、システムへのリクエストの数を制限することを考慮してください。無制限のリクエストを受け入れることは、カスケード障害中にリクエストの巨大なキューや同時スレッドを作成する可能性があります。

この蓄積はシステムを応答不能にし、しばしば介入や再起動を必要とします。これを避けるために、クライアントの再試行動作を適度に調整して再試行リクエストの洪水を避け、各インスタンスの負荷に制限を設定し、ロードバランサーで負荷シェディングを検討してください。後者はサービスにいくつかの制限を設けますが、カスケード障害の代替策にもなります。

テストの実施

他の潜在的なフィードバックトリガーに関しては、システムが不十分なセットアップや応答を持っていることに気づかないこともあります。問題のある状況に対してどのように対処するかを知る最良の方法は、それに対してテストすることです。

ファズテストは、悪い入力に対してクラッシュするプログラム、いわゆる「クエリの死」を検出するのに役立ちます。クラッシュするのではなく、プログラムは内部状態が安全性に関する懸念を引き起こす場合に、クラッシュを引き起こさない方法で反応できる必要があります。この種のテストは、組織の外部から頻繁に入力を受けるサービスに特に有用です。

負荷に加えて、クライアントの動作や非クリティカルなバックエンドもテストします。クライアントはシステムがダウンしている間に作業をキューに入れることができ、エラーに対して指数的にバックオフする必要があります。一方で、障害時のバックエンドの利用不可は、システムのより重要な部分に干渉してはなりません。

テストを行う際には、徐々に増加する負荷と急激な変化の両方を検討してください。システムは徐々に増加する負荷にうまく反応するかもしれませんが、突然の急増でクラッシュすることがあります。そして、一度システムに障害が発生すると、回復できるかどうかを確認するためにテストを続けてください。

システムに特有の問題を特定した後、適切な変更を実施できます。システムのセットアップを変更し、応答を改善することで、カスケード障害を軽減し、完全に防ぐことができます。

これらの投稿は私自身の意見であり、BMCの立場、戦略、または意見を必ずしも代表するものではありません。