【要約】監視ソースをYAMLで管理し、クラッシュしても再開できるキューを作る #3 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がニュース収集とLLM分析を自動化する際、外部サービスの停止やシステムクラッシュが課題となる。具体的には以下の問題に直面する。
- ・LLMの応答エラーによるパイプライン全体の停止。
- ・システムクラッシュ発生時の、処理中データの整合性喪失。
- ・監視対象ソースの追加に伴う、コード変更のコスト。
// Approach
収集フェーズと分析フェーズを、SQLiteを介して疎結合にする設計を採用した。以下の手法で解決を図っている。
- ・YAMLによる宣言的設定：sources.yamlで監視対象を定義し、コード変更なしでソース追加を可能にする。
- ・DBによる状態管理：収集した新着記事をpending状態でSQLiteに保存し、分析結果をanalyzedやskippedで更新する。
- ・フェーズの分離：収集はLLMの状態に依存せず完走させ、分析はDBのpending件数に基づいて実行する。
- ・インターフェースの固定：LLMクライアントの呼び出しを抽象化し、基盤の変更を容易にする。
// Result
設計の堅牢性が、実際のOSクラッシュ（BSOD）によって実証された。具体的な成果は以下の通りである。
- ・クラッシュ後のデータ整合性：SQLiteの1件ごとのコミットにより、未処理分（219件）がpendingとして無傷で保持された。
- ・自動リトライの実現：LLMエラー時はpendingのまま残るため、次回実行時に自動で再試行される。
- ・基盤移行の容易性：LLM実行基盤をllama.cppへ移行したが、パイプライン側の変更はimport文1行のみで完了した。
Senior Engineer Insight
> 本設計の真価は、エラーを「防ぐ」のではなく「許容する」設計思想にある。収集と分析をDBを介して疎結合にしたことで、LLMの不安定さやOSのクラッシュといった、制御不能な事象に対する耐性を確保している。特に、インターフェース（契約）を先に定義し、実装を差し替え可能にした点は、技術スタックの変遷が激しいLLM領域において極めて実戦的な判断だ。小規模な個人開発であっても、この「状態管理による再開可能性」の確保は、運用の信頼性を担保する上で不可欠な要素である。