【クラウドコンピューティング】 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が今後どのように進化していくのか、楽しみである。