サポート終了(EOL)を迎えたOS上で動き続けているレガシーアプリケーションをGoogle Cloudへ移行したい方に向けた記事です。EOL OSの仮想マシンをGoogle Compute Engineへインポートするための選択肢を整理します。
塩漬けレガシーアプリの実情
DoiT Internationalでは、クラウド移行のさまざまなフェーズにいるお客様と日々ご一緒しています。すでにクラウドネイティブで技術的負債もほとんどないお客様もいれば、事情があってレガシーアプリケーションを抱え続けているお客様もいます。アップデートを欠かさず最新に保っているケースもあれば、本記事のテーマである、EOL OS上で塩漬けになったレガシーアプリケーションをそのままホストし続けているケースもあります。そうしたアプリケーションをGoogle Cloudへ移行したいとお考えなら、本記事はきっとお役に立つはずです。利用できる選択肢を一通り押さえ、自社のworkloadsに合った判断ができるよう道筋を示します。
本記事を書くきっかけは、レガシーアプリをGoogle Cloud上で動かす手段としてGoogle Cloud VMware Engine(GCVE)を検討するお客様が複数いらしたことです。基盤がVMwareであるGCVEは、EOL OSを含む特定のVMを動かすうえで非常に有効な選択肢です。一方で、小規模なworkloadsへスケールダウンするのは苦手で、最小構成のリソースをきちんと使い切れる場合に限ってコスト効率が成立する、という難点もあります。
GCVEはGoogle Cloud上でレガシーアプリを動かす有力な手段ではありますが、その規模を必要とするworkloadsでない限り、最初に選ぶべき選択肢としてはお勧めしません。詳しくは後ほど触れます。
なぜお客様がGCVEに行き着くのかを掘り下げてみると、いくつかの壁が浮かび上がってきました。
まず、Centos 6のようなEOL OSから新しい仮想マシンを作成しようとしたケースです。試してみるとすぐに、目的のイメージがGoogleの公開イメージ一覧に載っていないことに気づきます。では、次は?
次に試したのが、VMイメージをアドホックに取り込めるGoogle Compute Engineのインポート機能です。過去のOSバージョンでも動きそうに思えますが、EOL OS(本例ではCentos 6)をインポートしようとすると、残念な結果に終わりました。
$ gcloud compute instances import centos-6 --source-uri=gs://eol-migration1322/centos6 --zone=us-central1-a
WARNING: Importing OVF. This may take 40 minutes for smaller OVFs and up to a couple of hours for larger OVFs.
Created [https://cloudbuild.googleapis.com/v1/projects/johnd-test-01/locations/us-central1/builds/0e67bbb8-3389-4a34-adae-5f5566732085].
Logs are available at [https://console.cloud.google.com/cloud-build/builds;region=us-central1/0e67bbb8-3389-4a34-adae-5f5566732085?project=306419495665].
starting build "0e67bbb8-3389-4a34-adae-5f5566732085"
[import-ovf]: 2022-07-05T21:25:20Z Starting OVF import workflow.
[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6.ovf
[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6-disk1.vmdk
[import-ovf]: 2022-07-05T21:25:21Z Didn't find valid OS info in OVF descriptor. OS will be detected from boot disk.
[import-ovf]: 2022-07-05T21:25:21Z Will create instance of `g1-small` machine type.
[import-disk-1]: 2022-07-05T21:25:22Z Inspecting the image file...
[import-disk-1]: 2022-07-05T21:28:26Z Inspecting disk for OS and bootloader
[import-disk-1]: 2022-07-05T21:30:05Z Inspection result=os_release:{cli_formatted:"centos-6" distro:"centos" major_version:"6" minor_version:"10" architecture:X64 distro_id:CENTOS} elapsed_time_ms:98933 os_count:1
[import-ovf]: 2022-07-05T21:30:06Z Cleaning up.
[import-ovf]: 2022-07-05T21:30:06Z os `centos-6` is invalid. Allowed values: [centos-7 centos-8 debian-10 debian-11 debian-8 debian-9 opensuse-15 rhel-6 rhel-6-byol rhel-7 rhel-7-byol rhel-8 rhel-8-byol rocky-8 sles-12 sles-12-byol sles-15 sles-15-byol sles-sap-12 sles-sap-12-byol sles-sap-15 sles-sap-15-byol ubuntu-1404 ubuntu-1604 ubuntu-1804 ubuntu-2004 windows-10-x64-byol windows-10-x86-byol windows-2008r2 windows-2008r2-byol windows-2012 windows-2012-byol windows-2012r2 windows-2012r2-byol windows-2016 windows-2016-byol windows-2019 windows-2019-byol windows-2022 windows-2022-byol windows-7-x64-byol windows-7-x86-byol windows-8-x64-byol windows-8-x86-byol]
ERROR
ERROR: build step 0 "us-central1-docker.pkg.dev/compute-image-tools/wrappers/gce_ovf_import:release" failed: step exited with non-zero status: 1
ERROR: (gcloud.compute.instances.import) build 0e67bbb8-3389-4a34-adae-5f5566732085 completed with status "FAILURE"つまり、イメージインポート機能が対応するのは特定のOSとバージョンに限られており、Centos-6は対象外です。Google Cloudコンソールから実行してもコマンドラインから実行しても結果は変わりません。ディスクイメージをそのままGoogle Compute Engine(GCE)へ取り込むという「お手軽ボタン」は、ここで使えなくなります。
ここに来てGCVEの存在に気づき、「VMwareで動くものなら何でも動かせる」と思い至る方もいるでしょう。クラスタを立ち上げて構成し、VMをインポートする──オンプレミスでの手順とほぼ同じです。これで一件落着!……本当にそうでしょうか?
EOL OSイメージに対するGoogle Cloudの対応状況
EOL OSに関するGoogleのサポートドキュメントの大半は、まずEOL OSをアップデートすることを推奨しています。確かに王道ではありますが、誰もがそれを実行できるわけではありません。アプリケーションの開発者がすでに離任している、特定のライブラリに依存している、そもそも更新に割けるリソースがない──こうした事情はよくあります。
EOL OSの仮想マシンをGCEへインポートする選択肢
順不同で選択肢を紹介します。それぞれにメリットとデメリットがあります。
選択肢1:非推奨の公開GCEイメージを使ってレガシーアプリを再インストールする
冒頭で触れたとおり、Google Cloudのネイティブイメージを使おうとして、最初は見つけられないというお客様を何度も目にしてきました。実はGoogleはイメージを残しているのですが、目立つ場所に置いていないだけなのです。EOLイメージのサポートドキュメントを読み込むと、イメージは「非推奨(deprecated)」の扱いで利用可能であることが分かります。Centos 6に関するドキュメントの例はこちら。
Google Cloud GCEコンソールの「イメージ」画面には、非推奨イメージを表示するトグルスイッチがあります。これをオンにすれば、過去のGCEイメージが一覧表示されます。
目的のイメージ(私の場合はCentos 6)を絞り込み、使いたいものを選べば、そこからGCEインスタンスを作成できます。
コマンドラインでも同じことができます。
gcloud compute images list --show-deprecated
この方法のメリットは、os-agentなどのGoogleツールが組み込まれ、Compute Engine上で動かすためのOSレベルの調整がすでに済んだ純正イメージを利用できる点です。アプリケーションの再インストールが容易で、移行対象のインスタンスが少数であれば、十分に検討に値します。
選択肢2:既存VMイメージをGCE互換フォーマットへ手動変換し、手動でインポートする
Googleにはイメージを手動でインポートする方法と、インポート後にGCEで適切に動作させるための調整に関するサポートドキュメントが用意されています。独自構築のVMアプライアンスや、単一ボリュームのサーバーが少数だけある場合に有効です。手作業中心のため、ミスが入り込む余地がある点には注意が必要です。
Centos 6を例に、基本的な手順を以下にまとめます。
段取りを計画します。ソース環境からエクスポートしたイメージを保管する場所、そのイメージを起動して変更を加える手段、そしてGCE互換フォーマットへ変換する手段が必要です。元のイメージ、圧縮後のイメージ、加えて余裕分を収められるディスク容量を確保し、容量不足エラーを避けましょう。
イメージのコピーを作成し、ソース環境で起動して、変換前にOSへ必要な変更を加えます。たとえば次のような作業です。
Linuxの起動設定ファイル(本例では/etc/grub.conf)を編集し、boot splashimageを設定している行を削除します。さらにカーネルパラメータからrhgbとquietを取り除き、console=ttyS0,38400n8dを追加します。
ユーザー名とパスワードでコンソールからログインできることを確認します。GCE起動後にネットワークインターフェースが正しく立ち上がらない際の備えになります。
念のため、イメージにアクセスできるsshキーも用意しておきます。
Centosリポジトリが今でも使えるか確認します。私の場合は、リポジトリをvault.centos.orgへ切り替える必要がありました。
デフォルトのネットワークインターフェース設定を更新します。centos-6では/etc/sysconfig/network-scripts/ifcfg-eth0が対象です。HW_ADDRとUUIDの行を削除し、ONBOOT=yesとMTU=1460を追記します。
VMwareなど、ハイパーバイザー由来のツールを削除します。
次の手順を実行できる場所へイメージをコピーします。
イメージをGCEが受け付けるフォーマットへ変換します。
私が一番手軽だと感じたのは、qemu-imgユーティリティを使う方法です。まずqemuをインストールします。
本例では、VMwareの.vmdkファイルをGCEが要求するrawフォーマットへ変換します。
qemu-img convert -f vmdk -O raw PATH/TO/VM.VMDK PATH/TO/disk.raw
.VMDKを.rawに変換したら、oldgnu形式でtarアーカイブにまとめます。
tar –format=oldgnu -Sczf compressed-image.tar.gz disk.raw- compressed-image.tar.gzをGoogle Cloud Storage(GCS)バケットへアップロードします。
gsutil cp compressed-image.tar.gz gs://BUCKET\_NAME最後にGCEイメージを作成します。
gcloud compute images create IMAGE_NAME --source-uri \ gs://BUCKET_NAME/compressed-image.tar.gz
作成したイメージからVMを生成し、Google os-agentをインストールしたうえで、必要な調整を行います。
手順3eで作成したイメージからVMを起動します。
gcloud compute instances create VM_NAME --zone ZONE --image IMAGE_NAME
手順2cで用意したsshキーを使ってイメージにログインします。
インスタンスにログインできない場合は、起動時に新しいネットワークインターフェースが検出された可能性があります。シリアルコンソールからユーザー名/パスワードでログインし、検出された内容に合わせてネットワークインターフェースを修正してください。
ログイン後は、Google os-agentをインストールします。
以上の手順が大変そうに感じる方には、次の選択肢のほうが向いているかもしれません。手動インポートとインポート後の調整に関するGoogleサポートドキュメントには、ぜひ目を通すことをお勧めします。基本手順とつまずきやすいポイントは上記でまとめましたが、要件や制限はほかにも多数あるため、必ず一読してください。
選択肢3:複数のVMをGCEへ移行するならMigrate to Virtual Machines
Migrate to Virtual Machines(旧Migrate for GCE)は、オンプレミスのサーバーをGCEへリフト&シフトするために設計された移行ツールです。最新版はVMware移行に特化しています。レガシーアプリケーションがすでにVMware上で稼働しているなら、最有力の選択肢になるでしょう。Migrate to Virtual Machinesは多少のセットアップが必要ですが、いったん準備が整えば、大量の仮想マシンを簡単・確実に、ダウンタイムを最小限に抑えて移行できます。
仕組みとしては、既存のVMware環境にmigrate applianceをインストールします。このapplianceがGoogle CloudとオンプレミスのvSphereをつなぎ、Migrate to Virtual MachinesからvSphere環境を参照して移行対象のVMを選び、データレプリケーションを設定し、テスト用のクローンや本番カットオーバーを管理できるようにします。
多くの方にとって、これが最も魅力的な選択肢になると思います。選択肢2の手動インポートと違い、多くの工程が自動化されており、私の経験でも安定してイメージを移行できました。サーバーが数台を超える規模なら、これが最も短時間で済む方法です。Migrate to Virtual Machinesは最新OSとレガシーOSの双方に幅広く対応しています。
Migrate to Virtual Machinesの利用には、migrate connectorからGoogle APIへ直接通信できることが前提です。経路はインターネット経由でも、VMware環境とGoogle Cloud間のプライベート接続経由でも構いません。こちらのサポートページで選択肢が整理されています。
Migrate to Virtual Machinesを使う基本的な流れは次のとおりです。
- 前提条件のセットアップ。関連するGoogle Cloud APIの有効化、利用するプロジェクトとIAM権限の決定などを行います。
- 既存のVMware環境にmigrate connectorをインストール、構成、登録します。
- VMの移行を開始します。移行プロセスは次のステップに分けられます。
- VMをMigrate to Virtual Machinesにオンボーディングします。
- 選択したVMまたは全VMのレプリケーションを開始します。レプリケーションはソースVMが稼働中でも実行可能です。
- VMインスタンスタイプやネットワーク構成など、ターゲットVMの詳細を設定します。
- 必要に応じて、クローン機能で移行テストを行えます。隔離したターゲット環境で実施するのがお勧めです。ソースイメージはVMware上で稼働を続けたままです。
- カットオーバーを実行します。ソースVMをシャットダウンし、最終レプリケーションを取得したうえでターゲットVMをプロビジョニングします。この段階ではダウンタイムが発生します。私が試したイメージでは、ソース停止からGoogle Cloud上の新インスタンス起動までおよそ15分でした。大半はイメージ処理の時間なので、サイズによって増減します。
- 後片付け。
選択肢4:大規模・多数のレガシーアプリにはGoogle Cloud VMware Engine
他の選択肢があまり知られていないため、最初に行き着く先がGoogle Cloud VMware Engineというお客様が多く見られます。GCVEはユースケースさえ合えば素晴らしい製品ですが、少数の仮想マシンをGCVEクラスタで動かすとコストはかさみます。
GCVEの最小構成は3ノードクラスタです。各ノードはve1-standard-72インスタンスで、ハイパースレッディング72コア(物理36コア)、768GBのRAM、20TB超のSSDを備えます。オンデマンド料金は1ノードあたり9.29ドル/時で、最小構成の3ノードクラスタは月額20,345.10ドルになります。1年または3年のcommitmentsを組み合わせれば、価格は大きく下げられます。
1ノード構成も用意されており、料金もリソースもやや抑えられますが、Googleはこれを主にPOC用途と位置づけ、利用期間を60日間に制限しています。本番workloadsをこの構成で動かすのは避けてください。
とはいえ、GCVEはEOLレガシーアプリを動かす有効な選択肢でもあります。リソース要件がそれを必要とする規模である、workloadsのライセンスがクラウドと相性が悪い(Windows Server、Oracleなど)、あるいは既にオンプレミスでVMwareを大規模に活用しており、ツールや運用への投資を活かして特定のworkloadsを引き続きVMwareで動かしたい──こうしたケースに向いています。
おまけの選択肢5:Migrate to Containersでレガシーアプリをコンテナ化する
Google CloudのMigrate to Containersも、特定のworkloadsには有効な手段です。すでにコンテナ運用に慣れていて、これ以上GCEの仮想マシンを増やしたくないのであれば、十分検討に値します。Migrate to Containersはworkloadsを分析し、コンテナ化に適していると判断されれば、VMベースのworkloadsをGoogle Kubernetes EngineやCloud Runで動かせるコンテナとして出力します。
注意点は、すべてのworkloadsが変換に向くわけではないということです。Googleは適しているworkloadsと適していないworkloadsの例を公開しています。分析ツールも判断の助けになります。多少の改修が必要になる場合もあります。最新OSとレガシーOSの双方が幅広くサポートされています。
塩漬けレガシーアプリにベストな選択肢は?
これまでお客様と取り組んできた経験から、総合的に最良なのはMigrate to Virtual Machinesだと考えています。必要な作業量、自動化、信頼性、ステートフルworkloadsで求められるダウンタイムの少なさ、いずれの観点でもバランスが取れています。
対象が1〜2台のイメージだけなら、非推奨のGoogle Cloudイメージへ再インストールするか手動変換で済ませたほうが、GCE上で仮想マシンを動かすまでの手間は少なくて済むかもしれません。ただし、ダウンタイムをほとんど許容できないステートフルworkloadsの移行には不向きです。
すでにコンテナ化されたアプリを運用していて、必要に応じてworkloadsへ多少手を入れる用意があり、これ以上仮想マシンを増やしたくないのであれば、Migrate to Containersは面白い選択肢です。一方で、すべてのworkloadsがこのプロセスに適しているわけではなく、動作させるためにアプリケーションの改修が必要になる場合もあります。
最後に、大規模な要件がある場合、特に既存のVMware環境がクラウド上で複雑なライセンス事情を抱えている場合には、GCVEが力を発揮します。GCEではコスト効率よく動かせない既存のライセンス契約を維持したまま、これまで培ったスキルセットやツールを活かせるからです。とはいえ、小規模なアプリが数本だけというケースには、GCVEは料金面で見合いません。