自然の赴くままに・そのときの 気分次第で・なんとなく

興味を持ったことを、なんとなく気の向くまま書いています。

VMware vSphere ベースのクラウドへ移行と利用を考えるときのメモ

vExpert vSphere VMware Cloud

この10月でIT業界から引退して、次の何かにチャレンジしようとしているのですが、とりあえずIT分野で数年前からクラウド関係の仕事をしており、それらの記憶が薄れる前にメモとしてこの記事を書いてみました。

最近のクラウドサービスはいろいろなものが出ていますが、コンピュートリソースに関するものは大きく分けて AWS や Google Cloudのような Linux KVM ベースのクラウドと、WIndows Hyper-Vベースのクラウド、 そしておなじみの VMware vSphere ベースのパブリッククラウド及びベアメタルクラウドの 3つがあります。その中で vExpert としては VMware vSphere のクラウドサービスについて、クラウドサービスプロバイダーごとにどんな特徴があるのかをちょっと調べてみました。 

VMware Cloud

VMware vSphere ベースのクラウドサービスプロバイダーはどういうのがあるの？

VMware vSphere ベースのクラウドは自社データセンターの中に展開した vSphere のリソースを切り出し利用者に提供（貸し出す）方式、利用者専有の物理サーバーを用意してそれを利用者に貸し出す方式とあります。そして後者の場合は利用者占有のサーバー自体の管理も一部制限はありますが利用者に開放している方式と、利用者占有のサーバーはクラウドサービスベンダーが管理して、ハイパーバイザー上の環境のあるレベルから利用者に貸し出す方式（マネージドサービスですね）とに分かれています。

vSphere のリソースを切り出し利用者に提供（貸し出す）方式をとっているクラウドサービスプロバイダーはどこ？

以前は多くのクラウドサービスプロバイダーがこの方式を採用し利用者に提供していましたが、現在はだいぶ少なくなってきています。今この方式をとっている代表的クラウドサービスプロバイダーとして、いくつか名前を挙げてみます。（もちろんほかにもありますが、全部調べるのは難儀なので、VMware vSphere ライセンスのトラブル時に名前の出ていた代表的なものをあげました。）

などがあります。

これらの特長としては、オンプレミスのようにハードウエアやファシリティーを所有することなく、またクラウドに移行してもクラウドサービスプロバイダー側で用意する決められた仕様の物理ハードウエアによる無駄などの心配することなく、必要なリソースを必要な時に必要な分だけ利用できる、パブリッククラウドのような柔軟な利用形態になっているところです。これは将来的にクラウドに移りたいけれど vSphere ベースが慣れているのでそのままであれば助かるというような用途に向いています。ただし他の利用者のリソースと共有する環境上で区分けされた自分のリソースを使うわけで、その環境を使う際の仕様に合わせてオンプレミスで動かしてきた仮想マシンの設定などを変える必要も出てきます。この辺りはオンプレミスではなく、そしてリソースを占有しているわけではないので仕方がないところです。

利用者専有の vSphere が動く物理サーバーを用意し貸し出す方式（ベアメタル）をとっているクラウドサービスプロバイダーはどこ？

これはメガクラウドと呼ばれる外資系クラウドサービスプロバイダーが提供をしています。上記のvSphere のリソースを切り出し利用者に提供（貸し出す）方式を提供しているクラウドサービスプロバイダーも提供している場合があります。

外資系クラウドサービスプロバイダーで提供をしているのは、

などがあります。これらの外資系クラウドサービスプロバイダーは VMware と密に連携しながらサービスを提供しているので、VMware のサイトにもサービスが掲載されてたりしています。

同じようなサービスは日本のクラウドサービスプロバイダーでも提供はしているのですが、vSphere のリソースを切り出し利用者に提供（貸し出す）方式と同じ名称でオプションのような位置づけになっているのが多いようです。例えば

などです。

なお、この専有にはもう一つの形があり、利用者のデータセンターに物理サーバーを配置してしまうサービスというものもあります。これは

意外にVMware vSphere ベースのクラウドは色々なサービスが提供されているというのがわかるかと思います。

クラウド移行の選択肢は？

クラウドを利用したことのない場合、クラウドをどのように使えばよいのかから考えなければならないのですが、実はシンプルに考えるとその回答が見えてきます。

例えば、システムの大幅な見直しまでは考えていない場合、下図のレガシーなシステムというのがクラウド移行の選択先になります。システムの基本的な設計をいじらないのに、いきなりクラウドネイティブに移行することはできません。どんなに頑張ってもIaaSへの移行が関の山です。また、VMware vSphere に依存してしまう場合は IaaS までに行けず（富士通の FJcloud-V は、一応 VMware vSphere ベースの IaaS なのですが。）、その下のVMware ベアメタルサービスである VMware vSphere ベースのクラウド 移行する形になります。ここ、真ん中のベルトのように業務システムだけではなくエンドの利用者まで含めて全体を見直す「デジタルトランスフォーメーション（DX）」を実施しながらシステムも見直すということをしない限り、モダンアプリケーション＆クラウドネイティブにいくことは困難です。

