【りとらい】
リトライ とは?
最終更新:
💡 再送の安全性と、待機・打ち切りを決める
失敗した処理を再試行すること。一時的なエラーと再送の安全性を判断し、待機・ジッター・回数と期限の上限、SDKとの重複を確認する方法を解説します。
📌 このページのポイント
失敗した処理をやり直すことをリトライと呼ぶよ。手動でも自動でもできる。ただ、タイムアウトは相手が未処理という証拠ではない。再送の安全性とエラーの原因を見て判断しよう。一時的な通信の不調なら、再試行で回復する場合がある。
じゃあ、失敗したらすぐにもう一回リクエストすればいいの?
なるほど!でも何回もリトライし続けたら永遠に終わらなくない?
だから回数と全体の期限に上限を決めておくんだ。初回の後に3回リトライする設定なら、送信は最大4回だよ。それでもダメなら失敗を呼び出し元に返すなど、打ち切った後の処理も決めよう。
サーキットブレーカーってリトライとどう違うの?
リトライは失敗した処理をやり直すこと、サーキットブレーカーは失敗が続く相手への呼び出しを一時的に止める仕組みだよ。障害中の相手に負荷をかけ続けるのを抑えるために組み合わせるけれど、それだけで障害の連鎖を必ず防げるわけではないんだ。
リトライって何でも再試行していいの?
もっと詳しく知りたい人へ
注文APIがタイムアウトしたら、同じ注文を送り直していい?
応答が届かなかっただけで、注文自体は完了している可能性があります。まず注文状況やAPIの再試行仕様を確認してください。APIが冪等性キーに対応しているなら、同じ注文の再試行では同じキーと同じ内容を使います。サーバー側で重複を扱う仕組みが必要で、任意のキーを付けるだけでは防げません。キーの有効期間もAPIごとに確認します。
503や401を受け取ったときは、どう判断する?
503は一時的な利用不能を表すので、再送しても問題ない操作なら再試行を検討します。Retry-Afterがあれば待機時間の判断に使い、回数と全体の期限にも上限を設けます。401は認証情報の見直しが先です。同じ無効な認証情報のまま繰り返さず、認証を更新できる場合はAPIの仕様に従って再送します。コードだけで再送の安全性は決まりません。
SDKが再試行するなら、アプリにも追加していい?
SDKや下位サービスの設定を先に確認します。各層で再試行すると、送信回数が掛け合わされて増える場合があります。どこで制御するかを決め、最大試行回数が初回を含むのか、再試行だけなのかも確認します。待機だけでなく各試行のタイムアウトも全体の期限に収めます。
まとめ:ざっくりこれだけ覚えればOK!
「リトライ」って出てきたら「失敗した処理をやり直すこと」と思えばだいたいOK!同じ操作を繰り返しても問題ないか、先に確認しよう。
📖 おまけ:英語の意味
「Retry」 = 再試行する
💬 re(再び)とtry(試す)で再試行という意味だよ。ITでは失敗した処理をやり直すことを指し、自動化する場面も多いんだ