上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
Webhookを使わずに大規模な一括処理ジョブのポーリングを設定する
一部のAPIは、大規模なバッチに対してジョブIDを返し、バックグラウンドで処理している間にポーリングするかWebhookを待つことを求めます。このAPIはそのような仕組みではありません。一括リクエストは大小にかかわらず、すべて同じ呼び出しの中で同期的に応答されます。このことは、非常に大規模なジョブの実行方法についての考え方を変えます。
キューではなくチャンク分割
1つの巨大な配列を送信して待つのではなく、大規模なジョブを、それぞれ数百件から数千件の項目からなる固定サイズのチャンクに分割し、通常の一括POSTリクエストとして順番に送信してください。各呼び出しはすぐに結果を返すため、ポーリングすべきジョブのステータスはなく、次に送るチャンクがあるだけです。
POST /v1/forward
Content-Type: application/json
["address 1", "address 2", "... up to a few hundred items"]ここでいう「ポーリング」の実際の意味
この構成でポーリングに最も近いのは、ジョブのステータスを確認することではなく、チャンクの合間に自分の割り当てヘッダーを確認することです。各チャンクが完了するたびにX-Quota-Free-RemainingとX-Credits-Remainingを読み取り、続行するのに十分なプリペイドクレジットがないまま1日あたりの無料枠を超えそうな場合は、ジョブを一時停止または中止してください。
X-Quota-Free-Remaining: 340
X-Credits-Remaining: 12.50シンプルな実行スクリプトを作る
チャンクをループで順に処理し、それぞれを送信し、レスポンスのヘッダーを確認して、その内容に応じて続行するか一時停止するかを決める小さなスクリプトがあれば、ここでの大規模なバッチジョブには十分です。送信したばかりのチャンクに、要求したものがすでにすべて含まれているため、呼び出すべき別のジョブステータス用エンドポイントはありません。
一時停止からの再開
これまでに正常に処理したチャンクのインデックスを記録しておいてください。そうすれば、割り当てのリセットやクレジットのチャージのために一時停止した場合でも、以前のチャンクを再処理してリクエストを二重に消費することなく、中断したところから正確に再開できます。
コスト
コストはどちらの方法でも同じで、ジョブ全体を通じて項目1件につき1リクエストです。チャンク分割の手法で変わるのはジョブの管理方法だけで、合計で使うリクエスト数は変わりません。
ここには存在しない非同期ジョブの仕組みを探すのではなく、大規模なジョブを通常の同期チャンクの連続として扱うことで、全体をシンプルに保てます。このパターンを支える割り当てヘッダーについては、レート制限のドキュメントで説明しています。