プライベートクラウドのジェネレーション(世代)について

Top / サービス一覧 / プライベートクラウドのジェネレーション(世代)について

Private Cloud Generation(世代)について

InfiniCloudの提供するプライベートクラウドサービスは、2002年にレンタルサーバ、2007年にSolarisベースのクラウドサービスを開始して以来、進化を続けています。下記は、その技術背景資料です。

プライベートクラウドより前の世代について(2002年〜)

レンタルサーバ(Webホスティング)時代〜プライベートクラウド開始まで

2002年にリリースされたPhase1Plus(フェイズワンプラス)は、ApacheベースのVirtualHostでテナントを分離し、FTPによりコンテンツデータをアップロードする、「いわゆる通常のレンタルサーバ」だった。現在もWebホスティングは小規模層に人気であり、十分コモディティ化されている。ただしマルチテナント環境としての隔離性は、UNIX/Linuxのユーザグループとしての隔離に過ぎず、リソース制限もulimit程度でしかない。当時のPhase1Plusの基本構造は、ほぼそれと同じものだった。

まず、データベースはMySQLかPostgreSQLの共有であり、やはりUNIXユーザによる隔離で、リソース制限はつけられない。コンテンツやプログラムはFTPという暗号化されない方法でアップロード。当時からFTPをすて、SFTPなどの必需性は叫ばれていたが、当時は使いやすいWindowsクライアントがなかったり、SFTP自体がOS設定にshellアクセス権を要求することもあったなど、苦渋の選択でFTPを採用する必要があったのだ。

アップロードされたプログラムは、「SuExec」というユーザ毎(この場合テナント毎)に異なるユーザ権限で実行する。これである程度の権限分離はできるものの、同サーバ上に設置したプログラムが書き込んだファイルは、ブラウザ経由では見えなくしたとしても、ファイルやディレクトリのパーミッションの設定をミスすると、プログラム同士で互いに閲覧可能になってしまう。つまりセキュリティ・マンションのようなもので「裏口の鍵を持つ人(FTPでアクセス出来るホストに収容された人達) は悪い人ではないに違いない」という性善説に基づいて作られているのだ。このレベルのセキュリティ、サービス的な脆さでは問題があるのなら、なるべく高効率にテナント毎の隔離を行う必要がある。

仮想化の出番だ。

仮想化といっても一般的にはハイパバイザを用いたものが多いが、当時のコンピュータでその技術を用い、サービスレベルまで漕ぎ着けるのは、様々な面で困難が伴う。そこで、様々な試験的サービスを作ることなり、これがプライベートクラウドの技術的な礎になっていく。

まず評価を行なったのが当時のVMware Workstationだ。起動時にVNC Desktopを起動し、仮想デスクトップ上にVMware Workstationだけを起動するという変則的な実装だ。ここでゲストOSを稼働させ、サーバとする。隔離性はあるものの、当時のマシンのスペックからすると1台に乗せられる仮想OSが少ないし、ライセンス的な問題もあるだろうということで、自社内の試験環境の利用に留まった。

2つめにUML(UserMode Linux)。技術としては非常に面白いもので、テナント単位のカーネルが個別のユーザランドプロセスになる一方で、ゲストOSのプログラムが親OSからみるとカーネルスレッドに見えるというもの。当時人気を集めていたLinuxで隔離実行ができることも面白い部分だったが、リソース隔離性は低く、当時はデプロイが難しいところがあったり、多数のゲストOSの動作には一工夫が必要なこともあり、当社内では試験で終わった。

3つめに、FreeBSDのjail。プロセスパーティション、いわゆるコンテナ型技術で、プロセスレベルで隔離してカーネル層を共有するため、リソース利用率という意味で着目した。すでにjail break技術はちらほらとは存在したものの、プロセスレベルの隔離よりはよほど隔離性が高い。FreeBSD(※)であると言うことを除き、当時としては良いソリューションだと考えられた。(※当時の当社の顧客はLinuxを好んでいたため)

Linuxへのコンテナ実装は、現在はLXCが標準実装であるものの当時は存在していない。また、OpenVZという技術評価も行われたが、残念ながらOSのディストリビューションにメインストリームとして入る技術ではなかったため、様々な状況で試験利用に留まった。

当時のCPUは命令セット、アーキテクチャの面の双方で仮想化に対してはまだ貧弱であった。

メインストリームは、Pentium 4 NetBurstアーキテクチャベースのXeon(Prestonia/Nocona)。このCPUは消費電力が大きく、また、当時のデータセンターは電力に余裕があまりないこともあって、1ラックあたりの集積度問題を抱えていた。このCPUはHyper-Threadingによって1CPUで2並列の動作が可能であったが、むしろ有効にすることによって、ほとんどの実アプリのベンチマークが悪化するため、無効にすることもあった。結果として、消費電力が少ないPentiumM(PentiumⅢベースのモバイル用CPU)系のCPUを搭載した小型サーバを並べた方がラック効率が高いため、その導入は何度も検討されていた。

こうした流れの中、InfiniCloudの最初のプライベートクラウドである「Phase2Server Lite」「Solaris x86 VPS」というプロジェクトへ繋がっていく。

1G(第1世代、2007年〜)

利用されたCPUモデル

下記は当時のサービスで利用されていたCPUの一覧。CPU数は1、ないしは2系統搭載されていた。

x64アーキテクチャ周波数(GHz)2ndCache(MB)HyperTransportCoreTDP
Opteron 260HE1.61 x21GHz255
Opteron 2802.41 x21GHz285

概要

InfiniCloudの記念すべきプライベートクラウドの第1弾は、「クラウド」や「VPS」という名前がまだ存在する前のサービスであったことから、専用サーバサービス延長上の「Phase2Server Lite」(フェイズツーサーバーライト)シリーズとしてサービスされていた。

CPUにAMD Opteron K8 revE(Italy)を搭載。まず64ビットCPUであること。そして同時期のIntel CPUよりも消費電力が少なく、かつDual Coreプロセッサをいち早く搭載したことが大きい。Dual Socketマシンなら合計4コアを実現することも採用のポイントだった。マルチプロセッサアーキテクチャも、SMPではなくccNUMAを採用することで、1物理CPUあたりのメモリバンドが6.4GBytes/sec、1コンピューティングノードあたり12.8GBytes/secと高性能であった。

しかしながら、CPUの仮想化支援機能やメモリバンド幅はまだ十分なものとは言えず、ハイパバイザ方式では性能劣化が無視できない。また、カーネルを全ての仮想マシンで確保するためには、メモリも不足しがちとなる。そこで、カーネルを単一にするプロセスパーティショニングの一種である、コンテナ型技術を採用することに決定。

