柔軟なキャパシティと回復
はじめに
VMware Cloud on AWS で用いられる物理マシンは、AWS のデータセンターにある i3.metal インスタンス (微妙に i3.metal と i3p.16xlarge は違うところがありますが、ユーザーには見えません) が使われています。AWS は、このインスタンスを正に売るほど豊富なハードウェア リソースとして保有しており、ユーザーのリクエストがあり次第いつでも使えるようにスタンバイさせています。
VMware Cloud on AWS のユーザーは、API やポータルでの操作を通じて、この豊富なハードウェア リソースを必要に応じて、必要な分、必要な時間だけ迅速に利用することができます。もうハードウェアの納期待ち、構築作業待ち、あるいは追加契約待ちといったことはなくなります。
豊富なリソース
AWS には、一般のユーザーから見たレベルからは無尽蔵とも思える物理マシンがあり、これをいつでも必要な分だけ利用することができます。ユーザーから見ると非常に都合の良い仕組みで、AWS には収支が合わないようにも見えます。ユーザーにとっては物理マシンをリース以上に手軽に使える一方、AWS はその物理マシンをユーザーが使わなくなったら在庫として抱えるだけに見えるかも知れません。しかしながら、AWS はそのユーザー以外にも大量のユーザーを抱えており、長い時間軸で考えれば誰かがその物理マシンをある程度の利用率で使用している状態を保てるのでしょう。大量の物理マシン、そして大量のユーザーを抱えているため実現できる、一種のハードウェアのシェアリング エコノミーと捉えることもできるのではないでしょうか。
この豊富なリソースによるメリットとして、容易な物理マシンの増強だけではなく、容易な物理マシンの廃棄も挙げられます。通常 オンプレミスにおいて物理マシンを廃棄する場合には、廃棄のための事務処理の他に、各種ケーブルの抜線、構成変更なども必要となりそれ相応の後始末の処理が必要となります。これが VMware Cloud on AWS では、単純 物理ホストを削除 (Remove) するボタンをクリックするだけで完了してしまいます。
もちろん Confirmation のダイアログ UI が削除実施の前にあります。
気付きにくいところですが、この VMware Cloud on AWS では、ネットワーク機器についてもこの辺の物理的なキャパシティの考慮が不要 (むしろできない) になるメリットがあります。AWS VPC と AWS のデータセンター ネットワークが容易な物理マシンの増減を支えてくれるのです。オンプレミスにおいては、物理マシンの数がネットワーク機器のポート数の上限近くに達する場合、追加のネットワーク機器を用意する必要があります。このときの追加を見据えたネットワーク設計をしていればスムーズな追加ができるかも知れませんが、そうではない場合にはネットワーク トポロジーやケーブルの配線などで頭を悩ますことになります。
自動化された SDDC 用のハードウェア
仮想マシンであればいくらでも自動化するのは可能で、物理マシンはそう簡単にはいかない、そう思っていた時期が私にもありました。昨今は様々な Software-Defined Network (SDN) 製品が登場しており、物理マシンの自動化の障壁の一つであるネットワーク構成の自動化を実現しつつあります。AWS でも最近のベアメタル インスタンスにて、Elastic Network Adapter (ENA)、Elastic Network Interface (ENI)、Elastic IP (EIP)、Virtual Private Cloud (VPC) を縦横に駆使し、これを実現しています。VMware Cloud on AWS の自動化は、AWS のベアメタル インスタンスの自動化なくしては有り得ませんでした。VMware Cloud on AWS では、この仕組みを AWS のベアメタル インスタンスの一般提供よりも 1 年以上前から利用してサービスを開発してきました。
新規の SDDC 作成 (120 分弱) もさることながら、物理ホストの追加 (10 分程度) でもこの自動化が威力を発揮します。120 分といえば 1 回分のインフラ設計ミーティングの時間、10 分程度といえばそのミーティングの調整メールを書く時間と言ってしまっても良いかと思います。
それでも残るキャパシティの制約
VMware Cloud on AWS としての制約
現在の VMware Cloud on AWS では、1 Cluster あたり 32 ホスト、という制約があります。また 1 vCenter あたり 最大 10 Cluster という制限があります。とはいえ、合計すれば 1 vCenter あたり 320 ホストとなるので、よほどの巨大企業でない限りはこの制限に困ることはないかと思われます。また、この制約は 1 SDDC あたりの話なので、複数 SDDC を作成することで この 320 ホストの制限すら超えることができます。
予算の制約
とはいえ、IT に使える予算が無尽蔵な会社、あるいは売上に比例して IT 予算を増やせる会社というのはまずないかと思われます。VMware Cloud on AWS の北米での価格は 1 ホスト 3 年間で 11万 USD 弱ですので、これを 100 台レベルで利用できるケースはなかなかないでしょう。キャパシティの制約というよりも、キャパシティを広げるための予算の制約があるといったほうがよいかもしれません。
AWS の各種インスタンスの価格について、オレゴン:東京の比率を求めるとおおよその東京リージョンの価格が予測できます。
