7. 障害耐性を高めるためのリトライ機構と指数バックオフの実装
一時的な障害による処理の中断と再実行の課題
外部APIのレート制限超過、一時的なネットワークの輻輳、あるいは外部サービスのメンテナンスなどにより、処理が失敗することは日常茶飯事です。この失敗を単に「エラー」として処理を止めてしまうと、ビジネスプロセス全体が停止してしまいます。重要なのは、失敗を「例外」として扱うのではなく、「一時的な障害」として捉え、自動的に回復させる仕組みを組み込むことです。
リトライ戦略の基本概念：失敗を前提とした設計
リトライ機構は、処理を「試行回数」と「待機時間」の組み合わせで制御する仕組みです。単に「失敗したら再実行」とするのではなく、失敗の性質に応じて戦略を使い分ける必要があります。
戦略に応じた実装パターン
最も重要なのは、リトライの戦略を適切に選択することです。
| 戦略 | 仕組み | 適用すべきケース |
|---|---|---|
| 1. 固定間隔リトライ | 一定時間（例：3秒）待って、同じ処理を繰り返す | レート制限が明確で、短時間での回復が見込める場合 |
| 2. 指数バックオフ (Exponential Backoff) | 待機時間を指数関数的に増やす（例：1秒, 2秒, 4秒, 8秒...） | 外部APIのレート制限や、一時的なシステム負荷による障害に最も有効。システムに負荷をかけすぎないよう配慮する |
| 3. 限界回数設定 (Max Attempts) | 最大試行回数を設定し、それを超えたら即座に失敗として処理を中断する | 無限ループを防ぐための最も基本的なガードレール |
バックオフとリトライの組み合わせ（推奨）
実務上最も堅牢なのは、この3つを組み合わせた「指数バックオフ＋最大試行回数制限」です。例えば、「最大5回まで、指数バックオフ（1, 2, 4, 8, 16秒）でリトライし、それでも失敗した場合は、即座に『致命的エラー』として処理を中断し、アラートを発報する」というフローを定義することが重要です。
まとめ：リトライは「保険」ではなく「設計要素」である
リトライ機構は、単なる「保険」として実装するのではなく、ワークフローのコアな「設計要素」として組み込むべきです。どのレイヤー（ネットワーク、API、ビジネスロジック）で障害が発生し得るかを洗い出し、それに対応するリトライ戦略を定義することが、システム全体の堅牢性を高めます。
