金融機関の基盤更改でVMware Cloudが有効なシナリオ Google Cloud VMware Engineを例に

アクセンチュア株式会社テクノロジーコンサルティング本部金融サービスグループ
アソシエイト・ディレクターの青柳雅之です。

Accenture Google Cloud Business Group (AGBG) Solution Architectを兼任しています。

こちらのブログは過去にAccenture Cloud Diariesに掲載されたものですが、公開ポリシーの変更に従い、個人ブログに転載をしています。

オンプレミスからパブリッククラウドに基盤を移行するにあたっては、いくつかの難易度の高いシナリオがあります。さらに、金融機関の基幹システムの場合は、その持つ特性上、パブリッククラウドへの移行後も高可用性と高耐久性が求められます。オンプレミスの仮想化環境がVMware vSphereの場合、これらに対するソリューションとして、VMware Cloudが検討できます。ハイブリッドクラウド、マルチクラウド環境であっても、VMware Cloudによって同一のVMwareのインフラストラクチャが提供され、基盤の移行制約の多くは緩和されます。

今回のブログでは機関の基盤更改でVMware Cloudが有効なシナリオを解説します。なお、このブログを書くにあたり、VMware様とディスカッションを重ねました。この場を借りてお礼を申し上げます。技術的な解説全般は、「参照情報」にある資料を参照してください。

VMware Cloudとは
VMware Cloudとは、パブリッククラウドのデータセンター内のクラスタ上に VMware vSphere をベースとしたソフトウエア定義データセンター、Software-Defined Data Center (SDDC)を展開して提供するサービスです。このブログでは、Google Cloud VMware Engine(GCVE)を例にとりますが、AWSやAzureも同様のアーキテクチャを取ります。GCVEのアーキテクチャは、Google Cloud VMware Engine 徹底解説に詳しい解説があります。こちらを抜粋、および筆者にて加筆して解説します。
※vSphereは、ESXiやvCenterを主要コンポーネントとして含む仮想化ソリューションのソフトウエア群です。

図：オンプレミス環境のVMware vSphere仮想化環境をGoogle Cloudへ拡張
出典：Google Cloud VMware Engine のプライベート クラウド ネットワーキング

まずは全体像を見ていきます。GCVE展開時に、GCVE専用の仮想ネットワーク(3rd party VPCネットワークであるGCVEとその中にあるGCVEプライベートクラウド)が構築され、そこにSDDCが展開されます。GCVEプライベートクラウドはNSXで定義されるネットワークセグメントであり、その上にアプリケーションを稼働させる仮想マシン(Compute Engine)を展開します。ユーザーが所有するCustomer VPCとGCVEプライベートクラウドは、プライベートサービスアクセスという仕組みにより、内部IPアドレスでプライベート接続が可能です。プライベート サービス アクセス接続を作成するときにVMware Engine に接続されている各 VPC ネットワーク毎（図の例ではCustomer VPC）に、サービスプロデューサー VPC ネットワークが作成されます。Customer VPCがCloud IntercconectもしくはCloud VPNによりオンプレミスと接続されていれば、オンプレミスののユーザーは、プライベート サービス アクセス接続によってCustomer VPCからサービス プロデューサー VPC ネットワークを経由して、 VMware Engine プライベート クラウドに非公開でアクセスできます。

図：オンプレミスからGCVEプライベートクラウドへの接続

次に、GCVE展開時に展開されるコンポーネントを解説します。GCVEでは、ユーザーが占有するハードウエア(物理サーバのクラスタ)上にvSphere仮想化環境であるGCVEプライベートクラウドが構築され、その上にSDDCが展開されます。SDDC環境には次のGCVEコンポーネントが展開されます。これらも上図に記載しています。

表：GCVEで展開されるコンポーネントの説明

最後に、GCVEプライベートクラウド上のSDDCで展開されるコンポーネントを解説します。

図：GCVEプライベートクラウド上のSDDCで展開されるコンポーネント
出典：Google Cloud VMware Engine 徹底解説

表：GCVEプライベートクラウド上のSDDCで展開されるコンポーネントの説明

また、すでにオンプレミス環境で VMware Aria Operations Manager (マルチクラウド、ハイブリッドクラウドで仮想基盤全体を俯瞰的に監視するサービス)をすでに活用されている場合は、GCVE環境にも同様に連携、活用できますが、同様に、GoogleCloudで提供されているCloud Monitoring(監視)やCloud Logging(ログ取得)を含むオペレーション スイートも活用できます。

金融機関の基盤更改でVMware Cloudの導入が有効なシナリオ
VMware Cloudの導入が有効なシナリオを解説します。クラウド移行の難易度が高いシナリオであっても、オンプレミス環境の vSphereに移行対象のシステムが存在している場合は、このVMware Cloudを活用することで、移行のハードルを下げることが可能です。ただし、いずれのシナリオでも、ビジネスケース（費用対効果）が成り立つことが必須となります。

