【要約】APIを大量に叩いて理解する非同期Memory Backend [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が非同期システムの設計を理解する際、構成図だけでは各コンポーネント間の「状態のズレ」を把握できない。特にAI Agentのメモリ管理において、以下の課題が生じる。
- ・APIの成功と検索可能状態の乖離
- ・後続処理（Worker）の停止による影響範囲の不明確さ
- ・外部DB（VectorDB）障害時のデータ整合性確保
// Approach
著者はOutbox Patternを採用し、APIの成功と検索インデックスの更新を分離する構成を構築した。大量のデータを投入して、各レイヤーの責務を観察する。
- ・MySQLに本体とOutboxイベントを同一トランザクションで保存
- ・Redis Queueを処理候補の通知レイヤーとして利用
- ・WorkerがMySQLのイベントをclaimしてVectorDBへ反映
- ・MySQLを状態の正本として管理
// Result
実験を通じて、各コンポーネントが独立して動作する様子を定量的に示した。これにより、障害時でもデータが失われない堅牢性が証明された。
- ・Worker停止時もAPIは正常に動作し、MySQLにデータを保持
- ・VectorDB停止時もretry_countにより失敗を追跡可能
- ・APIの成功は「保存」であり「検索可能」ではないことを実証
Senior Engineer Insight
> Outbox Patternの採用は、高負荷・高可用性が求められる現場では定石だ。APIのレスポンス性能と、検索インデックスの反映遅延を切り離せる点は極めて重要である。特に、Redisを単なる通知手段とし、MySQLを状態の正本とする設計は、重複配送への耐性を高める。ただし、結果整合性に伴う「検索できない時間」をアプリケーション層でどう許容するかが、実運用上の鍵となるだろう。