コンテナ型技術は、現在はDockerなどで数多く使われるメジャーな機能だが、当時はFreeBSDのjail、Linuxでは実装の一部としてOpenVZなどがあるだけで、リソースの制限機能が少なかった。そこで、コンテナ型ながらリソースの制限機能の実装や高い隔離性を実現した、Sun Solaris 10のSolaris Container(zone)を採用。

Sun Solarisには、いち早くコンテナ機能が採用されており、実績も伴っていた。

また、このジェネレーションで導入された技術は、共有ストレージだ。

Solaris ZFSとNFSv3を利用し、仮想サーバのイメージをNFS上に格納した。コンテナの技術特質上、ライブマイグレーションはできないが、様々な工夫をするとオフラインマイグレーションができる。当社独自で作られたそれらのソフトウェアスタックを、「DimentionPlus」という仮想化支援ミドルウェアとして構築。コンテナはconductorと言われる管理システムにより、管理されていた。

2G(第2世代、2009年〜)

利用されたCPUモデル

下記は当時のサービスで利用されていたCPUの一覧。CPU数は1または2系統搭載された。

x64アーキテクチャ周波数(GHz)2nd Cache(MB)HyperTransportCoreTDP
Opteron 2344 HE1.721GHz468
Opteron 2350221GHz495

概要

プライベートクラウドの第2世代では、まずは従来のSolaris Zone(コンテナ)を用いたDimensionPlusを線形進化。

これがPhase2Server「Solaris x64VPS」という名前でサービスインすることとなる。

OSはオープンソースである、Solaris系OSであるOpenSolarisに変更。さらに自社で特殊なOpenSolarisベースのディストリビューションを作成。これはコンテナ稼働のためだけに必要なOpenSolarisのリソースセットを持ち、USBメモリで起動してオンメモリのRAMDISKだけで稼働。ブート用のストレージも不要となり、コンピュートノードのコストダウンにも寄与する。

一方、このジェネレーションで導入されたハイパバイザとして、VMware vSphere ESXiが採用された。コンテナのリソース効率が良いとしても、Solarisだけでシステム全てを構築するには無理もあり、他OSが必要となる。LinuxもWindowsもシステム構築には必要となるためだ。

ESXiのようなType-I ハイパバイザを使う場合、ゲストOS用に異なるOS、カーネルを利用できるため、高度なIO管理やメモリ管理が必要になっていく。IO関連の仮想化はいち早くCPUに支援機能が実装され、またハイパバイザ自体にもパラバーチャリゼーションドライバが実装されたりしたことで、ベアメタルに比べてボトルネックは減ってきたが、メモリ確保にはロスが起きていた。これを解決するには、CPUに仮想化支援機能、特にNPTが重要だと判断していた。NPTはNested Page Tablesのことで、AMDではAMD-V RVI、IntelではIntel-VT EPTのことだ。

昨今のOSでは、アプリケーションはそれぞれ個別のメモリ空間を持つが、実際の物理メモリ空間は通常のコンピュータでは1つなので、CPUに内蔵するMMUがTLB(Translation Lookaside Buffer )を用いてハードウェアで変換している。しかし、ハイパバイザを用いる場合、ゲストOS毎に個別のメモリ空間を用いる必要があるため、このメモリアクセスは、アプリケーションの論理メモリ空間、ゲストOSが持つ(一見物理に見える)メモリ空間、ハイパバイザが扱う絶対的な物理空間と、ネストするメモリ空間マッピングが必要になるためだ。NPTが無い場合、これらはハイパバイザがTLBの入れ替えをしないとならないため、メモリアクセスの度にボトルネックが発生してしまい性能劣化が著しくなる。CPUにNPTがあればハードウェア処理で緩和できる。

AMD Opteron K10アーキテクチャ(Barcelona) には、4コア以上のモデルで、いち早くNPT(AMD-RVI)を搭載していた。そこで第二世代のクラウドシステムでは、これを採用することとなる。メモリバスが1CPUあたり10GBytes/sec、1コンピューティングノードあたり20GBytes/secと増強されたことも大きい。

搭載メモリ数は8Gと16GBモデルが採用。ストレージは、2.5inchのSAS HDDを用いたRAIDのみだった。

3G(第3世代、2012年〜)

特徴

  • Intel Xeon Nehalem世代を採用。
    • CPU世代をコアアーキテクチャプロセサに一新
    • 64ビットに最適化し、よりハイパバイザに向いたCPUラインナップに変更された
    • CPUスレッド数(論理コア)は16
    • 搭載メモリは24GB/48GB/96GBをラインナップ。メモリバンドは51GBytes/sec
  • Oracle SPARCを用いたSolaris SPARC クラウドをサービス開始
    • CPU世代はSPARC T4。CPUスレッド数(論理コア)は64、あるいは128
    • 搭載メモリは128GB。メモリバンドは34〜68GBytes/sec
  • ストレージファブリックの強化
    • HDD+SSDのハイブリッドストレージ化
  • ネットワークファブリックの強化
    • インターコネクトを20G。サービス用に1Gx2
    • 広域でのL2レベルのリージョン間接続(関東・中部・関西)サービスに対応
    • ユーザ拠点との間にフレッツ網を用いたL2接続線の用意

利用されたCPUモデル

下記は当時のサービスで利用されていたCPUの一覧。CPU数は1または2系統搭載されていた。

x64アーキテクチャ周波数(GHz)2nd Cache(KB)3rd Cache(MB)Core(Threads)メモリTDP
L55202.26256 x484(8)DDR3-1066 x360
SPARCアーキテクチャ周波数(GHz)2nd Cache(KB)3rd Cache(MB)Core(Threads)メモリTDP
SPARC T42.85128 x1248(64)DDR3-1066 x460

概要

第3世代のプライベートクラウドファブリックのコンセプトは、「ディザスタリカバリ」を命題としている。3-11の東日本大震災以後、ディザスタリカバリが企業の中で本格的に考えらるようになった。それ以前は、「このデータセンターが破壊される程の天災があるなら仕方が無い」と言うような見方も多かったが、3-11以降、たとえ大きな天災が起きたとしても、企業は、元の仕事に復帰する社会的責任を感じるようになっていった。そこで、地理的に離れた2つの拠点をどうにかして共同して動作させるインフラストラクチャの構築が課題となっていた。

