【要約】自動投稿botが同じツイートを2回投げかけた話 — YAML重複keyとlast-write-winsの罠 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
自動投稿botの運用者が、既に投稿済みのコンテンツが再度「投稿待ち」として通知される問題に直面した。設定ファイルである
content-manifest.yamlの管理において、以下の技術的課題が発生した。- ・原因: YAMLファイル内に、同一のキーを持つエントリが複数存在していた。
- ・挙動: PyYAMLの
safe_loadは、重複キーがある場合にエラーを出さず、後の値で上書きする。 - ・結果: 既投稿を示す
status: publishedが、後続のstatus: readyによってメモリ上で上書きされた。 - ・リスク: プラットフォームによっては、同一内容の重複投稿が発生し、サービスの信用を損なう恐れがある。
// Approach
運用者は、重複したエントリを特定・削除するとともに、再発防止策を講じることで問題を解決した。具体的には、以下のステップで対応を行った。
- ・現状把握:
grepを用いてファイル内の重複キーを特定した。 - ・修正: 重複していた古いエントリを手動で削除し、一意な状態に戻した。
- ・検知: Pythonの
reモジュールとCounterを用いた、重複キー検出スクリプトを作成した。 - ・再発防止策:
1.投稿成功時にステータスを書き換える際、古いエントリを物理的に削除する。
2.APIレベルでの重複チェックを継続し、二重投稿を最終防衛ラインで阻止する。
3.月次の監査スクリプトとして、重複キー検出コマンドを組み込む。
// Result
重複キーの検出と削除により、マニフェストファイル内の全291キーがユニークな状態に復旧した。この対応により、以下の成果が得られた。
- ・検知精度: 作成したPythonスクリプトにより、重複の有無を即座に判定可能となった。
- ・運用の安全性: 投稿プロセスに「ステータス更新＋古いエントリの削除」を組み込み、不整合を構造的に防ぐ設計とした。
- ・防御層の強化: 設定ファイルの不備を前提とした、APIレベルでの重複チェックという多層防御の重要性が再確認された。
Senior Engineer Insight
> 設定ファイルを単一のYAMLに集約する設計は、管理コストを下げる反面、整合性破壊の影響が甚大になる。PyYAMLのような「静かに失敗する」ライブラリを使用する場合、パース後のデータ構造だけでなく、パース前のファイル構造に対するバリデーションが不可欠だ。大規模運用では、設定の変更を伴うプロセスに、スキーマ検証や重複チェックを組み込んだCI/CD的なアプローチを導入すべきである。