【要約】APIのクォータ上限を1000だと思い込んで1週間溶かした話 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が、米国株スクリーニングシステムのデータ取得率が約56%で停滞する問題に直面した。原因はAPIクォータの仕様に関する複数の誤認であった。
- ・リソース単位の誤認：制限を「1日のリクエスト回数」と誤解したが、実際は「7日間の銘柄数」であった。
- ・上限値の誤認：ログの表示文字列を上限値と判断したが、実際の上限はそれより大幅に低かった。
- ・構造的欠陥：既存銘柄の更新が窓内のカウントをリセットし続け、新規銘柄の取得枠を奪う状態に陥っていた。
// Approach
開発者は、ログによる推測を止め、APIが提供する公式な情報を直接取得する手法を採用した。
- ・権威あるAPIの利用：
get_history_kl_quota(get_detail=True)を実行し、現在の使用量と窓の詳細情報を取得した。 - ・真実の確定：ログの文字列ではなく、APIの返り値から上限が300銘柄であることを特定した。
- ・代理指標の排除：キャッシュの更新時刻などの不確実な指標を捨て、API側の実態に基づいた分析を行った。
// Result
開発者は、APIの仕様に基づいた正確なリソース状況を把握することに成功した。
- ・原因の特定：上限が300銘柄であること、および既存銘柄の更新が新規取得を阻害する構造を解明した。
- ・設計の教訓：リソース単位の確定、ログの信頼性、権威ある情報の優先順位といった実戦的な知見を得た。
Senior Engineer Insight
> API連携において、ログや代理指標を仕様と誤認することは致命的な設計ミスを招く。特にローリングウィンドウ型の制限は、リクエスト回数ではなく対象の重複が鍵となる。設計ミスがシステムをデッドロック状態に陥れるリスクを理解すべきだ。現場では、推測を排除し、APIが提供する「信頼できる唯一の情報源」を即座に確認する姿勢が不可欠である。