【要約】観察フラグ運用のログ分離パターン — 未検証ロジックを本番と混ぜない [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
未検証ロジックを本番コードに混入させる際の運用リスク。具体的には以下の課題がある。
- ・本番ログに実験用ログが混入し、解析が困難になる。
- ・観察ロジックのバグや副作用が、本番の意思決定に干渉する。
- ・「フラグがFalseだから安全」という誤認による、予期せぬ挙動の発生。
- ・障害発生時、観察ロジックの関与を切り分けるのに多大な時間を要する。
// Approach
以下の3つのアプローチで、本番環境への影響を遮断する。
1.フラグの分離
- ・
observe_only=True(shadow): 計算とログ出力のみ。 - ・
dry_run=True(dry-run): 注文予定内容の記録のみ。
2.ログの3原則による分離
- ・物理分離:
logs/observe/への出力。 - ・論理分離:
logging.getLogger("observe.xxx")による階層化。 - ・識別:
OBSERVEプレフィックスの付与。 - ・重要設定:
logger.propagate = Falseによる本番ログへの伝播遮断。
3.呼び出し側の設計
- ・観察フックは結果を返さない（fire-and-forget）。
- ・
try-exceptにより、観察側の例外を本番へ伝播させない。
// Result
事故発生時の原因切り分けが劇的に高速化する。
- ・
grep OBSERVEにより、観察ロジックの関与有無を即座に判定可能。 - ・観察ロジックごとの個別ログ確認が可能。
- ・未検証ロジックのバグによる、本番システムの停止リスクを低減。
Senior Engineer Insight
> 極めて実践的かつ防御的な設計である。特に
propagate=False の徹底は、大規模システムにおけるログ汚染を防ぐ上で不可欠な規律だ。単なるコードの分岐に留まらず、ログの物理・論理分離まで踏み込んでいる点が、運用の堅牢性を担保している。ただし、観察フックが同期的に実行される場合、メインスレッドのレイテンシを悪化させる懸念がある。シビアな低レイテンシ環境では、観察処理をキューイングし、別スレッドで非同期処理する構成を検討すべきだ。