Azure Migrateによる仮想マシン移行【前編】

この記事の内容

仮想マシンの基本構造を理解し、移行の本質が「仮想ハードディスクのコピー」であることを解説します
CPU・メモリ・キャッシュの整合性という、見落とされがちな移行時の注意点を説明します
仮想マシン移行の5つの目的・パターンを整理します
Azure Migrateがサポートする移行シナリオと得意なことを紹介します
Azure Migrate非対応のHyper-Vへの移行など、注意点もあわせて解説します

仮想マシンの基本構造を押さえる

仮想マシン移行を理解するには、まず仮想マシンがどのような構造で動いているかを把握しておく必要があります。

仮想マシンは必ず、物理的なサーバー上に構築された「仮想基盤（ハイパーバイザー）ホスト」の上で動作しています。これはオンプレミスでもパブリッククラウドでも変わりません。パブリッククラウドの場合は物理サーバーの存在が隠蔽されていますが、必ずどこかに実体が存在します。

仮想マシンには「仮想ハードディスク」があり、その中にOSやソフトウェアが格納されています。Hyper-VであればVHD／VHDXというファイル形式がこれにあたります。そしてCPU・メモリ・キャッシュといったリソースは、仮想基盤ホスト上のものが仮想化されて各VMに割り当てられます。

移行の本質は「ファイルのコピー」

仮想マシン移行の本質は、この仮想ハードディスクファイルをどうやって移行先にコピーするか、という一点に集約されます。

物理サーバーで例えると、2台のサーバーがあったとして、ハードディスクを抜いてもう一方に差し込んで起動すれば、同じOSが立ち上がってきます。仮想マシンでも同じ原理です。仮想ハードディスクファイルさえあれば、どの仮想基盤でも前の環境と同じ状態の仮想マシンを起動できます。

移行時に考慮すべき「CPU・メモリ・キャッシュ」の問題

仮想ハードディスクの内容だけが重要なのかというと、厳密にはそうではありません。仮想マシンが動作中の場合、次の情報がディスク以外の場所に存在しています。

CPUレジスター：現在計算中のデータ
メモリ：起動中のプログラムやデータ
キャッシュ：ディスクへの書き込みが未完了のデータ

動いたまま移行したい場合は、これらも含めてケアする必要があります。特にデータベースのような整合性が重要なシステムでは、書き込み途中のデータが失われると深刻な問題が発生します。

最も安全な方法は「シャットダウン」

これらの問題を最も簡単に解決する方法は、仮想マシンをシャットダウンしてから移行することです。シャットダウンすれば、メモリやキャッシュの内容も仮想ハードディスクに書き出されるため、整合性を気にせずファイルを扱うことができます。

ダウンタイムは発生しますが、安全性は非常に高くなります。

WindowsではVSS（ボリュームシャドウコピーサービス）を使うことで、稼働中でも整合性のある状態でバックアップや移行データを取得することもできます。

動いたまま移行することの難しさ

「ダウンタイムなしで移行したい」という要望はよくありますが、技術的には非常に難易度が高い作業です。

仮想マシンが動作し続けている限り、常にデータが変化します。その変化を移行先に追いかけ続け、最後の瞬間までレプリケーションするのがライブマイグレーション（VMotionなど）の仕組みです。実際には最後のごく短い時間だけ停止していますが、ユーザーからはほとんど気づかないほどの短さになっています。

「なるべく短くしてほしい」という要件が厳しくなればなるほど、技術的な難易度とコストは上がっていきます。移行ソリューションを選ぶ際には、このトレードオフを理解しておくことが重要です。

異なる仮想基盤への移行では形式変換が必要

移行元と移行先の仮想基盤の種類が異なる場合、仮想ハードディスクのファイル形式を変換する必要があります。中身の本質は同じですが、仮想基盤ごとに扱うフォーマットが異なるためです。

オフラインで移行する場合は、ファイルを変換してから持ち込む作業が発生します。また、仮想基盤によっては連携用ツール（ゲストエージェント）のインストールが必要になる場合もあります。

