# REL 5 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか?
分散システムは、サーバーやサービスなどのコンポーネントを相互接続するために通信ネットワークを利用しています。このネットワークでデータの損失やレイテンシーがあっても、ワークロードは確実に動作する必要があります。分散システムのコンポーネントは、他のコンポーネントやワークロードに悪影響を与えない方法で動作する必要があります。これらのベストプラクティスに従うことで、ワークロードはストレスや障害に耐え、より迅速に復旧し、そのような障害の影響を軽減できます。その結果、平均復旧時間 (MTTR) が向上します。
**Topics**
+ [REL05-BP01 該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装する](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 リクエストのスロットル](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 再試行呼び出しを制御および制限する](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 フェイルファストとキューの制限](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 クライアントタイムアウトを設定する](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 可能な限りサービスをステートレスにする](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 緊急レバーを実装する](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装する
コンポーネントの依存関係が異常な場合でも、コンポーネント自体は機能しますが、パフォーマンスが低下します。たとえば、依存関係の呼び出しが失敗した場合、事前に定義された静的レスポンスにフェイルオーバーします。
サービス A によって呼び出されたサービス B が、次にサービス C を呼び出すとします。
![\[サービス B から呼び出されるとサービス C が失敗することを示す図。サービス B は、低下した応答をサービス A に返します。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
サービス B がサービス C を呼び出すと、エラーまたはタイムアウトを受け取ります。サービス B は、サービス C (およびそれに含まれるデータ) からの応答がないため、返せるものを返します。これは、最後にキャッシュされた適切な値であるかもしれません。または、サービス B は、サービス C から受け取るはずだったものを所定の静的応答に置き換える可能性もあります。次に、低下した応答を呼び出し元のサービス A に返すことでしょう。この静的応答がない場合、サービス C で障害が発生すると、サービス B を介してサービス A にカスケードされ、可用性が失われます。
強い依存関係の可用性方程式の乗数的因子により (「 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)」を参照)、C の可用性が低下すると、B の有効な可用性に重大な影響を与えます。静的応答を返すことによりサービス B は、C での障害を軽減し、パフォーマンスが低下しますが、サービス C が 100% の可用性を実現しているように見せます (エラー条件下で確実に静的応答を返すと仮定します)。静的応答は単純にエラーを返す代わりに行う手段で、別の手段を使って応答を再計算する試みではないことに注意してください。まったく異なるメカニズムで同じ結果を達成しようとする試みは、フォールバック動作と呼ばれ、回避すべきアンチパターンです。
グレースフルデグラデーションのもう 1 つの例は *サーキットブレーカーパターン*.障害が一時的な場合は、再試行戦略を用いるのがよいでしょう。障害が一時的ではなく、操作が失敗する可能性が高い場合、サーキットブレーカーパターンは、失敗する可能性が高いリクエストをクライアントが実行できないようにします。リクエストが正常に処理されると、サーキットブレーカーは閉じられ、リクエストは正常に流されます。リモートシステムがエラーを返し始めるか、レイテンシーが高くなると、サーキットブレーカーが開かれ、依存関係が無視されるか、結果的に返される応答は単純に取得されたが包括的ではない応答 (単なる応答キャッシュである場合もあります) に置き換えられます。システムは、依存性が回復したかどうかを判断するために、依存関係を定期的に呼び出そうとします。依存関係が確認できたら、サーキットブレーカーは閉じられます。
![\[サーキットブレーカーが開いた状態と閉じた状態を示した図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
図に示されている閉じた状態と開いた状態に加えて、開いた状態で設定可能な期間が経過すると、サーキットブレーカーは半分開いた状態に移行することもあります。この状態では、通常よりはるかに低いレートで定期的にサービスを呼び出そうとします。このプローブは、サービスの状態を確認するために使用します。半開状態で何度か成功すると、サーキットブレーカーは閉じた状態に移行し、通常のリクエストフローが再開されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装します。コンポーネントの依存関係が異常な場合でも、コンポーネント自体は機能しますが、パフォーマンスが低下します。たとえば、依存関係の呼び出しが失敗した場合、事前に定義された静的レスポンスにフェイルオーバーします。
+ 静的応答を返すことで、ワークロードは依存関係で発生する障害を軽減します。
+ [Well-Architected ラボ: レベル 300: ヘルスチェックを実装し依存関係を管理して、信頼性を向上する](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ 再試行オペレーションが失敗する可能性がある場合を検出し、クライアントがサーキットブレーカーパターンで失敗した呼び出しを行わないようにします。
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## リソース
**関連するドキュメント:**
+ [Amazon API Gateway: スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (「Release It\$1」よりサーキットブレーカーをまとめたもの)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard「Release It\$1 Design and Deploy Production-Ready Software」](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [The Amazon Builders' Library: 分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: キャッシュの課題と戦略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: タイムアウト、再試行、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**関連動画:**
+ [再試行、バックオフ、ジッター: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**関連する例:**
+ [Well-Architected ラボ: レベル 300: ヘルスチェックを実装し依存関係を管理して、信頼性を向上する](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 リクエストのスロットル
リクエストのスロットリングは、予想外の需要の増加に対応するための軽減パターンです。一部のリクエストは受け入れられますが、定義された制限を超えるリクエストは拒否され、スロットルされたことを示すメッセージが返されます。クライアントの期待は、リクエストが戻されて放棄されるか、遅い速度で再試行することです。
サービスは、各ノードまたはセルが処理できる既知のリクエスト容量に合わせて設計する必要があります。この容量は、負荷テストによって設定できます。リクエストの到着率をトラッキングし、到着率が一時的に制限を超えると、リクエストが適切にスロットリングされたことを示す応答があります。これにより、ユーザーは、利用可能なキャパシティを持つ可能性のある別のノードまたはセルに再試行することができます。Amazon API Gateway には、リクエストをスロットリングするためのメソッドが用意されています。Amazon SQS と Amazon Kinesis はリクエストをバッファリングし、リクエスト率を平準化し、非同期で対応できるリクエストのスロットリングの必要性を軽減することができます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
+ リクエストをスロットリングします。これは、予想外の需要の増加に対応するための軽減パターンです。一部のリクエストは受け入れられますが、定義された制限を超えるリクエストは拒否され、スロットルされたことを示すメッセージが返されます。クライアントの期待は、リクエストが戻されて放棄されるか、遅い速度で再試行することです。
+ Amazon API Gateway を使用します。
+ [スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## リソース
**関連するドキュメント:**
+ [Amazon API Gateway: スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS でのエラー再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: 分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: タイムアウト、再試行、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**関連動画:**
+ [Retry, backoff, and jitter (再試行、バックオフ、ジッター): AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328) (The Amazon Builders’ Library のご紹介)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 再試行呼び出しを制御および制限する
エクスポネンシャルバックオフを使用して、徐々に長い間隔で再試行します。これらの再試行間隔をランダム化するジッターを導入し、再試行の最大数を制限します。
分散ソフトウェアシステムの一般的なコンポーネントには、サーバー、ロードバランサー、データベース、DNS サーバーが含まれます。操作中に障害が発生すると、これらのコンポーネントのいずれかにエラーが発生し始める可能性があります。エラーを処理するデフォルトの手法は、クライアント側で再試行を行うことです。この手法により、アプリケーションの信頼性と可用性が向上します。ただし、再試行が大規模に行われた場合 (またエラーが発生してからすぐにクライアントが失敗した操作を再試行しようとすると)、ネットワークは、新しいリクエストと再試行されたリクエストですぐに飽和状態になり、それぞれがネットワーク帯域幅を奪い合うことになる可能性があります。これにより *再試行の大混乱が生じて、* サービスの可用性が低下します。このパターンは、システムが完全にダウンするまで続くかもしれません。
このようなシナリオを回避するには、一般的なエクスポネンシャルバックオフなどの *バックオフアルゴリズム* を使用する必要があります。エクスポネンシャルバックオフアルゴリズムは、再試行が行われる速度を徐々に下げて、ネットワークの輻輳を回避します。
多くの SDK およびソフトウェアライブラリ (AWS のものを含む) は、これらのアルゴリズムのバージョンを実装しています。ただし、 **バックオフアルゴリズムが存在することは想定しないでください。必ずこれをテストして検証してください。**
分散システムでは、すべてのクライアントが同時にバックオフし、再試行呼び出しのクラスターが発生する可能性があるため、単にバックオフするだけでは不十分です。Marc Brooker 氏のブログ記事「 [エクスポネンシャルバックオフとジッター](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/)は、エクスポネンシャルバックオフで wait() 関数を変更して、再試行呼び出しのクラスターを防ぐ方法を説明しています。解決策は、 *ジッター* を wait() 関数に追加することです。時間がかかり過ぎる再試行を行わないようにするには、実装ではバックオフを最大値に制限する必要があります。
最後に、 *再試行の最大数* または最大経過時間を設定し、これを超えると再試行が失敗するようにすることが重要です。AWS SDK はデフォルトでこれを実装しており、設定を変更することもできます。スタックの下位にあるサービスの場合、再試行の上限を 0 または 1 にするとリスクが緩和されますが、スタックの上位にあるサービスに再試行が委任されるため、効果的な方法です。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ 再試行呼び出しを制御および制限します。エクスポネンシャルバックオフを使用して、徐々に長い間隔で再試行します。これらの再試行間隔をランダム化するジッターを導入し、再試行の最大数を制限します。
+ [AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Amazon SDK は、デフォルトで再試行とエクスポネンシャルバックオフを実装しています。お客様独自の依存サービスを呼び出す場合は、同類のロジックを依存関係レイヤーに実装します。タイムアウトの時間と、再試行をいつ停止するのかをユースケースに基づいて決めます。
## リソース
**関連するドキュメント:**
+ [Amazon API Gateway: スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: 分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: キャッシュの課題と戦略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: タイムアウト、再試行、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**関連動画:**
+ [再試行、バックオフ、ジッター: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 フェイルファストとキューの制限
ワークロードがリクエストに正常に応答できない場合は、すぐに失敗するようにします。これにより、リクエストに関連付けられたリソースを解放でき、リソースが不足した場合にサービスを復旧できます。ワークロードは正常に応答できるが、リクエスト頻度が高すぎる場合は、代わりにキューを使用してリクエストをバッファします。ただし、長いキューは許可しないでください。クライアントがすでに処理を停止している古いリクエストを処理する原因となる可能性があるためです。
このベストプラクティスは、サーバー側、つまりリクエストのレシーバーに当てはまります。
キューはシステムの複数のレベルで作成される可能性があるため、応答が必要な新しいリクエストの前に (もはや応答を必要としない) 古い応答が処理されると、迅速に復旧する能力が著しく阻害される可能性があることに注意してください。キューがどこに存在するかに注意を払ってください。ワークフローや、データベースに記録された作業の中に隠れていることもよくあります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ すぐに失敗し、キューを制限します。ワークロードがリクエストに正常に応答できない場合は、すぐに失敗するようにします。これにより、リクエストに関連付けられたリソースを解放でき、リソースが不足した場合にサービスを復旧できます。ワークロードは正常に応答できるが、リクエスト頻度が高すぎる場合は、代わりにキューを使用してリクエストをバッファします。ただし、長いキューは許可しないでください。クライアントがすでに処理を停止している古いリクエストを処理する原因となる可能性があるためです。
+ サービスへの負荷が過剰になったときのフェイルファストを実装します。
+ [速やかな失敗](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ キューベースのシステムでは、処理が停止してもメッセージが到着し続けると、メッセージの負債が蓄積されて、大きなバックログになり、処理時間が長くなることがあります。作業の完了が遅すぎて、結果が役に立たなくなることがあります。これにより、基本的にキューイングが防御することを意図していた、可用性への悪影響が発生します。
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## リソース
**関連するドキュメント:**
+ [AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [速やかな失敗](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [The Amazon Builders' Library: 分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: キャッシュの課題と戦略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [The Amazon Builders' Library: タイムアウト、再試行、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**関連動画:**
+ [再試行、バックオフ、ジッター: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 クライアントタイムアウトを設定する
タイムアウトを適切に設定し、体系的に検証します。デフォルト値は通常高すぎるため、デフォルト値のままにしないでください。
このベストプラクティスは、クライアント側、つまりリクエストの送信者に当てはまります。
リモート呼び出しに接続タイムアウトとリクエストタイムアウトの両方を設定します。またこの設定は、プロセス全体のすべての呼び出しに一般的に行います。多くのフレームワークには組み込みのタイムアウト機能がありますが、その多くのデフォルト値は無限または高すぎるため、注意が必要です。値が高すぎると、クライアントがタイムアウトの発生を待機している間もリソースが消費され続けるため、タイムアウトの有用性が低下します。値が小さすぎると、再試行されるリクエストが多くなりすぎるため、バックエンドのトラフィックが増加し、レイテンシーが高くなってしまいます。場合によっては、すべてのリクエストが再試行されることになるため、完全な機能停止につながる恐れもあります。
Amazon がタイムアウト、再試行、およびジッターによるバックオフを使用する方法について詳しくは [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ リモート呼び出しに接続タイムアウトとリクエストタイムアウトの両方を設定します。またこの設定は、プロセス全体のすべての呼び出しに一般的に行います。多くのフレームワークには組み込みのタイムアウト機能がありますが、その多くのデフォルト値は無限または高すぎるため、注意が必要です。値が高すぎると、クライアントがタイムアウトの発生を待機している間もリソースが消費され続けるため、タイムアウトの有用性が低下します。値が小さすぎると、再試行されるリクエストが多くなりすぎるため、バックエンドのトラフィックが増加し、レイテンシーが高くなってしまいます。場合によっては、すべてのリクエストが再試行されることになるため、完全な機能停止につながる恐れもあります。
+ [AWS SDK: 再試行とタイムアウト](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## リソース
**関連するドキュメント:**
+ [AWS SDK: 再試行とタイムアウト](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: スループット向上に向けた API リクエストのスロットリング](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS でのエラーの再試行とエクスポネンシャルバックオフ](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [The Amazon Builders' Library: タイムアウト、再試行、ジッターによるバックオフ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**関連動画:**
+ [再試行、バックオフ、ジッター: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 可能な限りサービスをステートレスにする
サービスは、ステートを必要としないか、またはステートをオフロードして、異なるクライアントのリクエスト間で、ディスクやメモリのローカルに保存されたデータに依存しないようにする必要があります。これにより、可用性に影響を与えずにサーバーをいつでも交換できます。Amazon ElastiCache または Amazon DynamoDB は、オフロード状態の送信先として適しています。
![\[このステートレスウェブアプリケーションでは、セッション状態は Amazon ElastiCache にオフロードされます。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
ユーザーまたはサービスがアプリケーションと対話するとき、セッションを形成する一連のやりとりを頻繁に実行します。セッションは、ユーザーがアプリケーションを使用している間、リクエスト間で持続するユーザー固有のデータです。ステートレスアプリケーションは、以前のやりとりの知識を必要とせず、セッション情報を保存しません。
ステートレスな設計にすれば、あとは AWS Lambda や AWS Fargate などのサーバーレスコンピューティングサービスを利用できます。
サーバーの置き換えに加えて、ステートレスアプリケーションのもう 1 つの利点は、利用可能なコンピューティングリソース (EC2 インスタンスや AWS Lambda 関数など) がどのようなリクエストにも対応できるため、水平方向にスケーリングできることです。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ アプリケーションをステートレスにします。ステートレスアプリケーションは、水平方向へのスケーリングが可能であり、個別ノードのエラーに耐性があります。
+ リクエストパラメータに実際に格納できるステートを削除する
+ ステートが必要かどうかを調べてから、あらゆるステート追跡を Amazon ElastiCache、Amazon RDS、Amazon DynamoDB などの回復力のあるマルチゾーンキャッシュやデータストア、またはサードパーティの分散データソリューションに移動します。移動できないステートをエラーに強いデータストアに格納します。
+ 一部のデータ (Cookie など) は、ヘッダーまたはクエリパラメータで渡すことができます。
+ リクエストですばやく渡すことができるステートを削除するためにリファクタリングします。
+ 実際には毎回のリクエストで必要のないデータはオンデマンドで取得できます。
+ 非同期で取得できるデータを削除します。
+ 必要なステートの条件を満たしているデータストアを決めます。
+ リレーショナル型ではないデータには NoSQL データベースを検討します。
## リソース
**関連するドキュメント:**
+ [The Amazon Builders' Library: 分散システムでのフォールバックの回避](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [The Amazon Builders' Library: 克服できないキューバックログの回避](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [The Amazon Builders' Library: キャッシュの課題と戦略](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 緊急レバーを実装する
緊急レバーは、ワークロードの可用性に対する影響を軽減できる迅速なプロセスです。
**このベストプラクティスを活用しない場合のリスクレベル:** ミディアム
## 実装のガイダンス
+ 緊急レバーを実装します。これは、ワークロードの可用性に対する影響を軽減できる可能性がある迅速なプロセスです。根本原因がなくても操作できます。緊急レバーは、完全に決定的なアクティブ化と非アクティブ化の基準を提供することにより、リゾルバーの認知負荷をゼロに減らせるものが理想的です。緊急レバーは多くの場合手動ですが、自動化することもできます
+ 例えば、次のようなレバーがあります。
+ すべてのロボットトラフィックをブロックする
+ 動的ページの代わりに静的ページを表示する
+ 依存関係への呼び出しの頻度を減らす
+ 依存関係からの呼び出しをスロットリングする
+ 緊急レバーを実装して使用するためのヒント
+ 緊急レバーがアクティブになったら、実行数を増やすのではなく、減らす
+ シンプルに保ち、バイモーダルな行動は避ける
+ 緊急レバーを定期的にテストする
+ これらは、緊急レバーではないアクションの例です
+ キャパシティーを追加する
+ サービスに依存するクライアントのサービス所有者を呼び出して、呼び出しを減らすよう依頼する
+ コードを変更してリリースする