見出し画像
Photo by nyakopan

Day23「VMware Cloudによる解決策案を考えてみる」 @ ガバメントクラウドについて考えるAdvent Calendar 2022

Junnosuke Nakajima

この記事は、ガバメントクラウドについて考える Advent Calendar 2022のDay23「VMware Cloudによる解決策案を考えてみる」となります。

※こちらの記事は基本的には公開情報を元にしていますが、個人的な妄想・意見も含まれておりますので、ご承知おきください。

このAdvent Calendarは、日々活動している中で課題として感じることなどをどこかで整理しなくてはいけないと思っていて、ちょうど良いタイミングだったので、全日自分が思うところを書くというスタイルにチャレンジして、どこまで続けられるかやってみたいと思います。
https://adventar.org/calendars/8293

以前、以下のツイートに多くのことをまとめてみたのですが、改めて整理していきます。

VMware Cloudによる解決策案を考えてみる

今回は今までに振り返った課題感をどう解決するかを具体的な方法を持って検討していきます。まずは改めてガバメントクラウドの課題感を以下のように振り返ります。

  • 単純リフトではコストメリットが出ない

  • クラウドに合わせたシステム再設計が必要になる

  • アプリケーションの高可用性のための再設計が必要になる

  • 移行によるネットワークの再設計が必要になる

  • 20業務とそれ以外で運用管理の2重化が発生する

  • クラウドネイティブ化をマネージドサービスなどで実施することにより、クラウドへの依存度の高まりを検討する必要がある

今回だけは、ポジショントークとさせていただきますが、このような課題感にまさに最適なケースが、VMwareが持っているVMware Cloudなのだと思っています。これは2025年度までの標準化の負荷を踏まえて、単純リフトしか難しそうな場合に、より良いリフトの方法と捉えていただければと思います。とは言いつつ、クラウドは利用しますし、クラウドネイティブ化へも進んでいくものと位置づけて良いものと考えます。

そもそもVMware Cloudとはどんなものなのか簡単に紹介します。ここではガバメントクラウドの先行事業でも全ての団体が利用したAWSの上でのVMware Cloud on AWSをベースに紹介します。と紹介するように、VMware Cloudとは、前回紹介したオンプレミスとプライベートクラウドで構成されたテクノロジーをガバメントクラウド各社のクラウド上で実現するクラウドサービスを指します。広義では、日本の国内のクラウドサービスプロバイダはほとんどがVMware Cloudで出来ているとも言えます。

つまり、オンプレミス・プライベートクラウドを含むガバメントクラウドなどのクラウド事業者のどちらにおいても、全て同一技術で構成されたクラウドサービスということになり、これらを今までと同じツールで統合的に運用管理できるだけでなく、同一アーキテクチャでクラウドを問わないアプリケーションを構成することができます。また、そのクラウド間は無停止で移行が可能になります。

つまり、ガバメントクラウドの先行事業で出た課題感をかなりカバーできる、ガバメントクラウド上で実行されるクラウドサービスだと思っていただければと思います。つまり、今回の標準化では、オンプレミス・プライベートクラウドではなく、なんとかガバメントクラウド上へ移行したいという方のためのソリューションと言えると思います。元々の課題感は、このVMware Cloudにより、以下のように解決できます。

  • 単純リフトではコストメリットが出ない　→　追加ネットワーク費用以外は、コスト効果を出せる要素があります（後述します）

  • クラウドに合わせたシステム再設計が必要になる　→　ほぼ不要

  • アプリケーションの高可用性のための再設計が必要になる　→　不要

  • 移行によるネットワークの再設計が必要になる　→　不要

  • 20業務とそれ以外で運用管理の2重化が発生する　→　統一できる

  • クラウドネイティブ化をマネージドサービスなどで実施することにより、クラウドへの依存度の高まりを検討する必要がある　→　クラウドを問わない

