ハイブリッド・クラウドの実現でITはどう変わるか？ ―　技術編

このシリーズの最初にはハイブリッド・クラウドが何なのか、それがあれば何ができるかを書いた。そして、実際のハイブリッド・クラウド完全実現に立ちはだかる技術やその他の問題を指摘した。現在までのハイブリッド・クラウドは理論的には存在するが、本当の意味では現存しなかったと言っても過言ではないだろう。最近話をしたCloudVelocity社はこの問題を解決し、ハイブリッド・クラウドを実現した。それで、早速訪問して話を聞いた。 

 技術のまとめ

CloudVelocity社の CTO のAnand Iyengar氏に個人的に講義して貰った。

Anand Iyengar氏

技術の詳細と言っても、かなり省略して直感で分かるレベルで書いている。今後CloudVelocity社の技術とビジネスの進み具合によってはまたもっと詳細なブログを書く予定だ。

Anand は詳細に渡る説明をしてくれたが、全くシステムを知らない人にその様な詳細を提供しても、消化不良になるだけだ。省略し過ぎず、全体の様子が分かるレベルに省略して、以下にアーキテクチャーを示す。

 アーキテクチャー: バーチャル・マシン(VM) や物理・マシンやその他の付随機能は企業のデータセンターで形成されているプライベート・クラウド(大部分がVMwareベース) とパブリック・クラウド (大部分がAmazon AWS).

(図の出典: CloudVelocity)

 設定

まず最初に初期設定をみて見よう。

プライベート・クラウド側

