この記事は、 アマゾン ウェブ サービス (AWS) から Azure にワークロードを移行する方法に関するシリーズの一部です。
準備フェーズは、次の手順で構成されます。
- 環境を準備します。
- アプリケーションを準備します。
このフェーズの目的は、移行のために既存のワークロードを準備することです。 移行を開始する前に、できるだけ多くのワークロード インフラストラクチャとコードを Azure にデプロイします。 適切な準備を行うと、移行中に費やされる労力が削減され、十分なテスト機会が得られます。
このフェーズでは、Azure 環境を構築し、必要に応じてコードをリファクタリングし、継続的インテグレーションと継続的デリバリー (CI/CD) のツールとパイプラインを設定し、テストを実行して移行アプローチの信頼性を高めます。
Important
このフェーズでは時間を取ってください。 インフラストラクチャが正しく構成されていない、テストが不十分な、またはチームの準備ができていないと、移行中に遅延、セキュリティの脆弱性、またはデプロイの失敗が発生する可能性があります。
環境を準備する
アプリケーションランディングゾーンをプロビジョニングします。 Azure ワークロードの設計を Azure プラットフォーム チームに提供して、運用前および運用環境のワークロード環境用に Azure アプリケーション ランディング ゾーン をプロビジョニングできるようにします。
移行ツールを設定します。 実行フェーズに Azure Migrate を使用する予定の場合は、Azure Migrate アプライアンスをデプロイし、Azure Migrate プロジェクトを構成します。 このアプローチにより、カットオーバーする前にすべてのターゲット Azure リソースと検出プロセスの準備が整います。
Azure インフラストラクチャをデプロイして構成します。 リソースをデプロイするには、コードとしてのインフラストラクチャ (IaC) を使用します。 この方法により、一貫性と再現性が確保されます。 チームが引き続き Terraform を使用してデプロイ スクリプトを記述する場合は、Azure リソースの新しいスクリプトとモジュールを記述する必要があります。 既存のデプロイ スクリプトで AWS CloudFormation を使用する場合は、 Bicep を使用して Azure にデプロイします。 運用環境に進む前に、最初に非運用環境に焦点を当て、すべてを検証します。
環境を調整し続けるために、Azure の CI/CD パイプラインを更新します。
デプロイ パイプラインを変更して、Azure サービスをターゲットにします。
サービス接続を構成し、ビルドとリリースのワークフローで、選択した Azure コンピューティング リソース (Azure App Service、Azure Kubernetes Service (AKS)、Azure Virtual Machines など) をデプロイできることを確認します。
青緑色のアプローチを使用する場合は、移行中に AWS と Azure の両方にワークロードをデプロイできることを確認します。 たとえば、緊急の修正プログラムを適用したり、ロールバックをサポートしたりする必要がある場合があります。
インフラストラクチャをテストします。 Azure Virtual WAN またはハブ ネットワーク、および AWS Direct Connect、Azure ExpressRoute、仮想プライベート ネットワーク (VPN) 接続などの他の基本サービスを検証します。 ターゲット ワークロードと移行プロセスがサポートされていることを確認します。 Azure 環境と AWS 環境全体のエンドツーエンドの接続を検証します。 Azure Chaos Studio を使用して、仮想マシン (VM) やネットワークの停止などの潜在的な障害をシミュレートします。 このような状況で、移行されたワークロードの回復性を維持します。
ネットワークとセキュリティをテストします。 ネットワーク セキュリティ グループ (NSG)、ファイアウォール、ポリシーを設定するときに、アプリケーションが必要なすべてのサービスと通信できることを確認します。 接続テストを実行して、セキュリティ設定が厳しすぎるか、または緩すぎることがないように確認します。 必要に応じて設定を調整して、セキュリティと機能を維持します。
必要なすべてのポートが Azure と AWS 環境の間で開かれていることを確認します。
ファイアウォール規則と NSG またはアプリケーション セキュリティ グループ (ASG) の構成を検証します。
移行中に必要な一時的なセキュリティ例外を文書化します。
ロールバック 計画で、セキュリティ関連の変更を元に戻す必要があることを確認します。
アプリケーションを準備する
ワークロードの古い部分を削除します。 AWS ワークロードに、使用しない機能、インフラストラクチャ、または運用プロセスがある場合は、ワークロードからそれらを削除します。 この手順により、移行の対象領域を減らし、インフラストラクチャとテストを狭くすることができます。
AWS の運用ワークロードへの変更を最小限に抑えます。 移行に取り組む際には、ワークロードへの変更を最小限に抑えます。 新しいインフラストラクチャ、機能、または依存関係を導入する変更は避けてください。これにより、移行が危険にさらされる可能性があります。
アプリケーションのコードをリファクタリングします。 機能フラグを使用して、AWS と Azure 環境間の機能と構成の管理を簡略化します。
AWS 固有のライブラリと SDK を置き換えます。 多くのアプリケーションは、ストレージ、メッセージング、または認証のために AWS ネイティブ ライブラリまたは SDK に依存しています。 これらのライブラリと SDK は、通常、Azure サービスと互換性がありません。 リファクタリング中に、AWS 固有のライブラリを特定し、Azure と同等のライブラリまたはプラットフォームに依存しない代替手段に置き換えます。 この手順は、実行時エラーを回避し、アプリケーションが Azure サービスと統合されることを保証するのに役立ちます。
ヒント
GitHub Copilot などのツールは、開発者が AWS 固有のコード (SDK 呼び出しやサービス統合など) を特定し、Azure と互換性のある同等のコードにリファクタリングするのに役立ちます。 Copilot を使用して移行を加速し、手動での作業を減らします。
クライアント構成の変更を調整します。 クライアント側のすべての構成変更を実装して検証します。 クライアント チームがエンドポイント、認証、接続の更新をテストするための実稼働前環境を提供します。
運用機能を準備します。 運用チームと協力して、Azure にワークロード監視を実装します。 AWS CloudWatch アラームと同等のダッシュボードとアラート ルールを使用して、Azure Monitor または Application Insights を設定します。 これらのツールで運用チームをトレーニングします。 セキュリティ チームと協力してセキュリティ監視を実装し、Azure アーキテクチャを検証します。 Azure でワークロードのルーチン、計画外、緊急運用タスクを実行できることを検証します。
ワークロードの準備と Azure 環境の構築の詳細については、「 クラウドのワークロードを準備する」を参照してください。
Checklist
| 成果物に直結するタスク | |
|---|---|
| ☐ | アプリケーションランディングゾーンをプロビジョニングする |
| ☐ | Azure インフラストラクチャのデプロイと構成 |
| ☐ | Azure の CI/CD パイプラインを更新する |
| ☐ | テスト インフラストラクチャ |
| ☐ | ネットワークとセキュリティをテストする |
| ☐ | ワークロードの古い部分を削除する |
| ☐ | AWS での運用ワークロードへの変更を最小限に抑える |
| ☐ | アプリケーションのコードをリファクタリングする |
| ☐ | AWS 固有のライブラリと SDK を置き換える |
| ☐ | クライアント構成の変更を調整する |
| ☐ | 運用関数を準備する |