この記事は、 アマゾン ウェブ サービス (AWS) から Azure にワークロードを移行する方法に関するシリーズの一部です。
実行フェーズは、次のステージで構成されます。
- カットオーバー前
- カットオーバー中
- カットオーバー後
このフェーズの目標は、合意されたダウンタイムとデータ損失の制限内で AWS ワークロードを Azure に移行することです。 Runbook に密接に従い、プロセス全体を通して関係者と通信します。
Important
テストを急いだり、検証手順をスキップしたりしないでください。
実行フェーズでは、サービス中断のリスクが最も高くなります。 データ同期の問題、ネットワークの構成ミス、または予期しないアプリケーションの動作により、障害やデータ損失が発生する可能性があります。
カットオーバー前
ネゴシエートされたメンテナンス期間を開きます。
データ移行を実行します。 操作の順序をカットオーバー モデルに合わせます。 カットオーバー中にこれらの手順が確実に実行されるように開始する前に、非運用環境ですべてのデータ移行手順を完全にスクリプト化してテストします。
ライブまたはアクティブなレプリケーションシナリオの場合は、AWS と Azure の間で継続的なデータ同期を設定します。 この方法では、ダウンタイムを最小限に抑え、カットオーバー中のデータの一貫性を確保するのに役立ちます。
バックアップと復元のモデルの場合は、すべての AWS データをバックアップします。 バックアップを Azure に安全に転送し、ターゲット環境で復元します。 次の手順に進む前に、データの整合性を検証します。
アプリケーションのコンポーネントを設定します。 各コンポーネントを依存関係に接続します。 これらの依存関係の一部が AWS に残っている可能性があります。 たとえば、段階的な移行アプローチでは、最初にデータベースを AWS に保持し、後で移行することができます。
接続とネットワークの設定を変更します。 Azure リソースが AWS への依存関係に到達できることと、必要に応じて AWS リソースが Azure 上の依存関係に到達できることを確認します。 ファイアウォール規則、ネットワーク セキュリティ グループ (NSG) の規則とポリシー、およびルーティングを要件を満たすように調整します。 前のフェーズですべての接続の変更をテストして検証し、このフェーズのトラブルシューティングを減らします。
単純なテストを実行します。 機能、パフォーマンス、および障害のテストを行います。 これらのテストはシンプルにしてください。 前のフェーズで広範な機能テストまたはロード テストを行います。
問題を早期に繰り返して修正します。 この段階で修正プログラムを最小限に抑えるために、十分に計画してください。 問題が発生した場合は、今すぐ解決してください。 一般的な問題には、予想される値と一致しないスクリプトまたは API 呼び出しのパス、Azure サービス制限違反、増やす必要があるクォータ制限などがあります。 Terraform を使用する場合、一部の Azure リソース機能では異なる実装が必要になる場合があります。
有効期間 (TTL) を短縮します。 カットオーバーの前に TTL を減らし、ロールバック計画の伝達遅延を考慮します。
完全修飾ドメイン名 (FQDN) とドメイン ネーム システム (DNS) ルーティングを更新します。 計画フェーズで定義した FQDN 移行計画を適用します。 既存の FQDN を Azure エンドポイントにポイントするように DNS レコードを更新するか、新しい Azure FQDN を使用するようにアプリケーション構成を変更します。 公開サービスの場合は、ダウンタイムを最小限に抑えるために DNS カットオーバーを慎重に調整します。
カットオーバー中
Important
Runbook に従い、移行作業の進行状況について関係者と進捗状況を共有します。 タイムラインに対する予想される変更や、その他の問題に注意する必要がある変更を含めます。
この手順を実行する方法は、選択した戦略によって異なります。 推奨される青緑色のアプローチでは、カットオーバー 期間中にすべてのトラフィックを同時に切り替えます。 運用トラフィックを受け入れるように、すべてのデータを同期し、コンポーネントを準備する必要があります。 次に、すべての接続を Azure に切り替え、プライマリ環境として Azure 環境を起動します。 不整合を回避するために、トラフィックまたはアプリケーションを一時的に一時停止するメンテナンス期間をお勧めします。 カットオーバー中に、ヘルスチェックを自動化し、リアルタイムで監視します。
運用チームと緊密に連携して、新たな問題にすぐに対処できるようにします。 移行チームと運用エンジニアは、Azure Monitor またはカスタム テレメトリを使用して、リアルタイムの正常性ダッシュボードを積極的に監視する必要があります。 異常があれば、すぐにアラートと応答をトリガーする必要があります。 計画フェーズで定義したロールバック基準内の問題を解決できない場合は、ロールバックの準備をします。
カットオーバー後
ロールバックの準備を維持します。 ロールバックが必要な場合は、検証期間中に AWS 環境を使用できるようにします。 Azure 環境に自信がある場合は、AWS リソースの使用を停止します。
カットオーバー後の検証を行います。 Azure でワークロード メトリックを注意深く監視します。 システムが重大に劣化するか、重大なバグが検出された場合には、ロールバック計画を実行し、トラフィックを AWS に戻す準備をしてください。 可能であれば運用環境で完全な回帰テストを実行し、すべてのコンポーネントを確認します。 重要な機能のスモーク テストを実行し、セキュリティ ログを監視し、すべての監視シグナルとアラートが緑色であることを確認します。 1 日または 2 日後、コストと使用状況を監視して、不要なコストが発生する可能性がある暴走リソースを見つけます。
Azure の継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを更新します。 デプロイ パイプラインを更新して、AWS のターゲットを停止し、Azure のみをターゲットにします。
ドキュメントと手順を更新します。 新しい Azure 環境に合わせて、すべての運用 Runbook、サポート ドキュメント、運用手順を修正します。
運用の監視を受け渡します。 運用チームが Azure 環境の監視の所有権を持っていることを確認します。 ワークロードの正常性を監視するために、先ほど設定した Azure Monitor ダッシュボードとアラートを使用する必要があります。 チームが Azure デプロイのプライマリ サポートに移行する際に、知識のギャップに対処します。
詳細については、「 クラウドへの移行」を参照してください。
Checklist
| 成果物に直結するタスク | |
|---|---|
| ☐ | データ移行の実行 |
| ☐ | アプリケーション コンポーネントを設定する |
| ☐ | 接続とネットワークの設定を変更する |
| ☐ | 機能テストを実行する |
| ☐ | パフォーマンス テストを実行する |
| ☐ | 故障試験を行う |
| ☐ | すべての問題を解決する |
| ☐ | TTL を減らす |
| ☐ | FQDN と DNS ルーティングを更新する |
| ☐ | ロールバックの準備を維持する |
| ☐ | カットオーバー後の検証を行う |
| ☐ | Azure の CI/CD パイプラインを更新する |
| ☐ | ドキュメントと手順を更新する |
| ☐ | 運用監視の引き渡し |