Azure Migration Hub には、ワークロード チームが Azure への移行を計画して実装するのに役立つ、規範的で意見に即したガイダンスが用意されています。 オンプレミス環境と、アマゾン ウェブ サービス (AWS) や Google Cloud Platform (GCP) などのクラウド プラットフォームからの移行について説明します。
Important
このコンテンツでは、単一ワークロードの移行について説明します。 データセンターの完全な移行、リージョンの再配置、または複数のクラウドで同時に実行されるハイブリッド ワークロードについては説明しません。
Azure への移行には、ネットワーク、ID、データベース、コンピューティング、ストレージ、チームが長年にわたって構築したカスタム統合が含まれます。 これらのコンポーネントのガイダンスは、複数の記事とガイドで提供されています。
この記事は、状況に適用されるガイダンスを特定するのに役立ちます。 ワークロードが現在実行されている場所に基づいて、適切な移行ガイドに移動します。 また、一般的な移行の用語と戦略についても説明します。
この記事を読む必要があるユーザー
この記事は、ワークロードアーキテクトとエンジニアが、AWS、GCP、またはオンプレミスのデータセンターから Azure へのワークロードの移行を開始するのに役立ちます。 このガイダンスを使用して、リホスト、リプラットフォーム、またはリファクタリングを行う必要があるかどうかを決定します。
このガイダンスの目的は次のとおりです。
アーキテクチャの側面を再設計し、Azure のビジネス要件を満たすように全体的な設計を検証するワークロード アーキテクト。 アーキテクトは、ワークロードの特定の特性とビジネス上の制約を考慮して、ギャップに対処します。
移行中および移行後に責任がどのように変化するかを理解する必要があるワークロード チーム メンバー。 たとえば、Amazon Relational Database Service でスクリプトを管理し、毎日のバックアップを実行するデータベース管理者は、Azure SQL Database で同じタスクを実行するように調整する必要があります。
この記事では、シナリオに合わせて特定の移行ガイドを紹介するため、すぐに計画を開始できます。
移行戦略
移行戦略は、リスク、労力、報酬によって異なります。 ワークロードの複雑さ、タイムライン、および必要な変更レベルに基づいて戦略を選択します。
リホスト (リフトアンドシフト): コードを変更せずにワークロードを Azure インフラストラクチャに移動します。 このアプローチは高速でリスクが低いです。 速度が最も重要な単純なワークロードに適しています。 たとえば、Windows Server 仮想マシン (VM) から Azure VM に Web アプリケーションを移行できます。 ワークロードのアーキテクチャやコードを変更することなく、Azure インフラストラクチャの利点を得ることができます。 Web アプリケーションの実行方法ではなく、Web アプリケーションの実行場所を変更します。
リプラットフォーム (リフト、調整、シフト): Azure プラットフォーム サービスを利用するために最小限の変更を行います。 たとえば、SQL Server データベースを Azure SQL Managed Instance に移行して、アプリケーションを書き換えることなく運用上の利点を得ることができます。
リファクタリング： ワークロードの外部動作を変更することなく、パフォーマンス、スケーラビリティ、または保守容易性を向上させるためにコードを再構築します。 たとえば、Windows 固有のファイル パス処理、セッション状態処理、ローカル ディスク ログを置き換えて、Azure App Service で実行するモノリシック .NET アプリケーションをリファクタリングします。 リファクタリングには、より多くの事前作業が必要ですが、長期的な運用オーバーヘッドが削減されます。
再設計: Azure ネイティブ機能を最大限に活用するようにワークロードを再設計します。 たとえば、VM や SQL Server の代わりに Azure Functions と Azure Cosmos DB を使用するように Web アプリケーションを再設計します。 このアプローチでは、コードを大幅に変更する必要がありますが、スケーラビリティ、パフォーマンス、コストが最大限に向上します。
引退： 不要になったワークロードの使用を停止します。 この戦略は、古いワークロードや冗長なワークロード、またはサービスとしてのソフトウェア (SaaS) ソリューションが機能を置き換えることができる場合に使用します。 たとえば、データを Azure Files に移行した後、オンプレミスのファイル サーバーを廃止し、新しい場所にあるファイルにアクセスするようにユーザーをトレーニングします。
置き換える： 既存の実装を移行するのではなく、すぐに使用できるクラウド サービスを採用します。 SaaS ソリューションがワークロードを Azure に移行するよりも要件を満たしている場合は、このオプションを検討してください。
再 構築： 他の移行戦略のコストがメリットを上回る場合は、新しい実装を作成します。 再構築は、クラウドで効果的に実行するために基本的な変更を必要とするレガシ ワークロードに適しています。 たとえば、既存のコードベースを維持するのが難しい場合や、Azure サービスとうまく連携しない場合に、Dynamics 365 を使用してカスタム顧客関係管理 (CRM) システムを再構築します。
保持： コンプライアンス、待機時間、または技術的な制約によって移行が実用的でない場合は、ワークロードをオンプレミスに保持します。 たとえば、簡単にリホストまたはリファクタリングできないレガシ メインフレーム システムや、Azure への明確な移行パスがないレガシ メインフレーム システムを保持します。
Azure Migration Hub のほとんどのワークロード移行では、 リホストまたは再プラットフォームアプローチが 使用されます。 これらの戦略は、ワークロードを機能的に同じ状態に保つことでリスクを最小限に抑えます。 機能は、ソース プラットフォームで満たされたのと同じ主要業績評価指標 (KPI)、サービス レベル アグリーメント (SLA)、および Azure 上のサービス レベル目標 (SLO) を満たしている必要があります。 最初に移行を完了してから、最適化と最新化を行います。
詳細については、「 クラウド移行戦略の選択」を参照してください。
移行の過程
すべての移行は、5 つのフェーズに従います。 一部のフェーズは重複しており、ワークロードの要件の詳細を確認する前のフェーズを再検討することもできますが、このシーケンスは進行状況の追跡に役立ちます。
| Phase | タスク | 結果 |
|---|---|---|
| Plan | 現在のワークロードを評価し、依存関係を特定し、ソース サービスを Azure と同等のサービスにマップし、成功条件を定義します。 | 移行スコープ、必要な変更、および完了条件の明確なドキュメント。 |
| 準備 | ランディング ゾーン、ネットワーク、ID、ガバナンスなど、Azure 環境を設定します。 ターゲット状態アーキテクチャを設計します。 | ワークロードを受け取る準備ができている構成済みの Azure 環境。移行が開始される前にすべてのアーキテクチャ上の決定が解決されました。 |
| 実行 | インフラストラクチャ、データ、およびアプリケーション コンポーネントを移行します。 反復的なテストとカットオーバーを実行します。 | Azure に移行されたワークロード コンポーネント。 ワークロードの検証が成功した後に Azure にリダイレクトされた運用トラフィック。 |
| Evaluate | 移行されたワークロードが、フェーズ 1 で設定したベースラインに対する機能、パフォーマンス、セキュリティ、コストの要件を満たしていることを検証します。 | 移行が成功し、ワークロードが Azure で正しく実行されていることを確認します。 |
| 廃止 | ソース環境を廃止します。 リソースの削除、サブスクリプションの取り消し、古いプラットフォームのシャットダウン。 | ソース ワークロードがシャットダウンされます。 Azure でワークロードが排他的に実行されるようになりました。 |
移行ガイダンス
このセクションでは、Azure が提供する移行ガイダンスの種類を示します。 各ガイドは、移行の計画と管理に役立ちます。
Azure におけるクラウド導入フレームワーク
Azure のクラウド導入フレームワークでは、組織レベルの計画について説明します。 移行を構成する方法、実行する手順、ワークロードを移動する前に設定する方法について説明します。
Azure を初めて使用する場合は、ここから始めます。 クラウド導入フレームワークでは、組織の準備について説明します。 Azure 登録のセットアップ、プラットフォームランディング ゾーンの構成、移行計画の優先順位付けについて説明します。 ワークロードを移動する前に、これらの基本的な手順を完了してください。
Azure アーキテクチャ センター
Azure アーキテクチャ センターには、Azure でワークロードを構築するためのソリューションのアイデア、アーキテクチャ、設計パターン、アーキテクチャ ガイドが用意されています。
ほとんどの移行には、再プラットフォーム化が含まれます。 インフラストラクチャと管理レイヤーの両方をソース クラウドから Azure に移動します。 すべてのソース コンポーネントに直接同等の Azure があるわけではないため、アーキテクチャの一部を再設計する必要がある場合があります。 Azure アーキテクチャ センターには、 テクノロジの選択肢 の概要が示され、最も近い一致を見つけるのに役立ちます。
Azure Well-Architected Framework（アジュール ウェルアーキテクテッド フレームワーク）
Azure Well-Architected Framework には、信頼性が高く、セキュリティで保護され、コスト効率が高く、効率的なクラウド システムを構築するための原則が用意されています。 これには、Azure サービスの一般的なアーキテクチャ ガイダンスとサービス固有のガイドが含まれています。 これらのガイドでは、ワークロードのアーキテクチャ上の決定に役立つ主要なベスト プラクティスについて説明します。 これらを使用して、移行後のアーキテクチャを評価し、改善する領域を見つけます。
ソース プラットフォームから始める
開始するには、ワークロードとそのサービスの機能を、最も近い Azure に対応する機能と比較します。 次の記事には、シナリオの例と、比較を示すサービス レベルの移行ガイドが含まれています。
移行用のツール
ソース プラットフォームに関係なく移行タスクをサポートするには、次のツールを使用します。 これらは、ビジネス目標に対する移行の成功を測定するのに役立ちます。
| Tool | 目的 |
|---|---|
| Azure 移行 と 近代化 | インフラストラクチャ、アプリケーション、データ コンポーネントなど、移行資産を検出して評価します。 |
| Well-Architected ソース プラットフォームの評価を確認する | ソース プラットフォームでアーキテクチャのビジネス目標を確認して測定します。 ソース クラウド プロバイダーからのこの評価は、Azure での期待に対するベースラインを設定するのに役立ちます。 |
| Azure Well-Architected レビューの評価 | アーキテクチャの決定を評価して、ソース ベースラインから回帰を特定し、最適化の機会を探ります。 |
次のステップ
クラウド導入フレームワークでは、移行シーケンス、ウェーブ計画、依存関係マッピング、利害関係者の配置について説明します。 組織レベルの計画や移行戦略の選択については、「 移行の計画」を参照してください。