クラウド: 2009年12月アーカイブ

さて、ここまでは雲の階層（レイヤ）の話だったが、今度は雲の大きさ、広がりを見てみよう。言うまでもなく、もっとも広がった雲は、GoogleやAmazonに代表される、いわゆる「パブリッククラウド」である。このカテゴリのサービスは、多くのユーザが必要とする一般的な機能、サービスもしくはインフラを必要とするすべてのユーザに提供する。このレベルでのサービスには、言うまでもなく高いスケーラビリティが必要になる。なぜなら、多くのユーザ、しかも、規模も使う頻度も違うユーザ（企業）をストレスなく収容しなければならないからだ。そのためには、ある程度の規模のインフラが必要になる。もちろん、スモールスタートはあるだろうが、ユーザに意識されない形で随時、増強が可能なインフラでなければならない。こうした、幅広い企業やコンシューマを相手にするサービスは、価格の面でも要求がきつい。はっきり言って、安くなければ誰も使わないからだ。だから、ある程度の初期投資をして、規模を稼ぎ、さらにはユーザの負荷をうまく平準化してインフラを最小化することが必要になる。そういう意味で、最も敷居の高いサービスだといえるのかもしれない。大手優位の構造が最もはっきりするタイプのカテゴリだろう。

 もう少し、絞り込んで、特定の業種やビジネス上の企業集団などのレベルで考えると、共通する業務はより多くなる。たとえば、ＥＤＩや、部品の取引市場、行政サービスなどを考えてみるとわかりやすいだろう。このレベルで共通な業務をサービス化してクラウドで動かそうというのが、いわゆる「コミュニティクラウド」だ。これは、どちらかといえば、システムの標準化とインフラの共用によるコストダウンを狙うものと考えられるだろう。もちろん、対象となるコミュニティの規模や広がりによって必要とされるインフラの規模はかわる。たとえば、グローバルな取引システムなどは、時差による負荷の平準化も可能だが、日本国内のようなタイムゾーンがひとつの地域内のサービスでは、その効果は薄い。むしろ、共同システム運用的な要素が強くなる。クラウドという意味合いを強調するのであれば、たとえば、複数の会社や自治体のような機関が、それぞれ得意な部分のシステムを運用し、相互に乗り入れたり、バックアップしたりするようなモデルがいいのではないかと私は考える。クラウドというなら一か所にまとめる必要はないだろうし、それによる地理的な意味でのリスクも大きくなるからだ。たとえば、きちんとしたＩａａＳ／ＰａａＳ事業者がそういう大規模でスケーラブルな分散環境を用意してくれるのであれば、その上にまるごとのせてしまう手もあるだろう。いずれにせよ、クラウドコンピューティングというものが、ネットワーク上に分散された環境をうまく利用して効率のいいシステムを作るための技術だとすれば、そのような形で作るのでなければ、それは単なる共同計算センターにすぎなくなってしまう。ここがまた、「まやかしクラウド」の入りこむ隙間だろうと思う。

さて、では、ひとつの企業や団体、機関のレベルでの、「プライベートな」システムのクラウド化は可能なのだろうか。結論から言えば、可能だと私は思う。但し、それは、本来の意味でのクラウド基盤を提供できるＩａａS／ＰａａＳ事業者の存在なくしては困難だ。自社でこうしたスケーラブルなクラウド基盤を構築できる会社は、世界中で見てもそれほど多くはないだろう。通常の、特に自国内中心の商売をしている企業などのクラウド化は、上のレイヤで考える必要があると私は思っている。このようなクラウド化は「アウトソーシング」の一種ではあるが、これまで、一般のデータセンタ事業者に対して行われてきたものとは根本的に考え方が異なる。最も異なる点は、コストに対する考え方だ。アウトソーシング自体は、企業が本来自分たちの本業ではないＩＴリソースを保有せず、外部のリソースを利用して、こうした本業外のリソースを保有することのコストやリスクを下げようというものだ。ある程度規模のある事業者にシステムの運用管理やユーザサポートを委託することで、こうした目的はある程度達成できる。特に、人的リソースを保有しなくて済むことで、管理コストを含めた人件費とそれにかかわるリスク、たとえば、自社技術者のスキルへの依存やＩＴ技術の変化による人材の再教育、入れ替えといったリスクを軽減できることは大きい。しかし、それ以上のメリットをどれくらい享受できているのだろうか。