そのため、第3世代よりコンピューティングやストレージだけでなく、ネットワークに関する投資を大きくすることとなる。当社の技術の主力である「コンピューティング」「ストレージ」「ネットワーク」。この3つのパーツが揃うきっかけは、東日本大震災が契機なのだ。

コンピューティングノードではx64プロセサだけでなく、SPARCプロセサもサポートする。

x64アーキテクチャのプライベートクラウドの第3世代は、Intel Xeon Nehalem世代を搭載したモデルを採用。Intel Xeonを再び採用し、CPU世代がインテルコアアーキテクチャプロセサに一新。インテルXeonシリーズでは初めてメモリコントローラを内蔵し、マルチプロセサがSMP型からccNUMA型に変更、命令セットにもNPT(intel EPT)の実装も行われた。いくつかのフィーチャーでAMDに比べ採用が遅れたものの、消費電力単位のCPU性能の大幅な向上、x64命令セット(64bit)の本格的サポート、Hyper-Threadingの強化、メモリバス幅の強化(25GBytes/s)など、あらゆる意味で進化された本命のCPUであると言えた。

CPUスレッド数は16論理コア。搭載メモリを24GB/48GB、最終的には96GBまでをラインナップした。

仮想化技術は第2世代から継承しながら、VMware vSphereによるLinuxやWindowsマシンの提供。ディザスタリカバリを考え、VMwareではVMware層でのReplicationをしVMware Site Recovery Managerで管理。Solarisでは、ストレージ層でのレプリケーション機能(当社DimensionPlusプロジェクトで開発されたもの)を利用し、異拠点にデータを転送するメカニズムを持った。

また、Solaris 11のリリースと共にSolaris Zonesを採用。これは当社が、OpenSolarisの独自のディストリビューションを作る際に様々なRFE(Request for Enchantment)やバグ報告を行ったことから、米Oracle社とSolaris SPARC等のプラチナカスタマープログラム(後に、カスタマーアドバイザリボード)の契約締結を行ったこともある。その後も継続的に技術的なフィードバックが行われ、また当社からのRFEの大半は受け入れられたこともあって、当社の独自のディストリビューションを作る事は終了しSolaris11を利用する事となった。

一方、ユーザからの問い合わせの多かったSPARCアーキテクチャのSolarisクラウドサービスもスタート。

CPUには、Oracle SPARC T4を採用。SPARCはSun時代より、T1プロセサ、T2プロセサと進化を遂げていたが、その設計思想はマルチコア×CMT(Chipped Multi Threading)で論理コア数を64と増やし、当時のx64アーキテクチャCPUよりもかなりの並列性能を高めていた。しかし並列度は増すものの、SPARC T1/T2プロセサは単一スレッドの動作速度は奮わなかったため、アプリケーションのチューニングが難しいCPUとなってしまう。そこでT4ではシングルスレッド性能の性能向上にも力を注がれ、キャッシュの最適化をはじめ、Oracle/Sun SPARCシリーズで初めてアウトオブオーダー実行などを採用する。さらに、クリティカルスレッドオプティマイゼーションという機能を持ち、特定のスレッドがCPUコアのフル性能が必要になる場合は、自動的に1コアに与える機能などが実装された。(※一般に、CMTのような論理コアは、演算器などがコア毎に実装されている為、それらが空いているときでないと並列度があがらない) また、暗号化支援機能もCPUに搭載されている。

SPARC Solarisの仮想化機能では、Intel版のSolaris VPSと同じく当社製のDimensionPlusによるZoneの提供に加え、SPARCならではのロジカルドメイン機能、LDOM(後のOracle VM Server for SPARC)を採用。LDOMは厳密には仮想化ではなく、(ロジカル)パーティショニングだ。そのためCPUのオーバーコミットもなく、あくまで論理コアやメモリを固定的に割り振るため、リソースの配分に厳格となり、常に一定の性能をコミットしやすい。

データセンターネットワークはスタッキングされた1GのNetwork Switchが用いられ、2x1GbpsのLAG(リンクアグリゲーション)を用いシャシーを冗長化。

ディザスタリカバリの為に必須となる広域のネットワークファブリックでは、L2レベルのリージョン間通信に対応。リージョンも関東、中部、関西リージョンに増設。それぞれの間でL2での接続ができるため、特定リージョンのゲストOSを別のリージョンに持って行き、動作させることも可能としたため、ディザスタリカバリ基板の大きな礎となった。

ユーザとのアクセス線も、NTTフレッツ網内のIPv6 L2 VPNを用いたサービスをスタート。これは現在のクラウドコネクトに繋がる。事実上オフィスのLANをそのままのIP空間で延伸できるため、オンプレ機器とプライベートクラウドとの通信をシームレスに行う事ができ、オフィス内サーバのP2V(物理から仮想サーバに移設すること)にも役立つこととなった。

ストレージエリアネットワークは、2x1GbpsのLAGを採用し、IP-SANとしてiSCSIが選択された。ストレージサーバはSolaris ZFSを用い、当社製のDimensionPlus独自のレプリケーション機能や、異拠点転送のための枠組みなどを初めて用意した。初期はHDDをメインとしながらも、第3世代後半では、Solaris ZFSの機能を用いたキャッシュ(L2ARC、SLOG)にSSDを用い、ハイブリッドストレージとなっていた。

4G(第4世代、2015年〜)

特徴

4G
  • Intel Xeon SandyBridge/IvyBridge世代を搭載。
    • Intel XeonのCPU世代が一新。第2世代コアアーキテクチャプロセサへ。
    • AVX命令を装備し、より効率良く並列ベクタ演算が可能になった。
    • メモリがDDR3になり、メモリバンドは、42GBytes/sec(1CPU) 〜 120GBytes/sec(2CPU)強化。スレッド数のラインナップは4/24/40/48論理コアまでラインナップ。
    • 搭載メモリは、8GB/32GB/64GB/128GB/256GB。
  • SPARC S7 世代を搭載。
    • Oracle SPARCのCPU世代が一新。
    • メモリコントローラをプロセサに内蔵。DDR4-2400メモリを利用し、メモリバンドは153.6Gbytes/sec。
    • Software in Silicon機能として、シリコンセキュアドメモリ、暗号化アクセラレーション、インメモリDB用にDAX機能を持つ。
  • ストレージファブリックを強化
    • フルSSD化によるIO高速化
    • SANにMPxIOを用い20Gネットワーク化
  • ネットワークファブリックを強化
    • ハードウェアアクセラレーション付きのUTMサービスの開始。
 

