REL12-BP04 カオスエンジニアリングを使用して回復力をテストする

定常状態とは、正常な動作を示すワークロードの測定可能な出力であると定義します。

ワークロードは、信頼性が高く、期待どおりに動作していれば、定常状態を示します。したがって、定常状態を定義する前に、ワークロードが正常であることを検証します。一定の割合の障害は許容範囲内である可能性があるため、定常状態は、必ずしも障害発生時にワークロードに影響が及ばないことを意味するものではありません。定常状態は実験中に観察される基準値であり、定義した仮説が次のステップで想定どおりにならない場合に、異常を強調します。

例えば、決済システムの定常状態は、成功率 99％、往復時間 500ms で 300TPS を処理することと定義できます。

ワークロードがどのように障害に対応するかについての仮説を立てます。

良い仮説は、定常状態を維持するために、ワークロードがどのように障害を軽減すると予想されるかに基づいています。仮説は、特定の種類の障害が発生した場合、システムまたはワークロードが定常状態を維持することを示します。なぜならば、ワークロードは特定の緩和策を講じて設計されているからです。特定の種類の障害および緩和策は、仮説の中で特定する必要があります。

次のテンプレートを仮説に使用できます (ただし、他の表現も許容されます)。

例:

障害を挿入して実験を実行する。

実験はデフォルトでフェイルセーフであり、ワークロードが耐えることができる必要があります。ワークロードが失敗することがわかっている場合は、実験を実行しないでください。カオスエンジニアリングは、既知の未知、または未知なる未知を見つけるために使用される必要があります。既知の未知は、認識しているが完全には理解していないモノであり、未知なる未知は、認識も完全に理解もしていないモノです。壊れているとわかっているワークロードに対して実験を行っても、新しいインサイトを得ることはできません。実験は慎重に計画し、影響の範囲を明確にし、予期せぬ乱れが発生した場合に適用できるロールバックメカニズムを用意する必要があります。デューディリジェンスによりワークロードが実験に耐えられることがわかったら、実験を進めてください。障害を挿入するには、いくつかの方法があります。AWS のワークロードの場合、AWS FIS はアクションと呼ばれる多くの事前定義された障害シミュレーションを提供します。AWS Systems Manager ドキュメントを使用して、AWS FIS で実行するカスタムアクションを定義することもできます。

カオス実験にカスタムスクリプトを使用することは、スクリプトがワークロードの現在の状態を理解する機能を持ち、ログを出力でき、可能であればロールバックと停止条件のメカニズムを提供しない限り、お勧めできません。

カオスエンジニアリングをサポートする効果的なフレームワークやツールセットは、実験の現在の状態を追跡し、ログを出力し、実験の制御された実行をサポートするためのロールバックメカニズムを提供します。AWS FIS のように、実験範囲を明確に定義し、実験によって予期せぬ乱れが生じた場合に実験をロールバックする安全なメカニズムを備えた実験を行うことができる、確立されたサービスから始めてみてください。AWS FIS を使用したさまざまな実験については、「Resilient and Well-Architected Apps with Chaos Engineering lab」も参照してください。AWS Resilience Hub はワークロードを分析し、AWS FIS で実装および実行することを選択できる実験を作成します。

可能であれば、実験はコントロールと実験的なシステムデプロイの両方をスピンアップするカナリアデプロイを使用して、実際の負荷下の本番環境で実行する必要があります。オフピークの時間帯に実験を行うことは、本番で初めて実験を行う際に潜在的な影響を軽減するための良い方法です。また、実際の顧客トラフィックを使用するとリスクが高すぎる場合は、本稼働インフラストラクチャの制御環境と実験環境に対して合成トラフィックを使用し、実験を実行することができます。本番環境での実験が不可能な場合は、できるだけ本番環境に近い本番稼働前の環境で実験を行ってください。

