ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
プロバイダーを切り替えるときに想定しておくべきレート制限の違い
レート制限はプロバイダーによって、許可されるリクエストの数だけでなく、それ以外の面でも異なります。表面上の上限だけを確認する移行では、実際には数値そのものよりも重要な構造上の違いを見落とすことがあります。
移行先または移行元のどのプロバイダーについても、特に確認する価値のある構造上の観点がいくつかあります。
上限が何に対してカウントされるか。APIキーだけで制限するプロバイダーもあれば、IPアドレス、アカウント、またはそれらの組み合わせで制限するプロバイダーもあります。My Geocodeの構造では、無料割り当てをネットワーク単位、つまりIPv4では/24ごと、IPv6では/48ごとにカウントし、同じネットワークから発生するキーなしの利用とキーありの利用の間で共有されます。これは純粋にキー単位でカウントされる上限とは大きく異なるモデルで、企業ネットワークや多数のインスタンスがアドレスブロックを共有するクラウド環境など、共有IP範囲の背後で動作するアプリケーションでは特に重要です。
上限がどのようにリセットされるか。毎日、毎月、ローリングウィンドウはいずれも一般的な方式で、その違いは、一括ジョブのペース配分やトラフィックの急増への対処をどう考えるべきかに影響します。1日の決まった区切りでリセットされる上限は、ローリングウィンドウ方式の上限とは、トラフィックが集中したときの挙動が異なります。
上限の情報がすべてのレスポンスで公開されるか、別途確認が必要か。これによって、アプリケーションが事前に自らペースを調整できるのか、それともリクエストが失敗して初めて上限に達したことに気づくのかが変わります。My Geocodeはこれを直接公開しています。すべてのレスポンスには、X-Quota-Limit、X-Quota-Used、X-Quota-Free-Remaining、X-Quota-Network-Used、X-Credits-Remaining、X-Key-IPs-Used、X-Key-IPs-Limit、X-Quota-Resetがヘッダーとして含まれており、/docs/rate-limits/に記載されています。つまり、再試行やペース配分のロジックは、別のエンドポイントやダッシュボードをポーリングするのではなく、受け取ったばかりのレスポンスから現在の状況を読み取れます。
上限を超えたらどうなるか。プロバイダーはリクエストを完全に停止するのか、応答を遅くするのか、それとも超過分を自動で請求するのか。1日あたりの無料割り当てを超えた後のMy Geocodeのモデルは、1リクエストあたり€0.0001のプリペイドクレジットか、月額€50のUnlimitedキーで、すべてのエンドポイントが同じ料金です。現在のプロバイダーの超過料金やスロットリングの挙動と直接比較する価値があります。トラフィックの急増がその時点でアプリケーションの動作に実際にどう影響するかは、これらによって大きく異なる可能性があるからです。
切り替える前に、現在のプロバイダーに固有のヘッダー名、ステータスコード、数値のしきい値を参照している再試行やバックオフのロジックは、別のプロバイダーのレート制限のシグナルに対してもそのまま動くと考えるのではなく、明示的に書き直しておく価値があります。ほとんどのアプリケーションではわずかなコードですが、意図的に見直さなければ移行中に気づかないうちに壊れるのは、まさにこうした細部です。レート制限のエラーを誤って処理すると、実際のトラフィックの急増を改善するどころか悪化させがちだからです。