【要約】その「time.sleep(1)」が資金を溶かす - Botを止めないExponential Backoffの実装 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
自動売買Botの開発者が、APIの不安定なレスポンスへの対策を誤ると、深刻な資産損失を招く。開発者は、不適切なリトライ設計によって以下の問題に直面する。
- ・固定間隔のリトライによる、サーバー復旧前の過剰なリクエスト連打。
- ・認証エラー（401）等の、リトライしても解決しない例外への誤った試行。
- ・Thundering Herd問題による、リトライタイミングの集中とサーバーへの再圧迫。
- ・タイムアウト発生時の二重注文による、意図しないポジションの保有。
// Approach
開発者は、Pythonの
tenacityライブラリを活用し、通信状況に応じた高度なリトライ戦略を構築する。具体的には以下の手法を組み合わせる。- ・
wait_exponentialとwait_randomによる、指数バックオフとジッターの実装。 - ・
retry_if_exceptionを用いた、リトライすべき例外（5xx, 429, Timeout等）の厳密な選別。 - ・
Retry-Afterヘッダを尊重するカスタムWaitクラスによる、レート制限への適応。 - ・注文送信時のタイムアウトに対し、建玉API等で状態を確認するフェイルセーフの実装。
// Result
適切な設計を導入した開発者は、システムの可用性と資産保護を高いレベルで両立できる。設計の改善により、以下の成果が得られる。
- ・APIエラーによるBotの停止回避と、相場機会の損失防止。
- ・ジッター導入による、サーバー負荷の分散と安定した通信の確保。
- ・二重注文の防止による、不必要なポジション保有リスクの低減。
- ・
before_sleep_logによる、リトライプロセスの可視化と運用監視性の向上。
Senior Engineer Insight
> 単なるリトライ実装に留まらず、冪等性の担保（二重注文防止）に踏み込んでいる点が極めて実践的である。特に、クライアントID指定ができない国内取引所での「状態確認ポーリング」の推奨は、現場の痛みを理解した深い知見と言える。ただし、リトライ合計時間が全体のタイムアウトを食いつぶさないよう、
stop_after_delayによる制御も併用すべきである。