多くの場合、システムのソフトウエア、ハードウエアはユーザ側の資産である。従って、この部分の調達費用はユーザ側の負担だ。また、運用やサポートのアウトソースに関する費用も決してバカにならない。意外と高くつくのが、必要なＳＬＡ（サービスレベル保持契約）の締結だ。ＳＬＡを結ぶことは、事業者にとってはリスクのを負うことにほかならず、当然、保険の意味で高い料金を要求することになる。実際、それは、自社要員で運用するよりも、高くつくことが少なくない。それが認められていたのは、それでもユーザは人的なものを含めたリスクを負いたくないからだと私は思う。ただ、事業者にしてても、ユーザごとにシステムが異なる以上、そうせざるを得ないだろうと私は思う。共通化できるのはファシリティとネットワーク基盤くらいである。ここを一歩打開しようとするのが、仮想化基盤を使ったハードウエアの共有化だ。平たくいえば、個々のユーザが持っているシステム性能の余裕部分を共有化することで、この部分のコストを下げようという考え方である。注意が必要なのは、仮想化でハードウエアを共有したとしても、ＳＬＡがある以上は、個々のユーザの処理性能は保証しなければならない点だ。したがって、事業者としては、それをカバーできるだけの規模のシステムは最低限必要になる。

ここは本来、事業者側の腕の見せ所だ。たとえば、個々のユーザの利用統計をもとに、同じ仮想基盤にのせるユーザのピークが重ならないようにするとか、異なる性格のシステムをうまく混在させるとかして、負荷をできるだけ平準化し、必要なハードウエアリソースとその運用、保有コストを減らすといったことだ。このために、システムを動的に仮想環境上で管理できるような基盤も必要になる。ただ、先にも述べたように、これは一事業者の範囲ではなかなか容易ではない。しかし、ここをクリアできなければコストダウンはできず、ユーザのコストダウン要求と自社の利益とのはざまで板挟みになることになる。何度も言うが、ユーザにとってのクラウドとは、コストダウン以外の何物でもない。つまり、クラウド化は事業者に対しても劇的なコストダウン努力を求めることになるのだ。

こうした前提で、個々の企業が、事業者のインフラを安価に借り受けて自社システムを動かすことができれば、はじめてそれは「プライベートクラウド」と呼ぶことができるのだろうと私は思っている。

（続く）

さて、クラウドの代名詞といえば、SaaSつまり、Software as a Service なのだろうと私は思っている。しかし、SaaSがどのようなものか、という理解はかなりブレている。これがクラウドを最も見えにくくしている元凶なのではないだろうか。そもそも、「クラウド」なんて言葉がはやるずっと以前から類似のものは別の名前で存在していた。いわゆるASP（Application Service Provider）である。多くの人は、いまだに、この区別がついていない。SaaSをうたい文句にしている（その多くは、ついこの前まで自分たちをＡＳＰと称していた）サービス事業者の多くもしかりだ。

１章で、これまでの情報システムとそれをとりまく環境の流れを書いたのだが、それにあてはめて考えてみよう。ＡＳＰはお手軽な形で、必要な情報システムを手に入れられるという意味では、ＳａａSと同じではある。しかし、ＡＳＰは多くの場合、自分のサービスだけの世界で閉じている。つまり、それだけで最低限必要なすべてを提供するかわりに、それ以上のもの、たとえば機能やスケーラビリティを望んでも、それは事業者をのりかえるしか方法がない。しかも事業者を乗り換えれば使い勝手は大きく変わってしまい、利用者を戸惑わせることになってしまう。

さて、そこで質問だ。どのようにすれば、スケーラブルでなおかつ、適宜必要な機能を低コストで追加していける情報システムを作っていくことができるのだろうか。

