要約

  • Cloudflare は、旧 SaaS 事業者の完全一致のホスト名が新事業者のワイルドカード設定より優先され、CNAME 変更後も旧コンテンツが出る場合を説明している。
  • 新事業者は対象のホスト名を個別に登録する対応を取れる。ホスト名と証明書の準備、DNS 切り替え、実際の到着確認、旧設定の削除を順に受け渡す必要がある。

引っ越し完了報告の外にいる客

通販サイトの移行を想像してみる。新しい事業者と契約し、DNS の向きも変えた。担当者は完了報告を送り、次の仕事に移る。ところが、客がいつもの URL を開くと古いページが出る。暗号化された接続も成功する。移行チームの資料はそろっているのに、客だけが旧店舗にいる。

Cloudflare のトラブルシューティング文書は、この結果が起こる設定の組み合わせを挙げている。旧 SaaS 事業者が特定のホスト名を登録し、新事業者がワイルドカードを設定していると、CNAME を更新しても旧設定が優先される場合がある。

契約書は新しい相手を指している。リクエストの処理順を決める仕組みは、設定がどれだけ正確に名前を指定しているかを見る。署名の日付では解けない引っ越しだ。

一戸の番地が一帯の案内より強い

mystore.example.com のような名前を個別に登録すれば、その住所への完全一致を作れる。ワイルドカードは複数の名前をまとめて扱う。後者は管理を簡単にするが、既にある個別の指定と競合するときは優先順位を調べる必要がある。

Cloudflare のホスト名優先順位によれば、複数のゾーンに同じホスト名のプロキシ対象レコードがある場合、ゾーン設定と対応するオリジンサーバーを制御するのは一つのレコードだ。この条件下では完全一致がワイルドカードより先に選ばれる。文書にも、旧式の完全一致の設定が新しいワイルドカードを上回る例がある。

新しい事業者にとって、顧客の登録は一括処理できるほうが楽だ。しかし移行の相手には、その顧客だけを指す設定が残っているかもしれない。一括管理の効率には、個々の住所を受け継ぐ際の確認作業が付いてくる。

営業上の選択と実際の配送先が、この一点で離れる。顧客が新しいサービスを選んだ以上、その選択がリクエストの行き先になるまで、受け入れ作業は続いている。

新しい事業者にできる修正がある

Cloudflare は、新事業者がワイルドカードの代わりに対象のホスト名を個別登録することを推奨している。別の対応として、アカウントの Super Administrator が Cloudflare Support に SaaS 設定の更新を依頼する方法も示す。

したがって、移行会議では新事業者がその正確な名前を登録したかを確認できる。旧事業者が顧客を手放さない、と先に結論を出すより、実行できる仕事がはっきりする。公開資料には個別顧客の設定一覧、移行ログ、中断費用がなく、具体的な影響の判定にはそれらが必要だ。

新しいアプリケーションを用意し、契約を締結しても、利用者の要求が届かなければ購入したサービスの一部は未納品である。作成済み、変更済みという報告を集めるだけでは、その最後の納品を確認できない。

暗号化が成功しても、受取人は別に確かめる

Cloudflare for SaaS の設定ガイドは、ホスト名の有効化と証明書の発行・配置を分けている。本番トラフィックに使う条件は、双方が active で、DNS が目的の SaaS ターゲットを指していることだ。

TLS ハンドシェイクが成功していても、新しい証明書が active になる前という場合がある。Cloudflare が別の一致する証明書を提示できるためだ。暗号化接続の成功だけを見て、新しい証明書の配置まで完了と判断すると、異なる結果を一つにまとめてしまう。

フォールバックオリジンの active 表示にも範囲がある。ガイドによれば、それは指定 DNS レコードへトラフィックを送る準備ができた状態であり、正しいオリジンを向いているかは確認が要る。緑の表示が一つ増えるたびに、利用者が目的のアプリケーションへ一歩近づいたと決めつけるわけにはいかない。

検収に必要なのは、正確なホスト名、準備済みの証明書、DNS の宛先、そして新しいゾーンと予定したアプリケーションで処理された要求を突き合わせることだ。契約書に技術項目を大量に転記するより、その四つが同じ到着先を示す証拠を受け取るほうが役に立つ。

両方の入口を用意してから交代する

ホスト名の検証と移行の説明では、同じドメインについて複数の SaaS 事業者が active のカスタムホスト名を同時に持てる。既に Cloudflare を使うホスト名を事前検証しても、それだけでトラフィックは移らない。

推奨される通常の移行では、新ゾーンにホスト名を作って事前検証し、TXT または委任された検証で証明書も用意する。その後に顧客が CNAME を変更し、トラフィックが新ゾーンへ移ったことを確認してから旧事業者が設定を削除する。この手順と、完全一致・ワイルドカードの優先順位を併せて確認する。

準備の重複には意味がある。旧サービスを残しながら新しい受け入れ先を整えられる。一方、DNS 変更後にホスト名のリアルタイム検証や証明書の自動 HTTP 検証を行う方法では、有効化を待つ間に短い停止時間が生じる可能性を設定ガイドは示している。

旧設定の削除は、到着を確認した後の片付けに置く。早すぎれば、まだ役割がある準備を失う。残し続ければ、次の調査で読まなければならない履歴が増える。いつ準備し、いつ交代し、いつ片付けたかを分けて記録すれば、引き継ぎの話が具体的になる。

URL を変えずに相手を選び直せることは、顧客にとって価値がある。その同じ URL の裏で、選んだ相手が本当に応対するところまでが移行である。