移行か？継続か？──VMwareの完全リプレイスは不可能だからこそ押さえたい“現実解”への移行ステップ

第3の柱「エンジニアリング」：とにかく自動化を徹底する

──ハイパーバイザーやコンテナといった新しいテクノロジーにアプリケーションワークロードを移行するにあたって最大のポイントは何か。

　自動化の徹底だ。新しい環境の構築においてはもちろんのこと、古いVMware環境においても手動が入る余地を残さないように、とにかく自動化を徹底すること。エンジニアリングフェーズの成功はこれに尽きる。

──自動化にあたっては移行ツールの活用も有効になるか。

　残念ながら良い移行ツールは少ないのが現状だ。今のところ、Nutanixが提供しているツールがクラスタを一度に移行できる点などからおそらくベストだが、他はどれもあまり良くない。したがって自社で移行戦略を策定する準備、たとえばバックアップから仮想マシンを復旧する」「アレイレベルでストレージのクローンを作成する」といった準備をしておくといいだろう。

　また、ハイパーバイザーを変更する場合は、ハードウェアも多めに用意しておいたほうがいい。代替ハイパーバイザーはVMwareよりも効率が悪いことが多く、仮想マシン密度の低下が予想される。同じワークロードをVMwareで実行する際に必要とされたハードウェアよりも多く用意することだ。

──新しい環境に移したあとの残ったVMware環境の最適化では何をすべきか。

　とるべき介入措置としては、オーバーサブスクリプション、ホスト数の削減、仮想マシン数の削減、ホストCPUのダウングレード、ホストRAMのアップグレード、仮想マシンのライトサイジング、ワークロードのパフォーマンスチューニングなどが挙げられる。こうした措置を取ることで、ハードウェアの利用効率を挙げたり、VMwareライセンスのコア数を減らして運用コストを削減することが可能になる。

──エンジニアリングフェーズにおいて他に留意すべきことはあるか。

　VMwareからの移行は基本的にエンジニアリングプロジェクトだが、経営層の関与も重要だ。したがって上級マネジメント層やビジネス部門を早期かつ頻繁に関与させることを推奨する。VMwareのリプレイスには大規模な変更が伴うことが多いため、コストや労力を必要とする事態になった場合、変更に対しての賛同と協力を彼らから得る必要があるからだ。

第4の柱「アドミニストレーション」：運用保守でも自動化

──移行作業が終了し、新しい環境を立ち上げるにあたって気をつけるべきことは何か。

　いくつかあるが、まずは新旧の環境ともにワークロードをチューニングし、パフォーマンスの最大化を図ることだ。たとえば空きコアの待機時間、ホストカーネルの待機時間、他のvCPUの待機時間、メモリ競合、I/Oレイテンシなどをチェックし、パフォーマンスの劣化率を比較する。目安としてはベアメタルと比較して劣化率が5%未満であれば、その環境は良好に機能していると言っていいだろう。

　また、運用にあたってはVMwareユーザーが開発したスクリプトツール「vCheck」をガイドラインとして活用することを推奨する。vCheckはVMware環境の状態をレポートするツールで、潜在的な問題や警告を日次でレポートしてくれるので、日常的な保守作業を自動化するのに適している。このスクリプトの機能を新しいハイパーバイザーで再現できれば、日々のメンテナンスの負荷を軽減できるだろう。日次の作業を自動化できれば、週次、月次と自動化の範囲を拡げやすくなる。運用保守でも目指すべきは自動化の徹底だ。

──VMware環境のリプレイスは一度ではできないということだが、残ったVMware環境はどう扱っていくのがよいのか。

　一般的な企業のIT部門がVMware環境のすべてを一度に完全移行することはほぼ無理だといえる。残ったVMware環境に対しては、ホストの廃止、またはサイズを変更してコア数を減らすなどしてライスセンスコストを最小限に抑えるようにしたいところだ。