クラウドへの移行を実行する

この記事では、Azure への移行を成功させるための構造化されたガイダンスを提供します。 このガイダンスでは、さまざまなビジネス要件に対応するために、ほぼゼロのダウンタイムと計画されたダウンタイムの両方のアプローチについて説明します。

移行のために利害関係者を準備する

利害関係者の準備により、移行中の調整された実行と迅速な問題の解決が保証されます。 明確なコミュニケーションとリソースの割り当てにより、ビジネスの中断が軽減され、移行の成功率が向上します。 移行アクティビティを開始する前に、通信プロトコルを確立し、サポートの可用性を確認する必要があります。

1. すべての利害関係者に詳細な移行スケジュールを配布します。 包括的なスケジュールにより、組織全体の明確さと整合性が生まれます。 移行のタイミング、予想されるサービスへの影響、責任、コンティンジェンシー計画を指定するドキュメントを作成して配布します。 移行チームとサポート リソースの連絡先情報を含めます。 この準備により、誤解を防ぎ、移行期間中のビジネスの中断を軽減します。

2. 移行ウィンドウ全体でテクニカル サポートの可用性を確認します。 専用の技術リソースを使用すると、移行中に発生した問題にすぐに対応できます。 移行期間中に、関連する専門知識を持つ特定の技術スタッフをオンコールするようにスケジュールします。 重大な問題に対する応答時間の期待を持つ明確なエスカレーション パスを確立します。 このサポート構造により、移行の成功やビジネス運用に影響する可能性がある問題の解決時間が短縮されます。

3. すべてのサポート チームと移行前の準備レビューを実施します。 準備レビューでは、すべてのチームが自分の役割を理解し、必要なアクセス権を持っていることを確認します。 各サポート チームの代表者と会議を開催して、移行計画、検証手順、ロールバック条件を確認します。 サポート チームに適切なシステム アクセスおよび監視ツールが構成されていることを確認します。 この準備により、移行中に発生する問題に対する協調的な対応が保証されます。

変更の凍結を実装する

変更がフリーズすると、移行の成功を妨げる可能性のある変更が防止されます。 システムの安定性により、移行リスクが軽減され、データの一貫性が確保されます。 移行期間中にソース システムに対する変更を防ぐためのコントロールを実装する必要があります。

1. デプロイ パイプラインに自動変更制御を実装します。 自動化された制御により、運用システムに対する未承認の変更が防止されます。 固定ウィンドウ中にソース環境へのリリースをブロックするようにデプロイ パイプラインを構成します。 CI/CD ツールに承認ゲートを追加して、凍結期間を適用します。 これらの制御により、結果に影響を与える可能性のある偶発的なデプロイを防ぐことができます。

2. 緊急変更の手順を文書化します。 緊急手順では、安定性を維持しながら重要な修正プログラムを有効にします。 緊急変更の特定の条件を作成し、迅速な承認プロセスを定義します。 承認者の連絡先情報を含め、必要なテストを文書化します。 これらの手順では、システムの安定性とビジネス継続性の要件のバランスを取ります。

3. 承認されていない変更を監視します。 変更の検出により、変更ウィンドウ全体でコンプライアンスが固定されます。 ファイルの変更、データベース スキーマの変更、アプリケーションのデプロイに関するアラートを構成します。 構成管理ツールを使用して、システムの状態を追跡します。 この監視により、文書化されていない変更が成功に影響を与えるのを防ぐことができます。

運用環境の最終処理

運用環境の準備により、移行されたワークロードの一貫性、セキュリティ、運用上の準備が保証されます。 この準備により、構成の誤差が軽減され、ワークロードに対して検証済みの基盤が提供されます。 コードとしてのインフラストラクチャ テンプレートを使用して運用リソースを作成し、運用グレードの構成を適用する必要があります。

1. コードとしてのインフラストラクチャ テンプレートを使用して運用リソースを作成します。 コードとしてのインフラストラクチャにより、環境間で一貫性のある反復可能なデプロイが保証されます。 この方法では、構成エラーを減らし、インフラストラクチャの変更に対するバージョン管理を提供します。 Azure Resource Manager テンプレート、Bicep、または Terraform を使用して、標準化された構成でリソースをデプロイします。

