日々是仮想化

日々是仮想化

仮想化技術に関する情報などなど・・・

MENU

事例からわかるVMCのメリット

        f:id:furuyamas:20200908153529p:plain

今年はVMCに始まってVMCに終わりそうです。VMCをかなり推しているとかいうわけではないのですが、ユーザからの相談などで分かってきた?ことがあります。

VMC on AWSは、過去の記事で述べた通り、一定規模の仮想基盤をクラウドに移行したいという要件にピッタリではあります。しかし、対コストを考慮した場合、そこそこ大規模の仮想基盤でないとニーズに合致しません。3ホスト3年間で4500万円くらいからになるからです。一般に4~5ノードのHCIまたは3Tierを構築した場合、オンプレだとこの価格を下回ることが多いです(半分まではいかないと思いますが)。

また、通常5~7年間をリプレースサイクルとするユーザが多いので、さらに価格差は広がるケースが多いのが実情です。

私の活動地域は、いわゆる東京付近ではなく、西日本を中心とした地方ということもあり、VMCを提案する機会は少ないものと想像していました。実際、VMCを薦めてみても「いいのはわかるけど、、でもお高いんでしょ?」と返されることがよくあります。

上記をふまえても、あえて事例を交えて記事にしました。SIer視点からだけでは見えなかったユース事情が見えてきたからです。

 

f:id:furuyamas:20200908154441p:plain

まず、VMC on AWSの概要を簡単に。

AWSのベアメタルにvSphere+vSAN+NSXがベース構成です。ライセンスは利用料に同梱されています。また、VMwareによるフルマネージドになります。基本的には、監視などのコストはあえて考慮する必要はありません。(アプリ監視などは必要なケースもありますが)

※対象ノードが新規ではi3だけになりました。

 

f:id:furuyamas:20200908154715p:plain

アップデートやメンテナンスなど基本的な運用業務はすべてVMwareが実施します。また、サポートについても24h/365dで対応となります。

ここまでで重要なポイントは、ただ仮想基盤を構成するHWだけではなく、運用やサポート、監視などにかかる自社のコストも含めて比較する必要があるという点です。

 

また、3ノードが最小ノード数であったものから、2ノード構成の提供が開始されました。

f:id:furuyamas:20200908155138p:plain

これまでよりも、小規模のクラウド移行に対応できる形となりました。また、拡張も容易に実施できるため、サイクルを迎えたシステム単位の小規模移行も実現できます。

では、ここからは実際の事例について述べます。

CaseStudy①

・全社的に既存のシステムをAWS上に移行することを計画

AWS移行に伴うシステム開発コストを算出した結果、想定より大幅に増大し、移行計画が中断していた

・既存機器のリプレース期限も迫っており、早急な移行計画が必要であった

・レガシーOSで動作するシステムもいくつかあり、クラウドへの単純移行は困難であった

このケースでは、クラウドへの移行を検討しつつも、コストと期間について悩みを持っていました。当初、VMCはまったく見当範囲の外にありましたが、実際にトータルコストを比較することを実施されました。

f:id:furuyamas:20200908155608p:plain

上記のように、既存AWSネイティブの環境との接続性をより強化し、かつオンプレミス環境から一部のシステムを移行、アプリなどの開発なども不必要にしたという点が採用のポイントとなります。

ここで重要なポイントですが、既存がVMware仮想環境である場合、VMCだとそのまま移行できるというメリットはある意味当たり前となります。ただ、年間のDC運用コストとHWコスト(リプレース計画にかかる人件費)、運用や監視業務などもしっかり合算して比較検討していただいた結果、VMCのほうが安くなったという事実です。

地方のデータセンター利用料は、実は私が想定していた以上に高いんですね。しかもかなり高いという事実を知りました。この点においてクラウド移行を計画したが、AWSネイティブに持っていくにはアプリの再開発が必要でありそれが高すぎるどうしよう、簡単にいうとこうした悩みを解決した形になります。今後、リフト&シフトを中長期的に計画することを可能にしました。

 

CaseStudy②

メインサイト/DRサイト 2か所のDC運用

・DC利用料、運用コスト、リソースの確保、定期的なリプレースなど環境維持のための年間コスト増大が問題となっていた

AWSへのシステム移行も順次おこなっていたが、DCークラウド間の遅延も気になる

メインサイト罹災時を想定した場合、DRサイトへの切り替えに要する時間は要望されるものより大幅にかかることが想定されており、問題となっていた

クラウドへの移行計画も、既存環境から大幅な変更が必要であるため、長期的かつ費用増大となることが想定された

このケースでは、メインとDRをそれぞれ離れたDCにて運用されており、またクラウドへの移行を計画されていました。ここでポイントとなるのは、DR側はメイン罹災時を想定し、基本的に同等のリソースを確保し続けているという点です。まったく利用していなかったわけではないのですが、DCが罹災するようなケースは10年ないしそれ以上に1度という実情のなか、それでも5年おきにリプレースし同等のリソースを準備、DC利用料や運用監視といったコストもかかり続けるということです。

f:id:furuyamas:20200908160631p:plain

そこで、VMC on AWSの登場となりました。DRサイトからは、どうしても移行できないVMが稼働できる最低限のリソースを確保し、DRとしての機能をVMC上に移行しました。また、VMC上で通常時に保持しておくリソースは3ノードで最小限とし、AWSネイティブ移行のテスト環境としても利用できるようになりました。これは、AWSとの接続性がかなり良好となったことによるものです。さらに、メインサイトからはAWS-S3上にバックアップアプリでデータを転送することで、データ保管料も抑えました。メインサイト罹災時には、AWS-S3からVMC上にリストアすると同時に、必要なリソースを拡張することでRPOも最小限にすることを実現しました。

 

この2つのケースにみられるように、コストをどのように算出するか、それは正確に算出したものなのかという点で、コスト比較が正確にできます。そして、ケースによっては、最適化することが可能となります。

 

f:id:furuyamas:20200908161200p:plain

検討すべき項目(利点)をまとめました。一般に知られるように、VMC=高いというのは成立しないケースもかなりあるのだということがわかりました。各ユーザに対して、自社の仮想基盤を計画~運用~リプレースにおいてどの程度コストが必要なのか、一度見直していただくことをおすすめします。

その結果よっては、IT投資の効率化が可能となるかもしれません。