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

# 一般的な軽減戦略
<a name="mitigation-strategies"></a>

まず、障害モードがユーザーストーリーに影響を与えないように、*予防的*軽減策の利用を検討してください。次に、*是正的*軽減策について検討する必要があります。是正的軽減策によって、システムの自己修復や変化する条件への適応が可能になります。耐障害性の特性に合わせた、各障害カテゴリに対応する一般的な軽減策のリストを次に示します。


| 
| 
| **障害カテゴリ** | **期待される耐障害特性** | **緩和策** | 
| --- |--- |--- |
| 単一障害点 (SPOF) | 冗長性と耐障害性 |   [冗長性](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)の実装 — 例えば、Elastic Load Balancing (ELB) の背後で複数の EC2 インスタンスを使用します。   [AWS グローバルサービスコントロールプレーン](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-service-types.html#global-services)に対する依存関係を削除し、グローバルサービスデータプレーンにのみ依存関係を作成します。   リソースが利用できない場合は、システムが単一障害点に対して静的に安定するように、[グレースフルグラデーション](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html)を使用します。   | 
| 過剰な負荷 | 十分な容量 |   主な軽減戦略は、[レート制限](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems)、[負荷分散](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload)と作業の優先順位付け、[継続動作](https://aws.amazon.com/builders-library/reliability-and-constant-work)、[エクスポネンシャルバックオフとジッターによる再試行](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)または再試行なし、[小さなサービスに制御を任せる](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control)、[キューの深さの管理](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)、[自動スケーリング](https://aws.amazon.com/autoscaling/)、[コールドキャッシュの回避](https://aws.amazon.com/builders-library/caching-challenges-and-strategies)、[サーキットブレーカーです](https://brooker.co.za/blog/2022/02/16/circuit-breakers.html)。   また、キャパシティープランニングを検討し、将来到達する可能性のあるキャパシティーとスケーリングの制限を、システム内の AWS リソースと制限の両方に関連付けて考慮する必要があります。   | 
| 過剰なレイテンシー | タイムリーな出力 |   適切に設定された[タイムアウト](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)またはアダプティブタイムアウトを実装します (現在のレイテンシー条件と予測されるレイテンシー条件に基づいてタイムアウト値を変更し、遅いリクエストを断念する代わりに、遅い依存関係の進行を許可する可能性があります)。   オンプレミス環境からクラウドサービスに接続し、特定のルートでレイテンシーが発生するときに、[疎結合システムとの非同期のやり取り](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_loosely_coupled_system.html)、[キャッシュ](https://aws.amazon.com/builders-library/caching-challenges-and-strategies)、[作業の継続](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)により [Multipath TCP](https://en.wikipedia.org/wiki/Multipath_TCP) などのテクノロジーを使用して[エクスポネンシャルバックオフとジッターによる再試行](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) (ヘッジ) を実装します。   | 
| 設定ミスとバグ | 正しい出力 |   ソフトウェアで繰り返し発生し得る機能エラーを検出する主な方法は、[静的分析](https://en.wikipedia.org/wiki/Static_program_analysis)、[ユニットテスト](https://en.wikipedia.org/wiki/Unit_testing)、[統合テスト](https://en.wikipedia.org/wiki/Integration_testing)、[リグレッションテスト](https://en.wikipedia.org/wiki/Regression_testing)、[負荷テスト](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html)、[耐障害性テスト](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/)などのメカニズムによる厳格なテストを実行することです。   [Infrastructure as Code (IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html) や[継続的インテグレーションと継続的デリバリー (CI/CD) の自動化](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments)といった戦略を実施して、設定ミスによる脅威を軽減できます。   [ワンボックス](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)、[Canary デプロイ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html)、障害分離境界に沿った端数デプロイ、[ブルー/グリーンデプロイ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/blue-green-deployments.html)などのデプロイ手法を使用して、設定ミスやバグを減らします。   | 
| 共有される運命 | 障害分離 |   システムに[耐障害性](https://aws.amazon.com/builders-library/minimizing-correlated-failures-in-distributed-systems)を実装し、複数のコンピューティングクラスターまたはコンテナクラスター、複数の AWS アカウント、複数の AWS Identity and Access Management (IAM) プリンシパル、複数のアベイラビリティーゾーン、および場合によっては複数の AWS リージョンなど、論理的および物理的な障害分離境界を使用します。   [セルベースアーキテクチャ](https://youtu.be/swQbA4zub20)や[シャッフルシャーディング](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding)などの手法でも、障害分離を改善できます。   失敗の連鎖を防ぐため、[疎結合](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_loosely_coupled_system.html)や[グレースフルデグラデーション](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html)などのパターンを検討してください。ユーザーストーリーを優先する場合、その優先順位付けを使用して、主要なビジネス機能に不可欠なユーザーストーリーと、緩やかに退行していく可能性があるユーザーストーリーを区別することもできます。例えば、e コマースサイトでは、ウェブサイトのプロモーションウィジェットの障害によって、新規注文の処理機能に影響を与えないようにする必要があります。   | 

これらの軽減策の中には実装にかかる労力が最小限で済むものもありますが、特定のユーザーストーリーのコンポーネントだけでなく、ワークロード全体の再設計が必要になるものもあります (予測可能な障害分離と最小限の運命共有の失敗に対応するセルベースアーキテクチャの採用など)。前述のように、障害モードの可能性と影響を、それを軽減するために行うトレードオフと比較することが重要です。

各障害モードカテゴリに適用される軽減手法に加えて、ユーザーストーリーまたはシステム全体の復旧に必要な軽減策についても検討する必要があります。例えば、障害が発生するとワークフローが停止し、意図した送信先にデータが書き込まれなくなる可能性があります。この場合、ワークフローを再処理したり、データを手動で修正したりするために、運用ツールが必要になるかもしれません。また、障害発生時のデータ損失を防ぐために、ワークロードにチェックポイントメカニズムを構築する必要が生じる場合もあります。または、さらなる損害を防ぐために、Andon コードを作成してワークフローを一時停止し、新しい作業の受け入れを停止する必要が生じる可能性があります。このような場合は、必要な運用ツールとガードレールを検討する必要があります。

最後に、軽減戦略を策定する際に、人為的エラーの発生可能性を常に想定しておく必要があります。最新の DevOps プラクティスでは運用の自動化を模索していますが、それでもさまざまな理由から、人間によるワークロードの操作が必要になります。メンテナンス中に過剰な台数のノードを削除して過負荷を発生させたり、機能フラグを誤って設定したりするなど、人間が操作を誤ると、SEEMS カテゴリのいずれかで障害が発生する可能性があります。これらのシナリオは、予防的ガードレールで実際に発生する障害です。根本原因分析では、「人間がミスをした」という結論で終わるべきではありません。第一に間違いが起こり得る状況になった理由について対処する必要があります。したがって、軽減戦略では、人間のオペレーターによるワークロードコンポーネントの操作方法と、安全ガードレールを通じて人間のオペレーターのミスによる影響を防止または最小限に抑える方法を考慮する必要があります。