クラウド移行の選択肢

ようするに、 VMware vSphere ベースのクラウドを使うということは、AWS が提唱している 7R の下から3番目の「Relocate」しているだけで、この Relocate はもっと簡単に言うと、オンプレミスでのハードウエアリプレースの際の新しいハードウエアに移行しているだけと同じということになります。なにもかわらない、何も変えないが、 VMware vSphere ベースのクラウドへの移行の基本です。

オンプレミスの VMware vSphere そのままクラウドに移行するときの注意点は？

VMware vSphere ベースのクラウドに移行する際に SIer が良く使う言葉として以下のようなことを聞くことがあります。

  • 簡単に移行できます。
  • オンプレミスとシームレスにつないで使えます。
  • オンプレミスと同じ運用方法ができます。
  • オンプレミスと同じツールがそのまま使えるので運用を大きく変える必要がありません。

これらは非常に魅力的な言葉なのですが、裏を返せばオンプレミスのセキュリティレベルでパブリッククラウドにVMware vSphere環境を持って行ってしまうということで、オンプレミスでのセキュリティ対策や VMware vSphere システムへのアップグレード、アップデート適用の仕方、そして管理者権限の取り扱いなどもそのままクラウドにもっていくということになります。この辺り、VMConAWSや富士通やIIJ、NTTどこもビジネスなど VMwareSphere のリソースを切り出し利用者に提供する方式の場合は、それぞれ提供元の用意するセキュアな管理者アカウントを利用することができましたが、VMware vSphere ベアメタル  Cloudサービスの場合、そのようなサービスがありません。つまりユーザーが契約したVMware vSphere ベアメタル  Cloudサービス環境の管理者権限がユーザー責任となるため、クラウドサービスプロバイダーが提供するセキュリティ機能をフル活用して、自分たちのVMware vSphere ベアメタル  Cloud環境を守るしかありません。ここ、VMware vSphere ベアメタル  Cloudサービスへ移行する際の一番重要な部分になります。このセキュリティ設計を怠ると、場合によっては自分たちの管理する VMware vSphere ベアメタル  Cloud環境の特権レベルが侵害される恐れが出てくるとともに、侵害された環境の情報漏洩や、仮想マシンを全て勝手に暗号化されて身代金を請求されるなどの被害を受ける可能性も出てきます。そして、バックアップ設計も同じ環境内に同じようなセキュリティレベルでしてしまった場合、バックアップまでも侵害されてシステムを復旧することが困難な状態に陥る恐れもあります。そのため、オンプレミスの VMware vSphere 環境をそのままクラウドに移行する場合には、クラウドベンダーの用意しているベストプラクティスに従い、VMware vSphere ベアメタル  Cloud環境のクラウド環境のセキュリティ設計をしっかり行うことが肝要です。

以下は代表的なクラウドサービスプロバイダーの提供する、VMware vSphere ベアメタル  Cloud環境のセキュリティ設定の情報になります。各社アイデンティティを使用した認証、ポリシーを利用したアクセス管理、そしてクラウドサービスプロバイダーのIAMとの連携の仕方などを情報として提供しているので、これらをしっかり把握し、侵害されない環境にすることが大切です。

もちろん、VCF を使用してオンプレミスの VMware vSphere とハイブリッドクラウドを構成する場合は、オンプレミスで使用していた VMware vSphere 環境のアカウントを含むセキュリティの見直しも必要です。
vSphere 8.0 のセキュリティ

vSphere 7.0 のセキュリティ

また、それでもやられてしまった場合は復旧を考えなければならないですが、これは一般的なディザスタからのリカバリーの考え方と同じで、いつまでにシステムを復旧させるか（RTO (Recovery Time Objective)）、どの時点まで復旧させるか（RPO (Recovery Point Objective)）、どのレベルまでシステムを復旧させて業務を再開するか（RLO (Recovery Level Objective)）を明確にし、それに基づいてシステムのバックアップを用意したりしていきます。クラウドの場合はセキュリティ侵害で同じ環境にあるバックアップもやられてしまう可能性もあるため、１代限りのバックアップだけではなく、バックアップの置き場所も運用している環境と切り離したところに置くなどの計画が必要です。

バックアップの考え方

そうすることで、万が一現在運用している環境が侵害されて使えなくなっても、別途同じような環境を用意することで、そちらにバックアップを戻して復旧を進めていくなどが出きるようになります。参照系と更新系も分けておけば、被害からの復旧もそれぞれ分けて考えることができるようになり、業務システムの復旧を速めていくこともできるようになります。

