【MIX特集】Azure Storage ServiceとSQL Servicesのツンデレキャラ確定

Silverlight3が中心ではあったが、Azure関連では新しい発表が大きく２つあった。
１つはPHPコードへの対応で、もうひとつがSQL Servicesのアーキテクチャ変更である。

SQL ServicesはMIX前に開発チームのブログで公表されたように、プレビュー版での
フィードバックを元に大きくアーキテクチャを変更することになった。
既存のホスティング環境や御プレミスで稼働するソフトウェアをすでに保有している場合、
「いかに簡単にAzureにのせられるか？」がポイントになる。

反対に、マイクロソフトとしても、クライアントやサーバー側のWindows OSと同じように
自社プラットフォームの上で動くアプリケーションを豊富に取りそろえることを重視しており、
Azureでも同じようなエコシステムを早期に立ち上げたいという思いもある。

最初のバージョンで提供されるSQL Servicesはいってみれば、SQL Serverをクラウド側に
もってきて、その管理・運用の自動化をマイクロソフトが引き受けるサービスとして
展開されることになる。したがって、SQL Serverに対応したアプリケーションであれば、
クラウド用に変更することなくそのまま動作する。互換性の程度は商用サービス開始までに
詳細が通知されることになるだろうが、初期バージョンで制約となる分散トランザクション
のような処理を組み込んでいない限り、問題になることはないだろう。

ある意味、利用者に対して「デレ」なバリュープロポジションをとったといえる。
トレードオフとなるのはクラウドで語られる無限に近い拡張性だが、クラウド黎明期の
現段階では十分な拡張性かもしれない。

ただ、それならAmazon EC2でSQL Serverを動かすのと何が違うのかわからない、
という方はセッション資料の中にもある下図をみてほしい。この図の右上がオンプレミス
左下がSQL Services、真ん中がAmazon EC2や既存ホスティング環境のSQL Serverである。

そして「ツン」なAzure Storage Serviceの存在も忘れてはならない。
上図でいうならば、さらに左下にあたる。
こちらは拡張性の高いKeyValue形式のTableやQueueなどクラウドっぽいストレージ環境を
用意しているが、インタフェースも含めてクラウド風？なREST対応にしてあるため、
既存のアプリから利用するためにはデータアクセス部分を書き換える必要がある。
本格的に拡張させたくなったら、こちらに乗り換えればよいだけなのである。

なぜクラウド環境に似たようなストレージの仕組みを２つも用意する必要があるのだろうか？
その答えは既存アプリ資産の現実的なクラウド対応シナリオにある。

第一段階でクラウド対応（最小の工数で運用自動化のメリットを手に入れる）し、
第二段階でストレージの最適化（クラウドらしい拡張性の高いアプリにチューンする）する
シナリオがビシッとハマるツンデレコンビをそろえているのだ。

しかも、爆発的にヒットするかどうかわからない状態から、拡張性を保証したインフラを利用し、
アプリを書き換える工数や時間を費やすのはあまり賢い選択ではないのかもしれない。
本格的な対応をすべきかどうか、という選択オプションを後にずらせるこのシナリオは、
しかるべき対価を支払うエンドユーザーにとっても、技術習得も含めた対応工数を確保せざるを
得ないベンダー企業にとっても喜んでいただけるものと考えている。

今回のツンデレ（いや、順序的にはデレツンか）対応を生んだ背景には、
拡張性、可用性、整合性の３連立が困難であるというCAP定理がある。
さらに、重要性が再認識された既存のSQLとの互換性を考慮している。
技術的なチャレンジ精神が旺盛な方には、Azure Storage Serviceを基盤としながら、
SQL互換でのトランザクション処理を可能にするようなミドルウェア、フレームワークを
考えてみていただきたいものである。

ちなみに、MIX09でのセッションは、ほぼすべてストリーミングとPPTXが公開されているので、
是非コチラのサイトから最新情報を入手していただきたい。