3つのAPIに対する3つのスリープ間隔
4月に3つのディレクトリサイト向けにETLパイプラインを構築しました。各サイトは、Steam、GitHub、HuggingFaceという異なるAPIを使用しています。
それぞれに対してスリープ間隔を設定する必要がありました。数値、失敗のパターン、エラーハンドリングはすべて異なります。私が採用している設定とその理由を以下に示します。
Steam: 250msのスリープ
Steamのドキュメントはレート制限について曖昧です。コミュニティのデータによると、1つのIPにつき5分間に約200リクエストが目安とされています。つまり、1.5秒の間隔を空ければ安全だということです。
しかし、私は代わりに250msを使用しています。私の夜間ジョブが処理するゲームのエントリはわずか60件です。250msの場合、合計のスリープ時間は15秒です。1.5秒の場合、90秒になってしまいます。複数のサイトを処理する場合、時間の節約は重要です。
Steamがエラーを返しても、ジョブは停止しません。エラーをログに記録し、次のアイテムに進みます。データは翌晩に更新されます。
GitHub: 100msのスリープ
GitHubは非常に明確です。認証されていないユーザーは1時間あたり60リクエスト、トークンを持つユーザーは1時間あたり5,000リクエスト可能です。
私は礼儀（politeness）としての措置として100msのスリープを入れています。レート制限に関しては、トークンが大部分を担っています。私のパイプラインは検索APIではなく、コアのREST APIを使用しているため、より高い制限値を利用できます。
HuggingFace: スリープなし
数週間にわたる夜間実行でも、レート制限に達したことはありません。Registry APIは、私のようなバッチツール向けに設計されています。
一度に最大100個のモデルを取得します。認証トークンを使用して制限をさらに引き上げています。100個のモデルであれば、スリープなしが最もシンプルな解決策です。
まとめ表:
• Steam: 250msのスリープ。非致命的なエラー。 • GitHub: 100msのスリープ。非致命的なエラー。 • HuggingFace: スリープなし。非致命的なエラー。
スリープ間隔はあくまで推測に基づいたものです。本当の防御策は、エラーをどのように処理するかです。すべてのAPIコールにはtry/catchブロックを使用しています。コールが失敗した場合、システムはクラッシュする代わりにフォールバック用の行を書き込みます。
スリープ間隔は制限に達する頻度を制御し、エラーハンドリングは制限に達したときに何が起こるかを制御します。
オプションの学習コミュニティ: https://t.me/GyaanSetuAi