この答えはすでに出ていると思う。それは、ＳａａＳをSOA化されたバックエンドサービスとして扱うことだ。SOAという視点から見たSaaSは、ユーザＩＴ部門を、縛り付けられていたパッケージから解放するものだ。特定のパッケージを使ったり、自社で開発するのだったら、ＳＯＡのありがたみはない。部品として使えるサービスが選べてはじめてＳＯＡの意味があるのだとすれば、ＳａａＳこそが、それを可能にするものだと私は思っている。つまり、逆の言い方をするなら、そういう使い方ができないＳａａＳはＳａａＳではなく、単なるＡＳＰである。もちろん、独自のＵＩは、それのみを使いたいユーザにとっては必要だ。しかし、より高度なことを考えるユーザにより一般的な機能をサービス（ＡＰＩ）として提供できることが、ＳａａＳの条件だろうと思っている。

（続く）

ＩａａＳが、インターネットにおけるＩＳＰだとすれば、ＰａａＳ（Platform as a Service）は、さながらクラウド基盤の上に構築されたレンタルサーバやホスティングサービスだろうか。いささか、この定義はＩａａSともかぶるが、大規模分散と仮想化環境の提供がIaaSだとすれば、PaaSは、その上に作られた個別のホスト環境や、そのうえで、様々なサービス構築のためのツールを提供するようなサービスだと言える。

PaaSのレベルは様々だ。有名なところで言えば、Amazonは、個々の利用者に仮想マシンつまりＯＳを載せる環境を提供できる。そのぶん、スケーラビリティはある程度制限をうけるものの、利用者の自由度は高く、様々なソフトウエアをその上で動作させることができる。一方で、Google が提供する Google Appエンジンは、Webサーバとそのうえでアプリケーションを構築するための Python による開発環境と様々な Googleが提供する機能やアプリケーションへのＡＰＩを提供している。できることは制限されるが、この環境自体がGoogleの大規模分散環境にのっかっていることから、アプリケーションを変更することなく、小規模から超大規模のサービスまで柔軟に対応できるのが特徴だ。つまり、自由度とスケーラビリティの間には逆相関の関係がある。利用者は、これをうまく使い分ける必要がある。たとえば、自社やそのグループ、その他中小規模のコミュニティレベルに独自仕様のサービスを提供するような、いわゆるプライベート、コミュニティクラウドサービスの構築は、自由度の高い環境を、一方で、コンシューマのような大量の利用者を相手にするＳａａSなどのパブリッククラウドサービスを提供するつもりなら、スケーラビリティを選ぶことで、必然的にどちらの形態を選べばよいかが決まる。もちろん、料金は定額から従量制、その組み合わせまで様々だから、これも考慮に入れてサービスを選択する必要がある。

PaaSは、そのレベルによって差異はあるものの、ユーザが自分たちの仕様で自由にアプリケーションを構築でき、なおかつ自分たちが構築したレイヤより下の運用は意識する必要がないため、運用コストの大幅な低減に役立つ。一般に、情報システムを構築、導入する際のコストインパクトは、基本的に減価償却対象である初期投資と、毎年発生する運用コストにわかれ、前者はＢ／Ｓつまり貸借対照表上の資産として、後者はＰ／Ｌ（損益計算書）上のコストとして取り扱われる。資産は複数年度で償却され、単年度予算（Ｐ／Ｌ）へのインパクトは相対的に低いのに対し、運用経費はそのまま単年度のＰ／Ｌにインパクトをあたえる。企業のＩＴ部門が運用コストをより削減しようとするのは、そういう理由からだ。特に昨今のような経済状況下で、単年度のＰ／Ｌが重視されるような時はなおさらである。これが、大手企業をしてまで、クラウド化に走らせる理由だとしたら、ある意味で、一般企業が利用するのは、基本的には、このPaaSから上のレイヤでなくてはならない。私は、このあたりの整理をあえて、あいまいにする「まやかし」が今の「自称」クラウド事業者の一部にあるのではないかと危惧している。

（続く）

