移行では、大きく3つのポイントがあった。
1つ目は、仮想マシンの移行だ。OS無停止で移行するために「VMware Hybrid Cloud Extension(HCX)」の機能を活用した。HCXでは「コールドマイグレーション」「バルク(ウォーム)マイグレーション」「vMotion(ゼロダウンタイムマイグレーション)」「Cloud Motion(大規模マイグレーション)」という移行方法が選択できる。「開発環境については、IPアドレスを変えない方式が必要なのでCloud Motionを選択。商用環境については、IPアドレスを変えて現在の環境と並行稼働させるためコールドマイグレーションを選択しました」(渡邊氏)
HCXはL2延伸を行ってOS無停止、調整なしでの移行が可能だ。それには、「VMware vShpere」の仮想マシンのハードウェアバージョン 9.0以降で対応していて、2012年にリリースされた「VMware ESXi」5.1以上で作成した仮想マシンなら可能となっている。「ただ約85%の仮想マシンは、ハードウェアバージョンが古かったためvMotionで移行できず、ゲストOSの再起動が必要でした。何はともあれ、2019年5月末までに400仮想マシンの移行を完了しました」(渡邊氏)
2つ目のポイントは、AWSとの通信連携が難しいことだ。VMCの仕様では、AWSとの通信は「VMC接続用VPC」の特定サブネットで通信する必要がある。「既存システムでは、オンプレミスから直接サービスVPCに接続している通信があり、VMC接続用VPCの特定サブネットを経由させづらい。この課題を解消するための選択肢は中継用プロキシを立てるか、新サービスの『AWS Transit Gateway』とVPNを使うかの2つがあります。Transit Gatewayが本命なのですが、出たばかりでSLA(サービス品質保証)も少し低く、使い分けに悩んでいるところです」(渡邊氏)
3つ目のポイントは、2019年6月現在だが、VMC標準でロードバランサーが提供されていないことだ。ロードバランサーは、サーバの冗長化やスケールアウト、ローリングデプロイのために必須。選択肢としては、「Elastic Load Balancing(ELB)」でVMC接続VPCから負荷分散するか、VMC内に仮想マシンベースで負荷分散装置を作るかだが、渡邊氏は「どう構成するか難しい点も多い」とした。現在はサードパーティー製の仮想アプライアンスで負荷分散を行っているという。
VMCは新しいサービスということもあり、懸念点もある。渡邊氏は、アップデートが頻繁であること、設定上限、性能上限など仕様が不明瞭なこと、システム停止を伴うメンテナンスの頻度が読みにくいことなどを挙げていた。
このように「ハードウェアからの解放とフルクラウド化」を目指しているゼンリンデータコムだが、運用面では、AWSとVMCの使い分けが発生している。
「AWSは共通プラットフォームなので、メンテナンスが多いことや互換性が低いことを考慮する必要があります。例えば、Amazon S3のSigV2対応、AWS Lambdaの実行環境のアップデート、Amazon AuroraのPostgreSQLパッチ適用など、ハードウェアがないとはいえ、メンテナンスコストを見積もる必要があります。一方、VMCは、おそらくユーザーが意識しなければならないメンテナンスは少なくなるとみています。また旧システムとの互換性も高い。ただ、現時点では、VMwareと一緒にサービス品質を上げていく覚悟も必要です」(渡邊氏)
最後に、渡邊氏は「サービスが求めるシステム特性を踏まえて、クラウドを賢く使い分けることが重要です。革新を提供するAWSはアクティブなサービスで、安定性を提供するVMCはパッシブなサービスで活用しています。また、VMCへの移行をとにかく完了させ、2020年度内にオンプレデータセンターのクローズを目指します」と意気込みを語った。
時は令和。クラウド移行は企業の“花”。雲の上で咲き乱れる花は何色か?どんな実を結ぶのか? 徒花としないためにすべきことは? 多数の事例取材から企業ごとの移行プロジェクトの特色、移行の普遍的なポイントを抽出します。
Copyright © ITmedia, Inc. All Rights Reserved.