利用されたCPUモデル

下記は当時のサービスで利用されていたCPUの一覧。CPUは1または2系統搭載された。

x64アーキテクチャ周波数(GHz)ターボブースト(GHz)3rd Cache(MB)Core(Threads)メモリTDP
E5-26302.32.8156(12)DDR3-1333 x495
E5-2620 v22.12.6156(12)
DDR3-1866 x480
E5-2670 v22.53.32510(20)DDR3-1866 x4115
E5-2690 v233.62510(20)DDR3-1866 x4130
E5-2695 v22.43.23012(24)DDR3-1866 x4115
SPARCアーキテクチャ周波数(GHz)L2 Cache3rd Cache(MB)Core(Threads)メモリTDP
SPARC S74.27I: 512KB+D:1MB168(64)DDR4-2400 x4115

概要

第4世代プライベートクラウドファブリックのコンセプトは、「マルチアーキテクチャ、マルチハイパバイザと、IO高速化」を命題にしている。

最も現役時代が長かったx64アーキテクチャのプライベートクラウドである第4世代は、前期・中期・後期と、細かなアーキテクチャの変化が多い。CPUには、第2世代コアアーキテクチャプロセサのIntel Xeon SandyBridge 〜 IvyBridgeを搭載。AVX命令を装備し、より効率良く並列ベクタ演算が可能になるなど、きめ細かいCPUの強化が行われたが、なによりメモリバンド(リリース当初、コンピュートノード辺り42GBytes/sから最終的には120GBytes/s)の向上による性能向上がプライベートクラウド用の仮想環境としては大きい。

商品ラインナップは後半につれて徐々に追加され、8/24/40/48論理コアと増加。メモリも8G/32GB/64GB/128GB/256GBと初期ラインナップに比べて後半では大幅な拡張が行われた。

ハイパバイザ技術としてこの世代から導入された技術は、XenServer。XenPrivate Cloud(後のHigh Response Private Cloud)をラインナップし、ユーザはSolaris、VMware、Xenと、性格の異なる複数のアーキテクチャのプライベートクラウドを選ぶことができるようになる。

SPARC アーキテクチャのプライベートクラウドも一新。SPARC S7プロセサを採用。このCPUはSunがOracleに買収された以後に設計され、そしてOracleが満を持してリリースされたCPUであり、コストパフォーマンスが高いながら高い性能を持つ。クロックは4.27GHzと、最早、単一スレッドが遅かった時代は完全に過去のものとなっていた。コアは1CPUごとに8コア、64スレッド。Dual CPUなので論理コアでは128スレッドの同時実行を誇る。SPARCは元々ccNUMA型でありメモリコントローラも内蔵。メモリバンドが1CPUあたり76.8GBytes/sec、1コンピュートノード当たり153.6GBytes/secとなっている。このCPUには暗号化支援機能や、DAXというデータベース専用命令群があるため、Oracle Databaseを動かすとより高速に動作させることができるが、そうでない一般的なワークロードであったとしても、同世代のx64アーキテクチャのCPUに比べ、概ね動作が速いCPUとなる。

Solarisの仮想化機能は、x64アーキテクチャ、SPARCアーキテクチャ共々、Solaris Zoneのうち、Native Zoneという従来型のコンテナ型のものをやめ、Kernel ZoneというType II型ハイパバイザを採用。SPARCでは引き続きLDOMも利用可能。メモリやCPUパワーの増加でハイパバイザ型が中心となった。

リソース効率の良いコンテナ型だが、運用過程では2つの大きな問題が起きていた。

1つはアップデート問題。Solaris コンテナはカーネルとユーザランドを合わせてアップデートをする必要があり、各ゲストOSの管理者との都合を合わせるのが困難となる。回避策としてアップデートが必要な度に、オフラインマイグレーションをして新しいカーネルのホストに移設しながらアップデートしていたが、これではリソース利用率の高さがスポイルされてしまう。

2つめにカーネルリソース問題。カーネルにはプロセスIDやら、メモリ空間、ファイルディスクリプタなど、全体で共通に使うリソースがあり、これらは隔離されているものの、全コンテナで共有している。これらのカーネルリソースの確保渋滞がパフォーマンスのボトルネックにつながってしまう。特にメモリ問題が顕著だ。コンテナ型のシステムでは親OSからみて多量のプロセスが実行されるが、ゲストコンテナが増えるとこの量が甚大になり、常にメモリのマイナーフォールト+レクレイム(MMUのTLBが溢れメインメモリと入れ替える処理)が発生する。大きなメモリ空間で、大量のプロセスを動かすことになると、大量のメモリ空間を頻繁にスキャンすることに繋がってしまう。ハイパバイザでメモリ空間を区分けをして、それぞれのゲストOSに割り振る方がむしろ可動性が高くなってしまう。

Solaris Zoneでは、Kernel Zoneの上で、コンテナ型のNative Zoneを立ち上げることができる。顧客毎の利用はKernel Zone単位で貸出を行い、コンテナであるNative Zoneは自由にユーザが立てられるようにした。

プライベートクラウド用ストレージファブリックでは、フルSSD化を行った。ハイブリッド型もふくめたHDDストレージの廃止となる。IOを高速化する理由はプライベートクラウドがIOを集めてしまうためだ。海外勢のパブリッククラウドでは、IOを集めることによる問題に既に取り組んでおり、IOを「集めない」設計思想のクラウドシステムが作られていた。そのためにアプリケーション開発エンジニアは、特別なミドルウェアを使ったり、データストアへのアクセスをRDBから分散KVSに変えたり、様々なソフトウェアロジックの変更を余儀なくされた。この多くはIOの集約をさせない設計思想に起因するものが多い。一方、日本のクラウドサービスでは、インフラの都合で新たにソフトウェアを作り直させること難しい事から、今まで通りのOSイメージで動かすことができる仮想環境が多い。結果、IOを集約するものも多く、様々なベンダでストレージIO不足に起因する障害を発生させていた。

当社においても、当社独自のルールで利用者にミドルウェアを強要し設計をして貰う事は難しい。そこで、IO集中問題に関しては2つの回答を用意した。

1つめは、IOを集めてしまうことにはなるが、代わりにIOをEnterprise SATA/SAS SSDを用いて可能な限り高速化したもの。エンタープライズニーズでは、P2Vニーズも多く、いわゆる従来からの業務アプリの実行が多いため、特別なミドルウェアを用いてIOバランシングすることは難しい。要求されたIOとニーズによって、SSDはSATAモデルとSASモデルを用意し、大幅な高速化を行った。サービス提供初期では、SSDファームウェアによる問題や、寿命管理の難しさや応答劣化の管理の難しさを伴った。

