【要約】FastAPI + asyncpg でプロファイリングを用いたパフォーマンス改善 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
株式会社ブレインパッドの開発チームが、生成AIを活用した検索・レコメンドサービス「Rtoaster GenAI」のスケール要件に対応するため、高負荷時のレイテンシ増大という課題に直面した。具体的には以下の問題が発生していた。
- ・高負荷時にリクエストの処理待ちが蓄積し、レイテンシが大幅に増大する。
- ・p(95) が目標値を上回り、エラーが発生し始める。
- ・リクエスト量に応じてスケールするものの、処理能力が追いつかない。
// Approach
開発チームは pyinstrument を導入し、リクエストごとの処理時間を可視化することでボトルネックの特定と修正を行った。以下のステップで改善を実施した。
- ・pyinstrument を FastAPI のミドルウェアとして組み込み、プロファイル結果を JSON で取得する仕組みを構築。
- ・Pydantic のバリデーターが内部で zoneinfo を呼び出し、ファイルシステムをスキャンする問題を特定し、対策を実施。
- ・ミドルウェアでの CORS 検証時に、既に取得済みのデータを再取得している重複アクセスを解消。
- ・BackgroundTasks 内の DLP API 呼び出しにおける await 漏れを修正し、イベントループのブロッキングを解消。
// Result
改善策の適用後、負荷試験において劇的なパフォーマンス向上が確認された。開発チームは目標としていたレイテンシの閾値を大幅に下回る結果を得た。
- ・p(95) および平均レイテンシが、改善前の約 1/4 に短縮。
- ・中央値（med）については、約 1/6 まで短縮。
- ・高負荷時における成功率が目標値をクリアした。
Senior Engineer Insight
> Python の非同期エコシステムでは、ライブラリの内部挙動がボトルネックになるケースが多い。特に Pydantic のような高頻度で呼ばれるバリデーターのコストや、await 忘れによるイベントループのブロッキングは、大規模システムでは致命的だ。推測ではなく、プロファイリングによる「事実」に基づいた改善プロセスは、実戦において極めて重要である。