年初にクラウド予想2009をやった。これはだれでも容易に予想できる内容ではあるのだが、3ヶ月経った今では、「１）コストダウンは急速に進む」、「４）大手ITベンダはクラウドの大合唱」は言わずもがなとなった。
　コストダウンに関しては、Amazon S3は昨年11月に値下げして以降、一括支払いでさらに値下げ、SimpleDBを使えば6ヶ月間無料になるという話があり、その急激な値下げには驚かされるところとなった。
　「大手ITベンダはクラウドの大合唱」は予想通り自社製品のクラウド化が進んでいる。具体的な中身は、SunによるSun Open Cloud Platformの発表や、国内ではKDDI クラウドサーバサービスの発表があった。またIBMやCISCOなどによる、Open Cloud Manifestoなどの標準化の話も出てきた。
　そして、「５）OracleやMSは自己矛盾には陥らないが苦戦する」予想は、MSがAzureでかなり善戦しそうな感じを受けるもののSDSでの混乱ぶりがニュースとなっており今後どうなっていくか注目である。＜関連＞Azureに思うこと

　概してクラウドはコンサルがミソクソな話をしだしていることもあってバズワード化に拍車がかかっているのは否めないところである。だが、ここでクラウドの特長であるスケーラビリティの観点から話を整理すると重要なポイントが見えてくる。

　先日、ある大手ITベンダーのクラウド製品/サービスの説明があった。そのサービスがスケーラブルかどうかの質問が挙がったが、担当者はスケールアウトはしないがスケールすると答えていた。VM技術はつかうものの必要に応じてハイエンドの製品も使う。これは自社製品を無尽蔵に並べるサービスを提供することを意味していた。まあ、スケールアウトしなければ困るような大規模トランザクションなんてそうないだろうからそれでもいいのだろう。

　しかし、その話とスケールアウトしない話は別である。スケールアウトしないがスケールするというのはコストを無視した考えである。お金にいとめをつけないからクラウドでよろしくなんていう太っ腹な企業は別にして、コンシューマ相手では、このご時勢もあって相当な低価格でないと競争に生き残れないだろう。そして、それはタダ同然のレベルだと思う。

　先日、Google App EngineのJava対応が発表された。これを受けて、makers-hubという試みもはじまっている。「製造業向けネットサービスは無料に出来るんです。」だそうだ。

　こういったなかで生き残れるのは、GoogleやAmazonといった2強と、日本では、はてなぐらいじゃなかろうか。彼らに共通するのは、コモディティサーバを束ねてスケールアウトできる技術をもっているということ、それから、広告モデルという別の収入源をもっていること。コモディティサーバとOSS、広告モデルが競争力の源泉。とにかくお金をかけないでサービスを運用する技術とノウハウは大変なものである。そういう意味で、SQLServerを並べる戦略に転換したMSのAzureの競争力には疑問が残る。その運用コストは決して安くはないだろうから、しばらくは太っ腹を相手にしながら、スケールアウト技術を開発して競争力をつける戦略なのだろう。MSでさえ競争力に疑問が残るのだから他のベンダはなおさら厳しそうである。Open Cloud Manifestoが弱者連合と揶揄されるのはわかる気がする。しかし、新規の顧客開拓は厳しい一方で既存顧客の囲みこみは成功するとは思う。クラウド要求に応えられない大手ITベンダーはもっと苦戦すると思われるので、何かしら出さざるを得ない状況なんだろう。先の担当者が、「GoogleやAmazonとは真っ向勝負する気はない」といっていたのが印象的だった。

【クラウドコンピューティング】 AzureSDSに思うこと

先月MIX09で発表されたAzure SDSが物議をかもしている。実際に参加されたM先生のメールにはこうある。

昨年のPDCでは、まず、Partition Keyを必須とするSDSを提供して、その後に順次、Relational型をサポートをするというロードマップを持っていたのですが、今回は、まったく逆に、最初に、SDSとして、クラウド上のRelationalデータベースを出してから、その後に、Partitionの特徴を追加するというように、大きく路線を修正しました。

たしかに、ホームページにもAzure SDSはSQL Serverをベースにしていると書いてある。

Microsoft® SQL Data Services (SDS) is a cloud-based relational database platform built on SQL Server® technologies.

一方、今までのSDSの中核だったWindows Azure Storageは、ACEモデルの、EntityがProperty BagでKey/ValueベースのTableである。

なぜ２つのアーキテクチャーが存在するのか。ゼータの鼓動。SQL Data Servicesにみるクラウドデータストレージの現実解によれば、次のように説明されている。

