ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
プロバイダーの切り替え後にキャッシュ済みの結果を再マッピングする
キャッシュはジオコーディングにおける合理的で一般的な最適化です。同じ住所が繰り返し検索されることが多く、毎回新たな検索に費用を払ったり待ったりする理由はほとんどないからです。しかし、1つのプロバイダーの結果をもとに数か月、数年かけて蓄積したキャッシュは、移行時に特有の問題を生みます。背後のプロバイダーが変わったとき、そのキャッシュデータをすべてどうするのかという問題です。
一般的に最も安全な考え方は、特定のプロバイダーの座標精度、住所の書式の慣習、一致の信頼度に結びついたキャッシュ結果を、新しいプロバイダーが全般的に正確であっても、新しいプロバイダーの結果と同等のものとして黙って扱うべきではないということです。特に座標精度はプロバイダー間で微妙に異なることがあり、キャッシュした緯度と経度を小数点以下数桁まで保存しているアプリケーションは、その数値を最初に生成したプロバイダー固有の精度特性に依存している可能性があります。
実践的な方法をいくつか、徹底度のおおよそ低い順に紹介します。
- キャッシュのエントリーに提供元のプロバイダーを記録する。キャッシュが、どのプロバイダーがその結果を生成したかをまだ記録していない場合は、移行前にそのフィールドを追加します。そうすれば、キャッシュ全体を区別のない1つのまとまりとして扱うのではなく、今後は古いエントリーと新しいエントリーを区別できます
- 旧来のキャッシュエントリーに有効期限を設定する。キャッシュ全体を一度に無効化すると、新しいプロバイダーへのリアルタイムのリクエストが急増することがあります。そうするのではなく、キャッシュですでに使っているTTLに従って古いエントリーが自然に期限切れになるようにし、新しいプロバイダーの新しい結果への移行が徐々に進むようにします
- 重要度の高いキャッシュエントリーを選んで再確認する。主要な事業所や頻繁に使われる配送先住所など、特に重要な住所については、キャッシュが自然に期限切れになるのを待つのではなく、新しいプロバイダーで明示的に再検索する価値があります。微妙な差異が最も目立つのは、こうしたエントリーだからです
特にジオコーディングの結果は、正確な書式や精度がプロバイダー間で異なることがあるため、完全に切り替える前に、実際のキャッシュ済み住所から意味のあるサンプルを取り出して新しいプロバイダーでテストするほうが、合成したテスト住所や手作業で選んだテスト住所でテストするよりも価値があります。実際のキャッシュデータには、特殊なケースも含め、実際の利用パターンが反映されているからです。
My Geocodeの互換ホストは元のプロバイダーと同じフィールド構造でデータを返すため、フィールド名でキャッシュエントリーを読み取って保存するコードは、移行時に構造を変える必要はないはずです。ある住所について、値そのものがプロバイダー間でわずかに異なる可能性があるだけです。すべてのレスポンスに含まれる割り当てヘッダー(X-Quota-UsedやX-Credits-Remainingなど、/docs/rate-limits/に記載)も、キャッシュ無効化の計画に考慮する価値があります。キャッシュミスが急に押し寄せると、そのままリクエスト量の急増につながるため、その波を割り当てに合わせてペース配分することは、小さいながらも移行計画の本当に役立つ要素です。
キャッシュの移行を、プロバイダーの切り替えが稼働すれば自動的に起こる付け足しではなく、それ自体を1つの小さなプロジェクトとして扱うことで、事後に診断するのは事前に計画するよりはるかに難しい、微妙なデータ品質の問題を避けられます。