最高のクリスマスプレゼントとは言えない状況

Edgioの連邦倒産法第11章（チャプター11）手続きによる影響は、世界中のOTT、ストリーミング、デジタルパブリッシング組織の技術者にとって、予想外のクリスマスプレゼントとなってしまいました。2025年1月15日をもって、Edgioがサーバーのプラグを抜き始めることが発表されたためです。その結果、直近の30日間および年末年始の休暇期間の大半は、多くの人々にとって、EdgioのCDNおよび配信サービスから代替ソリューションへの迅速（かつ少々混乱を伴う）移行作業に完全に追われることになりました。

チャプター11のニュースにおける最も重要な側面の1つは、基盤となる技術ではなく、契約が買収されたという点でした。言い換えれば、望むと望まざるとにかかわらず、移行は避けられない状況だったのです。

これまでにいくつかの移行を乗り越えてきましたので、時間が限られている状況においてCDNおよび配信の移行を効果的に管理するのに役立つ、5つの重要な準備ステップを共有したいと思います。

5つの実践的な準備ステップ

1. 明確な命名規則の維持

大企業でドメイン、サブドメイン、プロパティを移行する際、最大の課題の1つとなるのが、その膨大な量です。エンジニアが `qa-1-test-pipeline-release4.domain.com` のような命名規則を使用していると、プレッシャーにさらされている移行チームが各ドメインの所有者やその役割を特定することが困難になります。

教訓：一貫性のある明確な命名規則は、長期的には大きな見返りをもたらします。この原則はドメインだけでなく、API、ルール、証明書、リダイレクトにも当てはまります。すべてに対して統一された命名システムを確立することで、移行の波に先手を打ちましょう。理解しやすく、人間が読めるものにしてください。

2. ドメインおよびサブドメイン台帳の導入

命名規則の重要性に続き、各ドメイン、サブドメイン、リダイレクト、およびそれを誰が申請したかを追跡する台帳を持つことが不可欠です。今回のいくつかの移行において、特定のサブドメインを最初に誰がいつ何の目的で申請したのか、あるいはそれが今でも使われているのかどうかを特定するだけで、貴重な時間が浪費される場面がありました。

これがなぜ重要なのでしょうか。プロバイダーAからプロバイダーBへの一括移行時には、設定が壊れたり、不正な形式になったりすることがあります。アセットが移行後にどこにたどり着いたかではなく、本来どこを指すべきなのかを把握するため、また誤ったリダイレクトルールの紐解きのために、かなりの時間が費やされました。各ドメイン、サブドメイン、書き換えルールに連絡先が紐づいた中央集中型の台帳があれば、混乱を大幅に減らし、トラブルシューティングを迅速化できます。

3. 定期的な整理整頓による恩恵

どのような移行プロセスであっても、そこには膨大な数のルールが存在することが浮き彫りになります。多くの場合、ルールの上にさらにルールが重ねられています。この複雑さにより、移行中または移行後に問題が発生した際、その原因を追跡することが困難になります。多くの組織は、この問題がどれほど大きくなり得るかを見失いがちです。誰もが任意の目的で任意のルールを申請できるようにしてしまうと、簡単に管理不能な状態に陥ってしまいます。

優れた整理整頓とは、未使用のルール、リダイレクト、ドメイン、サブドメインを定期的にクリーンアップすることです。これはベストプラクティスに従うだけでなく、移行後のテスト負荷を軽減することにもつながります。6か月ごとのクリーンアップ実施を検討してください。その期間中に各ドメインとパスについて報告し、特定のアドレスやURLがどれだけの訪問者やヒット数を得ているかを示します。使用されていない要素を廃止するためのガバナンスを作成し、一貫したフォローアップ監査のスケジュールを立てましょう。

4. すべてのWAFが同じように作られているわけではない

Webアプリケーションファイアウォール（WAF）は、本番環境にとっては最良の味方になり得ますが、テスト環境にとっては最大の敵になり得ます。正常に移行されたと確信しているサイト、API、エンドポイントがテスト中に失敗し、厳格なWAFルールがエッジでトラフィックをブロックしていることにエンジニアが気づくことがよくあります。オリジンが自身を保護するためにIPホワイトリストやホストヘッダーを使用している場合、課題はさらに複雑になります。

有用なアプローチは、テスト中（またはプレプロダクション/ステージング環境）にすべてのWAFルールをCOUNTまたはREPORTモードに移行することです。移行が完了した後にブロックを再有効化できます。これにより、ブロックを元に戻した後に何かが機能しなくなった場合、WAFが原因なのか、それとも設定の移行自体が原因なのかを即座に判断できます。すべてのWAFが同じように作られているわけではないことを念頭に置いておいてください。あるプロバイダーで機能していたビジネスロジックや知的財産ルールが、別のプロバイダーで同じように動作するとは限りません。

5. コミュニケーションフレームワーク

移行作業がプレッシャー下にあるとき、コミュニケーションが不足したり、逆に過剰になったりしがちです。ビジネスへの中断に関する初期の懸念の多くは、どのドメインやプロパティが誰に属しているか、その目的、そして現在のステータスをシンプルかつ透明性の高い形で提示することで緩和できたはずです。

1. 台帳を作成し、これを全体的な追跡シートとして使用する

計画と台帳は事前に作成しておくようにしましょう。過度に詳細である必要はありません。基本的なドメインとプロパティのリスト、所有者の詳細、それらが内部サービスと外部サービスのどちらを指しているか、そして人間が読める説明があるだけでも、混乱は大幅に軽減されます。このような状況が再び発生した場合でも、真っ向から取り組む準備が整います。なお、GANTTチャートや従来のプロジェクト計画は忘れてください。それらはリソース管理には役立ちますが、従来のリソースベースのモデルよりも、ドメインやプロパティに対して問題を追跡する方が簡単です。

2. 日常的なリアルタイムコミュニケーション計画を策定する

さらに、社内全体でのコミュニケーションのためにオープンなチャンネルを用意することをお勧めします。SlackやTeamsのチャンネルを活用してください。少人数で集中したチームが主導権を握るのが良いのは確かですが、ドメイン、プロパティ、サイト、リダイレクトの多くは、広範なプロダクトチームやマーケティングチームによって作成されたものです。土壇場でのテスト、パートナーやサードパーティへの情報提供、あるいは単に質問に対する迅速な回答を得るために、彼らの協力が鍵となります。

3. 分科会（スクワッド）とメーリングリストを作成する

最も成功する移行は、少人数で集中したグループが移行の課題に取り組み、社内に効果的にコミュニケーションを図るケースです。社内の誰もが助けを求めたり、何かがおかしいと指摘したりできる方法を用意してください。このプロセスを支援するために、連絡先を定義してメーリングリストを設定します。極めて重要なのは、全員が誰に連絡すべきか分かるように全社メールを配信することです。

4. オーディエンスに伝える

途中で見落とされるものが生じる可能性は十分にあります。消費者やオーディエンスへの潜在的なサービス停止を先回りして予測し、事前にウェブサイトやサービスに短いメンテナンスメッセージを掲載しておきましょう。サービス停止は決して理想的ではありませんが、ユーザーがたまに404エラーやオリジンエラーに遭遇した際にも、レピュテーションの観点から見栄えが良くなります。

まとめ

この規模と複雑さを伴う作業においては、常に何かしら見落としが発生するものです。私たちは、一部のリダイレクトが完全に正しい場所を指していなくても、何も機能しないよりは、何らかのサイトが表示されている方がマシであるという心構えを持っています。移行の完了は終わりではなく始まりであり、ここからクリーンアップと微調整がスタートするのです。