【要約】姉妹サービスで11時間続いた429を見て、まだ起きていない側を先に直した話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、姉妹サービスの障害から自サービスの潜在的なリスクを特定した。
- ・DevPickでLLMの利用上限に達した際、429エラーを無視してリクエストを継続した。
- ・11時間以上にわたり、無駄なAPIリクエストを送り続ける状態が続いた。
- ・AgentPickも共通のLLM呼び出し処理を使用しており、同様の障害が懸念された。
// Approach
開発者が、複数の呼び出し経路と複数プロセスに対応するため、以下の設計変更を行った。
- ・共通処理の入口にバックオフ判定を実装した。これにより、ジョブやCLIなど、多様な経路での実装漏れを防いだ。
- ・回復時刻をファイルに記録した。プロセスごとのメモリではなく、共有ファイルを用いることで、複数プロセス間での状態共有を実現した。
- ・テスト環境の分離を行った。テスト実行時にファイルパスを一時ディレクトリへ差し替え、テスト間の副作用を排除した。
// Result
開発者が、AgentPickにおいてレート制限に対する堅牢な仕組みを導入した。
- ・全ての呼び出し経路で、レート制限時に適切にリクエストを停止できるようになった。
- ・複数プロセス運用下でも、一方が検知した制限情報を即座に共有し、無駄な通信を抑制できる。
- ・テストの独立性が確保され、実行順序に依存する不安定なテストを防ぐことが可能になった。
Senior Engineer Insight
> 共通部品へのロジック集約は、実装漏れを防ぐ上で極めて合理的だ。しかし、単一プロセスを前提とした設計は、分散環境下で容易に破綻する。本件のように、状態共有の手段を適切に選択することが不可欠だ。また、テストにおける副作用の排除も、継続的な品質維持には欠かせない視点である。