フルSSD化に伴い、ストレージエリアネットワークは高速化が余儀なくされる。Solaris Private Cloudでは、第三世代で開発されたストレージファブリックをベースに2x10Gbpsの20Gbps MPxIO(マルチパスIO)を用いて高速化。VMware Private CloudではNFSv3をやめ、冗長パスに対応するためにiSCSIを用いてMPIO(マルチパスIO)化し、クラスタリングファイルシステムであるvmfsを採用。新しくVAAI(vStorage API for Array Integration)に対応したVMware専用ストレージ製品が使われた。VMwareでiSCSIストレージを利用する場合、ゲストOSの数や全体容量の多いストレージ環境では、VAAIに対応することが事実上の必須条件となる。クラスタリングファイルシステムでは複数ホストから書き込みが発生するとき、要所、要所でストレージのロックが必要となるのだが、通常のiSCSIのストレージではLUNボリューム全体のSCSI2 LUN LOCKしかファンクションが存在しない。つまり広域ロックが生まれてしまうのだ。この広域ロックが行われるとき、LUNボリュームに格納されるゲストOSの全てのIOがミリセカンド単位で停止する。格納ゲストOSの数が増えるとロック頻度も上がり、一定のゲストOSの数で最早無視できない性能劣化が発生していく。そのため、VAAIがないストレージでは、概ね1LUNあたり20ゲストOS程度という不文律が生まれる。VAAIはロックを狭域ロックにすることで、これを緩和することができるわけだ。これがVAAI対応ストレージを使うことになった最大の理由である。(※なお、その後、単一ソフトウェアスタックによる不具合時の連鎖化などがあり、後の第6世代ではバージョンではNFS v4.1にリプレースされることになった。詳しくは第6世代を参照のこと)

IO集中に関する2つ目の回答は、Xen Private Cloudだ。第4世代初期のXenサービスではVMware Private Cloudと同じようにストレージファブリックを用いた実装であったものの、Xen内部のiSCSIに関連するInitiatorの処理の遅延や、Xen HAの構造上の問題が散見され、ストレージに対する要求はVMware以上にシビアなものになっていた。そこでいっそのことストレージファブリックを利用することをやめ、かつ、IO集中問題を回避するため、コンピュートノード内に専有バスで接続される形に進化。コンピュートノードが個別のSSDをもつことで、ストレージIO集中時の安定性とレスポンス速度が担保されたが、もしもコンピュートノードが破損したときは、内蔵SSDの中のゲストOSがアクセス不能になってしまう。そこで稼働中の仮想OSイメージを1時間に1度程度という短いスパンでバックアップ専用HDDストレージ(このストレージは速度が必要としないためHDD)にリアルタイムバックアップすることで、コンピュートノードの障害時にはバックアップから少し前の状態にリカバリーできるように設計した。IOは集中していないので基本的にハイレスポンスであり、一貫性はゲストOS内部でデータベースクラスタなどを用いて解決できる。(※これはその後、第6世代でHigh Response Private Cloudと目的特化型へとさらに進化する)

ネットワークファブリック面では、セキュリティに関する関心も高まり、ハードウェアアクセラレーション機能付きのFirewall UTMサービスを開始。

なお、第4世代で導入されたサービスは、今現在も稼働台数が最も多く、当社では2018年まで販売されていた。

これはx64アーキテクチャでは拡張性が高くアップグレードでCPUのコア数を上げることができ、同時にメモリバンドも変えることができたため。一方、第5世代と第4世代のx64アーキテクチャのCPUの同一クロックでのCPU性能差はほぼわずか。第4世代と第5世代ではメモリの規格が異なり、第4世代はDDR3で1コンピュートノード当たり最大120GBytes/s、第5世代はDDR4で1コンピュートノード当たり120GBytes/secからスタートとメモリバンド幅は肉薄。その結果、大容量メモリの積載でDDR4を用いた第5世代が割高になってしまい、ほとんどのユーザがほぼ同じ性能で、メモリ容量を2倍近く利用できる第4世代を利用する結果となり、この世代のプライベートクラウドがユーザーに支持される結果となった。

※当社Private Cloudの場合、たとえ利用開始が第4世代のころであったとしても、ネットワークファブリック、ストレージファブリックなど、アップデート時にリプレース可能なものはメンテナンスを経て、第5世代、第6世代のものとより高性能な環境へと入れ替わることが多い。これも第4世代が支持され続けた原因の1つとなっている。

5G(第5世代、2019年〜)

特徴

  • Intel Xeon Haswell Refresh/Broadwell世代を搭載。
    • メモリがDDR4となり、メモリバンドが120〜137GBytes/sまで強化。
    • スレッド数ラインナップは、24/32/40論理コア。
    • 搭載メモリは、128GB/256GB。

利用されたCPUモデル

下記は当時のサービスで利用されていたCPUの一覧。CPUは2系統搭載された。

x64アーキテクチャ周波数(GHz)ターボブースト(GHz)3rd Cache(MB)Core(Threads)メモリバンドTDP
E5-2620 v32.43.2156(12)DDR4-1866 x485
E5-2630 v32.43.2208(16)DDR4-1866 x485
E5-2630 v42.23.12510(20)DDR4-2133 x485

概要

第5世代のプライベートクラウドファブリックは、x64アーキテクチャのクラウド用にXeon Haswell Refresh/Broadwell世代を搭載。メモリバンドがコンピュートノードあたり120〜136GBytes/s。CPUラインナップは24/32/40論理コア。搭載メモリは128GB/256GB。

x64アーキテクチャCPUとしてはメジャーアップデートとなる。CPUにL2-TLBを搭載されたため、プロセス数が多いコンテナ型システムに有用ではないかと考えられた。コンテナ型システムは、1つのカーネル上に多量のプロセスが走ることで、メモリのマイナーフォールト(TLBのメモリの入れ替え)が発生しやすいが、L2-TLBがその速度向上に寄与すると考えられた。コンテナを直接マルチテナントとしてユーザに引き渡すサービスはすでになくなっていたが、ハイパバイザ上のゲストマシンの上に、コンテナを設定することは増え始めたため、この性能向上を期待した。

