【要約】Python のグローバル初期化を「同一プロセスで一度だけ成功する」形にする [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
PythonでWebアプリやCLIを開発するエンジニアが、グローバルな副作用を持つ初期化処理の二重実行という問題に直面する。開発が進むにつれ、初期化関数は意図せず複数の経路から呼び出されるようになる。
- ・呼び出し経路の増大：FastAPIのlifespan、CLI、pytest、workerなど、多様な場所から呼ばれる。
- ・check-then-act競合：フラグ判定と更新の間に他スレッドが割り込み、二重初期化が発生する。
- ・GILの限界：GILはbytecode単位の実行を保証するが、判定と更新の原子性は保証しない。
// Approach
開発者は、threading.Lockを用いて判定・初期化・フラグ更新を一つのアトミックな区間にまとめる手法を採用する。これにより、同一プロセス内の複数スレッドからの同時呼び出しを安全に制御する。
- ・Lockによる保護：判定からフラグ更新までをwith _INIT_LOCK:内で完結させ、二重実行を防ぐ。
- ・成功時のみフラグ更新：初期化が成功したときのみ_INITIALIZEDをTrueとし、失敗時は再試行可能にする。
- ・Ownershipの定義：グローバル設定の責任境界を明確にし、別経路からの上書きを防ぐ設計を行う。
// Result
この手法により、スレッドセーフな初期化を実現したい開発者は、二重初期化によるエラーや警告を回避できる。実装の堅牢性と運用・テストの柔軟性が向上する。
- ・堅牢性の向上：スレッド競合による二重初期化や、OpenTelemetryの警告ログを回避できる。
- ・運用・テストの改善：依存関係不足時の再試行が可能になり、テスト用のリセット関数も容易に実装できる。
- ・設計の明確化：Ownershipの概念により、アプリ全体の初期化フローが整理される。
Senior Engineer Insight
> Observability基盤の導入において、このパターンは必須と言える。特に、GILに依存した「なんとなく安全」という勘違いは、free-threaded Pythonの普及により致命的なバグを招く。単なるLockの導入だけでなく、「成功時のみフラグを立てる」という失敗への考慮や、Ownershipの設計まで踏み込んでいる点が実戦的だ。マルチプロセス環境では無効であることを理解し、プロセス間同期が必要な場合は別途設計すべきである。