ただ、寡占化がすべて悪というわけではない。IaaSというレベルで、利用者側の視点から見れば、これはクラウドそのものではなく、あくまでシステムを「クラウド化」するための基盤である。それは安価で信頼性が高いものである必要がある。１社で独占されるのは困るが、ある程度体力のある大手が競争している状況が生まれれば、これは利用する企業にとってはいい話だ。この基盤は、企業の情報システムの基盤となるだけではない。後で述べる上のレイヤのサービス事業者のサービス基盤としても利用できるからだ。サービス基盤として考えた時のIaaSも、やはり価格とスケーラビリティが最重要課題である。サービス事業者はこの基盤を賃借して、その上に「付加価値」としての独自サービスを組み立てて売ることになる。このレイヤでもサービス価格は低く抑える必要があるから、基盤の賃借料は安いにこしたことがない。その要求は個々の企業よりも切実だ。つまり、ここでも大手優位の構造が出来上がってしまう。

問題は、現在、乱立気味の中小データセンタの行く末だ。これはかなりお寒いものであると私は思う。大手に対抗できるスケーラビリティを確保し、価格を下げるためには、１社の努力だけではもう無理だ。彼らが選ぶべき道は、仮想化基盤の標準化と、同規模のデータセンタ事業者による相互補完のためのアライアンスしかないと思う。回線だけは借りなければいけないのがネックだが、細い（つまり安い）回線で効率よく通信できる技術もあるから、コストはある程度おさえられるはずだ。これを阻んでいるのが、仮想化環境の相互接続性である。１種類のハイバーバイザですべてそろえるのが最も簡単だが、理想的なことを言えば、仮想マシンとハイバーバイザ、そしてハイパーバイザ間のインターフェイスが標準化されるとより柔軟な構成が可能になるだろう。

ともあれ、これから投資をしてこのレイヤに参入、というのは現実的ではない。あくまで、既にどっぷりひたって、途方に暮れている中小事業者の今後の話である。

では、これから参入する事業者はどうすればいいのか。せっかくＩａａＳ事業者が作ってくれた安価でスケーラブルな基盤があるのだから、これを利用しない手はない。クラウドにおけるIaaS事業者は、インターネットビジネスにおけるＩＳＰと同じ存在になるだろうと思う。ＩＳＰも最初は乱立したものの、最終的に淘汰が進んだ。むしろビジネスはこうした大手ＩＳＰが作った通信網の上に花開いている。これと同じ状況がクラウドでも起きると私は思っている。

（続く）

このレイヤを「クラウド」と位置づけて、一生懸命商売をしようとしているのが、サーバメーカーとか、仮想化ハイパーバイザやOSベンダ、そしてそれにのせられたデータセンタ事業者である。ちょっと皮肉っぽい言い方をするが、これは雲の断片を売るようなものだ。先にも書いたが、クラウドの神髄はスケーラビリティにある。たった一社で提供できるようなものを「クラウド」と私は言いたくないのだ。もちろん、日本でも例外的にこれができそうな会社が２～３社はあるのだが、やがては日本でのクラウドは、この２～３社の寡占状態になりかねないなと危惧している。

クラウド基盤の提供、つまり今風に言えば、IaaS　（Infrastructure as a Service）は、たしかに事業として面白いが、ユーザがこれに何を期待するかはきちんと見ておく必要があろう。それは、少なくとも今のところはコストダウンだ。しかも、かなり劇的なコストダウンである。しかし、そうしたコストダウンできる基盤を用意しようと思えばスケールメリットを稼ぐしかない。Googleなどを見てもわかるように、そのための投資は莫大だ。その結果として低価格でも損益分岐点を超えて利益が出るだけのユーザを収容できる。日本のデータセンタ事業者は安全性を強調するが、Googleのセンターに勝てるセキュリティを確保できると契約に明記できる事業者は皆無に等しいだろう。そもそもセキュリティとはそういうものである。この話は後半でするつもりだが、クラウドのセキュリティを語る場合には、いくつかの異なる視点が必要だ。ファシリティや基盤のセキュリティはその切り口のひとつでしかないのだ。

話を基盤に戻すが、結局は、処理能力をいかに効率よく配分し、負荷を平準化できるか、ということがクラウドとして見た時の重要な点である。だから、仮想化と大規模な分散環境、そしてそれを支える高速なネットワークが必要なのである。これを今、すべて自社で保有している企業は非常に少ない。持たざるものは借りてくるか自前で作るしかない。いずれにせよ、相当な費用や投資が必要であり、なかなか安い値段では売れない。ならば、と「付加価値」を強調してみても、結局、今の経済状況下では、ユーザに見向きもされない結果となってしまう。少なくとも今は、コスト削減が至上課題だからだ。大手は、この時とばかりに、価格競争に入るだろうから、もし、近い将来、景気がよくなったとしても、その頃にはユーザの多くは大手に囲い込まれてしまっているはずだ。

