クラウドはどのように進化していくのか？（後編）：賢者の意志決定（1/2 ページ）

クラウドという流行のテクノロジーの議論に終始していては、クラウドの本質をつかむことはできない。本稿は、日立ソフトが提供する「セキュアオンライン」の事業責任者であり主席アーキテクトである中村輝雄氏が、クラウドの最新事情と今後の方向性について、事例を交えながら語り尽くす。

[中村輝雄，ITmedia]

本稿は、中村氏による寄稿の後編となります。初めての方は前編をご覧いただくと、クラウドがこれまでたどってきた適用領域の拡大について確認いただけます。

5．性能を保証するクラウドがあってもいい【クラウド1.5】

　クラウドはどのように進化していくのか？（前編）では、筆者がクラウド1.0やクラウド1.1と呼ぶクラウドの利用形態によって、社外、社内を問わず、既存の物理サーバをクラウドのVMに置き換えることができることを説明した。しかし、これだけでは、企業がIT設備に要求するリクエストをすべて満たすことができないのも事実だ。その一番のポイントは、性能保証である。

　現在のクラウドのサービスのほとんどは、ベストエフォートでIT設備を提供することになっている。例えば、CPUのクロック数はベストエフォートで提供されるので、誰かが非常にCPUを食うプログラムを走らせれば、たまたまその環境にいた別のユーザーのVMの性能は劣化する。また、別のユーザーが重たいデータトランザクション処理をしてストレージに負荷をかければ、やはりその環境を共有しているユーザーのI/O性能は劣化する。ネットワーク帯域も同様である。これでは、現実に稼働しているシステムをクラウドに引っ越すことはできない。

　そこで、筆者は、こうした問題を解決するクラウドこそ、「クラウド1.5」だと呼んでいる。クラウド1.5は、従来のクラウドが苦手にしているリアルタイム処理やバッチ処理、さらにハード制御を可能にするものだ。以下、事例を交えて、クラウド1.5のメリットについて紹介しよう。

　最初の事例はシミュレーションだ。シミュレーションでは、リアルな事象にできるだけ近づけるために、より詳細な設定ができるようパラメータの数を増やす。しかし、パラメータが増えると、計算量が爆発的に大きくなり、希望の時間内に終わらない事態が発生する。そこで、サーバを複数並べて、計算を並列に実行することで計算時間を大幅に短縮しようと考える。

　実際、あるユーザーでは、100台のサーバを使ってシミュレーションの計算をする必要があった。ただ、実際に100台のPCを並べるとなるとそのラッキングから、必要台数分の電源の準備やネットワークの配線と、非常に手間の掛かる作業が予想されるため、100台のPCの購入をためらっていた。そこに目を付けたのが、クラウドだ。クラウドであれば、100個のVMは簡単に用意できるし、電源工事やネットワークの配線も要らないからだ（図7）。

図7　CPUクロック数を3GHz保証したVMを100個提供する

　ただし、この場合、各VMのCPUのクロック数を保証する必要がある。保証しなければ、計算時間が予測できないからだ。例えば、CPUのクロック数3GHzを保証せずにベストエフォートで提供したとしよう。このとき、ほかのユーザーでも非常にCPUパワーを食うアプリケーションを走らせていたとすれば、CPUのクロック数は3GHzではなく実質2GHzしか割り当てられないかもしれない。これでは、計算時間は1.5倍長く掛かってしまう。クラウド1.5では、こうしたCPUのクロック数を保証するサービスを提供する必要がある。

　2番目の事例はオンラインゲームだ。オンラインゲームはヒットすれば、爆発的にユーザーが増加する。そうなれば、サーバの性能が追いつかなくなる。そのため、翌日のピークが来る22時までに、CPUのコア数やメモリ容量を増やす必要がある（図8）。さらに、サーバの台数も増やす必要があるかもしれない。そうした迅速な設備増強は、クラウド1.0でも十分対応できる。

図8　インターネット回線のトラフィックは毎日22時にピークが来る