• まず最初に企業側のデータセンターまたはコーロケーションサイト（どちらもプライベート・クラウド）を見てみよう。最近のアプリケーション・システムは１つのサーバーで全てが実行される訳ではない。むしろ、システムは数台の物理マシンや仮想マシンに跨って実行される。だから、複数システムアプリケーションと呼ぶことにする。このシステムのコンフィギュレーションはアプリケーション領域や設計方法によって異なるが、一般的に負荷分散装置、ウエブ・サーバー、アプリケーション・サーバーや時としてサーバーのクラスターから成り立っている。
• この様子が上記の図に示されている。スペースの関係からS1とS2のサーバーしか描いていない。更に、複数システムアプリケーションはデータベース、ファイルをマウントするNFSボックスやLDAPサーバーを使用する。パブリック・クラウド上に設置されるサーバーやユーティリティは全てプライベート・クラウド上のもののコピーだ。但し、NFSはそれぞれのクラウド内でファイルを提供するもので、クラウドを跨いでファイルを提供するものではない。また、セキュリティを考慮すると、ものによってはパブリック・クラウドにコピーしないこともある。例えば、 LDAPサーバーなどである。
• 更にプライベート・クラウドとパブリック・クラウド間のアプリケーションの状態の同期をはかるための通信を司るアプライアンスがそれぞれに設置される。 (プライベート・クラウドにはCloudVelocity Nexus Site Manager、パブリック・クラウドには CloudVelocity Cloud Manager を）。 ここで、アプライアンスという名前をつけているのは、それが同期目的のみに使用されるということを強調するためだ。 CloudVelocity Nexusは物理マシンでも仮想マシンでも良いが、CloudVelocity Cloud Manager はパブリック・クラウドでは全てが仮想化されているので、仮想マシンとして実行される。
• 更に、S1 は仮想化されているが(ファイル形式はVMDK)、S2とDB1は仮想化されていないと仮定する。つまり、パブリック側ではこの２つは仮想化されないと、パブリック・クラウドでは実行されない訳だ。 

 パブリック・クラウド側

• 複数システム・アプリケーションでは、パブリック・クラウド側でこれを形成するものは全てプライベート側のコピーである。パブリック・クラウド側はまずプライベート側にあるものをコピーすることから始まる。そして、アップデートは順次コピーされて同期が保たれる。

A. システムS1はパブリック側にコピーされる。もし、以前にコピーされていなければを全てをコピーされ、以前にコピーされていれば、変更部分だけコピーされる。S1は仮想化されており、プライベートとパブリックでは ファイル形式が異なるので、コピーされる時に自動的にAMI ファイル形式が変更される。S2の場合S1同様にコピーされるが（既にコピーがなければ、そのままコピー、以前のコピーがあれば前回からの変更のみ）、S2は仮想化されていないので、コピーの際自動的に仮想化されAMI ファイル形式に変換される必要がある。

B. DB1とNFS1は双方物理マシンだが、同様なプロセスを辿り, AWS/AMI上で実行可能となる。

• ２つのクラウドは専用回線でもSSLを介したインターネットでも接続可能である。
• パブリック側で、どのシステムでも必要がなくなると、その実行を停止して除去される。または、将来必要であれば、実行は停止されるがコピーは除去されない。これは、将来のコピーに掛かるコンピューティング力を節約するためである。

では、次に実際のオペレーションをみて見よう。実際はもっと複雑だが、容易に理解できるように簡素化してある。

 オペレーション

• プライベート側のCloudVelocity Nexus はプライベート側のコンピューティングのリソースのコンフィギュレーション情報を収集してその情報をファイルに格納する。
• この情報はパブリック側のCloudVelocity Cloud Manager に送信される。この情報を元にパブリック側の環境を整える。パブリック側のストレッジやコンピューティングの使用はAWSの課金システムによって、コストが発生する。CloudVelocity Cloud Managerの大きさはせいぜい数百kb程度なので、これを常駐させることのコストは非常に小さい。Cloud Manager がコンフィギュレーション情報を受け取ると、それに応じて必要なコンポーネントに必要なストレッジ領域を確保して、コピーを作る。しかし、コンポーネントはまだ実行されいない。このように予めコピーを作っておくことで、パブリック側のコンポーネントの立ち上がりの時間を縮小することができる。 EC2/AWSの課金システムは、コンピューティングには大きく課金するがストレッジにはそれほどでもない。こうすることで、コストと起動速度のバランスを保つことができる。
• パブリック・クラウドでシステムを立ち上げると、大体3-5分を要する。これは、AWS上で仮想マシンをブートする時間だ。
• パブリック側でシステムが必要なくなれば、実行を停止する。その場合、将来の使用がないのなら、除去してストレッジを開放する。ストレッジを開放すれば、AWSの課金を防ぐことができる。そうでなければ、将来のためにコピーをそのままにしておこともできる。

応用領域

ではこれはどの様に使用されるのだろうか。

A. クラウド・フェイルオーバー: プライベート・クラウドでのオペレーションが何らかの理由で中断するが、全体のオペレーションを停止することが出来ない場合、完全コピーのパブリク・クラウドが起動されてオペレーションを継続することができる。これはフェイルオーバーと呼ばれてディザスタリカバリ(DR)やフォローザサンやフォローザムーンなどに使用できる。

B. 開発やテストのサンドボックス: プライベート・クラウドでアプリケーションが実行中に、１つ以上の同じアプリケーションをパブリック・クラウドで同時に起動することができる。これらの複数コピーは完全にサンドボックス化した環境で実行されるので、これらのコピーが現在のプロダクションコピーの実行に影響を与えることはない。

C. 完全移動: フェイルオーバーが一時的なのに対して、データセンターの容量不足とかその他の理由で、オペレーションに影響を与えずにアプリケーションを完全にパブリック・クラウドに移動することができる。

D. クラウド・バースティング: この機能を使えば、プライベート・クラウドでのコンピューティング力をパブリック・クラウドで補助することができる。プライベート・クラウドの容量を超える負荷が掛かった場合、通常は負荷を軽減するかその一部を処理することしかできない。 クラウド・バースティングがあれば、プライベート・クラウドで処理できない負荷をパブリック・クラウドで立ち上げたアプリケーションで処理することができる。負荷が収まったときは、パブリック・クラウドのアプリケーションを停止する。パブリック・クラウド上で実行されるアプリケーションの状態は常にプライベート側に送信され、パブリック側が停止しても、データの完全性を保証することが出来る。

 特許申請中の技術

Anand によれば、Cloudvelocity社のOne Hybrid Cloud Platform (OHCP) の２つ技術は特殊で、その中の２つの技術に関して特許出願中とのことだ。

そのうち、最初の技術は２つのアプライアンスで、プライベートとパブリック双方を常に同期させるものだ。詳細は割愛するが、この２つを同期させるのは、非常に難易度が高いそうだ。 ２つ目はプライベートとパブリックにある同じコピーから、プライベートにあるLDAPサーバーに問題なくアクセスできることだ。例えば、セキュリティの問題から、LDAPサーバーをパブリック側にしか設置しないと仮定する。双方で同時に実行されるアプリケーション・システムから１つの同じLDAPサーバーにアクセスしても問題が起きないようにすることだ。

OHCP と vMotion の比較

当初はOHCPとvMotionは類似した技術のように思っていたが、Anandとの議論で、vMotion とOHCP は似通った機能はあるものの、異なった問題を解決するものだと理解した。簡単に２つを比較してまとめると、以下の様な表にまとめることができる。

上の比較を見ると、２つの技術は競合というよりは補完関係にあるように見える。これに附いて、将来のブログでもっと詳しく書くつもりだ。

ところで、現在無料でこのシステムを試すことができるとのことだ。