VMware Cloud on AWS、非vSphereユーザーにとってのユースケースとメリット：「インスタンスタイプがない」はメリット

VMwareとAmazon Web Services（AWS）両社のスタッフが100人単位で関わリ、サービス提供開始に至った「VMware Cloud on AWS」。このサービスはユーザーにとって、どのようなメリットをもたらすのだろうか。ユースケース（使い道）としては何が考えられるのか。ここではVMware vSphereをこれまで使ったことのないユーザーにとってのメリット、使い道を紹介する。

[三木泉，＠IT]

　2017年8月末に、VMwareが提供開始したVMware Cloud on AWS（VMC on AWS）。トップマネジメント、フィールドエンジニアなど、VMwareとAmazon Web Services（AWS）両社のスタッフが100人単位で関わり、AWSのアンディ・ジャシーCEOは、四半期ごとの両社による進捗レビューミーティングで議長を務めてきたという。

　では、このサービスはユーザーにとって、どのようなメリットをもたらすのだろうか。ユースケース（使い道）としては何が考えられるのか。vSphereユーザーにとっては既存の「業務システムの一部を『リフトアンドシフト』する」「社内にしか置けなかったデータベースを移行して、AWS上に構築するフロントエンドと組み合わせて使い、ネットワーク転送課金を節約しながらセキュリティや可用性をコントールする」といった使い道がすぐに思い浮かぶ。ここではVMware vSphereをこれまで使ったことのないユーザーにとってのメリット、使い道を紹介する。

AWSだけがクラウドだと信じている人は、利用する意味がない

　まず、確実にメリットを享受できない場合について触れておきたい。「AWSのこれまでのやり方のみがクラウドだ」と信じ切っている人は、VMC on AWSのメリットを理解できないし、理解するつもりもないだろう。従って、VMC on AWSを調べる必要はない。迷わずAWSのネイティブサービスだけを使っていくだろう。

　だが、VMwareが提供するサービスであるにもかかわらず、アンディ・ジャシー氏をはじめ、AWSがここまで力を入れているのは、「AWSのこれまでのやり方だけでは、対応できないユーザーやユースケースがあるから」だ。VMC on AWSはあらゆるユーザー、ユースケースに当てはまるものではない。だが。AWSから見ると、いくら機能を強化しても、アーキテクチャ的に対応できないものがある。これを補ってくれる存在がVMC on AWSだ。

　本稿はユーザーにとってのメリットやユースケースを探る記事であるため、以下ではVMwareやAWSの都合には触れない。2社それぞれの考えについては、「『VMware Cloud on AWS』の、AWS、ヴイエムウェア、ユーザー企業にとっての意味は」という記事をお読みいただきたい。

　メリットを享受できないユーザーの例を具体的に挙げると、次のようになる。

　VMC on AWSに似た、vCloud Airというサービスが日本で提供開始された当時、ある日本企業のIT部長は、「AWSに比べて、インスタンスタイプが圧倒的に少ない」と批判していた。vSphereを少しでもちゃんと触ったことのある人なら、これほど大きな誤解をすることはなかっただろう。

　vCloud Airにしろ、VMC on AWSにしろ、基本はvSphereをサブスクリプションモデル（1カ月単位、および将来は1年、3年単位の支払い）で使えるサービスだ。従って、vSphereの特徴をほぼ全て生かすことができる。「VMware Cloud on AWSについて、現時点で分かっていること」という記事では、現時点での「機能制限」について触れたが、制限があったとしてもvSphereの基本的なメリットは変わらない。

　しかも、例えばオンプレミスからパブリッククラウドへのライブマイグレーションは、どのクラウドベンダーも、紙の上ではできたとしても、本格的なサービスとして提供できたためしはない。筆者が上記記事で触れた理由は、VMworld 2017の基調講演で紹介されていたため、当初から提供されると誤解する人が多いのではないかと考えたからだ。

