【マルチクラウド】Azure Migrate をプライベートネットワークで使用する全体像をまとめてみた【クラウド移行】

こんにちは、DWS二人目の大島です。

今日は、オンプレミスや他クラウドなどから Azure へのサーバー移行ができる Azure Migrate というサービスの全体像をまとめてみました。
特に、実際に移行を行う場合には「プライベートネットワークで移行を実施したい」という組織的要件があることも多いと思いますので、今回はプライベートエンドポイントというサービスと組み合わせたプライベートな通信での移行を取り扱います。

今回はAWSからの移行についてまとめていますが、オンプレミスからの移行も概ね全体像は変わりません。
また、細かな手順の解説などは、ドキュメントにもまとまっていますし、他にも様々な記事が出ているので、こちらでは手順の全体像や重要なポイントを主として取り扱います。

実際に移行を行う前に、全体像を頭に入れて理解をしやすくする手助けとなれば幸いです。

※こちらの情報は、2023年8月の情報をもとに記載しています。
※Azure Migrate を使用するために各種リソースのデプロイが必要となりますが、その際の Azure や AWS 上のロール・権限にはご注意ください

Azure Migrate とは？

念の為、Azure Migrate について簡単に解説します。

Azure Migrate とは、仮想サーバーや、オンプレミス・その他クラウドなどに存在するサーバーやデータベース、アプリケーションを Azure 上に簡単移行するためのサービスです。

単純なサーバーの「移行」はもちろん、移行する対象サーバーがそもそも移行可能かどうか・移行先のサーバーのサイズはどうすべきか、といった対象マシンの「評価」も含めて、クラウドへの移行を行うための一連のツールを一つのプロジェクトとしてシームレスに取り扱うことができます。

プライベートエンドポイントとは？

念の為、プライベートエンドポイントについても簡単に説明します。

プライベートエンドポイントは、Azure 上の PaaS サービスなどを自分でデプロイした仮想ネットワーク上のプライベートIPアドレスから使用を可能にするためのサービスです。

本来 Azure 上のサービス間はパブリックIPアドレスを用いて、通信が行われます。
ただ組織的な要件として、閉域網での接続を実現しなければならないケースや、Expressroute のような専用回線をオンプレミス環境から構築していて、より高速な回線を使用したいケースなどで有用です。

今回は、このプライベートエンドポイントを Azure Migrate と併用することで、
なるべく対象のマシンの情報がパブリックなインターネットを流れないようにしています。

実際に Azure Migrate を使用する案件でも、
すでに Azure とオンプレミスで専用回線（Expressroute）を引いているため、より高速な回線を利用して移行をしたい、という要望は多いです。（特に、サーバーやDBのレプリケーションはデータのサイズも膨大です）

公式ドキュメントでもそのように記載があります。

公衆ネットワークを経由することなく Azure Migrate やその他の Azure リソースにアクセスするという組織的な要件がある場合には、プライベート エンドポイントの接続方法をお勧めします。 Private Link を使用し、既にある ExpressRoute プライベート ピアリング回線を使用すると、帯域幅や待機時間の要件を満たしやすくなります。

抜粋：プライベート エンドポイントで Azure Migrate を使用する - Azure Migrate | Microsoft Learn

※ Azure Migrate の使用にあたっては、パブリックネットワークへのアクセスを完全に遮断できるわけではなく、特定のソフトウェアダウンロードの際には、インターネットアクセスが必要となります

Azure Migrate の全体像

Azure Migrate を使用するにあたっての全体像はこちらです。

Azure Migrate では、まず「Project」と呼ばれる評価・移行のための各種設定やリソースを管理するための入れ物を用意します。

Azure Migrate の Project は大きく以下2つのツールから構成されます。
それぞれのツールは、Azure のデフォルトとなっているツール以外にも、サードパーティツールなど、評価や移行する対象に応じて様々なオプション選択可能です。

• 評価ツール

  Azure 上に移行したいサーバーのOSやスペック、パフォーマンスなどを確認して、Azure 上へ移行がそもそも可能なのか、移行した場合のコストはどうなるのか、推奨のVMサイズは何になるのか、など移行の準備のための対象のマシンの「評価」を行います。
  
  デフォルトでは、「Azure Migrate Discovery and assessment」が選択されています。
  
  詳細はドキュメント

• 移行ツール

  実際に、Azure 上へ対象のマシンを移行するためのツールです。評価ツールを使用した上での移行が推奨されますが、もちろん移行ツール単体での使用も可能です。
  
  デフォルトでは、「移行およびモダン化（Migration and modernization）」が選択されています。

こちらが実際の Azure Migrate の Project の画面です。

前述の通り、評価ツールと移行ツールにはそれぞれ「Azure Migrate Discovery and assessment」「移行およびモダン化（Migration and modernization）」が選択されています。