当社のデータセンタインフラストラクチャ部門ではこのCPUは歓迎された。第4世代に比べ消費電力が少なく、活躍した第4世代の性能を、価格以外の全ての面で上回るったからだ。ユーザが乗り換えることを希望していたが、第4世代との併売が続いたこともあり、コストパフォーマンスの高さから継続して第4世代のサーバが好まれた。そのため、残念ながら人気は奮わない形となり、稼働台数も最も少ない。

なお現在、6Gと併売されている5Gモデルは、コンピュートノードが5Gなだけであり、そのネットワークインタフェイスも含め、その他の基盤は6Gと同等になっている。また、SSDもNVMeが搭載できるモデルも存在するため、CPU含め、コストパフォーマンスが極めて高いモデルとして併売されている。

6G(第6世代、2020年〜)/6Gs(第6世代セカンドエディッション)

VMware Private CloudSolaris Xeon Private CloudHigh Response Private Cloudで提供中。

特徴

  • CPU世代の進化
    • x64アーキテクチャサービス
      • Intel XeonのCPU世代を一新し、Scalable Processorを採用。6GではSkylake-SP、6GsではCascade Lake Refresh。
      • AVX-512などの、科学技術シミュレーションや、AI・画像処理に秀でた拡張命令群を装備。
      • コア数は32〜88論理コア(スレッド数)、幅広いメモリバンド(最大230〜256GBytes/sec)。
      • メモリラインナップは96GB/192GB/384GB/768GBまでをサポート。
    • SPARCアーキテクチャサービス
      • Oracle SPARC S7に加えて、Oracle SPARC M8 Processorを追加。
      • S7は4.27GHz、M8は5.06GHz。Software in Siliconより、セキュアメモリ、インメモリDBなどで高いワークロードに対応。
      • S7は128、M8は256論理コア(スレッド数)、幅広いメモリバンド(S7は最大307GB/sec、M8は最大374GB/sec)。
  • インターコネクテッドストレージモデル
    • 内蔵ディスクにNVMeモデルを採用したモデルをラインナップに追加
  • ストレージファブリックの強化
    • Enterprise NVMe SSDを本格採用
    • 新しくリファインした自律型ストレージの採用
  • ネットワークファブリックの強化
    • 同一データセンター内のインターコネクトを400Gbpsに強化
    • リージョン(関東・中部・関西)間の冗長化された通信網。低レイテンシ、ワイドバンド通信の実現
    • ロードバランサー機能、SSLアクセラレータ機能、WAF機能をハードウェアもつADC(アプリケーションデリバリコントローラ)サービスの開始
    • パブリッククラウドと閉域接続するパブリッククラウドリンクをサービス開始

プライベートクラウド・ラインナップ

プライベートクラウドのコンピュートノードのラインナップは下記の通り。

x64アーキテクチャ論理コア合計(Threads)メモリバンド合計最大値メモリ搭載(GB)備考
Xeon Silver(Skylake-SP)32230GBytes/sec96〜2022年新規販売終了
Xeon Silver(Skylake-SP)40230GBytes/sec192〜2022年新規販売終了
Xeon Gold(Skylake-SP)64256GBytes/sec384〜2022年新規販売終了
Xeon Gold(Skylake-SP)88256GBytes/sec768〜2022年新規販売終了
Xeon Silver(Cascade lake refresh)48230GBytes/sec192GB 
Xeon Silver(Cascade lake refresh)48230GBytes/sec384GB 
Xeon Gold(Cascade lake refresh)80256GBytes/sec768GB 
Xeon Gold(Cascade lake refresh)96280GBytes/sec1.5TB 
SPARC S7-2128307GBytes/sec256/512GB 
SPARC T8-1256187GBytes/sec512/1024GB 
SPARC T8-2512374GBytes/sec1024/2048GB 

利用中のCPUモデル

x64アーキテクチャ周波数(GHz)2nd Cache(MB)3rdCache(MB)CoreメモリバンドTDP
Xeon Silver 41102.18 × 1118 (16)6 × DDR4-240085 W
Xeon Silver 41142.210 × 113.7510 (20)6 × DDR4-240085 W
Xeon Gold 61302.116 × 12216 (32)6 × DDR4-2666125 W
Xeon Gold 61522.122 × 130.2522 (44)6 × DDR4-2666140 W
Xeon Silver 42142.21216.512 (24)6 × DDR4-240085 W
Xeon Gold 5218R2.12027.520 (40) 6 × DDR4-2667125 W
Xeon Gold 6240R2.42435.7524 (48)6 x DDR4-2933165 W
SPARCアーキテクチャ周波数(GHz)2nd Cache3rdCache(MB)CoreメモリバンドTDP
SPARC S74.27I: 512KB+D:1MB168(64)DDR4-2400 x4115 W
SPARC M85.0632 × (I: 128KB+ D: 256KB)6432 (256)374GBytes/sec非公開

概要

第6世代のクラウドファブリックのコンセプトは、「ハイブリッドクラウド時代の片翼を担うプライベートクラウドのIaaSは、パブリッククラウドのIaaSより原則として高速でなくてはならない」という命題のもとに設計されている。これは、5Gケータイ普及に伴うサービスの高速化ニーズ、デジタルトランスフォーメーション(DX)によるITインフラストラクチャに対する性能向上の期待に応えたものだ。

コンピュートノード(プライベートクラウド基盤)の進化

まず、x64アーキテクチャプライベートクラウドはCPU世代を一新してIntel Xeon Scalable Processorを採用。このプロセッサは、科学技術シミュレーションや、AI・画像処理に秀でたAVX-512などの拡張命令群を装備しており、論理コア数の向上、なによりもメモリバスの向上が大きい。リーズナブルなモデルでも48論理コア(スレッド)、ハイエンドでは96論理コア(スレッド)を持ち、加えて幅広いメモリバンド(1コンピュートノードあたり230GBytes/sec 〜 280GBytes/sec)を持つため、メモリの大容量化時の性能劣化を抑えることができる。プライベートクラウド基盤には、192GB〜1.5TBのメモリモデルがあるため、このCPU性能の向上は、多くのインスタンスを稼働させるのに役立っている。

これを動作させるハイパバイザは、5Gに引き続きVMware ESX Enterprise Plusと、XenServerを採用した。VMwareはx86/x64のハイパバイザとしては一日の長があり、オンプレミス仮想化基盤のマイグレーションには強く役立つ。VMware Private Cloudでは基本、1つのユーザ毎に1つのvCenterを持つため、オンプレミスからのワークロードの移設には極めて親和性が高いだろう。下記に記すインターリージョナルファブリックと組み合わせてDRセットにした場合、異なるリージョンで同一のネットワークセグメントを持ち、異拠点vMotionなどを駆使して、容易に異拠点のDR環境を準備できることも大きいアドバンテージだ。

