ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
何かを移行する前にロールバックを計画する
ロールバック計画は、うまく準備できていれば誰も使う必要のない移行の一部です。だからこそ、時間に余裕がないときには省かれがちです。しかし省くのは誤りです。ロールバックが必要になったのに用意がなかった場合のコストは、使われずに終わる計画を準備するコストよりもはるかに大きいからです。
よいロールバック計画の前提は、事前にどれほど入念にテストしても、新しいプロバイダーは少なくとも1つの点で、予想しなかった形で以前のプロバイダーと異なる動作をするということです。これは悲観論ではなく、外部システムとの連携が一般にどう進むかを率直に表したものにすぎません。テストですべてを見つけられたという期待ではなく、この前提に基づいて計画を立てるほうが、よりよい計画になります。
位置データプロバイダーの切り替えにおけるロールバック計画には、次の内容を含めるべきです。
- すばやく切り替えられる仕組み。機能フラグ、環境変数、またはデプロイ済みのビルドに組み込むのではなくリクエスト時に読み込む設定値のいずれであっても、切り替え後の一定期間は、以前のプロバイダーの認証情報とエンドポイントを有効なままにし、コードをデプロイせずに再び使える状態にしておくべきです
- 明確な発動条件。何があればロールバックが正当化されるのかを、事前に具体的に決めておきます。たとえば、あるしきい値を超えるエラー率、特定の種類のリクエストの失敗、一定数のユーザーからの苦情などです。合意された基準がないまま、プレッシャーの中で判断を下すことにならないようにします
- ロールバックの責任者。ロールバックを決定する責任を明確に負う1人または少人数のグループを決めておきます。そうすれば、複数の人が誰かの判断を待って決定が滞ることがありません
- ロールバック期間の明確な期限。両方のプロバイダーの認証情報を無期限に有効にしておくと、移行する意味がなくなります。以前のプロバイダーへのアクセスを完全に廃止する具体的な日付を決めておきます
My Geocodeの互換ホストはプロバイダーのリクエストとレスポンスの形式をそのまま再現するため、互換ホストを使った移行でのロールバックは、多くの場合、以前のホストとキーに設定を戻すだけで済み、別の解析コードを再デプロイする必要はありません。そのため、必要になったときにロールバックの実行にかかる時間が短くなります。とはいえ、これには両面があります。ロールバックが機能すると思い込むのではなく、実際に機能するかを計画段階で一度きちんとテストしておく価値があるということでもあります。テストしていないロールバック手順は、ロールバック計画がまったくない状態と実質的に変わらないからです。
ロールバックの対象となる期間中に処理されたデータやリクエストをどう扱うかも、決めておく価値があります。翌朝に問題が見つかる前に、夜間のバッチジョブが新しいプロバイダーに対して実行されていた場合、そのバッチを再処理する必要があるのか、それとも差異は許容できるのか。実際のインシデントの最中ではなく事前に決めておくことで、ただでさえストレスの大きい場面での判断が1つ減ります。
前に進むことしか書かれていない移行計画は、実際のところ不完全な計画です。ロールバックの部分があってこそ、移行は後戻りできない賭けではなく、根拠が求めればきれいに元に戻せる、よく考えられた判断になります。