　さて、IT部長の発言に戻ろう。vSphereには、もともと「インスタンスタイプ」という概念がない。そして、これこそが、特にvSphereを使ってこなかったユーザー企業にとってのメリットにつながる、最大のポイントの1つだ。

vSphereの機能を、AWSとの比較でおさらいする

　vSphereにはAWSには見られない機能がある。vSphereを使ったことのある企業にとっては常識だが、以下ではこれをおさらいする。

自由にインスタンスタイプが作れ、後から構成を変えられる

　vSphereでは、ユーザーが仮想CPU、メモリ、ストレージを自由に設定して、仮想マシンを作れる（Google Cloud PlatformのCompute Engineにも「カスタムマシンタイプ」という、似た機能がある）。しかも、ホットアド（Hot Add）という機能を備えている。ゲストOSが対応していれば、仮想マシンを停止することなく、仮想CPU数とメモリ量の追加ができる。

　AWSでは確かに多数のインスタンスタイプがあるが、ユーザーのアプリケーションにぴったり合ったサイズのインスタンスがあるとは限らず、無駄が生じることが考えられる。また、インスタンスサイズの変更にはさまざまな制限がある。これに比べると、VMC on AWSのほうが柔軟性は高いし、工夫次第で多くの仮想マシンを詰め込める。

メモリ・オーバーコミットメントで集約率を向上

　vSphereでは「メモリ・オーバーコミットメント」と総称される機能があり、メモリを実際の搭載量よりも多く利用できる。このため、集約率をさらに高められる。

vMotionで計画停止に対応できる

　VMC on AWSではメンテナンスがどう行われるのかが分からない。だが、AWSで見られるようなセキュリティパッチなどのための停止・再起動は。ライブマイグレーション機能のvMotionを使って仮想マシンを停止することなく行える。

DRSで物理マシンの負荷を自動的に平準化

　vSphereには、物理マシンの負荷がしきい値を超えると、自動的に一部の仮想マシンを他の物理マシンに移動して、平準化が図れる機能「Distributed Resource Scheduler（DRS）」がある。また、新たにElastic DRSという機能を開発中だ。この機能では、1クリックで新物理マシンを追加し、DRSクラスタに参加させられる。

VMware HA、VMware FTで可用性を向上する

　「VMware HA」は再起動型HAだ。いずれかの物理マシンに障害が発生した場合、自動的に別の物理マシン上で仮想マシンを再起動できる。また、仮想マシンが何らかのソフトウェア障害で停止状態になると、これを検知して自動的に再起動することもできる。

　もう1つの可用性向上機能、VMware FTは、仮想マシン間でメモリの内容を同期し、これによって一方の仮想マシンがダウンした場合に、他方の仮想マシンでサービスを継続できる。

では、非vSphereユーザーに、どのようなユースケースが考えられるのか

　集約率、可用性、自由な仮想マシンの構成などの利点を踏まえると、非vSphereユーザーであっても、より従来型に近い運用ができるに越したことはないソフトウェアコンポーネントに、VMC on AWSを使うことが考えられる。

　当然ながら、短期的あるいは長期的に、AWSの各種サービスを使いたいということが1つの前提となる。AWSを使う必要がないのであれば、VMwareの他のクラウドパートナーを使えばいいからだ。

　逆の表現をすればこういうことになる。例えば自社が提供しているオンラインサービスについては、AWSへの移行を進めている。だが、運用担当チームとしては、落ちてはならないサービスの可用性をできる限りコントロールできるようにしておきたい。

　上記の機能を活用し、例えばデータベースだけはVMC on AWSで動かし、フロントエンドにAWSのサービスを使うということが考えられる。

　vSphereを全社的に使ってこなかった企業が、例えば物理マシン上のアプリケーションをVMC on AWSに移行することも考えられる。この形であれば、既存システムについてはクラウドネイティブへの改変（そして特定クラウドへのロックイン）をせずに、とりあえずのクラウド化が図れ、クラウドネイティブ化をしたければ順次自社のペースで進めればよいということになるからだ。