この記事は、 アマゾン ウェブ サービス (AWS) から Azure にワークロードを移行する方法に関するシリーズの一部です。
計画フェーズは、次の手順で構成されます。
- ワークロードを評価します。
- 似たアーキテクチャを設計します。
- 移行計画を作成して文書化する。
計画フェーズの目的は、技術的およびビジネスの観点から既存の AWS ワークロードを理解し、Azure でレプリケートする計画を自信を持って構築できるようにすることです。
Important
計画フェーズで時間を取り、順番に手順に従います。 不完全な検出または不明確な移行目標は、期待値がずれ、依存関係が見逃されるリスクがあります。
AWS ワークロードを評価する
Azure で同等のシステムを構築するには、まず、現在のシステムを完全に理解する必要があります。 複数の観点から評価し、ユーザー、オペレーター、開発者、コンプライアンス、ビジネス利害関係者のニーズを均等に満たす Azure 実装を最終的に設計できるようにします。
既存のワークロード アーキテクチャを文書化します。 ワークロード アーキテクチャを完全に文書化して検証します。 ネットワーク構成、データ フロー、外部統合など、すべてのワークロードの依存関係を含めます。
ドキュメントの認証と承認: 評価に ID とアクセス管理 (IAM) の構成を含めます。 AWS による認証と承認の処理方法に関する包括的なドキュメントは、同等のセキュリティで保護された機能的な Azure を設計するうえで重要です。
探索ツールを使用する: AWS のワークロードを視覚化するには、 AWS 上のワークロード検出などの AWS 固有のツールを使用します。 このツールは、AWS Config と AWS Systems Manager のデータを使用して、ワークロードのコンポーネント、依存関係、およびリレーションシップを識別するのに役立ちます。 Azure Migrate などの Azure ツールを使用して、より多くの AWS ワークロード コンポーネントを検出し、Azure 固有の推奨事項を作成するのに役立ちます。
重要なフローを特定する: 重要なユーザーとシステムの相互作用と ワークフローをマップします。 次のセクションでターゲット アーキテクチャを設計する場合、この情報は信頼性の取り組みに優先順位を付け、最も重要で影響の大きいコンポーネントを障害から保護するのに役立ちます。
詳細なインベントリを作成します。 すべてのサーバー、ストレージ コンポーネント、データベース、サービスなど、ワークロードを実行するために現在の AWS 環境で必要なものの一覧を作成します。 また、使用パターン、パフォーマンス メトリック、ライセンス要件も含まれます。
対象分野の専門家 (中小企業) に関与する: 自動化された検出ツールに加えて、ワークロード チーム全体の専門家と連携して、非表示の依存関係、複雑なコンポーネントの関係、機密性の高い状態を明らかにします。 多くの場合、ツールでは、スケジュールされたスクリプト、文書化されていない統合、レガシ構成など、重要なコンポーネントが見落とされます。 中小企業との会話は、これらの微妙な違いを明らかにし、移行中の予期しない動作を防ぐことができます。 移行計画とRunbookに彼らの意見を含めます。
チームのスキルを評価します。 同様の機能マッピングに焦点を当てます。 チームが AWS で既に使用しているスキルを特定し、同等の Azure サービスとツールに合わせます。 プロジェクトタイムラインに Azure トレーニングを含め、ワークロードチームと運用チームを準備します。 AWS の既存のエクスペリエンスは新しい環境に直接変換されるため、このアプローチによって摩擦が軽減され、Azure との信頼度が高まります。
既存のコミットメントを文書化する: スループット、待機時間、エラー率、リソース使用率など、ワークロードの定義済みのパフォーマンス ベースラインを文書化します。 これらの主要業績評価指標 (KPI) を使用できない場合は、AWS 環境からこれらのメトリックを収集して、このベースラインを確立します。 これらの KPI は、移行後の評価フェーズで、Azure のワークロードが AWS と同様に実行されることを検証するために使用します。
ワークロードに関連付けられているサービス レベル アグリーメント (SLA) またはサービス レベル目標 (SLO) があるかどうかを確認します。 ユーザーまたは利害関係者に対するこれらのコミットメントは、クラウド プラットフォームに基づいて変わることはありません。 たとえば、AWS の目標復旧時間 (RTO) が 45 分の場合は、45 分の RTO も含まれるよう Azure でワークロードを設計する必要があります。
現在の監視とアラートを文書化します。 AWS で現在ワークロードを監視する方法を文書化します。 たとえば、CloudWatch のメトリック、アラーム、またはダッシュボードを使用できます。 ターゲット環境に対して同等の Azure 監視を計画します。 Azure Monitor ログ、メトリック、または Application Insights ダッシュボードを使用できます。 Azure ベースの監視とアラートを実装および管理する準備が整うので、運用チームはこの評価に参加します。
同様のアーキテクチャを Azure で設計する
多くのクラウドベースの最新のワークロードでは、多くの機能に仮想マシン (VM) ではなく、マネージド サービスまたはサーバーレス サービスが使用されています。 AWS ワークロードで Amazon Elastic Kubernetes Service (EKS) や Amazon Elastic Container Service (ECS) などのマネージド サービスを使用している場合は、ユース ケースに最適な Azure を見つける必要があります。 場合によっては、コンテナー化されたアプリなど、Azure に複数のサービスを選択できる場合があります。 最も似たサービスを選択します。 たとえば、移行中にコンテナー オーケストレーション プラットフォームを切り替えないでください。
次の図は、AWS と Azure 上の Kubernetes ワークロードに似たアーキテクチャの例を示しています。
似たアーキテクチャのマッピングを開始するには、最初に強固な基盤を確立します。
ネットワークから始めます。 ワークロードのネットワーク要件についてプラットフォーム チームと話し合います。 この説明では、ターゲット アーキテクチャと移行接続について説明する必要があります。 AWS トランジットゲートウェイは、Amazon Virtual Private Cloud (VPC) をスポークネットワークとして使用するネットワークハブとして機能します。 Azure アプリケーション ランディング ゾーンの設計では、プラットフォーム チームはスポーク仮想ネットワークをワークロード チームにプロビジョニングします。 これらのスポーク ネットワークは、ハブまたは Azure Virtual WAN ネットワークを介して他の内部および外部ネットワークと通信します。
移行中にデータを交換するには、AWS Direct Connect でサイト間仮想プライベート ネットワーク (VPN) または Azure ExpressRoute を使用できます。 小規模または概念実証 (POC) の移行には、サイト間 VPN を利用できます。 運用環境規模の移行または大規模なデータ転送には、AWS Direct Connect を使用した ExpressRoute をお勧めします。 信頼性を高めるために両方のオプションを使用する場合は、フェールオーバーにサイト間 VPN を使用します。
詳細については、「 AWS から Azure へのネットワークの移行」を参照してください。
ネットワークを計画したら、次の手順に従います。
Azure サービスを識別します。 AWS と Azure のリソース比較ガイド を使用して、ワークロードの Azure コンポーネントを選択できます。 POC を構築して信頼を得るか、コンポーネントとその構成を選択するのに役立ちます。 Azure Well-Architected Framework サービス ガイドを使用して、同様のアーキテクチャが機能的に同等であり、Azure のプラットフォーム特性とベスト プラクティスに合わせて最適化されていることを確認します。
ID 管理を計画する。 ユーザーとワークロード操作のために Azure で ID とアクセスを処理する方法を計画します。 ワークロードで AWS IAM ロールまたはフェデレーション ID プロバイダーを使用している場合は、これらのロールが Microsoft Entra ID ロール、マネージド ID、またはサービス プリンシパルにどのように変換されるかを決定します。 アプリケーションでハードコーディングされた Amazon リソース名 (ARN)、IAM ポリシー、または ID 統合を確認します。 ID マッピングを見落とす場合は、移行後のアクセスの問題や統合の破損が発生する可能性があります。 パートナー ID プロバイダーとの統合は、移行中の課題です。 可能であれば、Microsoft Entra ID に移行して ID 管理を統合します。
移行に関する決定事項を文書化します。 移行しないリソースと、実行するアーキテクチャの決定を文書化します。
リスクを軽減します。 リスクの高いコンポーネントまたはフローを特定し、それらのリスクをテストして軽減するために必要に応じて POC を構築します。 コンポーネントに 対して障害モード分析 (FMA) を実行して、潜在的な障害点を事前に見つけて、それらがワークロードの信頼性に与える影響を評価します。 Azure コンポーネントに新しい障害モードがあるか、AWS の対応するコンポーネントとは異なる方法で失敗する場合があります。
可用性を確認します。 特に特殊なリソースの種類を使用する予定の場合は、お好みのリージョンで Azure サービスの可用性と容量を確認します。 ターゲットリージョンを選択したら、現在の AWS リージョンに合わせて調整します。 地理的に似た Azure リージョンに移行すると、一貫した待機時間を維持できます。
要件を検証します。 Azure Migrate を使用する場合は、 Azure Migrate のサポート マトリックス を確認して、AWS インスタンスがオペレーティング システム (OS) と構成の要件を満たしていることを確認します。 Azure Migrate を使用しない場合は、ワークロードと Azure サービスの互換性を手動で確認します。 このチェックには、サポートされている OS のバージョン、VM サイズ、ディスク構成、およびネットワークの依存関係の確認が含まれます。
コンプライアンスとセキュリティの要件を満たす。 ワークロード内で同じセキュリティ体制を維持します。 Azure の実装が、OS セキュリティの修正プログラムの適用、ネットワークの分離、イングレスとエグレスの検査、最小特権アクセス、静的コード分析、侵入テストのスケジュールなどのセキュリティの期待と一致していることを確認します。
移行を容易にするために作成する一時的なインフラストラクチャ、ネットワーク接続、プロセスもセキュリティの期待を満たしていることを確認します。 移行は混乱を伴うことがあり、移行中にセキュリティの見落としやショートカットをすると、インシデントが発生する可能性があります。
AWS が使用するセキュリティ モデルは、Azure セキュリティ モデルとは大きく異なります。 詳細については、「 AWS からセキュリティ サービスを移行する」を参照してください。
移行計画を開発して文書化し、Runbook を作成する
移行計画を作成し、AWS から Azure への移行用の Runbook を作成します。 カットオーバー戦略を選択し、復旧ポイント目標 (RPO) の要件に基づいてデータ移行アプローチを選択し、詳細な Runbook の手順を文書化します。 リスクを最小限に抑え、制御された移行を保証する、利害関係者が承認した包括的な計画を作成します。
カットオーバー戦略
AWS 環境から Azure 環境への運用トラフィックを削減する方法を計画します。 最も一般的な方法は次のとおりです。
- Big Bang の移行: メンテナンス期間中は、すべてを同時に移行して切り替えます。
- 段階的な移行: ワークロード コンポーネントは段階的に移行します。
- 青緑色の移行 (推奨): 2 つの環境が並列で実行され、検証後にトラフィックを切り替えます。
主な相違点
| 戦略 | 稼働停止時間 (ダウンタイム) | リスク レベル | コストの影響 | ロールバックの容易さ |
|---|---|---|---|---|
| ビッグバン | High | High | 低 | 困難 |
| 段階的に | 低 | ミディアム | ミディアム | 適度 |
| ブルーグリーン | 低 | 低 | High | Easy |
リスクを低く抑え、ロールバックを簡単にするには、青緑色のアプローチを選択します。 このシナリオでは、2 つの環境を維持します。 青は現在の環境 (AWS) で、緑は新しい環境 (Azure) です。
青緑色のシナリオでは、移行期間を計画し、移行全体を通じて AWS でワークロードを実行し、ドライランが成功した後にトラフィックを Azure に移動します。 どちらの環境も移行全体で並列に実行されるため、Azure 環境で問題が発生した場合にトラフィックを AWS に戻すことができます。 このシナリオでは、変更される可能性のある状態のロールバック戦略も必要です。 メッセージ キュー内の未処理の項目など、データベースとあまり明確でない状態を考慮してください。
ワークロードがより複雑で、リスクを最小限に抑えたい場合は、ブルーグリーン戦略とカナリア アプローチを組み合わせてトラフィックを切り替えることができます。 カナリア アプローチでは、トラフィックのごく一部を新しい環境にルーティングし、その量を徐々に増加させます。 カナリア アプローチでは、移行中にライブ状態が AWS と Azure の両方に存在する必要があるため、移行の複雑さが増します。
AWS 上のコンポーネントが Azure 上で実行されるコンポーネントと共存する場合は、制御されたカットオーバー戦略の一部として 、Strangler Fig ファサード のようなパターンを適用することを検討してください。 これらの間接参照の追加レイヤーは、移行の次のフェーズで実装します。
青緑色のアプローチでは、コストのトレードオフが生じます。 移行中に両方のクラウド プロバイダーのコストが発生します。 ほとんどのチームでは、ブルーグリーン戦略によってリスクと運用上の負担が軽減されるため、追加コストは価値があります。
メンテナンス期間を計画する
使用するカットオーバー戦略の計画フェーズでは、寛大なメンテナンス期間をネゴシエートすることをお勧めします。 十分なウィンドウでは、移行アクティビティの機密性の高い性質が考慮され、移行中の機能の損失が考慮されます。 この計画的なダウンタイムを使用して、データ損失、データ破損、または一貫性のないユーザー エクスペリエンスのリスクを軽減する計画を策定します。 たとえば、この時間を使用して、Amazon Simple Queue Service (SQS) メッセージを処理します。
ワークロードに停止予算がある場合は、その予算から移行期間を除外し、移行後の問題に備えて予約することを検討してください。 この決定が契約 SLA にどのように影響するかを検討します。
データ移行戦略を選択する
データ移行戦略は、データの量、データ ストレージの種類、および使用要件によって異なります。 オフライン移行 (バックアップと復元) とライブ レプリケーションを決定します。
戦略をワークロードの RPO に合わせます。 使用停止フェーズ中およびデータベース移行戦略を選択する場合は、ワークロードの RPO を参照して決定を導きます。 RPO は、カットオーバーの一部として受け入れることができるデータ損失の最大量です。 たとえば、RPO では、カットオーバー中に 5 分を超えるデータ損失が許容されない場合があります。 切り替える前にワークロード内の状態変更操作をシャットダウンすることで、データ損失のリスクを最小限に抑えます。
RPO が低いほど、継続的レプリケーションまたは最近のバックアップとメンテナンス期間を考慮する必要があります。 RPO を低くすると、データを移行するためのコストと労力も増加する可能性があります。
データベースを移行します。 データベースの移行のために AWS と Azure のツールを評価します。 たとえば、Azure Data Studio を使用して、 Amazon Relational Database Service (Amazon RDS) for SQL Server を Azure SQL Database にレプリケートできます。 この機能は、Amazon RDS から SQL Database への継続的レプリケーションをサポートします。 または、 AWS Database Migration Service (AWS DMS) を使用できます。これにより、カットオーバーするまで継続的なレプリケーションと変更データキャプチャが提供されます。
ほとんどのシナリオでは、データ移行は複数のフェーズで行われます。 たとえば、テストと検証のために最初の移行を行い、最後のカットオーバー移行または継続的な同期を実行してデータの鮮度を確保できます。 このアプローチにより、チームは最終的なカットオーバーの前に Azure でのアプリケーションの動作を検証できます。 また、データ損失のリスクを軽減し、ロールバック計画をサポートします。
ストレージ データを転送します。 Amazon Simple Storage Service (Amazon S3) から Azure にストレージ データを転送するには、次のオプションを検討してください。
| Tool | 目的 |
|---|---|
| AzCopy | CLI を使用してデータをすばやく一括転送します。 |
| Azureデータファクトリー | エンタープライズ レベルのオーケストレーションと変換の負荷の高いデータ転送を提供します。 |
| AWS DataSync | ファイルの転送と、AWS から Azure への非構造化データのレプリケーションを自動化します。 |
ヒント
AWS DataSync を選択した場合は、 準備フェーズ中に DataSync エージェントを Azure にデプロイする必要があります。
メンテナンス期間を計画します。 最終的なカットオーバーと使用停止の手順の専用ウィンドウをスケジュールします。 移行を開始する前に、関係者にドキュメントを作成して伝えます。 可能なロールバックとドメイン ネーム システム (DNS) スイッチの時間を含めます。
ランブックに記載する
移行に関係するすべてのチームと利害関係者と共有するために、Runbook で次の情報を文書化します。
一連の手順: 手順のシーケンスを大まかに文書化します。 正確な手順、その順序、移行のタイミングを定義します。 計画メンテナンス期間をドキュメントに含めます。 特に複雑なカットオーバーの場合は、ドライ ランを実施することを考慮します。 ロールバック戦略、DNS Time to Live (TTL)、成功メトリックをテストする方法を文書化します。
セキュリティとネットワークの構成: Azure 接続をサポートするために必要なすべてのファイアウォール規則の変更、必要なポートの開放、ネットワーク セキュリティ グループ (NSG) またはアプリケーション セキュリティ グループ (ASG) の更新を含めます。 カットオーバー中に必要な一時的な例外またはオーバーライドを文書化し、ロールバック プロシージャがこれらの変更を考慮していることを確認します。
サインオフの受け入れ条件:安定した操作の意味を定義し、測定可能にします。 たとえば、カットオーバー後、Azure はエラーなしで特定の数分間または数時間実行する必要があり、ワークロードはすべてのテストに合格することに同意します。
ロールバック トリガーの条件と手順: AWS 環境へのロールバックをトリガーする正確な条件を文書化します。 たとえば、重要な機能がダウンしている場合や、システムがベースラインより下の特定の割合のように、指定した分数を超える低下状態にある場合は、ロールバックを開始します。 ロールバック手順を文書化します。
状態の変化によっては、Azure の問題を軽減するよりもロールバックが複雑になる場合があります。 軽減策の試行が失敗すると、ロールバックが複雑になる可能性もあります。 問題を修正するタイミングと、移行中のリスクを軽減するために変更をロールバックする必要があるタイミングを理解します。
クライアント構成の変更: ワークロードの移行が影響を受けるクライアント側のすべての構成項目を特定して文書化します。 これらの項目には、DNS エンドポイント、認証フロー、接続文字列が含まれます。 クライアント チームを早期に関与させ、今後の変更、タイムライン、責任を伝えます。
トラフィックとルーティングの変更: トラフィック ルーティングの変更を詳細に計画して文書化します。 DNS レコード、ロード バランサーの構成、およびルーティング規則を更新して、トラフィックを Azure に送信する方法を正確に定義します。 DNS の変更が反映されるまでの時間が決まりますので、構成する TTL 値を検討してください。
多くのアプリケーションとスクリプトは、エンドポイント、API、およびサービスの完全修飾ドメイン名 (FQDN) を参照します。 移行中に FQDN が予期せず変更された場合、統合が中断する可能性があります。 ルーティングとカットオーバーの計画の一環として、ワークロードで使用されるすべての FQDN のインベントリを作成します。 DNS 転送を使用して既存の名前を保持するか、新しい Azure FQDN を使用するようにアプリケーション構成を更新するかを決定します。 公開サービスの場合は、ダウンタイムを最小限に抑え、スムーズな移行を確実にするために、DNS のカットオーバーを慎重に計画してください。
注意事項
トラフィック ルーティングを明示的に計画しないのは、予期しないダウンタイムにつながる一般的な落とし穴です。
利害関係者と計画を確認し、異なる期待を調整します。 最初から IT セキュリティチームとリスク管理チームを含め、計画を確実に承認します。 この段階での共同ワークショップは、後の段階での遅延を最小限に抑えるのに役立ちます。
利害関係者と意思決定者が計画と Runbook を確認して同意したら、準備フェーズに進みます。
出力と成果物
計画フェーズの最後に、次の項目が配置されている必要があります。
- ターゲット アーキテクチャの図
- アーキテクチャ決定レコード (ADR)
- 予算とコストの見積もり
- 移行ランブックとタイムライン
- 移行計画の利害関係者の承認
Checklist
| 成果物に直結するタスク | |
|---|---|
| ☐ | 既存のワークロード アーキテクチャを文書化する |
| ☐ | ドキュメントの認証と承認 |
| ☐ | 探索ツールを使用する |
| ☐ | 重要なフローを特定する |
| ☐ | 詳細なインベントリを作成する |
| ☐ | アプリケーション チームに参加する |
| ☐ | スキルを評価する |
| ☐ | 文書の主要業績評価指標 |
| ☐ | 監視と運用のハンドオフを計画する |
| ☐ | ネットワーキングに対処する |
| ☐ | 一致する Azure サービスを識別する |
| ☐ | ID 管理を計画する |
| ☐ | 移行に関する決定事項を文書化する |
| ☐ | リスクを軽減する |
| ☐ | リソースの可用性を確認する |
| ☐ | Azure Migrate を使用する場合の要件の検証 |
| ☐ | コンプライアンスとセキュリティの要件に対処する |
| ☐ | カットオーバー戦略の選択 |
| ☐ | データベース移行戦略の選択 |
| ☐ | ストレージ移行戦略の選択 |
| ☐ | メンテナンス期間を計画する |
| ☐ | 手順のシーケンスを記録する |
| ☐ | セキュリティとネットワークの構成を文書化する |
| ☐ | ドキュメントのサインオフの受け入れ条件 |
| ☐ | ロールバック トリガーの条件と手順を文書化する |
| ☐ | クライアント構成の変更を文書化して伝達する |
| ☐ | トラフィックとルーティングの変更を文書化する |