安価なIaaS基盤であるHighResponse Cloudでは、XenServerベースのXCP-ngを採用。加えてXenOrchestraによるオーケストレーションが行われており、XenインスタンスのWebベースの管理が可能となっている。同拠点上でのインスタンスの自動バックアップや、異拠点レプリケーションが可能になるため、安価にDRを前提としたよりロバストな環境を実現することができるだろう。

一方、SPARCアーキテクチャプライベートクラウドは、S7に加え、M8プロセッサもラインナップに追加。SPARC M8プロセッサはCPUクロックが5GHzへと向上し、キャッシュ構造の進化、演算器の強化などが行われ、純粋な意味でSPARCプロセッサの集大成とも言える高速なプロセッサと言える。Software in Silicon 第2世代を搭載し、インメモリデータベースや、Java ストリーム処理にさらに適合したDAXと、暗号化支援機能などを持ちつつ、幅広いメモリバンド(1コンピュートノードあたり最大374GBytes/sec)を持つのも特徴だ。

ハイパバイザはOracle VM Server for SPARCを採用。これはLogical Domain(LDOM)という技術が利用されており、x64の仮想化基盤とは設計思想が大きく異なる。アーキテクチャとしては仮想化よりも、ドメイン毎、つまりCPUやメモリリソースを分割、割譲していくことに主眼がおかれているため、それぞれのインスタンスが、これらリソースにおいて互いに影響を及ぼすことがない(ただし、ネットワークとストレージに関しては、コンピュートノード単位で仮想化による共有も可能)。

現実的に言えば、もっとも利用ニーズが多いオンプレミスのSolaris10 SPARC環境のマイグレーションには、S7で十分な性能が出ていた。しかしここにSPARC M8プロセッサが加わることで、システム寿命の長いSPARCのシステムにおいては、既存システムをスケールアップにより性能向上させ、長く使えるシステムへ進化させることに一役買うことになった。Solaris10、11で当たり前のように利用しているコンテナ技術も、仮想インスタンス内で利用することができる。Solaris SPARC環境のオンプレミス代替としてのリフト&シフトだけでなく、最新のSolaris11を利用する事でモダナイゼーションさせることも期待できるだろう。

ストレージファブリックの進化

どの時代でも、ストレージファブリックに要求されるものは、データの安全性と速度である。実はこの2つは基本的には二律背反するため、基本はどちらかをメインにとらえるしかない。See:テクニカルノート/時空に拡張されるCAP定理:落ちず、速く、確実なサーバをどう作るのか?

プライベートクラウドを支える3-Tier型のストレージにおいては、どうしてもデータの安全性が最重要課題となる。いくら高速でもデータが化けたり消えてしまうのでは、信頼性の置けるシステムが構築できないからだ。しかしながら、昨今のデータ量増加に伴い、よりヘビーなIOにも答える必要がでてきた。IO不足は「遅くなる」のではなく「停止する」事に繋がるためだ。

そこで、安全性能に関しては「自律ストレージ」であることをコンセプトとし、実績のある第3世代のストレージファブリックをベースに、これらの新要求に対応すべく、再設計されたのが6世代目のストレージファブリックとなる。

第6世代目のストレージを、第3世代のストレージファブリックを元に、自律型に再設計したのには意味がある。第4〜5世代のVMware用ストレージファブリックは、VMwareの為のAPIであるVAAIなどに対応したストレージ製品を利用していた。これらのVMware用のストレージ製品は、ハイパバイザとストレージの間でソフトウェアが連携、連動する。これは主に、VMwareのクラスタリングファイルシステムにおいて発生する「ロック」を狭域化するなど、技術的且つ合理的な理由があるし、製品によっては利便性のために用意されているものももちろんある。しかし逆に、連携するということは、そこ由来のインシデント発生時、ハイパバイザだけでなく、ストレージを巻き込む事故になることもある。たとえば、負荷が増えてストレージの臨界点動作の時、その時でのみ起きうる不具合は、復旧困難になりがちなのだ。

一般に、ハイパバイザが専用のクラスタリングファイルシステムを利用する場合、ハイパバイザベンダがファイルシステムの恒常性を担保する必要がある。この場合、ストレージベンダはあくまでブロックレベルのストレージを提供するにすぎない。もしもハイパバイザベンダが提供するクラスタリングファイルシステムに障害が起きた場合、ハイパバイザベンダの管轄範囲となるはずだが、それはローレベルのブロックストレージが「恒常的に正しい」ことが担保されない限りは「クラスタリングファイルシステムの上のファイルが正しく保存されている」と、言い切ることはできない。つまり「そこにあるファイルが正しいかどうか」を保証する為には、ハイパバイザとストレージを提供した2つのベンダの管轄範囲を跨ぐことになる為、障害発生時の問題解決が極めて困難になってしまう。

ファイルレベルストレージの場合、ファイルが正しいかどうかは、ストレージベンダの管轄範囲だけで提供される。したがって障害が発生した場合でも、ストレージベンダが対応する範囲でデータの整合性担保ができるメリットがある。第6世代で再びNFSに戻したのにはこの理由が大きい。NFSでの利用では一般に性能劣化などが考えられるが、ロックは元々ファイルノード単位で狭域でもあるし、IO性能が十分にあれば、これらのマイナスをある程度、カバーできる。

冗長性はダブルパリティを二系統でダブルシャシー型でデータロストの可能性を極力排除した。

自律型であれば、コンフィギュレーションにより、2系統を単なるミラーや、遅延ミラーが可能で、スナップショットによる世代管理、オプション機能ではディザスタリカバリのために異拠点へのレプリケーションなど、ストレージ層だけで独立してデータを守る構造をもつ。臨界点異常が仮に発生したとしても、今の時点のファイルシステムは保持できているため、最悪「停止する」だけでデータは保護できる。

昨今、世界中のクラウドベンダーによるデータ欠損事故はユーザが考えている以上に多く、無視できないレベルに達している。ストレージもソフトウェアで制御される以上、バグが付きものとも言える。特に負荷が臨界点に達する時点でのみ発生するようなバグは発見しづらいため、データ安全性を最大限、深刻に考慮し、あえてハイパバイザソフトウェアスタックとは連動しない、独立型の構造を持ちながら、データ保全に努める設計を採用した。

安全性が高くても速度が十分でなければ、3-Tier型仮想化基盤用ストレージとしては機能しない。