クラウドに移行するということは？

今回はあくまでも VMware vSphere ベースのクラウドへの移行の「さわり」を書きましたが、VMware vSphere ベースのクラウド移行はあくまでも「一時的避難」であり、本当のDXを実現したいのであれば、VMware vSphere ベースのクラウドへ移行して作れた時間を活用し、このままクラウド上のVMware vSphere環境を使い続けるのが良いのか、それともクラウドネイティブに移行するのが良いのかなどを、組織のデジタルトランスフォーメーションの進め方に合わせて選択してく必要があると思います。特にオンプレミスで稼働していた仮想マシン型のサーバーは、物理サーバー時代の設計思想のままというのが多いので、まずはそこを見直ししてリソースを無駄に使わないシステム構成に設計変更していく必要がありますし、データーへのアクセスもオンプレミスでは性能とコストの面でどうしても同じサーバーの中にすべてのデータを入れて処理をするということも多かったはずですが、これらも分散して処理する形にしアクセスをシンプルに変えることによるパフォーマンス向上なども考えることができます。またオートスケールやディザスタ対応などを考え、リードオンリー用途とリードライト用途のフロントを分ける設計にしたり、複数のクラウドベンダーにシステム分散して、どちらかのクラウドサービスがダウンしてもサービスが継続できるようにする、またはクラウドベンダーの過去の障害復旧時間を参考にしその時間内はサービスの一部提供が耐えられるようにするなども、業務システムによっては考慮していくことが必要です。特に最近クラウドサービスプロバイダー同士でマルチクラウドを形成するのに必要なサービスを連携して用意したりしているので、それらをうまく活用していくことも大切です。

どのように既存のシステムをクラウドに移行する？

クラウドをフルに活用したITシステムに移行するためには、考えなければならないことや、やらなければならないことが多々あります。それらをエンドの業務も含めてしっかり見直して、VMware vSphere ベースの得意部分と各クラウドサービスプロバイダーが提供するクラウドネイティブの得意部分を組み合わせた、最適なクラウド利用をしていくようにすることが、今後は必要になってくるかなと思います。この辺り、システムをどのように変えていくかがわかるように、その流れのイメージを簡単に図にしてみました。

モダナイゼーションの流れ

その他の重要な点として、クラウドを利用するということは、サービスを使ったらその分常にお金を払い続けるということなので、どのように支出を減らすかも重要な点になります。そこはオンプレミスで稼働していたシステムを分析し、業務での使われ方を十分把握して、例えばリクエストの回数を減らすようにする、ネットワークのトラフィックを減らすようにする、データのサイズをコストメリットが出る最大にするなど、既存のオンプレミスでのシステム設計とは違う観点での設計が必要になります。ここ、クラウドでのコストを減らすための一番重要な点になりますので、ITサイトや記事などでやたら出てくる「クラウドにしたらコスト増で大変な目にあったから、オンプレミスに戻すことを検討」なんて言っているところは、こういう視点での検討をしなかった失敗例と考えて気にしないことが大切です。そして、これらの要因を検討してどうしてもコスト削減できない部分が出てきたら、それは最終的にオンプレミスに存置するという形も出てくるかもしれませんが、まずはシステムを見直さない限りクラウドでのメリットを見出すことはできないということ、VMware vSphere 上でシステムに慣れてきたIT技術者は、視点を変える必要があると思います。

またもう一つ考えなければならない点、例えば Oracle データベースを使っているから Oracle Cloud を使い、そこのサービスの OCVS に VMware vSphere 環境を移行すると安易に考えないことです。要するに自社の業務システムでどのような機能を使っていて、その機能をサービスとして多く提供しているのはどのクラウドなのかということも併せて考えることが重要です。つまり、最初は一時的移行だからと「安い」とか「パフォーマンスが良い」という言葉に釣られ、そのクラウドにある VMware vSphere ベースのクラウドサービスに移行したとします。しかし、その先のモダンアプリケーションへ移行をする場合、業務システムに必要なサービスがクラウドネイティブサービスとして提供されていなかった場合、結局は VMware vSphere ベースのクラウドサービス上に仮想マシンとして存置せざるを得ない、またはクラウドサービスプロバイダー上の仮想マシン型の IaaS に同じものを作らなければならないなど、結局はリソースの無駄遣いの選択をしなければならなくなります。そうならないためにも、しっかりと業務分析をしそれに必要な機能を明確にし、そしてその機能をコストを下げられる形でクラウドネイティブなサービスで提供しているクラウドサービスプロバイダーを選択、最後にそのクラウドサービスプロバイダーが提供している  VMware vSphere ベースのクラウドサービスに一時移行するというのが適切つまりベストプラクティスになると思います。

どのクラウドサービスプロバイダーを選択する？