2. 運用グレードの構成を Azure リソースに適用します。 運用環境の構成では、ワークロードを保護し、組織の要件を満たすセキュリティ、パフォーマンス、コンプライアンスのベースラインが確立されます。 サービス間で必要なトラフィックのみを許可する制限付き規則を使用して、ネットワーク セキュリティ グループを構成します。 必要な通信パスを有効にしながら、承認されていないアクセスをブロックするファイアウォール規則を適用します。 最小限の特権の原則に従って、ID とアクセス管理の制御を設定します。 Azure で正しいバージョンを使用してデータベースをプロビジョニングし、レプリケーションに必要なユーザー アカウント、ロール、およびアクセス許可を構成します。 データベース接続をセキュリティで保護するために、ネットワーク アクセス制御とファイアウォール規則を構成します。 これらの構成により、移行されたワークロードの安全な基盤が作成されます。

3. すべてのサービスが正しく実行されていることを確認します。 サービス検証により、Azure インフラストラクチャが移行されたワークロードをサポートできるようになります。 この検証により、移行プロセスに影響する前に潜在的な問題が特定されます。 サービスの正常性状態、リソースの作成の完了、およびサービス固有の正常性チェックを確認します。

4. ネットワーク接続が確立されていることを確認します。 ネットワーク接続の検証により、必要なすべての通信パスが機能します。 この検証により、移行またはアプリケーションの機能を中断する可能性のある接続の問題を防ぐことができます。 必要なすべてのサービス間のネットワーク接続をテストし、重要なエンドポイントの DNS 解決を検証します。

切り替えを実行する

移行の実行により、ワークロードのデータと操作がソース環境から Azure に転送されます。 次の手順では、計画されたダウンタイムを許容できるシナリオに対応しながら、ほぼゼロのダウンタイムを優先する標準化されたアプローチを提供します。 これらの手順は、特定のダウンタイム要件とワークロードの特性に基づいて調整する必要があります。 データ移行ツールを参照してください。

ダウンタイムをほとんど発生させない移行を実行する

1. データベース レプリケーションを確立します。 ソースと Azure ターゲット システムの間で継続的なデータ レプリケーションを確立するように、データベース プラットフォームのネイティブ レプリケーション機能を構成します。 初期データ同期が正常に完了し、レプリケーションが正常であることを確認します。

2. レプリケーションのラグを監視します。 データベース プラットフォームの監視ツールを使用して、レプリケーションのラグを監視します。 待機時間が長いほど、カットオーバーのリスクと期間が増加します。 レプリケーションのラグがゼロになるまで、次の手順に進む必要はありません。

3. 安定したレプリケーション中に非構造化データとファイルを移行します。 最終的なカットオーバーの前に、非構造化データとファイルを Azure にコピーします。 オブジェクト とファイルの移行にツールを使用し、 適切な Azure ストレージ サービスにファイルを転送する機能を使用します。 この準備により、最終的なカットオーバー中にコピーする必要があるデータの量が減ります。

4. 最終同期期間中に書き込み操作を一時停止します。 アプリケーション チームと連携して、書き込み操作を停止するか、事前に定義されたメンテナンス期間中に読み取り専用モードを有効にします。 この手順により、最終的なカットオーバー中のデータの不整合を防ぐことができます。 トラフィックの少ない期間中にこの一時停止をスケジュールし、タイムラインをすべての関係者に伝えます。 書き込み操作を一時停止しない場合は、データ損失のリスクが高くなります。

5. 最終的なデータ同期を完了します。 AzCopy または同様のツールを使用して書き込みを一時停止した後に変更されたデータの最終同期を完了します。 ソース システムに保留中のトランザクションが残っていないか確認し、データベース レプリケーションが完全にキャッチされていることを確認します。

6. データの整合性とワークロードの機能を検証します。 データベースの行数を比較して簡単なチェックを行うことができますが、検証を深める場合はチェックサムとハッシュ関数を使用することをお勧めします。 ファイル システムの場合は、MD5 ハッシュ関数を使用し、ファイルの数、サイズ、タイムスタンプを検証します。 認証やコア トランザクションなどの重要なワークロード機能を確認します。

7. トラフィックを新しい Azure ワークロードに転送します。 ユーザー トラフィックを Azure 環境に転送するように、DNS レコードとロード バランサーの構成を更新します。 ワークロードの正常性とパフォーマンスを監視します。

8. 移行後の包括的な検証と監視を実施します。 自動化されたテスト スイートを使用して、すべての重要なビジネス プロセスのエンドツーエンドの機能テストを実行します。 ソース システムとターゲット システム間のチェックサム検証とハッシュ関数の比較を使用して、データの精度を検証します。 すべての主要な機能が正しく動作することをアプリケーションの所有者に確認させます。 カットオーバー後の最初の 24 ~ 48 時間のシステム パフォーマンス、エラー率、およびユーザー アクセス パターンを監視して、パフォーマンスの低下や機能の問題を特定します。

