まず新しいサーバーを準備してテストし、アプリケーションがサポートする一貫性のある方法でデータをコピーし、切り替えウィンドウを定義し、古い環境を保持します。ロールバックは、DNS の変更だけでなく、新しいサーバーで受け入れられた書き込みを考慮しなければなりません。
マシンを移動する前にサービスを棚卸しする
移行にはアプリケーションファイル以上のものが含まれます。データベース、アップロード、スケジュールされたジョブ、キューワーカー、証明書、ドメイン、シークレット、外向きの連携を列挙します。ソフトウェアのバージョンと、ファイル権限やストレージパスなど重要な運用上の前提を記録します。新しい専用サーバーでは、古い環境に何年も前にひっそりとインストールされていた忘れられた依存関係が露呈する可能性があります。
切り替え判断の担当者を割り当て、成功とは何かを定義します。ユーザーに見えるチェック、データの一貫性、アクセスを回復する能力を含めます。移行日を告知する前に、新しい構成が提供され使用可能であることを確認します。注文確認や記載されたハードウェア仕様は、本番データを受け入れる準備ができた実用的な移行先と同じではありません。
移行先を別個の環境として構築する
必要なスタックをインストールし、管理を確立し、意図したファイアウォールを構成します。シークレットを非公開に保ち、サービスの権限を意図的に設定します。公開トラフィックを移動する前に、アプリケーションが期待するホスト名と証明書の挙動を検証します。Apache のバーチャルホストに関するドキュメントは、ホスト名ルーティングがサーバーのアドレスとは別の構成判断である理由を示しています。動作するデフォルトページは、正しいアプリケーションホストが構成されていることを証明しません。
リハーサルには代表的な復元データセットを使用し、送信メール、支払い、スケジュールされたジョブを無効化するか、安全なテストシステムにリダイレクトします。これにより、テスト環境が実際のユーザーに作用するのを防ぎます。ログイン、アップロード、バックグラウンド処理、復元を実行します。手順とその所要時間を記録し、実際のウィンドウが楽観ではなく観測されたプロセスに基づくようにします。
一貫したデータ境界を選択する
データベースとアプリケーションがサポートするバックアップまたはレプリケーション方法を使用します。PostgreSQL は SQL ダンプ、ファイルシステムバックアップ、継続的アーカイブを区別し、それぞれに独自の前提があります。そのダンプのガイダンスは、データベースダンプは内部的に一貫していても、クラスタ全体のロールやその他の詳細は別途処理する必要があると述べています。開いているデータファイルを無差別にコピーするのではなく、実行している正確なシステムの要件を読んでください。
データベースがアップロードやキュー状態とどのように関係するかを計画します。レコードが別の時点でコピーされたファイルを指している場合、両方のコピーが個別に成功していても、復元されたアプリケーションは不完全になる可能性があります。書き込みを短時間停止するか、テスト済みのレプリケーション構成を使用するか、アプリケーション固有のエクスポートを実行するかを決定します。その一貫性の判断をランブックに明示してください。
| 段階 | 必要な証拠 | 判断 |
|---|---|---|
| リハーサル | アプリケーションと復元データがチェックに合格 | 移行先を切り替え候補として検討可能 |
| 最終同期 | 定義された一貫性のある復旧ポイント | 理解された残りの変更のみで続行 |
| トラフィック切り替え | 正しいルーティングと証明書の挙動 | 両方の移行先を監視 |
| ロールバック | 新たに受け入れられたすべての書き込みの場所 | トラフィックを戻す前にデータを照合 |
即時の変更を約束せずにトラフィックルーティングを準備する
DNS の time-to-live は、レコードをキャッシュできる期間を制御します。これは Cloudflare の DNS ドキュメントで説明されています。DNS が移行の一部である場合は、早い段階で TTL を確認し、既存のキャッシュされたレコードを以前の設定の下で経過させます。切り替えの瞬間に値を変更しても、すべてのキャッシュされた応答を遡って短縮することはできません。移行中、異なるクライアントが異なる移行先に到達する可能性があります。
ルーティングの変更が落ち着くまで古い環境を利用可能に保ち、それがまだ書き込みを受け入れられるかどうかについて意図的なポリシーを設けます。アプリケーションがそのように設計されていない限り、重複するキューコンシューマーやスケジュールされたジョブを実行しないでください。両側でリクエストを監視し、独立したクライアントから意図したホスト名、TLS 証明書、アプリケーションバージョンを確認します。
書き込み開始後のロールバックを定義する
新しいシステムが変更を受け入れる前は、トラフィックを戻すのは比較的単純かもしれません。その後は、DNS を反転させるだけで作業が失われたり、2つの矛盾する履歴が生じたりする可能性があります。新しく作成されたレコードとアップロードがどのように保持または調整されるかを定義してください。アプリケーションがそれらを安全にマージできない場合は、場当たり的に古いコピーへ戻すよりも、制御されたメンテナンス期間の方が望ましいことがあります。
移行を一時停止する必要がある条件を設定し、意思決定の担当者に連絡できる状態を保ってください。プロジェクトの保持ルールに従ってログと有用な証拠を保存してください。ホームページが一度読み込まれたというだけで、古いマシンやその独立したリカバリコピーを削除しないでください。保持期間は、合意された検証とロールバックのニーズをカバーする必要があります。
運用チェックで移行を締めくくる
カットオーバー後は、バックアップ、アラート、証明書の更新、スケジュールされた作業、アクセスの復旧を検証してください。監視対象のホストが新しい宛先であること、および本番環境にテスト用の連携が残っていないことを確認してください。通常のトラフィック下でアプリケーションのエラーとユーザーに見えるタイミングを確認してください。インベントリとランブックを更新し、次の管理者が何が変更されたかを推測しなくて済むようにしてください。
SwissOctet の専用ファミリーは異なる物理構成を提供しますが、選択したサービスについて移行作業とマネージド支援が確認できる必要があります。カタログを使用して適切なリソースを選択し、アプリケーションのデータに合わせてテスト済みの移行を構築してください。移行は、ファイルが転送されただけではなく、サービスとその復旧プロセスが移行先で機能したときに完了します。
実践チェックリスト。
- データ、ジョブ、シークレット、連携を棚卸しする。
- スケジュール設定の前に、提供された移行先を検証する。
- 安全な外部連携を使用してリハーサルを行う。
- データベースとアップロードの整合性を定義する。
- ルーティングの切り替えと重複ジョブの防止を計画する。
- 新しい書き込みに対するロールバックを指定する。
- カットオーバー後にバックアップと監視を検証する。
重要な詳細。
アプリケーションディレクトリをコピーするだけで移行できますか？+
それがサービスに必要なすべてを捕捉し、整合性を保つ場合に限ります。データベース、アップロード、ジョブ、シークレット、設定には通常、個別の対応が必要です。
DNS の TTL を下げるとカットオーバーは即時になりますか？+
いいえ。以前にキャッシュされた応答は、その以前の有効期間が終了するまで残ることがあり、クライアントは異なるタイミングで更新する可能性があります。
ロールバックは DNS を古いサーバーに向けるだけですか？+
新しいサーバーが書き込みを受け入れた後はそうではありません。トラフィックを戻す前に、それらのレコードとファイルを考慮する必要があります。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- PostgreSQL: バックアップと復元 www.postgresql.org
- PostgreSQL: SQL ダンプの整合性と復元 www.postgresql.org
- Apache: バーチャルホストのドキュメント httpd.apache.org
- Cloudflare DNS: Time to Live developers.cloudflare.com
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。