ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
2つのプロバイダーを並行運用するためのチェックリスト
2つのプロバイダーを同時に運用するのは、通常は移行期間中の意図的かつ一時的な状態であり、恒久的なアーキテクチャではありません。それでも、コードベースのあちこちに条件分岐が散らばって混乱した状態にならないよう、十分な構造が必要です。チェックリストがあれば、この段階を短く保ち、その目的を明確にしておけます。
2つ目のプロバイダーに実際のトラフィックを送り始める前に:
- 両方のプロバイダーのレスポンス形式が共通の内部データ構造にマッピングされていることを確認し、どちらのプロバイダーが実際にリクエストに応答したかに関係なく、アプリケーションのコードが1つの正規化された形式から読み取れるようにします
- 振り分けのロジックを事前に決めておきます:トラフィックの割合、特定のエンドポイント、特定の顧客セグメント、または2つ目のプロバイダーを呼び出すものの結果はログに記録するだけで使用しないシャドーモードなどです
- どのリクエストをどのプロバイダーが処理したかを後から判別できるよう、ログやタグ付けを分けて設定します。問題が起きて、まずどこを調べるべきかを知る必要があるときに、これが非常に重要になります
両方のプロバイダーが稼働している間:
- 2つのプロバイダーのエラー率と応答時間を、最初に一度だけでなく定期的に比較します。挙動は数日から数週間かけて変化することがあり、最初の1回のテストではそれを見逃してしまうからです
- 同じ入力に対する2つのプロバイダーの実際の結果の食い違いに注意し、どちらか一方が単純に正しいと決めつけるのではなく、結果が一致しない場合の対応について明確な判断プロセスを用意しておきます
- 2つのプロバイダー間で明らかに挙動が異なるリクエストのパターンを継続的に記録しておきます。それこそが、旧プロバイダーを廃止する前にさらに徹底的にテストすべきケースだからです
元のプロバイダーを廃止する前に:
- 旧プロバイダーを呼び出す可能性のあるすべてのコードパスが、一般的なケースだけでなく、実際に新しいプロバイダーに対して実行されたことを確認します
- 旧プロバイダーが常に利用可能であることを前提としたハードコードされたフォールバックのロジックがないか確認します。並行運用の期間には、誰も削除を覚えていないフォールバックのコードが残ることがあるからです
- 並行運用の期間をいつまでもずるずると続けるのではなく、旧プロバイダーを停止する具体的な日付を決めます。終わりの決まっていない移行は、実際には決して終わらない傾向があるからです
My Geocodeの互換ホストは、この作業の前半であるレスポンス形式の正規化を、移行元のプロバイダーに対応するホストがすでにある場合にはほぼ不要にするために作られています。形式は元のプロバイダーとまったく同じままなので、既存の正規化のコード(すでにある場合)も変更なしでそのまま動作します。17個の互換ホストの一覧は/compatibility/にあります。また、すべてのリクエストにはX-Quota-Limit、X-Quota-Used、X-Quota-Free-Remainingなどの割り当てヘッダーが付いており、/docs/rate-limits/で説明しています。これらは、どのプロバイダーを2つ目として評価している場合でも、上記の比較用ログの手順に役立ちます。
うまく進めた並行運用の期間は、短く、十分に計測され、予定した日に終わります。うまくいかない場合は、恒久的で分かりにくい仕組みとして残ってしまいます。その違いは、時間に追われる中でもこのようなチェックリストを省略せずに守れるかどうかに、ほぼすべてかかっています。