【要約】プロバイダー単位のロックでブラウザ自動化の競合を防ぐ - 実装手順 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
自動化エンジニアが、スケジュール実行によるジョブの重複に直面した際、ブラウザ操作の競合が発生する。同一のログイン済みブラウザを複数のジョブが操作すると、フォームやタブの奪い合いが生じる。具体的には以下の問題が発生する。
- ・同一セッションへの同時アクセスによる、ブラウザ操作の不安定化。
- ・プロセスが正常終了しても、目的の成果物が得られたか判断できない不透明性。
- ・エラー発生時にどこまで完了したか不明で、再実行時に処理が重複するリスク。
// Approach
開発者は、プロバイダー単位のロック取得と、工程ごとの状態をJSONで管理する手法を採用した。これにより、競合の回避と、機械的な再開を実現する。具体的な手法は以下の通りである。
- ・プロバイダー単位のロックをtry-finallyで管理し、操作の競合を物理的に防ぐ。
- ・完了条件を「生成」「品質」「操作」「結果」の4段階に定義し、状態を構造化する。
- ・各工程の成果物をJSONとして出力し、次工程が機械的に判断できる契約を設ける。
- ・供給工程と公開工程を分離し、在庫管理を通じて処理の安定性を確保する。
// Result
この設計により、運用者はシステムの停止やエラー発生時でも、正確な地点から処理を再開できるようになった。単なるタスクの起動ではなく、実効的な成果に基づいた運用が可能となる。
- ・再起動後もファイル成果物から再開し、外部操作の重複を確実に防ぐ。
- ・「実URLの確認」を成功指標とすることで、実効的な目標達成を正確に監視できる。
- ・認証切れや画像生成失敗などの例外状態を構造化し、無駄な再試行を抑制する。
Senior Engineer Insight
> 本記事の価値は、単なるエラーハンドリングではなく「状態の契約」に主眼を置いている点にある。分散環境における冪等性の確保は、スケーラビリティを支える要だ。特に、プロセス終了と目的達成を分離し、JSONで状態を明示する設計は、運用コストを劇的に下げる。監視指標を「タスク起動数」ではなく「実URL確認数」に置く視点も、実戦的で極めて正しい。堅牢な自動化システムを構築する上で、極めて示唆に富む内容である。