上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
失敗した検索を正しくリトライする
自動再試行は、あるエラーに対しては正しい対応ですが、別のエラーに対してはリクエストの無駄です。これを誤ると、苦しんでいるエンドポイントにリクエストが殺到するか、1秒後には成功したはずの検索をあきらめることになります。
再試行する価値のあるエラー
503レスポンスはサービスが一時的に利用できないことを意味し、まさに少し間を置いた再試行が想定している一時的な状態です。自分の側でネットワークがタイムアウトし、レスポンスをまったく受け取れなかった場合も、リクエストが処理されたかどうかわからないため、同じ分類に入ります。
HTTP/1.1 503 Service Unavailable
{
"status": "error",
"error": {"code": "service_unavailable", "message": "Temporarily unavailable, try again shortly"}
}再試行する価値のないエラー
400は、必須パラメーターの欠落や範囲外の座標など、リクエスト自体の形式が正しくないことを意味します。401は認証に失敗したことを意味します。根本的な問題を修正せずにこれらを再試行しても、同じエラーが再び返されるだけです。しかもほとんどの場合、試行のたびにリクエストとしてカウントされるため、不正なリクエストに対する再試行ループは、何も得られないまま割り当てを使い果たすおそれがあります。
試行の間隔を空ける
単発の対話的な検索であれば固定の短い待ち時間で問題ありませんが、失敗した多数の項目を再試行するバッチジョブでは、妥当な上限まで試行間の待ち時間を倍にしていくなど、段階的に間隔を空けるべきです。そうすれば、短い障害が、サービスの復旧と同時に再試行の殺到に変わることを防げます。
429は特別なケース
429は再試行すべき失敗というより、一時停止すべきというシグナルです。固定の短い待ち時間で再試行するのではなく、X-Quota-Resetヘッダーを読み取ってその時刻まで待ってください。リセット前に再試行しても、同じ429が何度も返されるだけだからです。
リクエストのコストを意識する
サーバーに届いた再試行は、成功したかどうかにかかわらず、すべて1リクエストです。一時的なエラーと恒久的なエラーの違いを踏まえた再試行戦略をとれば、1日あたりの割り当てとプリペイドクレジットを、失敗の繰り返しではなく実際の作業に使えます。
「もう一度試す」と「まず修正する」を区別することが、よい再試行戦略の大部分を占めます。エラーのページには、APIが返すすべてのエラーコードと、それぞれが発生する条件が記載されています。