AWS - Azure 間のネットワーク接続

移行を進めていくにあたって、まずは、AWS - Azure 間のネットワーク接続が必要です。
実際のケースでは、既に何らかの方法で接続を確立しているケースも多いかと思いますが、今回は VPN による接続をします。
こちらも詳細な手順はドキュメントが詳しいので省き、全体像のみお伝えします。

構築するネットワークのイメージは以下です。

AWS のプライベートサブネットに対象のマシン（Windows Server）を移行します。
AWS - Azure 間は専用回線は引けないので S2S で繋げます。

S2S 接続を構成するにあたって、AWS の VPC と Azure の Vnet （それぞれ AWS, Azure における仮想ネットワークの呼称）のアドレススペースが被ってはいけないので注意してください。
今回は、AWS 側を 192.168.0.0/16、Azure 側を 10.2.0.0/16 とします。

AWS 側のリソースとしては、Virtual Private Gateway を用意して VPC へアタッチ、そしてAzure 側のネットワークを Customer Gateway として登録します。
それぞれ通信を行う際には、それに応じたセキュリティグループ、ルートテーブルの追加も忘れないように注意してください。

Azure 側では、同様に、VPN Gateway と Local Network Gateway を用意します。（それぞれ、Virtual Private Gateway, Customer Gateway と同じ役割です）
Azure 側では、AWS と違い、VPN Gateway の作成時に専用のサブネットが必要となります。（VPN Gateway 作成時に自動で作成されます）
また、Azure 側では NSG (AWS におけるセキュリティグループのようもの）の更新は同様に必要になる場合がありますが、ルートテーブルは基本的に全て自動更新されます。

公式ドキュメントはこちら

Azure 仮想ネットワーク トラフィックのルーティング

図に DNS 用のサーバーがあり、疑問に思われる方もいらっしゃるかもしれませんが、こちらは後ほど解説いたします。

対象マシンの評価の手順

ネットワーク接続が、確立ができたところで、次に対象のマシンの評価を行っていきます。

使用するツールは、Azure Migrate の Project 作成時にデフォルトで選択されている「Azure Migrate: Discovery and assessment」を使用します。
Azure Migrate アプライアンスというソフトウェアをインストールしたサーバーを別途用意し、移行対象のマシンを評価します。

公式ドキュメントはこちら

Azure Migrate Discovery and Assessment を使用して物理サーバーを検出する

評価における手順全体の流れはこのような形です。

• Azure Migrate アプライアンスを準備する
  
  評価のためには、Azure Migrate アプライアンスというツールを使用します。
  専用サーバーが必要かつ、インターネットアクセスのアクセスが必要がですので、パブリックサブネットに専用のサーバーを設置し、インストールします。
  導入手順や要件等についてはこちらのドキュメントが役に立ちます。
  
  各種操作は、アプライアンス上から操作をしますので、パブリックインターネットからのRDP接続のセキュリティグループで許可が必要です。
  
  
• 対象のマシンをアプライアンスへ登録する
  
  移行対象のマシンをアプライアンスへ登録します。
  アプライアンス上から、対象のマシンのIPアドレスや、クレデンシャルを登録する必要があります。
  また、要件に応じたセキュリティグループの設定も必要です。
  
  
• 対象のマシンのパフォーマンスデータの評価作成と収集
  
  対象のマシンの登録が完了したら、Azure 上から対象サーバーの「評価」を作成する必要があります。
  この「評価」を作成することで、Azure への移行可否・コストパフォーマンスなどを視覚化することができます。
  
  パフォーマンスデータ自体は設定完了後、5分ほどで反映がされますが、データの信頼度が低い状態となります。ドキュメントでも、パフォーマンスを元に評価を正確に行う場合、検出を開始してから少なくとも1日を必要としています。
  
  
  
  

対象マシンの評価の全体像

評価にあたっての、アーキテクチャの全体像はこちらです。

前の図から追加となったのは、以下のとおりです。

• AWS
  
  Azure Migrate アプライアンス用サーバー
  

• Azure
  
  DNSサーバー、プライベートDNSゾーン、各種プライベートエンドポイントと対応する PaaS

Azure Migrate アプライアンス用サーバー

こちらは手順の方にも記載したとおりですが、対象のマシンを評価するために必要なアプライアンスをインストールするサーバーです。
こちらのサーバーにアプライアンスを設定すると、ローカルで操作用のサイトが設定されているため、GUIを使って対象サーバーの登録などが可能になります。
対象サーバーの登録には、対象サーバーへアクセスするためのアカウントのクレデンシャルとIPアドレスの登録が必要です。

対象サーバーとの通信のために、アプライアンスサーバーから移行対象サーバーへのポート5985（winRM という powershell による遠隔操作）のセキュリティグループを開いておく必要があります。
さらに注意点として、今回移行の対象とする Windows Server ではデフォルトでマシンローカルのファイアウォールで、同一サブネット外からの winRM の通信を遮断する設定がついている場合があります。
そのため、対象サーバーのファイアウォール設定にも注意が必要です。

また、プライベートエンドポイントを使用した Azure Migrate の利用には、プライベートエンドポイントへの名前解決が必要です。

プライベートDNSゾーンとプライベートエンドポイント

Azure Migrate Project をプライベートエンドポイントを利用設定をして作成すると、
Azure Migrate アプライアンス登録などの際に必要なリソースとそれに応じたプライベートエンドポイントが自動で作成されます。

プライベートエンドポイントは、Azure Migrate ・ストレージアカウント・Key Vault といった PaaS に対してそれぞれ生成されます。（これらのリソースも自動生成されます）

さらにプライベートエンドポイントの名前解決のために、プライベートDNSゾーンも合わせて生成されます。
Azure Migrate アプライアンスは対象の PaaS へ URLにてアクセスを行うため、プライベートエンドポイントへの名前解決ができない場合、サービスの実行ができなくなってしまうため、プライベートDNSゾーンが必要となります。

DNSサーバー

ここでさらに名前解決のために、図にあるDNSサーバーが必要となってきます。
Azure 上で Virtual Machine を起動し、DNSサーバーとして設定をしています。

Azure では、168.63.129.16 というパブリックなエンドポイントを介して、自身がデプロイしたプライベートDNSゾーンの名前解決が可能となっています。（正確には、Vnet とリンクしたプライベートDNSゾーンですが、Azure Migrate 側で勝手にリンクまでしてくれています）

このエンドポイントは、パブリックIPではあるものの、Azure 内部のリソースからしかアクセスすることができません。
つまり、AWS側のリソースからは直接はプライベートDNSゾーンの名前解決が使えないこととなります。
そこで Azure 側にDNSサーバーを立てて、AWS にあるサーバーの名前解決を該当のDNSサーバーへ向けます。（AWS 側の DNS設定の方法はなんでも構いませんが、DHCPオプションセットを用いて制御しています）

その後、Azure にある DNS サーバーを168.63.129.16 へフォワードするように設定することで、AWS 側のサーバーからプライベートエンドポイントの名前解決が行えるようになります。

もちろん、名前解決ができればいいので、
AWS 側のサーバーの hosts ファイルにプライベートDNSゾーンのレコードを全て書きこんでもOKですし、DNS サーバーを立てるのが面倒であれば、Azure Private DNS resolverというマネージドサービスを使ってもOKです。

↓の公式ドキュメントの画像の DNS forwarder の部分が今回プライベートエンドポイントで必要なDNSの構成です。

対象マシンの移行の手順

対象サーバーの評価ができたら、次は移行をしていきます。
使用するツールは、Azure Migrate の Project 作成時にデフォルトで選択されている「移行およびモダン化（Migration and modernization）」を使用します。


移行の流れは以下のとおりです。

• レプリケーションアプライアンスを準備する
  
  移行用のアプライアンスです。
  Azure Migrate アプライアンスの時と同じく、別でサーバーを用意する必要があります。
  また、Azure Migrate アプラインスと同じサーバー内に共存できません。
  導入手順や要件等についてはこちらのドキュメントが役に立ちます。
  
• モビリティサービスを準備する
  
  モビリティサービスとは、レプリケーションのために、Azure Site Recovery へデータを送信するためのエージェントです。
  こちらは、移行の対象のマシンへインストールする必要があります。
  
  レプリケーションアプライアンスを準備する際に、モビリティサービスインストール用の .exe ファイルが入っているのでそれを対象サーバーで起動してインストールします。（プッシュインストールという、外部マシンから対象マシンへインストールする方法もあるのですが、現在対応していません）
  
  
• ストレージアカウントへデータをキャッシュ
  
  レプリケーションを開始します。レプリケーションを開始すると、ストレージアカウントへデータがキャッシュされます。
  評価を事前に行っていれば問題ないのですが、評価を行わず移行のみを行う場合、自分でストレージアカウントとプライベートエンドポイント・プライベートDNSゾーンを用意する必要があります。
  
• テスト移行を行う
  
  レプリケーション体制が構築できたら、テスト移行を実施します。
  テスト移行を行うと、実際に指定した Vnet 上にレプリケーションデータから VM が作成されます。
  
  
• 実際に移行を完了する
  
  テスト移行に問題がなければ、実際に移行を行い、完了となります。
  
  

対象マシンの移行のアーキテクチャ

移行にあたっての、アーキテクチャの全体像はこちらです。
※評価に必要なリソースなどは記入しておらず、移行のみに必要なリソースです。

変更点は以下のとおりです。

• AWS
  
  レプリケーションアプライアンス用サーバー

• Azure
  
  各種 PaaS と対応したプライベートエンドポイント

レプリケーションアプライアンス用サーバー

移行を行うためのアプライアンス用のサーバーです。


まずAWSの場合、Windows Server 2016 or Windows Server 2012 R である必要があります。
Azure Portal 上だと Windows Server 2022 を指定されるのですが、これはオンプレミスの場合であり、AWSの場合は、2016としっかりとドキュメントに記載があります。

また、このレプリケーションアプライアンスは Migrate アプライアンスと共存できません。（IISの設定などでコンフリクトする部分があります）
そのため、別でサーバーをたてる必要があります。

なかなかドキュメントで指定されているマシンサイズはコストもかかるものなので、検証環境などで評価を使用しないのであれば、検証完了次第評価用サーバーは削除した方が良いかもしれません。（検証であれば、ドキュメント通りのマシンを用意しなくても十分かとは思いますが）

レプリケーションアプライアンス用のサーバーでは、IIS機能を有効にしないようドキュメントにも記載があります。

これらの役割を有効にしないでください。
・Active Directory Domain Services
・インターネット インフォメーション サービス
・Hyper-V

抜粋：Azure Migrate レプリケーション アプライアンス - Azure Migrate | Microsoft Learn

モビリティサービス

モビリティサービスとは、Azure Sites Recovery に対してマシンのデータをキャプチャして送るためのエージェントです。
このモビリティサービスは、移行対象のマシン自体にインストールする必要があります。

このモビリティサービスが、対象のマシンからデータをキャプチャする主な役割を担っており、前述のレプリケーションアプライアンスはどちらかというと、そのデータを Azure 上へ渡すゲートウェイのような調整役として機能します。

レプリケーションアプライアンスをインストールすると、
インストールしたファイルの中に、.exe ファイルが入っているので、この .exe ファイルを対象のマシンで実行することでインストールできます。
対象マシンからの、インターネットアクセスは不要ですが、モビリティサービスをインストールした後に、レプリケーションアプライアンスに対して通信を行う必要があります。

ソース AWS VM は、レプリケーション管理とレプリケーション データ転送のために、HTTPS 443 (コントロール チャネルのオーケストレーション) および TCP 9443 (データ転送) の受信ポートでレプリケーション アプライアンスと通信します。 レプリケーション アプライアンスは次に、HTTPS 443 送信ポート経由でレプリケーション データを Azure に送信します。

抜粋：アマゾン ウェブ サービス (AWS) の EC2 VM を検出して評価し、Azure に移行する

Recovery Services Container とストレージアカウント とプライベートエンドポイント

まず、Recovery Services Container についてです。

マシンの移行の際には、マシンのデータのレプリケーション行う必要があり、この Recovery Services Contaienr がそのレプリケーションを担ってくれるサービスとなります。
「評価」の際と同じく、Azure Migrate にてレプリケーションアプライアンスの設定などを行う際に、裏側で勝手にプライベートエンドポイントともにデプロイを行ってくれます。


次にストレージアカウントです。
Azure Migrate にて移行を行うためのデータをクラウド上にキャッシュしておくために、ストレージアカウントを用意する必要があります。
ただし、このストレージアカウントには、Azure Migrate 側ではプライベートエンドポイントをデフォルトでは用意されません。自分で設定をする必要があります。
（事前に Azure Migrate アプライアンスによる評価を行っていれば、ストレージアカウントがプライベートエンドポイントとセットでデプロイされているので、それを考慮の上でかもしれません）

また、特に自分で用意する場合、ストレージアカウントのソフトデリートの機能がONとなっていると、レプリケーションに失敗するので注意してください。（ストレージアカウントのデプロイをデフォルトの設定で実行すると、ONとなっています）

ソフトデリートがONとなっているストレージアカウントにレプリケーションを行うと、↓以下のようなエラーが出ます。

プライベートエンドポイントや、プライベートDNSゾーンについては、評価と全く同じ構成となりますので、こちらでの説明は割愛します。

終わりに

全体像のまとめは以上です。
正直、最初に移行を行おうとすると、なかなか全体像が掴みづらく、進め方に戸惑うことも多いです。
こちらの記事が少しでも、実際の移行の手助けとなれば幸いです。

「クラウドへの移行方法のノウハウがない」「クラウドへの移行を行うだけの人材がない」など、クラウドに関するお悩みをお持ちであれば、クラウドのスペシャリストである当社へぜひご相談ください。
クラウドへの移行案件も経験豊富なエンジニアがご支援いたします。
以下リンクより、ご連絡お待ちしております。

お問い合わせ

お問い合わせ - クラウド・AWSのデロイト トーマツ ウェブサービス株式会社

tak