上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
大量の一括処理ジョブに適切なタイムアウトを設定する
単一の住所検索では問題なく機能するタイムアウト値でも、数千件の項目を含む一括リクエストでは、サーバーがすべての処理を終えるずっと前にリクエストを打ち切ってしまいます。十分な時間があればリクエストは完了していたにもかかわらず、失敗のように見えてしまうのです。
一括リクエストにより多くの時間が必要な理由
一括配列の各項目はそれ自体が1回の検索です。そのため、2,000件の項目を含むリクエストは、こちら側からは1回のHTTP呼び出しであっても、単一の検索のおよそ2,000倍の処理を伴います。単一の住所であれば妥当な1秒から2秒のタイムアウトでは、その規模のリクエストにはまったく足りません。
バッチに合わせてタイムアウトを調整する
コードが送信するすべてのリクエストに、大小を問わず1つの固定値を使うのではなく、送信する配列のサイズに比例してクライアントのタイムアウトを設定し、通常のばらつきに備えてある程度の余裕を持たせてください。
timeout_seconds = max(5, item_count * 0.05)これは実際に観察した挙動に合わせて調整するための出発点であり、確定的なものとして扱うべき固定の数値ではありません。項目ごとの実際の処理時間は、公表された保証ではないためです。
1つの巨大なリクエストより小さなチャンクを優先する
ますます大きくなる単一のリクエストに対応するためにタイムアウト値をどんどん引き上げるのではなく、非常に大きなジョブを、それぞれ数百件から数千件の項目からなるチャンクに分割してください。チャンクが小さければ、タイムアウトは短く予測しやすくなり、途中で失敗してもジョブ全体ではなく現在のチャンクだけを失うことになります。
実際にタイムアウトが発生した場合の対処
こちら側でリクエストがタイムアウトした場合、サーバーが実際に処理を完了したかどうかはわからないことがあります。元のリクエストが完了していた場合に割り当てを二重に消費するおそれがあるため、同じチャンクをやみくもに再送信するのではなく、直近の成功した呼び出しの割り当てヘッダーを確認して、タイムアウトしたチャンクが処理された可能性が高いかどうかを見積もり、慎重に再送信してください。
タイムアウトの設定はコストに影響しません
タイムアウトは、どれだけ待つつもりがあるかという、純粋にクライアント側の設定です。クライアントが最後まで待ったか途中であきらめたかにかかわらず、リクエストのコストには影響せず、処理された項目1件につき1リクエストのままです。
タイムアウトをバッチのサイズに合わせ、1つの非常に大きなリクエストよりも複数の小さなチャンクを優先することで、大規模なジョブは信頼性が高く、問題が起きても簡単に再開できるものになります。大規模なジョブのチャンク分割と割り当ての戦略については、レート制限のドキュメントで詳しく説明しています。