つまり、2025年度までに迅速に移行しないと行けない中で、そのスピードであるとか、その移行に伴うシステムとしてのリスク軽減を重視した形にできるだけでなく、人材・スキルセット不足による品質面での懸念を払拭することができます。また、今後を踏まえて、クラウドネイティブへの移行を前提としたネイティブサービスとの連携も可能になる構成です。これを私は個人的に、Lift & Learn Then Shift（一旦リフトしてクラウドを学び、それからシフトする）という方法として呼んでいます。

また、今回の先行事業では経緯及び時間的にもリソース的にもAWSでの構成が多くなっていますが、今回は単純にIaaS利用で、次回調達以降にクラウドネイティブ化が進んでいくことを考えると、今回VMware Cloudで構成することで、その際に適切なクラウド選択ができるようにしておくことにも繋がります。

今後のクラウド選択の変化に備えるには、各クラウド独自のIaaSを採用するとクラウドスイッチがしにくくなるところを、オンプレミス・プライベートクラウドからガバメントクラウドまで含むクラウドで共通のIaaSへ統一することができ、将来的なクラウド選択が非常に柔軟になります。もちろん、ガバメントクラウドの上で構成されるので、これらの共通IaaSと各クラウドサービスのPaaS/SaaSとも密接に連携可能な仕組みになっています。

このようなクラウドサービスの利用の仕方にすることによって、ガバメントクラウドに移行するにあたり、今までより高くなってしまう必要コストを抑えつつ、本来の標準化・クラウド移行を現実的なものにし、重点的に投資する分野へ集中し、無理にお金をかけない取り組みとすることができると考えています。

こういった背景から、全てのガバメントクラウドの事業者がVMware Cloudのサービスを整備しており、クラウド化の最大のハードルとなるようなネットワークやアプリケーション・システム再設計を解決し、ネットワークの最適化やシステム改修の最小化を実現して、クラウドに引き込む手段として提供されています。

VMware Cloudの解説

では、もう少しVMware Cloudについて紹介していきます。

まず、AWSで言うEC2とVMware Cloud on AWSのリソースの考え方の違いと販売単位について整理します。まず、今までのオンプレミスやプライベートクラウドはハイパーバイザーという仮想化ソフトウェアが販売単位でした。これがAWS EC2の場合は、定められた仮想マシンサイズから適切なものを選択して購入することになり、販売単位が仮想マシンとなります。VMware Cloud on AWSは、AWSから提供される物理サーバー（EC2ファミリー）を購入することになり、物理サーバー1台が販売単位となります。

そのため、VMware Cloud on AWSの場合は、その物理サーバー上にどのような組み合わせのCPUとメモリの仮想マシンを作成することも可能で、かつ詰め込めば詰め込むほどコスト効率が上がっていくという仕組みになっています。

選択可能な物理サーバーをベアメタルサーバーと呼びますが、現時点では下記のようなものから選ぶことが可能です。システム全体で必要なリソース容量から選択する必要があります。

では、このVMware Cloud on AWSが今回のような複数に分かれる環境などにどう効果的かを説明していきます。

VMware Cloudによる運用管理面への寄与

まずは運用管理面です。20業務がガバメントクラウドで構成され、それ以外がオンプレミス・プライベートクラウドで構成されると、以下のような形になり、管理コンソールも監視・障害対応も別々のノウハウで運用しなければならないということが、人材・スキルセット不足を引き起こすかもしれないということでした。

しかしながら、クラウド側をVMware Cloud on AWSとすることで、同一運用管理にすることができ、運用人材も既存人材を活用することができます。

それだけでなく、統合して運用管理することができるため、別々の管理コンソールで運用しなくても1つの管理コンソールで統合することができます。このような統合運用化による運用コストの低減が図れることになります。

さらに、クラウド側をVMware Cloud on AWSだけでなく、クラウドのマネージドサービスと組み合わせるケースもあると思います。

AWS EC2 + RDSのようにする場合は、結局AWS側のコンソールを使うことになるのではないかということも、実は今までオンプレミス・プライベートクラウド側で提供されていた高度管理ツールであるVMware Aria(旧vRealize Operations)により統合管理可能です。

以下のようにクラウド側のサービスも統合して運用監視することができます。

