有効期限のないAPIキーの問題点
何年も前に発行され、一度もローテーションされず、今も有効なキーは、便利なものではありません。何年も誰も実際に確認していない負債です。
一括リクエストを呼び出し単位ではなく項目単位で数える理由
1回の呼び出しで1,000件の住所を受け付け、割り当てに対しては1リクエストとしかカウントしないバッチエンドポイントは、料金ページでは気前よく見えます。しかし気前がよいわけではありません。それはやがてキャパシティの問題になる端数処理の誤差です。その呼び出しの背後にある実際の処理、つまり1,000件の個別の検索は、1つの封筒で届いたからといって減るわけではないからです。
私たちは一括リクエストとバッチリクエストを、他のすべてと同じようにカウントします。1項目につき1リクエストです。1回のバッチ呼び出しで1,000件の住所を送れば、エンドポイントを1,000回別々に呼び出した場合とまったく同じように、無料枠またはプリペイドクレジットに対して1,000リクエストとしてカウントされます。往復回数の削減や接続のオーバーヘッドの軽減といったバッチ処理の利便性は現実のものであり、利用する価値があります。まとめて依頼したからといって、検索そのもののコストが変わるわけではありません。
バッチ呼び出しを不自然に安く設定すると、奇妙なゆがみが生じます。バッチ処理がワークフローに本当に合っているからではなく、純粋にお金を節約するために、大きなバッチ呼び出しを中心に連携を組み直すことが得をする仕組みになってしまいます。また、「リクエスト」がもはや一貫した作業単位を意味しなくなるため、外部からプロバイダーの実際のキャパシティ計画を推し量ることも難しくなります。1日あたりのリクエスト数でプロバイダーを比較するお客様は、あるプロバイダーのリクエストには密かに1,000件の検索が含まれ、別のプロバイダーのリクエストには含まれていない場合、公平に比較することができません。
件数ベースのカウントは、割り当てヘッダーの意味を保つことにもつながります。すべてのレスポンスには使用量と残量が含まれていますが、その数値が意味を持つのは、リクエストの形に関係なく1件のリクエストが1件として数えられる場合だけです。1,000件のバッチがひっそりと1単位しか消費しないのであれば、これらのヘッダーは実際の消費量についてほとんど何も教えてくれません。そして、バッチを使わないはるかに大きな利用パターンが予想外の制限に達したときに初めて、本当の数値を知ることになります。
公平性の観点もあります。個別に呼び出しを送るお客様とバッチを送るお客様は、同じ合計金額で同じ合計量の作業を当社に依頼しています。リクエストがまとめられているというだけでバッチのお客様の1件あたりの料金を安くすれば、個別に呼び出すお客様が、自分では負荷をかけていないインフラの費用を実質的に肩代わりすることになります。どちらのお客様にも1件あたり同じ料金を請求することで、価格は作業のまとめ方ではなく作業そのものに結びついたままになります。
だからといって、バッチ処理が無意味になるわけではありません。既知の大量の検索を1回のラウンドトリップで送るには、今でもバッチ処理が正しい方法です。接続数が減りオーバーヘッドが少なくなることはお客様側にとって実際の効率向上になるため、当社はバッチ処理をサポートしています。ただし、バッチ処理は、リクエストのどちら側においても、検索の実際のコストを変えるべきではありません。1,000件の検索は、午後いっぱいかけて1件ずつ届いても、1回の呼び出しで一度に届いても、1,000件の検索です。