【要約】バックテストがタイムアウトする前に — 長時間実行を制御するための実行設計 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
自動売買のバックテスト等の長時間ジョブは、外部データの遅延や対象期間の拡大により、想定外のタイムアウトを引き起こす。従来の「落ちないように作る」設計では、強制終了時にデータが破損したり、最初からやり直しになったりするため、運用コストとデータ損失のリスクが極めて高い。
// Approach
「中断可能・再開可能・観測可能」の3要素を軸に設計する。具体的には、内側にSoft Deadlineを設けてGraceful Stopを実現し、1 symbol単位のJSONL形式で進捗を保存する。また、外部通知による進捗可視化と、systemdのOnFailureを用いた自動クリーンアップを組み合わせる。
// Result
外部APIの遅延により実行時間が倍増した際も、チェックポイントにより未処理分のみを再実行することで、データロスゼロでの復旧を実現した。タイムアウトを「事故」ではなく「制御可能な運用イベント」へと昇華させている。
Senior Engineer Insight
>
設計思想が極めて実戦的である。「落ちない」ことへの執着を捨て、「落ちても困らない」というDesign for Failureの原則に則っている点が評価できる。特に、Hard/Soft Timeoutの分離や、JSONL形式によるI/Oの堅牢性確保は、大規模なデータ処理において極めて重要な勘所だ。また、systemdのOnFailureを用いたクリーンアップまで設計に組み込んでおり、アプリケーション層とインフラ層の両面から信頼性を担保している。この設計パターンは、バックテストに限らず、あらゆる長時間実行ジョブの標準モデルとなり得る。