さて、そうならないようにどうしなければいけないのだろうか。それは、「持たざる」事業者がその命運をかけて考えるべき事柄である。

（続く）

現在言われている仮想化技術の原型はもうずいぶん前に作られている。メインフレーム時代、ＩＢＭのＭＶＳというＯＳは、今で言うハイパーバイザとして機能し、そのうえで複数のＯＳ環境を作ることができた。ＰＣの世界ではＶＭＷＡＲＥが、ＰＣのＯＳ上で別の仮想ＯＳ環境を起動できる仕組みを、これも比較的早い時期から実用化し、私なども検証用に複数の環境が必要な時に重宝したものである。

仮想化、ということがサーバ側で本格的に言われだしたのは、ここ数年だ。追い風になった要因は様々だが、たとえば、不景気によるコストダウン圧力からＴＣＯ削減を目的に始まった、サーバ統合、これは電力消費の削減と平準化という意味ではエコでもあり、それもまた追い風になっている。ＪＳＯＸなどを皮切りに日本では、ＢＣＰの一環として、情報システムの災害対策が一気に進んだが、バックアップシステムを新たに作るにあたって、既存システムを仮想マシン化し、仮想化環境の上で動作させることが多くなっている。

こうしたニーズを受けて、仮想化プラットホームも進化していく。もともと１台のサーバリソースの有効利用だった仮想化は、複数サーバ、しかも遠隔地にあるサーバ間での仕事の受け渡しが、限定的ながらも可能になった。あと少し進化すれば、複数のデータセンタと高速な通信回線を基盤として、データセンタグリッドを作る条件が整う。これができれば、クラウドコンピューティングのスケーラビリティは格段に向上する。しかし、経済的な問題はついてまわる。１社で大規模な複数のデータセンタを配置し、高速な回線を占有できる会社は限られているから、ここでも放置すれば寡占化が進んでしまう。独立系のデータセンタ事業者は、そろそろこれに対抗する策を真剣に考えないと生き残りが難しくなってくるかもしれないと思う。Ｇｏｏｇｌｅの例を見れば明らかなように、大規模化と負荷の平準化によるハードウエアリソースの削減は低価格化を促すからだ。タイムゾーンが重なる日本でも、多くの異なる業種のユーザを共存させることで、ある程度の平準化は可能だろう。したがって、そのようなことができる一定規模以上のファシリティを用意できない事業者は価格競争に勝てない可能性が高いのである。

（続く）

なんとなくネガティブな響きがするが、決してクラウド全般が儲からない、といっているわけではない。現に、大手はかなり利益を上げる商売をしている。問題は、これのまともに太刀打ちしても儲けにならないという点だ。では、どうやって利益を享受していくのか、このあたりは今のところビジネスモデルとからんで、私の会社の企業秘密でもあるから、書くのは最後にしておくことにしよう。

ここで、世の中でクラウドと呼ばれているものを、ちょっと整理してみる。

まずは、漠としたクラウドコンピューティングの広義の意味だ。「クラウド」つまりは、ネットワークの模式図に書かれる雲のマーク。広域通信網、多くの場合はインターネットを意味する絵柄である。つまりは、インターネットを使ってコンピュータリソースを共有し、効率よく、低価格の情報処理を行おう、ということだ。

たとえば、インターネットを使ったグリッドコンピューティング、皆さんご存じの Seti@homeに代表される、大規模な計算を分割してネット上に分散して、大量のＰＣを使って高速に計算しようという、いわばクラウドスパコンなども、クラウドコンピューティングだと言えるだろう。また、悪名ばかりが広まってしまったＰ２Ｐ技術は、こうしたグリッドの基盤になる技術であると同時にデータ共有、分散処理の基盤にもなりうる。実際、最近のＰＣグリッドはＰ２Ｐ技術の基盤の上に作られているものも多い。私は、これらの技術が本来のクラウドコンピューティングの最下層の基盤だろうと思っている。今のところ、これらはまだ不完全だが、よりリアルタイムに最適化された分散処理が可能になれば、クラウドの可能性は格段に広がるはずだ。