1)現行のデータセンターの廃止までに時間がない
オンプレミスに存在するシステムの中には、例えば接続先のシステムを意味するIPアドレスが多くのコードの中に書かれているケースがあります。オンプレミスと、それに接続するパブリッククラウドでは、拠点が異なりネットワークセグメントは異なります。つまり、IPアドレス範囲が変わります。これらのシステムがクラウドに移行する場合、コードの中のIPアドレスを書き換える工数が発生します。パブリッククラウドへの移行では、名前解決で相手のシステムにアクセスする仕組みに変えることが一般的なベストプラクティスではありますが、その対応にはソースコードの修正(リファクタリング)が必要になり、時間がかかる可能性があります。現行のデータセンターの廃止までに時間がない場合は課題になります。

コードの中のIPアドレスを変更せずにシステムをパブリッククラウドに移行し、問題なく相手先システム（こちらも同じクラウドにあるとしましょう）にアクセスできるようにする方法としては、L2延伸による拠点間（オンプレミス=パブリッククラウド間）接続が考えられます。

L2ネットワークによる通信（建物内のLANに該当）では、ネットワークセグメントを超える通信は出来ません。オンプレミスとパブリッククラウドは拠点が異なりますので、それぞれに異なるネットワークセグメントを持ちます。そのため、通常はネットワークセグメントを超えて通信ができるL3ネットワーク（ネットワーク層）を利用します。一方で、L2延伸では、オンプレミスとクラウド間で同一のセグメントを利用できるため、移行の前後で仮想マシンのIPアドレスを変更する必要がありません。このように、L2延伸では離れた拠点間をL2レベルで通信できるようにする仕組みとなります。VMware Cloudでは、L2延伸が可能であり、現行のシステムで利用されているIPアドレスをクラウド上でもそのまま利用可能です。

なお、データセンター廃止といったデッドラインがなくとも、リファクタリングのための要員を確保する必要はなくなり、移行期間も短くなるため、VMwareのL2延伸には大きなメリットがあります。

2)高可用性が要求される
• システム全体として高いSLAを要求される
通常、AWS/Azure/Google Cloudといったパブリッククラウドでは、仮想マシンやDNSといったサービス単位でSLA(Service Level Agreement)が定義されています。一方で、VMwareのSLAはサービス単位ではなく、システム単位で定義をすることができます。VMware上で稼働するシステムのサービスレベルが非常に高く、パブリッククラウドへの移行後にも同等のサービスレベルが要求される場合、VMware Cloudの導入が有効です。VMware Cloudでは、オンプレミスと同様に、SLAをシステム単位で定義することが可能です。なお、本当にそのレベルのサービスレベルが必要か否かは移行計画時に検討すべきです。

• ハードウエアの入れ替え、仮想マシンの再起動にかかる時間（ダウンタイム)を許容できない
オンプレミス環境ではハードウエア故障やEOLに従うハードウエアの入れ替えが発生します。パブリッククラウドではその問題は解決しますが、パブリッククラウドのハードウエア故障時や、ハードウエアへのパッチの適用が必要となる際に、クラウドベンダーより指定された期間の中でユーザー側の運用担当者が再起動を行う時間帯を指定しなければなりません。再起動によって、仮想マシンは故障したハードウエアから正常なものに移り稼働します。システムによっては仮想マシンの再起動にかかる時間を許容できない場合があります。VMware Cloudを利用する場合、vMotionの仕組みにより、再起動にかかる時間を回避することが可能です。

3)高耐障害性が求められる
• パブリッククラウドのリージョン障害
オンプレミスのvSphereで稼働するシステムの仮想マシンを、パブリッククラウドの仮想マシンに変換して移行するケースも多いです。VMwareは、耐障害性要求の厳しい金融機関の要望を受けて、双方向クロスクラウドDRという機能を開発しました。複数のパブリッククラウドをまたがるDRソリューションとなります。あらかじめオンプレミス及び GCVE それぞれの VMware vCenter など各コンポーネントのバージョン互換性を留意します。

• 可用性ゾーン(AZ)障害
○ vSphere Replicationでバックアップ、Site Replication Managerで復旧自動化をシンプルに実現
○ クラウド間ーオンプレ間でVMをvMotionでLive Migration可能

まとめ
VMware Cloudの導入に際しては、そのビジネスケース（費用対効果）を求める必要があります。一般的には、仮想マシンの数が少なすぎる場合、初期費用や運用コストの方が高く、よいビジネスケースは得られません。別のブログで、VMware Cloudのビジネスケースについて解説します。

参照情報
Google Cloud VMware Engine 徹底解説
【実演】Google Cloud VMware Engine と VMware ソリューションを組み合わせたハイブリッド環境の実現・運用管理方法」
Google Cloud VMware Engine のプライベート クラウド ネットワーキング