　しかし、クラウド1.0では対応できない課題がある。オンラインゲームのユーザーが爆発的に増えた時でもユーザーの操作性能を保証するために、インターネット回線の帯域をベストエフォートではない形で保証する必要があるというものだ。さらに、そのインターネット回線に接続しているファイアウォールやロードバランサについても、十分な性能を保証しなければならない。そこで、クラウド1.5では、インターネット回線に1Gbpsの帯域を保証し、さらにもう1本別回線を用意しておく周到さが求められる。しかも、それに応じてファイアウォールやロードバランサも余分に準備しておく必要がある。

　3番目の事例はバッチ処理だ。バッチでは、特にストレージI/Oの性能保証が求められる。実際のところ、クラウドでは比較的潤沢にサーバが用意されているので、CPUの性能保証はある程度の規模に到達したクラウドセンターではさほど難しい要求ではない。しかし、ストレージI/Oの性能保証は、クラウドセンターにとってはかなりハードルが高い要求だ。これを理解するために、クラウドセンターのシステム構成を簡単に説明しよう。

　クラウドセンターでは、VMの可用性をできるだけ高めるために、複数のサーバをクラスタと呼ぶ単位でまとめている。そして、クラスタ内のサーバは共通のストレージを共有している。これは、あるサーバがハード障害を起こした場合、そのサーバ上で動いていたVMを同じクラスタ内の別のサーバで自動的に再起動させるためだ。

　しかし、この仕組みでは、あるVMが非常に重いストレージアクセスをした場合、そのVMと同じクラスタで稼働するVMはすべて、ストレージI/Oの性能低下に見舞われることになる。このため、クラウドではストレージI/Oの性能を保証するのは難しいのだ。

　クラウドでストレージI/Oの性能を保証するためには、そのクラスタ内のそれぞれのVMの特性を理解し、重いストレージアクセスをするVMはほかのクラスタに移動させるなど、運用上の支援が不可欠となる。そうしたきめ細やかな対応が、クラウド1.5には求められるのだ。

　最後の事例はハード制御である。例えば、PCのUSBポートに開発中の組み込みボードを接続し、そのボード上で実行されるプログラムをデバッグする開発環境を取り上げよう。この開発環境をクラウド上で実現したいのだ。なぜなら、組み込みプログラムの開発を人件費の安い海外に移したいというビジネス上のニーズがあるためである。

　しかし、この場合、2つの問題に直面することになる。1つは、海外で組み込みプログラムを開発するためにボードを輸出しなければならないことだ。通常、ボードと組み込みプログラムは平行して開発されるため、プロジェクトの後工程で、頻繁に変更されるボードを毎回海外に輸出する時間的余裕がない。しかも、ボードは新製品の中核技術だ。発売前に自社工場から出すことに関して、セキュリティ上の懸念もある。そこで、クラウドを使って、海外から日本のボードを制御して、組み込みプログラムを開発できる環境が望まれている（図9）。

図9　海外からクラウドセンターのVMにアクセスし、工場のボードを操作する

　図9では、まず、海外拠点のPCにUSBキーを挿して電源を入れる。これにより、普通のPCがクラウドセンターにアクセスするためのシンクライアントになる。次に、日本のクラウドセンター内のボード制御VMにリモートログインする。そして、クラウドセンター内のVMから工場内の組み込みボードを制御するのだ。

　しかし、ここで解決しなければならない課題がある。それは、海外拠点と日本との間で、通常、インターネットのデータ転送で100msを越える遅延が発生することだ。これでは、海外拠点から日本のVMにRDPでリモートログインしてストレスなく操作できる性能とはいえない。そこで、海外にサービスを提供しているクラウドセンターでは、インターネットの遅延を軽減するために、さまざまな工夫が施されている。例えば、図9では高速化装置を導入して、データ転送の遅延を軽減し、RDPで十分な操作性能を保証している。このように、クラウド1.5では、海外にサービスを展開するためにインターネットの遅延問題を解決しているのだ。