指数バックオフは、ネットワーク アプリケーションの標準的なエラー処理方法で、クライアントはリクエスト間の遅延を増加させながら、失敗したリクエストを定期的に再試行します。HTTP 5xx および 429 レスポンス コードエラーを返す Memorystore for Valkey へのすべてのリクエストに、クライアントは指数バックオフを使用する必要があります。
Memorystore for Valkey REST API を直接使用するクライアント アプリケーションを構築する場合は、指数バックオフの仕組みを理解することが重要です。
Google Cloud コンソールを使用している場合、ユーザーの代わりに コンソール が Memorystore for Valkey にリクエストを送信し、必要なバックオフを処理します。
アルゴリズムの例
指数バックオフのアルゴリズムは、再試行の待ち時間の間隔を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。次に例を示します。
Memorystore for Valkey にリクエストを行います。
リクエストが失敗した場合、1 +
random_number_milliseconds秒待ってから、リクエストを再試行します。リクエストが失敗した場合、2 +
random_number_milliseconds秒待ってから、リクエストを再試行します。リクエストが失敗した場合、4 +
random_number_milliseconds秒待ってから、リクエストを再試行します。このようにして、最大
maximum_backoff時間まで繰り返します。再試行の最大回数まで待機と再試行を続行しますが、再試行の待ち時間の間隔は増加させません。
ここで
待ち時間は min(((2^
n)+random_number_milliseconds),maximum_backoff) で、nはイテレーション（リクエスト）のたびに +1 されます。上記のフローで、
random_number_millisecondsは、1,000 ミリ秒以下の乱数です。これにより、なんらかの状況によって多数のクライアントが同期され、再試行が一度に実行されて、リクエストが同時に次々と送信されるような状況を避けることができます。random_number_millisecondsの値は、再試行リクエストの後に毎回再計算されます。通常、
maximum_backoffは 32 秒または 64 秒です。適切な値はユースケースによって異なります。
maximum_backoff 時間に達した後でも再試行を続行できます。この時点より後の再試行では、バックオフ時間を増加させ続ける必要はありません。たとえば、クライアントで 64 秒の maximum_backoff 時間が使用されている場合、この値に達した後は、クライアントは 64 秒ごとに再試行を繰り返します。いずれかの時点で、クライアントが無限に再試行を行わないようにする必要があります。
クライアントが使用する最大バックオフと再試行の最大回数は、ユースケースとネットワーク条件によって異なります。たとえば、アプリケーションのモバイル クライアントでは、同じアプリケーションのデスクトップ クライアントに比べて、より多くの再試行回数とより長い再試行間隔が必要になる可能性があります。
再試行リクエストが再試行の最大回数を超えた後に失敗した場合は、サポートの利用に記載されているいずれかの方法でエラーを報告または記録します。