翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# フレームワークの適用
<a name="applying-framework"></a>

耐障害性分析フレームワークを適用する最善の方法は、障害カテゴリ別に整理された標準的な一連の質問から始め、分析するユーザーストーリーの各コンポーネントについて質問することです。ワークロード内のすべてのコンポーネントに適用されない質問がある場合は、最も当てはまる質問を使用してください。

障害モードの考え方には、次の 2 つの視点からアプローチできます。
+ 障害がコンポーネントのユーザーストーリーをサポートする機能にどのような影響を与えるか?
+ 障害がコンポーネントの他のコンポーネントとのやり取りにどのように影響を与えるか?

例えば、データストアと過剰な負荷を考慮する場合、データベースが過剰な負荷にさらされたり、クエリがタイムアウトしたりする障害モードについて検討します。また、データベースクライアントが再試行によりデータベースが過負荷になったり、データベース接続を閉じなかったことが原因で接続プールを使い果たしたりする状況について検討することもできます。もう一つの例は、いくつかのステップで構成される認証プロセスです。多要素認証 (MFA) アプリケーションまたはサードパーティー ID プロバイダー (IdP) の障害がこの認証システムのユーザーストーリーにどのように影響するかを考慮する必要があります。

以下の質問に答える際には、障害の原因を考慮する必要があります。例えば、過負荷は、顧客の急増や、人間のオペレーターがメンテナンスアクティビティ中に過剰な台数のノードを停止させたことによって引き起こされましたか? 各質問で障害の原因を複数特定できることがあり、さまざまな軽減策が必要になる可能性があります。質問する際は、検出した潜在的な障害モード、それらが適用されるコンポーネント (複数可)、および各障害の原因を記録しておきます。

**単一障害点**
+ コンポーネントは冗長性を考慮して設計されていますか?
+ コンポーネントに障害が発生した場合はどうなりますか?
+ お使いのアプリケーションでは、1 つのアベイラビリティーゾーンの部分的または全体的な損失を許容できますか?

**過剰なレイテンシー**
+ このコンポーネントでレイテンシーが増加した場合、または操作するコンポーネントでレイテンシーが増加した場合 (または TCP リセットなどのネットワーク中断が発生した場合) はどうなりますか?
+ 再試行戦略でタイムアウトを適切に設定していますか?
+ すぐに失敗しましたか、または時間が経ってから失敗しましたか? 障害が発生したリソースにすべてのトラフィックを意図せずに送信するなど、すぐに失敗したことによる連鎖的な影響はありますか?
+ このコンポーネントに対して行われた最も費用のかかるリクエストは何ですか?

**過剰な負荷**
+ このコンポーネントが過負荷になる要因は何ですか? このコンポーネントが他のコンポーネントに負荷をかける理由は何ですか?
+ 正常に実行されることのない作業でのリソースの浪費を防ぐにはどうすればよいですか?
+ このコンポーネント用に設定されたサーキットブレーカーはありますか?
+ 克服できないバックログが作成される可能性はありますか?
+ このコンポーネントのどこでバイモーダル動作が発生する可能性がありますか?
+ 超過する可能性のある制限または Service Quotas (ストレージ容量を含む) は何ですか?
+ コンポーネントは負荷下でどのようにスケールされますか?

**設定ミスとバグ**
+ 設定ミスやバグが本番環境にデプロイされないようにするにはどうすればよいですか?
+ 不正なデプロイを自動的にロールバックしたり、更新または変更がデプロイされた障害コンテナからトラフィックを移行したりできますか?
+ オペレーターのエラーを防ぐために、どのようなガードレールを用意していますか?
+ 期限切れになる可能性のある項目 (認証情報や証明書など) は何ですか?

**共有される運命**
+ 障害分離境界とは何ですか?
+ デプロイユニットへの変更は、意図した[障害分離境界](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)と少なくとも同じくらい小さいが、理想的にはワンボックス環境 (障害分離境界内の 1 つのインスタンス) などのさらに小さいものになっていますか?
+ このコンポーネントはユーザーストーリーや他のワークロード間で共有されていますか?
+ このコンポーネントに緊密に結合されている他のコンポーネントは何ですか?
+ このコンポーネントまたはその依存関係で部分的な障害またはグレー障害が発生した場合はどうなりますか?

これらの質問をした後、SEEMS を使用して、ワークロードや各コンポーネントに固有のその他の質問を作成することもできます。SEEMS は、障害モードについて考えるための構造化された方法として、また耐障害性分析を実行する際の発想源として使用するのに最適です。これは厳格な分類ではありません。特定の障害モードがどのカテゴリに該当するかについては、重要ではないため心配する必要はありません。重要なのは、障害について考え、書き留めておくことです。**答えに間違いはありません。既成概念にとらわれない、クリエイティブな発想が有益となります。さらに、障害モードがすでに軽減されていると仮定しないでください。考え得る潜在的な障害モードはすべて含めるようにしてください。

最初の演習では、すべての潜在的な障害モードを予測することはほとんどなかったでしょう。フレームワークを複数回繰り返すことでより完全なモデルを生成できるようになるため、最初のパスであらゆることを試したり解決したりする必要はありません。分析は、定期的、毎週、または隔週の頻度で実行できます。各セッションでは、特定の障害モードまたはコンポーネントに焦点を当てます。これにより、ワークロードの耐障害性向上について着実かつ段階的に進めていくことができます。ユーザーストーリーの潜在的な障害モードのリストを収集したら、それらの対処方法を決定できます。