ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
移行後の最初の1週間：注視すべきこと
移行が本番稼働してから最初の1週間は、テストでカバーした範囲と実際の本番トラフィックとの差が表れやすい時期です。テストは、どれほど徹底していても有限のシナリオを抽出したものにすぎません。1週間分の実際のトラフィックは、テスト計画ではほとんど完全には想定できない、実際の利用のロングテールを明らかにします。
ほとんどのチームがすでに確認している一般的なエラー率のダッシュボード以外に、最初の1週間に注意深く見ておく価値のある具体的な項目をいくつか紹介します。
テストしようと思わなかったリクエストのパターン。実際のユーザーは、タイプミスや珍しい書式、テストデータではカバーしきれていない可能性のある地域ごとの慣習を含む住所を入力します。特に「結果が見つかりません」というレスポンスが、移行前のベースラインと比べて増えていないかを見ることで、きれいなテストデータでは見落とされていた、プロバイダー間の住所の書式や照合の違いが浮かび上がることがあります。
実際の見積もりに対する割り当ての消費量。移行前に必要な割り当てを見積もっていた場合、最初の1週間はその見積もりが現実と向き合う時期です。/docs/rate-limits/で説明しているX-Quota-UsedヘッダーとX-Quota-Free-Remainingヘッダーを、予測した1日の利用量と照らし合わせれば、長期的に特定の料金プランに決める前に、見積もりが近かったのか調整が必要なのかをすぐに把握できます。
平均だけでなく、応答時間の分布。問題なさそうに見える平均応答時間の裏に、実際の同時負荷の下でしか現れない、小さいながらも無視できない遅いリクエストの裾野が隠れていることがあります。限られたテスト環境では、これを正確に再現できることはめったにありません。
今もひそかに旧プロバイダーを参照しているコードパス。移行では、呼び出し箇所を見落とすことがあります。特に、あまり使われない機能や、まれにしか実行されないバックグラウンドジョブの中にあるものです。最初の1週間は、その見落としが自然に表面化することが多い時期で、たいていは積極的に探した結果ではなく、サポートチケットや予期しないログエントリーを通じて見つかります。
旧プロバイダーと新プロバイダーの結果の間でずれていくキャッシュデータ。移行計画に、ほかの記事で取り上げたキャッシュの扱い方(エントリーに提供元のプロバイダーのタグを付ける、古いエントリーを自然に期限切れにするなど)が含まれていた場合、最初の1週間は、それが設計どおりに動いていると思い込むのではなく、実際に確認する価値のある時期です。
この最初の1週間に、関連するダッシュボードとヘッダーを確認するだけの15分程度でもよいので、短い日次チェックの時間を決めておけば、問題がサポートチケットとして表面化するのを待つよりもはるかに早く、移行で見落とされたかもしれないことのほとんどを発見できます。最初の1週間に大きな問題がなければ、ほとんどのチームは通常の監視ペースに戻して問題ありません。その期間を、テストではなく実際のトラフィックだけが明らかにできる違いを見つけるために使ったことになるからです。
テストで見落とされていた何かが実際に見つかった場合、プレッシャーの中で即興で考えるのではなく、移行前からロールバック計画を用意しておくことが、つまずきのある最初の1週間を本当にひどい1週間にしないための鍵です。