【要約】PCが落ちても朝の放送は出る——リブートタップと成果物マーカーで作る自己復旧パイプライン [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
個人開発者が運用するAIニュース生成パイプラインにおいて、レンダリング中の熱暴走や原因不明の電源断により、定刻のジョブが実行されない問題に直面した。物理的な停止が発生すると、以下の課題が生じる。
- ・ハードウェアが沈黙すると、ソフトウェア側からの復旧操作が一切不可能になる。
- ・ダウン中に予定時刻を過ぎたジョブがスキップされ、パイプラインが停滞する。
- ・従来の「実行履歴（帳簿）方式」では、クラッシュ時に履歴自体が破損するリスクがある。
// Approach
開発者は、ハードウェアとソフトウェアの両面から多層防御を構築することで、物理的な電源断を前提とした自己復旧を実現した。具体的には以下の手法を採用している。
- ・ハードウェア層：リブートタップでAC電源を制御し、UEFIの「Restore on AC Power Loss」設定により通電時の自動起動を可能にする。
- ・ソフトウェア層：ジョブの実行履歴ではなく、成果物（JSONファイル等）の存在を確認する「成果物マーカー」を採用し、起動時に未完了ジョブを検知・実行する。
- ・設計思想：下流ジョブが上流の成果物をポーリングして待機する設計とし、ジョブ間の依存関係を自然に解決する。
// Result
この多層防御の実装により、PCが夜間に停止しても、朝には自動的にジョブが再開され、動画がYouTubeへアップロードされる環境を構築した。導入後の成果は以下の通りである。
- ・復旧速度：AC通電からスケジューラ稼働まで、実測で約2分で完了する。
- ・運用の効率化：人間は朝に動画を確認して公開コマンドを打つだけで済む。
- ・堅牢性の向上：LLMの出力欠落、熱暴走、レンダラーの失敗、ログ喪失といった複数の障害クラスを個別に吸収できる。
Senior Engineer Insight
> 可用性を「コードの堅牢性」だけに求めず、「物理層の制御」まで広げた点が極めて実践的である。特に、実行履歴ではなく成果物の存在を真実とする設計は、分散システムにおける状態管理の定石であり、極めて高い信頼性をもたらす。小規模な個人開発であっても、障害を「防ぐ」のではなく「吸収する」という多層防御の考え方は、大規模なインフラ運用においても共通する重要な原則である。物理的な電源サイクルをソフトウェアの復旧フローに組み込む発想は、現場の泥臭いトラブルを解決する強力な武器となる。