そこでまずは最新世代のEnterprise NVMe SSDを用い、高帯域のストレージインターコネクトに、高いIOPS処理能力を確保した。これにより実測ベースでストレージ内では約4百万IOPS、約18GB/secを超えるリード&ライトを実現。ストレージサービスのSAN帯域は合計で2x25Gの帯域を持ち、Multi-Chassis Link Aggregationによってコンピュートノードとストレージファブリックが接続されている。コンピュートノードのSAN帯域は2x10Gbps。

実効ベンチマークとしてはVMware上のゲストOS内からでも2.35GBytes/secのリードをマーク。SAN帯域の限界値に近く、IO性能もVMwareハイパバイザ側のドライバ層性能を限界ぎりぎりまで絞りだしている。つまり、このようなベンチマーク中でもストレージファブリックには、IO余剰が持てるほどに十分な性能を持つことを意味する。埋め尽くすことができないレベルのストレージ性能があるからこそ、自律型でレプリケーションが可能になる。

これらはVMware、Solaris、IaaS(High Response Cloud)だけでなく、ユーザネットワークに対しても,ファイルレベルストレージ、ブロックレベルストレージとして提供できるようになったのも特徴だ。これらのストレージを直接、インスタンスから操作できると、現世代の選別したオンプレミスシステム並の性能を出すことができる。

これらはデジタルトランスフォーメーションにおいて、有用なエンジンとなる。

ネットワークファブリックの進化

6世代目はネットワークファブリックの進化も大きい。5Gケータイの帯域需要に加え、エンタープライズ企業では、デジタルトランスフォーメーション(DX)需要の高まりとともに「BCP」も重視されるようになってきたためだ。

まず、ユーザからの出入り口であるPrivate Connectは200M〜最大100Gbpsまでをサポート。国内の4つのリージョン(関東、関西、中部、九州)に対して、直接、InfiniCloudファブリックにレイヤー2で接続することができる。高帯域、低レイテンシで、オンプレミスと変わりない速度と同じIPアドレスで、「最も近いプライベートクラウド」が提供できることになる。

足回りを支える同一データセンター内のネットワークファブリック性能も大幅に強化し、インターコネクトは400Gで接続。Multi-Chassis Link-Aggregationによって1コンピュートノードあたり2x10/25Gの帯域を確保。同一リージョン、異データセンターでも、たとえば2x100Gなど、高帯域で接続することで、同一リージョンであれば統合されたデータセンターのように振る舞うことができるのも特徴だ。

リージョン(関東、中部、関西、九州)間接続であるインターリージョナルファブリックの性能強化も行っている。L2での冗長性の確保や、帯域増強と低レイテンシ化を行い、tagVLANの利用も可能。L3の場合は経路最適を行う事も可能だ。一般に、DRを実現するためには回線コストが問題になるが、これらを手軽に実現できれば、BCP/DRを極めてローコストで実現できることになる。そこで、4つのリージョンを同じように帯域を確保し、プライベートクラウドとあわせてより高性能なリージョン間ネットワークを強化した形となる。

パブリッククラウドとの接続線である「パブリッククラウドリンク」も新サービスとして追加した。昨今のシステムは、オンプレやプライベートクラウドだけで完成することも少なく、パブリッククラウドと連携することによって完成するものも多い。FaaSやAPIなど連携方法も多いため、単なる「アクセスやメンテナンスのための裏線」だけでなく、システム連動のための線としても使われる。プライベートクラウドとパブリッククラウドをインターコネクトで簡単につなぐことで、ハイブリッドクラウドが造り込みやすいよう、リーズナブルなプランを用意することとした。

通常、パブリッククラウドとプライベートクラウドをつなぐ為には、こういったコネクティビティサービスを申し込むだけでなく、ユーザ企業でBGPによるダイナミックルーティングの設定が必要となる。このルータ設置費やルータ設置作業は、ネットワークに詳しくないパブリッククラウドの利用者には敷居が高すぎ、且つ、冗長線、マルチリージョンともなると、難易度が跳ね上がる。そこで、BGPルータをセットとするサービスも用意し、エンジニアリングサービスと組み合わせて販売することが可能となったのも特徴だ。

もちろん、これらを連携するために、ネットワークアプライアンスサービスの拡充も必要となった。従来からのUTMのクラウド利用だけでなく、ロードバランサ、SSLアクセラレータ、WAFなどの機能を統合したADC(アプリケーションデリバリコントローラ)のクラウドサービスも開始。

Internetへの出入り口も強化。東西のIXに直接足を卸し、4つのリージョンから全て、高帯域Internetが利用できるようにしたのも特徴だ。大規模自然災害時において、インターネット接続は重要となる。日本においては東は東京大手町、西は大阪堂島がInternetの中心となり、どちらでもアクセスが可能になる必要があるためだ。

まとめ

5Gケータイや、デジタルトランスフォーメーションなど、第6世代が担うクラウドファブリックは重大となっている。

そして自然災害の多い日本においては、デジタルトランスフォーメーションが進むほど、ディザスタリカバリは重要となり、どうやって待機系に切り替えるかはシミュレーションが必要になるはずだ。

これらは個別に用意することはできるが、実際に事が起きた時に「どうやって切り替えて良いのかわからない」という企業もおおい。InfiniCloudファブリックの特徴はリージョンを「統合」したようにみせ、東でも西でも全く同じように利用できるのが特徴だといえる。

たとえば関東の会社にとって、関西にあるDR用サーバリソースは、普段有効利用されることが少なく、単なる置物のサーバリソースになる傾向がある。企業の情報システム部にとっては必要でありつつも、会社から見て削減されやすく頭の痛い問題だ。もしもこれらが、L2、ワイドバンドかつ低レイテンシ通信ができるならば、全ての拠点のサーバリソースは、通常時から仮想マシン単位で移動、クローン可能になり、かつロードバランサーで分散動作させて有効利用することができる。かつ、データストア(主にデータベースや分散KVS)も、レプリケーションやクローンが可能なので、きちんと障害時に「そのまま動作する」環境を作りやすい。いざディザスタが起きた際は、データストアのマスタ切り替えをするだけですむため、ディザスタ時の情報システム部の負担が大きく減るメリットもある。

このように、5Gケータイ向けの高帯域サービスや、デジタルトランスフォーメーション、4つのリージョンのネットワークは統合されることで、BCP/DRなどにフォーカスを当てたサービスが更に進化した形となった。

Private CloudPrivate Cloud
StorageStorage
NetworkNetwork