実験が本稼働トラフィックや他のシステムに許容範囲を超えて影響を与えないように、ガードレールを確立してモニタリングする必要があります。停止条件を設定し、定義したガードレールのメトリクスでしきい値に達した場合は実験を停止するようにします。これには、ワークロードの定常状態のメトリクスと、障害を挿入するコンポーネントに対するメトリクスを含める必要があります。合成モニタ (ユーザー canary とも呼ばれます) は、通常、ユーザープロキシとして含める必要があるメトリクスの 1 つです。AWS FIS の停止条件は実験テンプレートの一部としてサポートされており、テンプレートごとに最大 5 つの停止条件を許可します。

カオスの原則の 1 つは、実験の範囲とその影響を最小化することです。

短期的な悪影響は許容する必要がありますが、実験の影響を最小化し、抑制することは、カオスエンジニアの責任であり義務です。

範囲や潜在的な影響を検証する方法として、本番環境で直接実験を行うのではなく、まず非本番環境で実験を行い、実験中に停止条件のしきい値が想定どおりに作動するか、例外をキャッチするためのオブザーバビリティがあるかどうかを確認することが挙げられます。

フォールトインジェクション実験を実行する場合は、すべての責任者に情報が十分に伝達されるようにします。オペレーションチーム、サービス信頼性チーム、カスタマーサポートなどの適切なチームとコミュニケーションをとり、実験がいつ実行され、何が期待されるかを伝えます。これらのチームには、何か悪影響が見られた場合に実験を行っているチームに知らせるための、コミュニケーションツールを提供します。

ワークロードとその基盤となるシステムを、元の既知の良好な状態に復元する必要があります。多くの場合、ワークロードの回復力のある設計が自己回復を行います。しかし、一部の障害設計や実験の失敗により、ワークロードが予期せぬ障害状態に陥ることがあります。実験が終了するまでにこのことを認識し、ワークロードとシステムを復旧させる必要があります。AWS FIS では、アクションのパラメータ内にロールバック設定 (ポストアクションとも呼ばれます) を設定することができます。ポストアクションは、ターゲットをアクションが実行される前の状態に戻します。自動化 (AWS FIS の使用など) であれ手動であれ、これらのポストアクションは、障害を検出して処理する方法を説明するプレイブックの一部である必要があります。

仮説を検証する。

カオスエンジニアリングの原則は、ワークロードの定常状態を検証する方法について、以下のようなガイダンスを示しています。

システムの内部属性ではなく、測定可能な出力に焦点を当てます。その出力を短期間測定することによって、システムの定常状態のプロキシが構成されます。システム全体のスループット、エラーレート、レイテンシーのパーセンタイルはすべて、定常状態の動作を表す重要なメトリクスになり得ます。カオスエンジニアリングでは、実験中のシステムの動作パターンに焦点を当て、システムがどのように動作するかを検証するのではなく、システムが実際に動作することを検証します。

先の 2 つの例では、サーバーサイド (5xx) エラーの増加率が 0.01% 未満、データベースの読み取りと書き込みのエラーが 1 分未満という、定常状態のメトリクスが含まれています。

5xx エラーは、ワークロードのクライアントが直接経験する障害モードの結果であるため、良いメトリクスです。データベースエラーの測定は、障害の直接的な結果として適切ですが、顧客からのリクエストの失敗や、顧客に表面化したエラーなど、顧客への影響も測定して補足する必要があります。さらに、ワークロードのクライアントが直接アクセスする API や URI に、合成モニタリング (ユーザー canary とも呼ばれます) を含める必要があります。

回復力を高めるためのワークロード設計を改善する。

定常状態が維持されなかった場合は、AWS Well-Architected の信頼性の柱のベスト プラクティスを適用して、障害を軽減するためにワークロードの設計をどのように改善できるかを調査します。その他のガイダンスとリソースは、「AWS ビルダーライブラリ」にあります。このライブラリには、ヘルスチェックの改善方法や、アプリケーションコードでのバックオフによる再試行方法などに関する記事がホストされています。

これらの変更を実施した後、再度実験を行い (カオスエンジニアリングフライホイールの点線で表示)、その効果を判断します。検証の結果、仮説が正しいことがわかれば、ワークロードは定常状態になり、このサイクルが続きます。