「SQL Azureって名前も付けてんです」SQL Servicesの名称変更でAzureの鼓動も俄然高まる

ドラクエか、Silverlight3か今日のお題は悩むところだが本業×ガンダムネタで。
ついにキタ。MSZ-006 ゼータガンダムが。クラウドでやりたいことはたくさん
あるかもあるかもしれないが、PaaSの本命はやはりデータベース機能だろう、
と思ってしまうのは、オラクル出身者の性だろうか。

今回名称を変更したMicrosoft SQL Azureは、従来、Azure Services Platformで
Windows Azureの上に５つ並ぶビルディングブロックの一角を占めていた機能群であり、
あわせて先行して開発者向けにプレビューを行っていたSQL Data Services も、
SQL Azureブランドの配下で、SQL Azure Databaseと呼ばれることになった。
すでにご案内の通り、SDS改めSQL Azure Databaseは、実際に使って頂いた開発者からの
フィードバックに基づき、春先に大幅なアーキテクチャ変更を行い、商用サービス開始に
向けて準備を行っている。

多少わかりにくいかもしれないので、Azureに関わるストレージ機能の全体感と
ここに至るまでの流れを説明しておきたい。

まず、Azure上のストレージの仕組みには、大きく分けてWindows Azure Storageと
SQL Azureの２系統がある。Windows Azure Storageは、KeyValueストアとして
実装されているTableや、大容量データ格納用のBLOB、クラウド上でのデータ
受け渡しに利用するQueueの３つからなる。

GoogleのBigTableやAmazonのSimpleDBなどと同じく、スケーラビリティに重きを置いた、
いわゆるクラウドらしいストレージの仕組みである。ただ、KeyValueストアなどは、
注目され始めたのが比較的新しい概念であるため、当然のことながら、そのアクセス
には独特のクセがあり、クラウドに従来のアプリケーションを移行するためには、
データアクセス部分の書き換えが必須となっており、クラウドにアプリを配置する
上での大きな壁となっていた。

対するSQL Azureは、その名の通りSQLが通るリレーショナルデータベースを中心とした
機能群であり、クラウド上にSQL Serverを配置したようなイメージである。従来のように、
関係性を持つテーブルを扱うことができ、当然SQLでのデータ操作が可能である。
したがって、SQL Serverで動くことを前提につくられたアプリケーションであれば、
わずかな変更でクラウド対応させることができる。

という説明ができるようになったのも、実は冒頭で軽く触れた春先のアーキテクチャ
変更後の話なのである。それまでは、SQL Azureの前身であるSQL Data Servicesも、
「SQL」と冠つけておきながら、従来のSQLとの互換性がないACEモデル（Authority、
Container、Entity）という新しい概念を習得し、実装する必要があった。賛否両論
ありながらも、これはこれで美しいデータモデルだったが、開発者が乗り越えなければ
ならないハードルが少し高すぎたのではないかと感じている。

そのような開発者の声に耳を傾け、大幅なアーキテクチャ変更に踏み切れたのは、
商用サービス提供開始時期が決まっている中、かなりのチャレンジであったといえる。

なぜこのリスクをとったかといえば、ビジネス的な要因が大きい。

プラットフォームであるAzure上に、早い段階からできるだけ多くの対応アプリを
展開することが優位に働くことになるため、比較的対応が容易な方法を開発者に
提供することが非常に重要だったのである。

一度SQL互換でアプリをクラウドに配置した後、スケーラビリティやパフォーマンス等の
観点で大幅な改善が必要な機能については、KeyValueストアを使う方式に該当部分だけ
書き換えてゆけばよいのである。まずやってみてから考える、という発想はクラウド風
ではなかろうか。

追って、OracleのCoherenceにあたるようなメモリキャッシュ（開発コード：Velocity）や
クラウド上のリソースを使うことでいかにも処理を効率化できそうなBI分析、レポーティング、
さらに、オンプレミスやデバイスのリソースとデータ同期を行うSyncサービス機能
（開発コード：Huron）といったサブセット群が開発中である。

なかでも、SQL Azure DatabaseとSQL Serverとの対称性は強力だ。システムの初期段階で
とりあえずクラウドではじめてみて、パフォーマンスやデータ保護管理などの観点から
やはり手元にあった方が都合がよい、ということになれば手元のSQL Serverを利用すればよい。
近い将来にはHuronがデータ同期の支援をしてくれるようになるはずだ。

クライアントOSでも、クラウドでも、マイクロソフトの最大の強みは個別機能の優劣ではなく、
その包括性、連続性にある。SOAのWS-*のような標準に則っただけでは業務で安心して
使えるレベルの包括性を実現することは残念ながら難しく、体力のないベンダーには
要求レベルに応じた連続性を持った製品ポートフォリオを持ち続けることは難しい。
そして何より、不確実性が増している状況では、包括性や連続性で担保される自由度を、
お客様が求めていることにある。

クラウドにおいてスケーラブルで可用性が高いことはもはや当然。
構造化データでも、大容量データでも、無限に蓄積し続けたいデータでも、トランザクション
整合性を捨てきれないデータでも、さらに、クラウドにおいてもよし、手元に戻してもよし、
データ同期までも支援するという、あらゆる性質のデータ、ユースケースを受容する柔軟さが、
SQL Azure最大の特徴なのである。

まさに、MSZ-006 Zガンダムと呼ぶに相応しい。
宇宙でも、地上でも、大気圏突入も難なくこなし、格闘戦では高い機動性を発揮しながら、
戦況によってはメガビームランチャーで長距離砲撃も可能な柔軟性の高さこそが名機の証。

SQL Azureが従来のデータベースの固定観念を一掃する日も、そう遠くはないだろう。

---
今日のタイトルはアーガマ艦内モビルスーツデッキにて交わされた、
カミーユとアストナージの会話からの引用だ。

「へぇ、新しいモビルスーツかい？」
「MkIIとディアスに新しい装甲を付け足してみたんです。Zガンダムって名前も付けてんです。」
「さすが、ニュータイプってやつは違うなぁ。」
「そんなの関係ありませんよ。」
「でも、計算は合ってるんだぜ。」
「まぐれですよ。」

このときのデータがアナハイムエレクトロニクスに送られ、長らく課題だった変形機構に、
左右に分かれて回り込むフライングアーマーや、AMBAC支援にもなるテイルバインダー
などの新しい発想が活かされ、MSZ-006が完成することになる。
カミーユがZガンダムの何を設計したのかはこのサイトが詳しい。

今日の投稿が何のことやらさっぱりよくわからなかったという方は、初期の頃の投稿、

アーガマ隊＝Azure Services Platformの全貌

を、理解できるように最低限のZガンダムの背景知識を蓄えると、
このブログをさらに楽しんで頂けると思われる。