【要約】同じ「マルチワーカーだと二重に動く」問題を、2つの個人開発サービスで別々に踏んだ話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
個人開発者が、負荷分散のためにプロセス数を2つに増やした際、予期せぬ不具合に直面した。1プロセスでは発生しない、マルチプロセス特有の競合や不整合が原因である。
- ・プロセス間でのDB更新情報の不整合。
- ・同一リソースに対する複数プロセスからの同時アクセス。
- ・リクエスト終了に伴うDB接続の予期せぬ切断。
- ・ロック機構の故障と競合の区別不能による処理停止。
// Approach
開発者は、不具合の根本原因を特定し、分散環境における整合性と信頼性を確保する対策を講じた。設計レベルでの修正と、エラーハンドリングの厳格化を同時に行った。
- ・DBから常に最新の状態を取得する設計への変更。
- ・排他制御のためのロック機構の導入。
- ・バックグラウンド処理用の独立したDB接続の確保。
- ・ロック失敗理由（競合か故障か）の厳密な判別。
// Result
開発者は、一連の対策を通じて、マルチプロセス環境におけるデータの整合性と処理の確実性を向上させた。これにより、リソースの浪費と検知不能な停止を回避した。
- ・二重実行によるリソース（AI API）の浪費を防止。
- ・ロック故障時にエラーとして検知可能な体制を構築。
- ・ローカル環境では見えない、本番特有の不具合を解消。
Senior Engineer Insight
> スケーラビリティ確保のためのマルチプロセス化は不可避だ。しかし、分散システム特有の複雑性が増す。特に「ロックの失敗」を「競合」と同一視する設計は、致命的なサイレント故障を招く。本件は、単なるバグ修正ではなく、分散環境における観測性とエラーハンドリングの重要性を示している。開発環境と本番環境の差異を埋めるための、テスト戦略の再考も求められる。