しかし、こうして多数のコンピュータリソースを統合することが出来ても、大量のデータ解析やシミュレーションのような用途以外では、そこまで大規模な計算能力を必要としない。そこで、リソースをうまく配分して、個々の処理、またはＯＳ環境に振り分けるための処理レイヤ、つまり仮想化ハイパーバイザが必要になる。今のところ、世間ではこのレイヤがクラウドの最下層だと認識されているが、本来ならばこの下に分散リソースの管理レイヤが存在するはずだ。現在の仮想化ハイパーバイザはきわめて限定的な形で、このレイヤを一部サポートしているが、完全ではない。

ともあれ、なぜ、クラウドに仮想化が必須なのか、それは、そのうえで動く環境に意識されない形で、各種のリソースを制御し、配分する必要があるからである。

（続く）

２．混沌とした「雲」

「クラウドコンピューティング」が言われて久しいが、最初は比較的形がはっきりしていた「雲」は、どんどん広がって、いまや空一面を覆い尽くして、形も、その先にあるものもよく見えない。ベンダ側は都合よく整理をしているのだが、ユーザから見ると、それがどのように自分の役に立つのかはわかっても、それを自分たちの情報システムにどう位置づけ、どう使っていくのかという点では、まだ整理がついていないのだろうと思う。

「クラウド」＝「コスト削減」というのが、ユーザ側の入り口だ。コストを下げるのだから、多少は我慢も必要だと思っている・・・、というよりも、経営からの「劇的な」コストダウン要求の前では、そう思わざるを得ないのが実情だと思う。一方、ベンダはいわゆる「パブリッククラウド」だけでは儲からない。大手クラウドベンダのサービスを売るだけでは、ほとんど利益にならない。薄利多売の世界だ。だから、なんとか「付加価値」の名のもとに独自のサービスや仕組みを売ろうとする。しかし、ベースとなる大手クラウドサービスの値段があまりに低いので、それ以上の価格をつけると、それだけでユーザは拒否反応をおこしてしまう。クラウドブームに乗って商売を広げたいが、ユーザにとってのクラウドは「コストダウン」が第一義だから、どう考えても、これまでと同じ投資は得られないし、投資の大半は大手のクラウドサービス事業者に持っていかれてしまう。つまり、リセールモデルは成り立たない。付加価値も安く上げないと売る理由にはならない。つまり、付加価値部分もクラウドサービスとして提供せざるを得ないのだ。

しかし、大手のグローバルなサービス事業者が年間数千億の投資をしているのに比べ、少なくとも日本での事業者が投資できる額は限られている。地理的要因もある。世界を相手にするサービスには大きな利点がある。システムの稼働率を利用者のタイムゾーンに合わせて最適化できるのだ。ひとつのタイムゾーンしかない日本では、利用者のピーク時間帯は集中する傾向にある。毎朝の通勤電車のような状態が、システムにも発生するわけだ。たとば、始業時間直後や終業直前のようなピークに行われる仕事には急ぎのものも多いから、ここでシステムのレスポンスが落ちてしまってはユーザから不満が出る。だから、この負荷にある程度耐えられる規模のシステムを用意するのだが、そうするとピーク以外の時間帯はその半分以下の規模のシステムで十分なほどの負荷でシステムの大半を遊ばせるしかないのだ。これが、設備投資が過大になってしまう理由だ。ある意味、サーバメーカーの思うツボである。故に、価格もあまり下げられない。一方、世界を相手にする場合、ピーク時間帯はかなり分散され、負荷が平準化されるので、相対的なサーバ台数は少なくて済む。うまくやれば日本のピークをさばける程度の能力で世界を相手にできるだろう。そもそも、そういうハンデが、大手事業者と新参者の間にはあるのだ。つまり、張り合うのは無謀であり、新規参入する事業者は、大手を補完するようなサービスで、「コバンザメ」商法に徹するしかなくなるのである。

（続く）