ダウンタイムを伴う移行の実行

1. ソース システムへのすべての書き込み操作を停止します。 この手順により、移行中に新しいトランザクションが発生しないようにします。 続行する前に、すべてのトランザクションが完了していること、およびユーザーがロックアウトされていることを確認します。

2. すべてのデータを Azure に移行します。 データベース、ファイル、オブジェクト ストレージを Azure にコピーします。 データの種類とボリュームに応じて、Azure Migrate、AzCopy、Azure Database Migration Service (DMS) などのツールを使用します。 データ移行ツールを参照してください。

3. 移行後にデータの整合性を検証します。 チェックサム、行数、およびメタデータ比較を実行して、データの精度を確認します。 手動作業を減らし、信頼性を高めるために、使用可能な場合は自動化されたツールを使用します。

4. Azure 環境でアプリケーションをテストします。 エンド ツー エンドのテストを実行して、移行されたデータでアプリケーションが正しく機能することを確認します。 レポート、統合、バックアップ検証を含めます。

5. トラフィックを新しい Azure ワークロードに転送します。 Azure を指す DNS、ロード バランサー、アプリケーション構成を更新します。 接続の問題を監視し、リダイレクトが成功したことを確認します。

6. カットオーバー後にワークロード機能を検証します。 最終的なチェックを実行して、アプリケーションが安定しており、データが正確であることを確認します。 アプリケーション所有者と連携して、ビジネスクリティカルな機能を検証します。

フォールバック オプションを維持する

フォールバック オプションとしてソース環境を保持します。 ソース環境のリテンション期間により、許容できる期間内に解決できない重大な問題が発生した場合に、迅速な復帰が可能になります。 このフォールバック オプションは、安定化期間中のビジネス継続性保険を提供します。 ソース環境を使用可能な状態に保ち、必要に応じて DNS レコードを元に戻し、以前の構成を復元する機能を維持します。

移行の成功を検証する

移行後の検証では、ワークロードが正しく動作し、すべての要件を満たしていることを確認します。 この検証により、データの整合性が維持され、移行が成功したことが確認されます。 移行の完了を宣言する前に、包括的な検証を行う必要があります。

1. 正常なユーザー アクセスとシステム パフォーマンスを確認します。 ユーザー アクセスの検証により、Azure への移行が透過的になり、パフォーマンスが期待を満たすことが保証されます。 この確認は、ユーザーが中断することなくシステムにアクセスできることを検証します。 移行後の初期期間中に、ユーザー アクセス パターン、システム パフォーマンス メトリック、エラー率を監視します。

2. 完全な検証後にのみ、移行の成功を発表します。 完全な検証により、すべての関係者がワークロードが安定して機能していることを確認できます。 この確認により、後で問題が発生する可能性のある早期の成功宣言を防ぐことができます。 アプリケーションの所有者、テスト担当者、ビジネス利害関係者から、ワークロードがすべての要件を満たし、正常に動作していることを確認します。

安定化中のワークロードのサポート

サポート範囲が強化され、重要な安定化期間中に移行後の問題に迅速に対応できます。 このサポートにより、移行後に一般的に発生する問題をより迅速に解決できます。 専用のサポート モデルを確立し、運用ドキュメントを更新する必要があります。

1. 安定化期間中のサポート範囲の強化を確立します。 専用のサポート モデルにより、重要な安定化期間中に移行後の問題に迅速に対応できます。 このサポートにより、移行後に一般的に発生する問題をより迅速に解決できます。 経験豊富な IT スタッフまたは移行パートナーを割り当ててワークロードを注意深く監視し、通常の運用よりも短い SLA を提供します。

2. 構成管理とインベントリ システムを更新します。 構成管理の更新により、運用ツールとプロセスに新しい Azure 環境が確実に反映されます。 このメンテナンスにより、運用ドキュメントが最新の状態に保たれ、継続的な管理アクティビティがサポートされます。 既存のインベントリ ツールによって IP アドレス、CPU、メモリ、その他のインフラストラクチャの詳細が自動的に更新されることを前提として、新しいホスティング環境の構成管理データベース (CMDB) を更新します。

Azure のツールとリソース

次のステップ