プロに教わるAzure設計運用のベストプラクティス 第2回

オンプレミスからIaaSへの単純な「リフト」でもよく発生するトラブルと解決策

「失敗あるある」から考える、Azure移行のベストプラクティス

ネットワークの「失敗あるある」と対処法

　続いて、ネットワークにおけるベストプラクティスを見ていこう。

　Azureのネットワークにおけるベストプラクティスはさまざまなものが存在するが、今回はAzure環境とオンプレミスを接続するネットワークや、移行時のネットワーク接続にターゲットを絞って確認していく。

●Azure移行ではExpressRouteの利用が基本

　まず、Azure環境とオンプレミスのネットワークをつなぐ選択肢は、一般的には次の2とおりである。

　・ExpressRoute（専用線）
　・サイト間VPN（IPsec-VPN）

　このうちAzure移行で重要な役割を果たすのはExpressRouteのほうだ。ExpressRouteは、Azureの提携データセンターやISPとAzure環境の間を専用線で接続するサービスだ。そのため、すでに企業の拠点内ネットワークと提携データセンター／ISP間で接続しているならば、比較的容易にAzureへの接続環境を実現できる。インターネット越しに接続するサイト間VPNとは異なり、帯域保証型である点が魅力のサービスだ。

　ExpressRouteには、ユーザー自身のIaaS環境と接続することができる「プライベート ピアリング」、マイクロソフトのPaaS/SaaS環境との接続ができる「マイクロソフト ピアリング」という2種類がある。1回線で両方を契約し、同時に接続することも可能だ。

　プライベート ピアリングを使えば、オンプレミス環境とIaaSを接続して、文字どおりプライベートIPアドレスを利用した相互の通信が可能になる。一方でマイクロソフト ピアリングは、パブリックIP（グローバルIPアドレス）を使った通信となるが、本来インターネット経由で接続する必要があるPaaS/SaaS環境に対して、帯域保証型の専用線経由で接続できる点がメリットだ。インターネット接続が制限されている環境からPaaS/SaaSを活用したいケースでも有用である。

　このExpressRouteは、オンプレミスからAzureへの移行時に仮想マシンをレプリケーションするためのネットワーク経路としても利用できる。現在、Azure移行を支援するサービスとして「Azure Migrate」が提供されているが、このAzure MigrateでもExpressRoute経由でレプリケーションデータを送信できる。

　Azure Migrateでは、Azure移行前に移行対象の仮想マシンを検出／評価する「Azure Migrate : Discovery and Assessment」や、オンプレミスにある仮想マシンのディスクをAzureにレプリケーションして移行する「Azure Migrate : Server Migration」といった、Azure移行にまつわる一連のサービスをまとめて提供している。このServer Migrationのレプリケーションで、ExpressRouteが利用できるわけだ。

　Server Migrationがレプリケーションデータを送信する先は「*.backup.windowsazure.com」や「*.blob.core.windows.net」といったAzure上のストレージ サービスとなる。これらのURLはパブリックIPにひも付けられているため、ExpressRouteのマイクロソフト ピアリング経由ならば通信できるが、プライベート ピアリング経由で直接通信することはできない。ただし、Azureの「Private Endpoint」サービスを利用することで、プライベート ピアリングでのみ接続してるオンプレミス環境からでも、上述したServer Migrationの送信先ストレージにアクセスできるようになる。

　Private Endpointは、IaaSの仮想ネットワーク内にPaaSとの接続ポイントとなる特別なプライベートIPを作成してくれるサービスだ。これを作成して、「*.backup.windowsazure.com」や「*.blob.core.windows.net」といったURLをPrivate EndpointのプライベートIPに名前解決するようDNSを設定すればよい。少々複雑な構成にはなるが、マイクロソフト ピアリングを契約していない環境でも、帯域保証の安定したネットワークを使ってAzureへの移行作業が可能になる。

●ExpressRouteが使えない環境での問題

　説明が長くなってしまったが、Azure移行においてExpressRouteが利用できるならば大きな問題はなく、ベストプラクティスにあたる構成と言えるだろう。帯域が安定したExpressRouteを利用すれば、仮想マシンの台数とディスク容量からマイグレーション処理にかかる時間が予測可能となり、移行の計画も立てやすいはずだ。

　問題はExpressRouteが利用できないケースである。前述のとおり、Azure Migrateによるデータのレプリケーション先はパブリックIPを持つストレージなので、インターネット経由でもレプリケーション処理そのものは可能だ。この通信はHTTPSで暗号化されるため、セキュリティの観点からも問題はない。ただし、インターネット回線の場合は、どうしても帯域の安定性が損なわれてしまうという問題が生じる。通常、Server Migrationでは数百GB～数TBクラスのディスクデータをレプリケーションすることになるため、通信帯域が不安定であれば、計画的な移行の妨げになってしまう。

　実際、筆者がある顧客環境でインターネット経由のAzure移行をテストした際、回線帯域幅の問題から仮想マシンを1台ずつしかレプリケーションできないことが判明し、実施は現実的でないという結論に至ったケースがあった。もちろん、移行対象とする仮想マシンの数やディスク容量などの要件次第ではあるが、ある程度まとまったボリュームのAzure移行を計画するならば、やはりExpressRouteの導入を検討するのが望ましいと言える。

●失敗あるある：hostsファイル

　ExpressRouteによる接続に関しては、もうひとつ注意事項がある。オンプレミス環境とAzure環境のレイヤー2延伸（L2延伸）接続はできないという点だ（オンプレミスとAzureのVMware環境間を接続する「Azure VMware Solution」ではL2延伸構成が可能だが、ここでは割愛する）。そのため、Azureへの移行時には必ず仮想マシンのIPアドレス変更が伴う。

　このIPアドレス変更に関連する「失敗あるある」として、移行時にホスト上のhostsファイルの修正を忘れ、名前解決に失敗するというものがある。筆者の経験上、hostsファイルを使った名前解決は意外なほど多用されている。そして、担当者自身でもhostsファイルの存在を忘れているケースも多い。hostsファイルの存在に気づかずAzureに移行して、接続トラブルが発生してから慌てることになるわけだ。

　あらかじめ、移行対象の仮想マシンでhostsファイルが使われていないかどうかを確認するだけで、このトラブルは減らすことができる。移行前に確認すべきポイントの1つとして覚えておいていただきたい。

★ネットワークのベストプラクティス

　・Azure Migrateによる移行はExpressRouteの利用が望ましい
　・また、現在ではAzure Peering Serviceも検討できる
　・Azure移行は必ずIPの変更を伴うので、hostsによる名前解決が使われていないか事前に確認しておく