例えば Oracle データベースを使っているから Oracle CLoud の OCVS を使うような感じで選択するのではなく、この場合では自社のシステム全体で考えた時の Oracle データベースを使用している比率が高い、Oracle データベースのパフォーマンスやレスポンスについて厳格な要件があるなど制約がある場合は Oracle CLoud の OCVS を選択するということもありますが、そこまで要件が厳しくない場合は、先に紹介したような、AWSならOracle Database@AWSを、Google Cloud ならOracle Database@Google Cloud、AzureならOracle Database@Azureなどを使うという選択肢もあると思います。また、社内システムの分析結果 AWS の提供している多くのサービスが利用でき適していると判断できる時には Amazon EVS を選択する、社内の多くの業務が Google Workspace ベースだったり、既にビッグデータの分析などで　Google Cloud を利用しているのであれば、Google Cloud の GCVEを、Windows ベースのシステムが多く MIcrosoft 製品が多い、そしてそれらのライセンスコストをどうにかしたいというのが主であれば Microsof Azure の AVS を選ぶなど、クラウドジャーニーを考えながら移行先を選択することが重要かと思います。特にマルチクラウドを志向する場合は、相互に高速接続ができるアマゾンとグーグルの高速接続サービス利用を考え、これら2社のサービスが自社の業務システムの分析結果に合致しているかを含めて検討してみるのもよいかもしれません。

兎に角、クラウドへ移行するということは、その先そのクラウドと運命共同体になる可能性があるということなので、安易に選択するのではなく、自社の状況をしっかり考えて、可能であればクラウドサービスプロバイダー間を移っても業務システムを大きく変えることなく移行できるようなデザインに変えていくということも必要かなと思います。

今回の記事のあとがき

今回の記事は久しぶりに書いたので、だいぶ端折ったりしている部分が多いのですが、オンプレミスの VMware vSphere のクラウドへの移行は、簡単に見えても考慮して設計しなおさなければならない部分も多々あります。この記事がそれらについてすこしでも考えるきっかけになり、クラウド移行の際のに少しでも役に立てれば良いかなと思い書いています。なので、詳細は各クラウドサービスプロバイダーの提供するベストプラクティスやドキュメントを熟読し、もし SIer に依頼をしているのであれば、十分な検討とクラウド移行に際してのセキュリティに関する各種変更も行うなど指導しながら、クラウドへの移行を進めるようにしましょう。そして、Mware vSphere ベアメタル  Cloudサービスはあくまでも「一時的な環境」と割り切り、クラウドネイティブへの移行も併せて検討していくことをお勧めします。

ここからはちょっと独り言

あと、もしクラウドへの移行の検討する必要がない、またはクラウド移行したく無いならば、無理してクラウドマイグレーションしなくても良いかなとも思います。オンプレミスでVCFでずっと行くという選択肢もあるかなと。クラウドはクラウドサービスプロバイダーにインフラを抑えられるということなので、そこに支払うお金はクラウドサービスプロバイダー次第になります。なので、クラウドネイティブにして常にコストを考えながら運用をしていかなければならなくなるので、VCF & 自分達で全て管理できるのであれば、オンプレミス存置も悪く無い選択肢だとおもいます。これ、内製していたシステムを外部のSIerに依頼することで、当初はコストダウンできたけれど、ずっとそれを続けて来た結果、SIer に依存せざるを得ない状態になり、システムの進化が止まっているのにも関わらず、外注コストは実は社員採用してやるよりもどんどん増加しているということと同じ結果になるように感じます。なので、自分達で出来ることはオンプレミスで、出来ないことや特化したことはクラウドをという使い方、あると思っています。これ、なんでもSIer使うのでは無く、自分達で出来ることは自分達でやる事で、俊敏性や融通の利くシステム開発および保守・運用に、そして自分達で今は出来ない部分はその部分の「専門家」にノウハウ伝授含めて外部依頼する、またシステム開発でも本当に人手が必要なら部分だけ外注化し、設計やコントロールは自分達でやるなどしていくようにしないと、適切なにはならないかなとも思います。あくまでも独り言・・・・ですが。

ITから離れて個人的にやっていることをちょっと。今は還暦を迎えて始めた 3D CAD と 3D プリントで、ここまでのものが作れるようになりました。なんでも始めると深く探求し極めようとする自分が、ここでも発揮されているように思います。（笑）

京王帝都井の頭線 3000系たち

この展示物は全て私がデザインと出力したものを、仲間と一緒に組み立てたもので、今月号の鉄道模型趣味雑誌にも掲載されています。1999年から VMware 製品とともに歩んできて、そして日本のクラウドサービスプロバイダーや外資系のクラウドサービスプロバイダー、そして中の人になって変えていくことを考えず現状を踏襲するだけで顧客へサービスを提供する幻滅した SIer などいろいろな経験をしてきた IT から転身し、こういう方向に進んでいくのも楽しいものですね。