この記事シリーズでは、アマゾン ウェブ サービス (AWS) から Azure に 1 つのワークロードを移行するための規範的で実用的なガイダンスをアーキテクトとエンジニアに提供します。 計画と準備から、AWS リソースの実行、評価、使用停止までの完全な移行ライフ サイクルについて説明します。
このシリーズでは、単純なものから中程度に複雑なものまで、組織内の他のワークロードからほとんど独立したワークロードに焦点を当てています。 ミッション クリティカルなワークロードをカバーしません。
AWS からのワークロードの移行は、慎重な計画と利害関係者の調整を必要とする戦略的イニシアチブです。 確実な移行計画と適切な準備がないと、計画外の中断が発生するリスクがあり、ワークロードの信頼性が損なわれる可能性があります。
ワークロード移行戦略
同様の移行戦略は、リスクを最小限に抑え、通常は Azure への最も安全なパスです。 このアプローチを使用すると、ワークロードは既存のアーキテクチャと運用パターンを引き続き使用します。 移行が最も成功するのは、スコープの拡大を避け、既存の技術的負債の返済やワークロードホスティングの移行中に最適化を導入しない場合です。 目標は、移行されたワークロードが、AWS で満たされたのと同じ主要業績評価指標 (KPI) を Azure で満たすことです。 同じサービス レベル アグリーメント (SLA)、サービス レベル目標 (SLO)、およびワークロードに現在存在するバグを維持する必要があります。
ヒント
移行中の変更を最小限に抑え、パフォーマンスと安定性の検証に重点を置きます。 移行が完了したら、技術的負債の返済とさらに最適化を調べることができます。
推奨されるツール
必要に応じて AWS と Azure のツールを使用して、移行プロセスを強化します。 これらのツールは、次のタスクをサポートします。
- 事前検出
- AWS ワークロードに関して収集されたデータに基づく Azure アーキテクチャの計画
- データとコンピューティング プラットフォームの転送
- 移行後の検証
- リソースのクリーンアップ
AWS で Workload Discovery を使用してワークロードを評価します。 AWS ツールと Azure Migrate などの Azure ツールを組み合わせて、AWS インスタンスを評価し、Azure リソースのサイズ設定に関する推奨事項を提供できます。 必要に応じて、Microsoft 以外のソリューション ( Dr Migrate や CAST Highlight など) を調べて、コード分析、依存関係マッピング、移行準備の評価を支援できます。
タイムラインの前提条件
ワークロードの移行は、数週間または数か月に及ぶ可能性があります。 期間は、ワークロードの複雑さと、移行とカットオーバーの戦略によって異なります。 次のタイムラインは、中程度に複雑なワークロードに対して同様のアプローチを使用する一般的なワークロード移行を示しています。 中程度に複雑なワークロードには、通常、複数のコンポーネントと依存関係が含まれますが、ミッション クリティカルではなく、他のシステムと深く統合されません。
負荷作業チームの責任
現在 AWS のワークロードを担当しているチームは、通常、Azure のワークロードも担当します。 このチームはワークロードを移行する必要があります。 ワークロード チーム外のタレントに移行をアウトソーシングすると、次の結果が生じる可能性があります。
- プロセスの後半で予期しない検出が発生する
- トレーニング不足のワークロード チーム
- 所有権の低下
多くの場合、Azure の専門知識を持つ外部パートナーと連携して移行をサポートできます。 これらのパートナーには、システム インテグレーターと Microsoft Industry Solutions Delivery チームが含まれます。 彼らは計画と準備をリードできますが、ワークロード チームは、パートナーが開発した Runbook と自動化を使用して運用のカットオーバーを実行します。
ワークロード チームは、プロセスの一環として移行の専門家と相談する必要がありますが、チームはプロセスを推進し、密接に関与し続ける必要があります。
[前提条件]
移行を計画する前に、次の前提条件が満たされていることを確認してください。
以前のエクスペリエンス: コア クラウドの概念と AWS に関する経験と、Azure サービスとクラウド移行プロセスの基本的な理解が必要です。
利害関係者の連携: すべての関係者が一致するように、タイムライン、予算見積もり、プロジェクトマイルストーンを関係者と共有し、同意する必要があります。
サポート戦略: Microsoft サポート プランを購入し、無料またはコミュニティ サポートのオプションを調査します。
プラットフォーム戦略: このシリーズでは、1 つのワークロードを移行する方法について説明します。 プラットフォームの基盤が整っており、移行戦略が定義され、 Azure のクラウド導入フレームワークと一致していることを前提としています。
この戦略の一環として、既存の プラットフォーム ランディング ゾーンを確立します。 移行されたワークロードはアプリケーション ランディング ゾーンになり、組織の Azure ランディング ゾーン トポロジの一部になります。 これは、管理グループ階層の下に存在し、特定のネットワークに接続するか、特定のネットワークから分離されたままで、必要なガバナンス ポリシーに従います。
トレーニングまたはパートナー サポートへの投資: チームの Azure スキルを評価し、必要に応じてトレーニングまたはパートナー サポートを計画します。
移行の準備状況の評価も行う必要があります。 この評価は、10 のディメンション間で移行する準備状況をスコア付けします。 評価の後、要件と制約を収集し、バイインを確保するために、すべての利害関係者を含むキックオフ ワークショップを開催します。
ワークロードを計画して正常に移行するには、次の順序で 5 つのフェーズを進めます。
各フェーズには、移行プロセスをガイドする詳細な手順とチェックリストが含まれています。
Important
各フェーズを通じて、運用チームを巻き込み、運用準備を整えるようにします。 タスクには、ワークロード の監視 と アラート 、正常性ダッシュボードの実装 が含まれます。 運用チームが Azure でワークロードを管理できるように、正式な引き渡しを計画します。 たとえば、移行の完了後に、AWS CloudWatch に似た Azure Monitor ダッシュボードとアラートを設定できます。