なお、仮想マシン本体の設定（CPU数やメモリ量など）は移行先で新規に作成し、同じ値を設定することで論理的に同等の環境を再現できます。

仮想マシン移行の5つのパターン

仮想マシンの移行には、大きく分けて5つのパターンがあります。

1. VMをそのまま移行（リフト＆シフト）

最も多く求められるパターンです。仮想基盤が変わっても、VMの動作はそのまま維持したいというケースです。既存の環境を変更せず、基盤だけを移行します。

2. PaaSへの移行

VMで動かしているサービスを、クラウドのマネージドサービス（PaaS）に載せ替えます。例えばデータベースサーバーをデータベースサービスに移行し、基盤管理から解放されるといったケースです。

3. コンテナ化して移行

オンプレミスで動いているサービスをコンテナ化し、コンテナを受け入れるPaaSサービスに移行するパターンです。Azure App Serviceなどへのコンテナデプロイが例として挙げられます。

4. リビルド（作り直し）

移行を機に、クラウドのサービスを活用した構成で作り直すパターンです。部分的な作り直しから、システム全体の刷新まで幅広いレベルがあります。

5. SaaSへの移行

既存のシステムをSaaSに置き換えるパターンです。例えばオンプレミスで動かしているWordPressをWordPress.comに移行するようなケースが挙げられます。月額・年額の固定費で運用の手間を大幅に削減できます。

Azure Migrateでできること

大量のVMを抱える組織では、すべてのVMの構成や担当者を把握すること自体が困難な場合があります。Azure Migrateは、そうした複雑な移行を支援するツールです。

主な機能

検出（Discovery）：オンプレミスや他クラウド環境にある物理・仮想サーバーを自動検出します
評価（Assessment）：検出したリソースを分析し、移行先の推奨構成やコスト見積もりを提示します
移行（Migration）：実際の移行作業を、シナリオベースでガイドします

対応する移行先

Azure仮想マシン（IaaS）
Azure VMware Solution（AVS）
Azure Stack HCI
Azure App Service（Webアプリ移行）
Azure Managed Instance（データベース移行）
Azure Virtual Desktop（VDI移行）

利用コストについて

Azure Migrateは基本的に無料で利用できます。検出・評価フェーズだけの活用でも非常に有用で、移行前の調査ツールとして積極的に使うことが推奨されます。

Azure Migrateの注意点：Hyper-Vへの移行は対象外

Azure MigrateはAzureへの移行を支援するツールのため、オンプレミスのWindows Server Hyper-Vへの移行には対応していません。

Hyper-Vへの移行を検討している場合は、以下のような選択肢があります。

System Center Virtual Machine Manager（SCVMM）：Microsoftが提供する仮想マシン管理ツール。ただしSystem Centerスイート全体が必要になるため、移行目的だけに使うには大がかりになりがちです。
サードパーティ製の移行ツール：VeeamやCohesityなど、各ベンダーが移行ツールを提供しています。

なお、まずAzure Migrateで評価・コスト見積もりを行い、その上でHyper-Vへの移行が最適と判断した場合に別ツールを使う、という流れも有効です。

まとめ

仮想マシン移行の本質は、仮想ハードディスクファイルのコピーです。ただしCPU・メモリ・キャッシュの整合性問題や、仮想基盤が異なる場合のファイル形式変換なども考慮が必要です。最もシンプルかつ安全な方法はシャットダウン移行ですが、ダウンタイムの要件に応じて適切な手法を選ぶ必要があります。

移行パターンはリフト＆シフトからPaaS移行、コンテナ化、リビルド、SaaS移行まで5種類あり、VM単位で最適なパターンを検討することが重要です。

Azure Migrateは検出・評価・移行をシナリオベースでガイドしてくれる強力なツールで、特に多数のVMを抱える環境での移行検討に役立ちます。無料で利用できる期間も長く、まず評価目的で使ってみるだけでも大きな価値があります。ただし、Hyper-Vへの移行はサポート対象外である点に注意が必要です。