ZapierやMakeの自動化を新しいジオコーディングホストへ移行する
ジオコーディングのステップを含むノーコードの自動化には、独自のコードとは異なる移行方法が必要です。その切り替えの進め方を紹介します。
APIホストを変更するためのダウンタイムゼロのチェックリスト
本番環境でAPIホストを障害なしに変更することは可能ですが、そのためには、変更を本番環境に直接反映する1行の設定変更としてではなく、独自のリスクを持つデプロイとして扱う必要があります。スムーズな切り替えとインシデントの違いは、ほとんどの場合、実際に切り替える瞬間ではなく準備の段階にあります。
切り替えの前に:
- 新しいホストの認証情報を十分前もって用意し、手動のテスト呼び出し1回だけでなく、実際のリクエストパターンを使ってステージングまたはテスト環境で動作することを確認します
- 一時的にでも、各リクエストをどのホストが処理したかをログに記録するようアプリケーションを計測できるようにしておきます。そうすれば、ロールアウトの進み具合を確認でき、後から問題をホスト別に診断できます
- 環境変数、フィーチャーフラグ、リモート設定サービスのいずれであれ、アプリケーション全体を再デプロイせずにホストの値を変更できる設定の仕組みになっていることを確認します。変更のたびに再デプロイが必要な手順では、切り替えの途中で問題が起きたときの対応が遅くなるからです
切り替えの間:
- インフラが対応していれば、変更を一度にすべてではなく段階的にロールアウトします。トラフィックの一定割合、サーバーやリージョンを1つずつ、あるいは重要度の低いエンドポイントを他より先に、といった方法です
- ロールアウトの期間中はエラー率と応答時間をリアルタイムで監視し、許容できると想定した範囲ではなく、切り替え前のベースラインと直接比較します
- この期間中は以前のホストの認証情報を有効なまま、すぐに使える状態にしておきます。そうすれば、元に戻すのは新しいデプロイではなく設定の変更で済みます
切り替えの後に:
- 移行が完了したとみなす前に、新しいホストをすべてのトラフィックで一定の観察期間稼働させます。問題の中には、継続的な負荷がかかったときや特定の時間帯にしか現れないものがあるからです
- 両方をログに記録している場合は、同一のリクエストのサンプルについて、新旧のホストの実際のレスポンスデータを比較し、エラー率だけでは表に出ない微妙なデータの違いを見つけます
- 旧ホストの認証情報を廃止するのは、観察期間が問題なく過ぎてからにし、それも「そのうち」ではなく、具体的に決めた日付に行います
My Geocodeの互換ホストはプロバイダーのリクエストとレスポンスの形式を正確に再現するため、互換性に基づく移行で実際にコードレベルで変わるのは、多くの場合ホスト名と認証情報だけです。これにより、切り替え期間の中で最もリスクの高い部分で導入される新しいコードの量が減ります。認証自体も、X-API-Keyヘッダー、Authorization: Bearer、HTTP Basic認証、クエリパラメーターの4つの方式に対応しているため、既存のクライアントライブラリの構造によっては、変更のこの部分はコードの変更ではなく、純粋な設定の更新で済むことがよくあります。
ダウンタイムゼロの移行に必要なのは、巧妙なインフラよりも規律です。徹底的に準備し、段階的にロールアウトし、注意深く監視し、必要ないと確信できるまでは戻る手段を残しておくことです。