"このコンテンツは古いものです。現在、このバージョンの Well-Architected Framework は、次の場所にあります。 https://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/reliability.html

REL 5: 障害を緩和または耐えるために、分散システムの操作をどのように設計しますか?

分散システムは、サーバーやサービスなどのコンポーネントを相互接続するために通信ネットワークを利用しています。このネットワークでデータの損失やレイテンシーがあっても、ワークロードは確実に動作する必要があります。分散システムのコンポーネントは、他のコンポーネントやワークロードに悪影響を与えない方法で動作する必要があります。これらのベストプラクティスに従うことで、ワークロードはストレスや障害に耐え、より迅速に復旧し、そのような障害の影響を軽減できます。その結果、平均復旧時間 (MTTR) が向上します。

リソース

Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)
Error Retries and Exponential Backoff in AWS
Amazon API Gateway: Throttle API Requests for Better Throughput
The Amazon Builders' Library: Timeouts, retries, and backoff with jitter
The Amazon Builders' Library: Avoiding fallback in distributed systems
The Amazon Builders' Library: Avoiding insurmountable queue backlogs
The Amazon Builders' Library: Caching challenges and strategies
Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability
CircuitBreaker (summarizes Circuit Breaker from “Release It!” book)
Michael Nygard “Release It! Design and Deploy Production-Ready Software”

ベストプラクティス:

改善計画

該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装する

  • 該当するハードな依存関係をソフトな依存関係に変換するため、グレイスフルデグラデーションを実装する: コンポーネントの依存関係が異常な場合でも、コンポーネント自体は機能しますが、パフォーマンスが低下します。たとえば、依存関係の呼び出しが失敗した場合、事前に定義された静的レスポンスにフェイルオーバーします。

    • スロットルリクエスト

  • スロットルリクエスト: これは、予想外の需要の増加に対応するための軽減パターンです。一部のリクエストは受け入れられますが、定義された制限を超えるリクエストは拒否され、スロットルされたことを示すメッセージが返されます。クライアントの期待は、リクエストが戻されて放棄されるか、遅い速度で再試行することです。

    • 再試行呼び出しを制御および制限する

  • 再試行呼び出しを制御および制限する: エクスポネンシャルバックオフを使用して、徐々に長い間隔で再試行します。これらの再試行間隔をランダム化するジッターを導入し、再試行の最大数を制限します。
    Error Retries and Exponential Backoff in AWS

    • すぐに失敗し、キューを制限する

  • すぐに失敗し、キューを制限する: ワークロードがリクエストに正常に応答できない場合は、すぐに失敗するようにします。これにより、リクエストに関連付けられたリソースを解放でき、リソースが不足した場合にサービスを復旧できます。ワークロードは正常に応答できるが、リクエスト頻度が高すぎる場合は、代わりにキューを使用してリクエストをバッファします。ただし、長いキューは許可しないでください。クライアントがすでに処理を停止している古いリクエストを処理する原因となる可能性があるためです。

    • クライアントタイムアウトを設定する

  • リモート呼び出しに接続タイムアウトとリクエストタイムアウトの両方を設定します。またこの設定は、プロセス全体のすべての呼び出しに一般的に行います。: 多くのフレームワークには組み込みのタイムアウト機能がありますが、その多くのデフォルト値は無限または高すぎるため、注意が必要です。値が高すぎると、クライアントがタイムアウトの発生を待機している間もリソースが消費され続けるため、タイムアウトの有用性が低下します。値が小さすぎると、再試行されるリクエストが多くなりすぎるため、バックエンドのトラフィックが増加し、レイテンシーが高くなってしまいます。場合によっては、すべてのリクエストが再試行されることになるため、完全な機能停止につながるおそれもあります。
    AWS SDK: Retries and Timeouts

    • 可能な場合はサービスをステートレスにする

  • アプリケーションをステートレスにする: ステートレスアプリケーションは、水平方向へのスケーリングが可能であり、個別ノードのエラーに耐性があります。

    • 緊急レバーを実装する

  • 緊急レバーを実装する: これは、ワークロードの可用性に対する影響を軽減できる可能性がある迅速なプロセスです。根本原因がなくても操作できます。緊急レバーは、完全に決定的なアクティブ化と非アクティブ化の基準を指定することにより、リゾルバーの認知負荷をゼロに減らせるものが理想的です。緊急レバーの例には、すべてのロボットトラフィックをブロックしたり、静的応答を行ったりすることが含まれます。緊急レバーは多くの場合手動ですが、自動化することもできます。