REL05-BP03 再試行呼び出しを制御および制限する

エクスポネンシャルバックオフを使用して、徐々に長い間隔で再試行します。これらの再試行間隔をランダム化するジッターを導入し、再試行の最大数を制限します。

分散ソフトウェアシステムの一般的なコンポーネントには、サーバー、ロードバランサー、データベース、DNS サーバーが含まれます。操作中に障害が発生すると、これらのコンポーネントのいずれかにエラーが発生し始める可能性があります。エラーを処理するデフォルトの手法は、クライアント側で再試行を行うことです。この手法により、アプリケーションの信頼性と可用性が向上します。ただし、再試行が大規模に行われた場合 (またエラーが発生してからすぐにクライアントが失敗した操作を再試行しようとすると)、ネットワークは、新しいリクエストと再試行されたリクエストですぐに飽和状態になり、それぞれがネットワーク帯域幅を奪い合うことになる可能性があります。これにより 再試行の大混乱が生じて、 サービスの可用性が低下します。このパターンは、システムが完全にダウンするまで続くかもしれません。

このようなシナリオを回避するには、一般的なエクスポネンシャルバックオフなどの バックオフアルゴリズム を使用する必要があります。エクスポネンシャルバックオフアルゴリズムは、再試行が行われる速度を徐々に下げて、ネットワークの輻輳を回避します。

多くの SDK およびソフトウェアライブラリ (AWS のものを含む) は、これらのアルゴリズムのバージョンを実装しています。ただし、 バックオフアルゴリズムが存在することは想定しないでください。必ずこれをテストして検証してください。

分散システムでは、すべてのクライアントが同時にバックオフし、再試行呼び出しのクラスターが発生する可能性があるため、単にバックオフするだけでは不十分です。Marc Brooker 氏のブログ記事「 エクスポネンシャルバックオフとジッターは、エクスポネンシャルバックオフで wait() 関数を変更して、再試行呼び出しのクラスターを防ぐ方法を説明しています。解決策は、 ジッター を wait() 関数に追加することです。時間がかかり過ぎる再試行を行わないようにするには、実装ではバックオフを最大値に制限する必要があります。

最後に、 再試行の最大数 または最大経過時間を設定し、これを超えると再試行が失敗するようにすることが重要です。AWS SDK はデフォルトでこれを実装しており、設定を変更することもできます。スタックの下位にあるサービスの場合、再試行の上限を 0 または 1 にするとリスクが緩和されますが、スタックの上位にあるサービスに再試行が委任されるため、効果的な方法です。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

リソース

関連するドキュメント:

関連動画: