【要約】31. 壊れた公開APIからログを集める収集層の設計 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
データ分析のため、コミュニティサイトの非公式APIから特定の属性を持つセッションログを集める際に、APIの挙動が設計を阻害した。サーバー側の仕様が期待通りに動作せず、以下の問題に直面した。
- ・サーバー側のフィルタが故障し、属性指定による絞り込みが機能しない。
- ・ページングが一定数で400エラーとなり、全件走査が不可能である。
- ・素のHTTPクライアントがCDNのレート制限により遮断される。
- ・Playwrightの並列化時に、スレッド間でのリソース競合が発生する。
// Approach
サーバー側の挙動を「信頼できないもの」と定義し、クライアント側で制御を完結させる設計を採用した。具体的には以下の4つの手法を導入した。
- ・スノーボール収集: 履歴から関連アカウントを辿るグラフ探索で、対象を芋づる式に特定する。
- ・ステータス別制御: 400は打ち切り、429等はリトライと、HTTPコードで挙動を分ける。
- ・取得口の一本化: ブラウザの
fetch()を使い、確立済みセッションでリクエストを統一する。 - ・スレッド分離:
threading.local()を用い、スレッドごとにブラウザを管理する。
// Result
堅牢な収集層を構築したことで、不安定なAPI環境下でも大量のデータ取得を実現した。
- ・延べ27,101セッション分のログ収集に成功した。
- ・計6つのデータセットを構築できた。
- ・取得経路を一本化したことで、遮断リスクを最小化した。
Senior Engineer Insight
> 外部APIの不備を「壊れている前提」で設計する姿勢は、実戦において極めて重要である。サーバーの挙動を盲信せず、クライアント側で状態を補完する防御的設計は、システムの堅牢性を高める。特に、リソースの所有権をスレッド単位で明確にする設計は、並列処理の複雑性を制御する上で極めて実践的である。スケーラビリティを確保しつつ、エラー耐性を高めるための優れた設計パターンといえる。