誤解を恐れず簡単に説明するならば、Azure Storage Servicesがいわゆるクラウド的なアーキテクチャであり、SDSは従来のRDBMS的なインタフェースを提供する役割を担っている。＜中略＞従来のソフトウェア資産を活かしながら、最終的に完全なクラウド対応でスケーラビリティのメリットを享受するステップとして、SDSを利用したクラウド側の運用に移行できることは、ユーザー企業にとっても、ソフトウェアベンダーにとっても現実的な落としどころではないだろうか。

先生も次のようにおっしゃっている。

概して好意的で歓迎していた人いわく、「今までの資産と開発技術が、そのまま、クラウドで使える」　確かに、Azureのしたたかなところは、そのOn Premiseとの共存や、開発者のスキルの温存といった現実主義にあったわけで、データ・モデルの部分だけが、大きな飛躍を含んでいたわけですので、こうした反応が出てくることは、理解できないわけではありません。

現実主義・・・私はここにMSの文化を強く感じてしまう。ちょっと話がずれてしまうかもしれないが、IBMと繰り広げたOS戦争でも同じことが起きていたように思う。OS2はWin3.1互換モードなどを搭載していたが重いOSにPC側の性能がついていかず敗北した。実はNTもほぼ同じ問題を抱えていたが、Win3.1、Win95などでユーザをつなぎとめつつNTの改善を図り、やっとWin2000で移行に成功したのである。

Windows NT系(wikipediaより抜粋)

しかし、初期のWindowsは見た目はGUIではあったが内部的にはMS-DOSを土台とし、また16ビットのメモリの壁、マルチタスクの不完全さ、ネットワーク機能の欠落など課題が山積していた。
ビル・ゲイツは一から作り直すことを決断し、＜中略＞サブシステムで致命的な問題が起きてもクラッシュと呼ばれるシステム全体の破綻を起こさない、当時のPCで動作するOSとしては画期的なシステムであった。
＜中略＞
当初は重いOSにPC側の性能がついていかず、デスクトップ用の業務用OSの後継にしようというマイクロソフトの目論みは失敗した。
しかし、NT 3.1、NT 3.5に続いて発表した NT 3.51において、時をほぼ同じくしてリリースしたWindows 95をクライアントとしたサーバOSとしての性格を強調するマーケティングを行い、NetWareの牙城であったNOSの市場に足場を確保することに成功した。
バージョンアップを重ねる際にマイクロカーネル概念の一部を放棄してWin32サブシステムやグラフィクス・デバイスドライバの論理層などをカーネル空間に展開してスループットを向上するなど、重いオペレーティングシステムという汚名を払拭する為のいくつもの改修が行われた。
＜中略＞
その後もマイクロソフトはデスクトップ用の業務用OSの後継としても売り込みを図るが、一部のITプロフェッショナルを除いては市場に浸透せず、2000年にリリースしたWindows 2000に於いてようやくデスクトップOSとしても市場に認められることとなった。
Windows 2000が認められたのは、Windows 9xシリーズのプラグアンドプレイやACPI等の電源管理機能、USBへの対応などユーザビリティの高い機能を実装したことと、この頃にはハードウェアの性能がNT系OSの重さを問題としない（つまり重たくない）レベルにまで向上していたことによると考えられる。
Windows 2000は業務用のデスクトップOSとして歓迎されたが、一般家庭向けの市場でNT系OSが普及するのは次のWindows XPまで待つことになる。

　16ビットOSから32ビットOSへの移行は実に10年近くかかっている。このようにアーキテクチャーの変更が伴う移行は長い月日を必要とする。これはクライアントOSに限らずクラウドも同様だと私は思う。

　話を戻して、なぜSQLServerが求められるか。

　ホストを中心としたプロプライエタリな世界を開放してくれたのは、RDBの成功にあったといっても過言ではない。RDB中心のアーキテクチャーは90年代初期のダウンサイジング以降インターネット時代の今に至るまで変わっていない。その間すべてのアプリケーションはRDBを中心に作られている。実はホスト時代のストレージはRDBではなくkey/valueに近いものであったのだが、そこからRDBへのアーキテクチャーの変更が可能だったのは、パラダイムシフトによりUNIXやWindowsといったオープン系OSにまるごと変わってしまったからである。ホストからのデータ移行もそれほど問題にはならなかった。
　
　Azureの事例をみてもわかるように、今後、key/valueへの移行が進むとしても、クラウドデータにおけるUIを担うのはやはりSQLだろうと思う。ACEモデルに限ったことではないがSQLより優れた操作性をもった言語を開発することはとても難しい。またSQLには既存の多くの開発者スキルもある。スケールできるという理由だけでRDBをkey/valueに移行するとは到底思えない。

　となると、内部的なアーキテクチャーはkey/valueでインターフェースがSQLになるのが理想なのだろう。Azure SDSが今後どのように進化していくのか、楽しみである。