Ariaは全体を以下のように統合して俯瞰することで監視し、異常のある部分をドリルダウンして運用監視を行います。

この仕組みはオンプレミスやプライベートクラウドとの統合だけでなく、複数のガバメントクラウドを統合して見ることができるというのも特徴的です（ここではAzureも追加した場合を載せておきます）

異常が起きた際のアラートについてもこのように統合して見ることができ、複数のツールでアラート管理などする複雑性を回避することが可能です。

VMware Cloudによる可用性面への寄与

続いて、可用性の観点です。AWS EC2で構成される場合、データセンター障害に対応するため、マルチAZ構成を取ることが通常かと思います。しかしながら、今までのオンプレミスやプライベートクラウドでは、インフラ側でHAクラスタなどの耐障害性の仕組みを持っていましたが、クラウド上ではそれらが提供されないため、アプリケーション側でそういった仕組みを実装しなければなりません。また、双方のAZで仮想マシンを常に立てて障害に備えなければなりません。

VMware Cloud on AWSでは先に述べたインフラ側の耐障害性の仕組みをそのままクラウドに持ち込んでいますので、マルチAZ構成のためにアプリケーション側でのフェイルオーバーの仕組みを実装することも必要ありません。また、双方に仮想マシンを準備しておかなくても、AZ障害時には片方のAZからもう一方のAZへ自動的にフェイルオーバーされます。加えて、AZ内での障害もAZ内で自動的にフェイルオーバーされる仕組みになっているので、単純に障害が発生したときのシステムとしての強さが高度化され、簡単にAZ切り替えなどが起きないようにすることも可能です。

このAZ跨ぎの構成をストレッチクラスタと呼んでいて、オンプレミスやプライベートクラウドでもデータセンター間の耐障害性のために使われているソリューションなのですが、クラウド上でもチェックボックス1つでマルチAZ構成の実現が可能です。

VMware Cloudによるオートスケール面への寄与

続いて、必要なときに必要なだけ用意するというオートスケールについてです。先の販売単位の説明の通り、EC2の場合は、必要なメトリックを設定した上で、仮想マシン単位で増減（スケールインスケールアウト）を実装していきます。

VMware Cloud on AWSも販売単位と同様に増減する単位は仮想マシンではなく、物理サーバー単位となります。Elastic DRSという機能で、性能が足りなくなりそうな場合は、自動的に物理サーバーが追加されます。

あくまでリソースプールの追加を行うイメージですので、そこから仮想マシンの追加については、仮想マシン側で実装する必要があります。

VMware Cloudによる移行・ネットワーク面への寄与

最後に、既存環境からの移行やオンプレミス・パブリッククラウドとのネットワーク接続についてです。VMware Cloud on AWSにおいては、HCXという機能があります。オンプレミス・プライベートクラウドからL2延伸が可能なため、既存のネットワーク環境をそのままクラウドに移行できるだけでなく、クラウド間でライブマイグレーションができます。つまり、既存環境の仮想マシンを無停止でクラウド上へ移行できるということです。この他にもウォームマイグレーションということで、クラウド側へデータを同期しておき、再起動程度の時間でクラウド側へ移行するというオプションもあります。

このHCXを利用すると、ネットワークの移行に伴う課題感を解決することができると思います。IPアドレス体系の再設計やルーター・端末・DNSの再設定が求められるところを、VMware Cloud on AWSではそれらの設定変更が最小限に留められるため、移行のリスクを低減することが可能です。

クラウドへのネットワーク接続には様々なオプションが用意されており、特にHCXの場合は、クラウドとのネットワーク接続がWAN最適化されるようになっており、通信帯域の効率化にも寄与します。

VMware Cloud on AWSによるコスト面での寄与

今まで説明してきたVMware Cloud on AWSですが、自治体規模によってはオーバースペックというケースがあり得ます。これは物理サーバー単位で提供されるため、あまり大きくない規模の自治体で仮想マシン数が少ない場合には、仮想マシン単位で購入したほうがコスト有利になる場合があります。

