リトライポリシーとは何か、単純な失敗時の再実行とどう違うのか？
リトライポリシーとは、自動化フローが失敗に遭遇した際、自動的に再試行すべきか、何回再試行するか、各試行の間隔をどれだけ空けるかを決める一連のルールであり、失敗するたびに無条件で即座に再実行することではない。完全なリトライポリシーは少なくとも3つの質問に答える。この種の失敗は再試行する価値があるか（一部の失敗は再試行しても無駄）、何回の再試行が妥当な上限か、各再試行の間隔をどう設定すべきか、である。
単純な失敗時の再実行との最大の違いは「間隔設計」と「上限メカニズム」にある。単純な再実行は通常失敗すればすぐにもう一度試す。問題が一時的なもの（短時間のネットワーク瞬断など）であれば、即座の再試行はネットワークが回復する前に再び失敗するかもしれない。リトライポリシーは代わりに試行ごとに間隔を延ばしていく設計をし、問題が自ら回復する時間を与え、再試行の上限を設定する。上限を超えたら停止し、無限に再試行し続けるのではなく人への通知に切り替える。
リトライポリシーにはどんな限界があり、最も見落とされやすいのはどれか？
最も見落とされやすいのは、すべての失敗がリトライポリシーで解決するのに適しているわけではないことだ。リトライポリシーが扱うのは一時的で自己回復の可能性がある失敗、例えば短時間のネットワーク中断や相手サーバーの一時的な過負荷である。失敗の原因がロジック自体の誤り——判断条件が逆に書かれている、データ形式が最初から間違っているなど——であれば、何回再試行しても結果は同じ誤りになる。この場合の再試行は時間と計算資源の無駄でしかなく、本当に修正すべきはロジック自体であり、再試行回数を増やすことではない。
2つ目に見落とされやすい限界は、再試行回数は多ければ多いほど安全というわけではないことだ。再試行回数を多く設定しすぎ、間隔も長く延ばしすぎると、本来すぐに気づかれるべき問題が、システムが黙って再試行し続けているために、実際に人に発見されるのがずっと遅れてしまうことがある。この種の遅延は状況によっては（顧客の支払い失敗など）コストが高くつく可能性がある。リトライポリシーは「問題に自己回復の機会を与える」ことと「問題が続いている場合すぐに人に知らせる」ことの間でバランスを取る必要があり、単に再試行回数を増やせばよいわけではない。
どのような場合にリトライポリシーを設計すべきで、どのような場合には不要なのか？
リトライポリシーに適する核心的な状況は、その動作が外部システムに依存しており、外部システムがときどき一時的で本質的でない問題を起こす場合である。サードパーティAPIの呼び出し、データベースへの接続、ネットワークリクエストの送信といった動作は、ネットワークの変動や相手システムの一時的な過負荷でときどき失敗するが、問題は通常数分以内に自然に回復する。この状況でリトライポリシーを加えれば、人による介入が不要なほとんどの一時的な失敗を自動的に処理できる。
リトライポリシーが不要なのは、失敗の原因が本質的に時間とともに変化しないものである場合だ。入力データの形式が間違っているために失敗する、ロジックの判断が誤っているために誤った結果になる、といった失敗はどれだけ待っても何回再試行しても結果は同じになる。この場合リトライポリシーは全く機能せず、本当にすべきなのは問題の根本原因を直接修正することだ。簡単な判断法は、「この失敗は数分後に自然に消える可能性があるか」を自問することだ。可能性があればリトライポリシーが適しており、可能性がなければロジックを直接修正すべきだ。
上級者は自動回復と本当の問題の適時発見を両立させるために、リトライポリシーをどう設計すればよいか？
上級者の要点は、固定間隔や線形的な増加ではなく、リトライ間隔を指数関数的に増加させることだ。具体的には、最初の再試行は短い待機時間（1分など）で行い、それでも失敗すれば2回目の待機時間はある倍率をかける（5分など）、3回目もさらに倍率をかける（30分など）。この指数関数的に増加する間隔設計により、問題が発生したばかりで最も一時的な変動である可能性が高いときに素早く再試行でき、失敗が続く場合は問題が一時的でない可能性を示す。徐々に間隔を延ばすことで、問題に回復のための時間を多く与えられると同時に、短時間に同じシステムへ大量の再試行リクエストを送って余分な負荷をかけることも避けられる。
もう一つの上級テクニックは、「再試行回数を使い切ったが問題が依然として存在する」ことを、沈黙のまま終わらせるのではなく明確なエスカレーションパスとして設計することだ。具体的には、リトライポリシーをエスカレーションパスの仕組みと組み合わせて使い、再試行の上限を使い切ったら自動的に通知をトリガーし、その期間中の各再試行失敗の具体的なエラーメッセージを添付する。これにより引き継いで対応する人が問題がどこにありそうか一目で分かり、「このタスクは失敗しました」という一言だけを受け取って自分で記録を遡って何が起きたか調べる必要がなくなる。
毎晩外部の為替レートAPIを呼び出し、最新レートをシステムに更新する自動化フローを設計したとする。リトライポリシーがなければ、ある日このAPIがたまたま短時間のメンテナンスで応答に失敗すると、フローはそのまま失敗と判定されて終了し、その日の為替レートは更新されず、翌日まで再試行を待たなければならない。その間丸1日システムは古いレートを使い続けることになる。リトライポリシーを加えると、最初の失敗は2分待って再試行し、それでも失敗すれば10分待って再試行し、3回目も失敗すれば30分待って再試行し、3回とも失敗して初めて本当に失敗と判定して通知を送信する。外部APIの短時間メンテナンスは通常数分から十数分で回復するため、このリトライポリシーによりシステムは3回の再試行以内に更新後のレートを自動的に捉えられる可能性が高く、翌日まで待つ必要も人による介入も不要になる。実務上の要点は、外部システムに依存し、そのシステムがときどき短時間の問題を起こす自動化フローには、間隔を徐々に延ばすリトライポリシーを加えることで、短時間の障害による人的介入の頻度を大幅に減らせることが多いということだ。
リトライポリシー最大の利点は、ほとんどの一時的な失敗を自動的に処理でき、毎回人による介入で再実行する必要がないことで、特に外部システムに依存する自動化フローではこの価値が非常に明確だ。代償は、設計が不適切だと本来すぐに気づかれるべき問題の発見が遅れたり、すでに完全に機能停止している外部システムに不要な再試行リクエストを送り続けたりする可能性があることだ。適するのは、動作が外部システムに依存し、そのシステムがときどき一時的な問題を起こす場合である。適さないのは、失敗の原因が本質的に時間とともに変化しない場合、例えばロジックの誤りやデータ形式のエラーである。要するに、リトライポリシーは一定の遅延時間と計算資源を、ほとんどの一時的な失敗が人による介入なしに自動回復することと交換する仕組みであり、その投資が割に合うかは失敗の原因が本当に一時的で自己回復の可能性があるかにかかっている。