それなりに仮想マシン数がある場合には、1つの自治体でVMware Cloud on AWSをご利用いただくことで全く問題ないのですが、仮想マシン数が少ない場合は複数の自治体を共同でホストするなどしたほうがメリットがあります。そのため、自治体間で調整いただくか、アプリ業者に複数自治体をホストしてもらうのが良いでしょう。

こうしたメリットを踏まえて、クラウドへの移行を検討される自治体においてVMware Cloud on AWSは稼働実績も2021から出てきており、2022〜2023年においても大きく増えて来る見込みです。

最後に、クラウドのIaaSにリフトした場合と、VMware Cloud on AWSに移行した場合の具体的な詳細コスト比較が出ていますので、紹介して終わりたいと思います。

https://blogs.vmware.com/cloud/2022/12/13/comparing-vmware-cloud-to-traditional-public-cloud/

前提条件の概要は以下のとおりです。

  • 3年、300TB、1,000VM、4vCPU 16GB RAM、ディスカウントなし

  • AWS m5.xlarge EC2 + EBS vs VMware Cloud on AWS 28ノード

一般的なクラウドのIaaSは仮想マシン単位での提供となるため、VMware Cloudの特徴であるリソースプール（物理サーバー）提供においては、仮想マシン間でのストレージ重複排除、CPU共有、メモリ重複排除などの機能が利用でき、この物理サーバー群に詰め込める仮想マシン数はさらに向上していきます。物理サーバーにはCPU・メモリだけでなく、ストレージも含まれていることから、そういった面でも価格的メリットが出るケースが多いとされています。ライセンス的にも物理サーバー単位で購入することになり、こちらも詰め込めば詰め込むほど有利なケースがあると言えます。

自社ブログからの引用なので、ポジショントークっぽくなってしまいましたが、このような点で、移行や人材・スキルセットと併せて、総合的なコストメリットが出るようになっているわけで、各ガバメントクラウドベンダーの全てがこぞってこのサービスを自社のクラウド上に構成できるようにして、クラウド移行を推進させようとしていると言えるのだと思います。

もう少し詳細を見られたい方は、英語で申し訳ありませんが、以下をご参照いただければと思います。

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/docs/vmw-whitepaper-comparing-vmware-cloud-to-traditional-public-cloud.pdf

まとめ

今までの内容を整理させていただきます。ガバメントクラウドの中間報告によると単純なリフトだと今までより高くなってしまうため、クラウドネイティブ化が求められるものの、標準化の負荷も踏まえると現実的ではないとするベンダーも多いことや、クラウドへのネットワーク費用が追加で必要になったり、20業務以外も含めた運用も必要になってくることから、今までのコスト感で進めようとすると何かしらの対策が必要な状況です。

そういったケースにおいて、各クラウドのIaaSへ単純リフトに比べて、VMware Cloudはより良いリフトを提供し、既存人材を活用した20業務以外との統合運用に効果を発揮し、移行にまつわるシステム・運用・アプリケーションの再設計を最低限に留めることができるソリューションです。また、各ガバメントクラウド業者それぞれでVMware Cloudが提供されており、これらは共通のテクノロジーで一貫性がありますので、クラウドネイティブ化を待つにあたっても、各クラウドに依存しない形で備えることができます。

VMware Cloudを活用した場合に、共同利用方式・単独利用方式の双方において先のメリットが得られ、運用範囲が統合されていきます。

これまでのメリットを踏まえて、20業務の移行先として、プライベートクラウド、単純リフト、VMware Cloudリフト、クラウドネイティブシフトのどれが最も効果的でコストメリットがあるかについて、ぜひ試算してみていただき、今後の選択肢となれば幸いです。

執筆後記

このようにガバメントクラウドを考えるAdvent Calendar 2022では、以下の流れで進んでいくことになると思いますので、Day23以降もお待ちいただければと思います。

  • ガバメントクラウドの在り方

  • ガバメントクラウドの整備における課題感

  • ガバメントクラウドの利用における課題感

  • ガバメントクラウドの今後について考えてみる

Twitterなどで情報発信していますので、もしよろしければ覗いてみてください。