SQL Azureを見極める第1回

SQL　Azure初期リリースにおける制限事項

　ここまでの説明の中で、「ほぼ同等の挙動」「無限ではありませんが」「若干の制限事項がありながら」といった言い回しがあり、お気づきの方も多いと思いますが、初期リリースのSQL Azureにおいてはいくつかの制限事項が存在しています。

　技術の限界や特性を知った上でうまく使いこなす能力はクラウド時代においても引き続きエンジニアに求められる普遍的な素養です。

　アプリケーション開発の観点で大きな制約の一つはCLR（Common Language Runtime：共通言語ランライム）がサポートされていない点です。使い慣れたC#やVisual Basicでのストアドプロシージャーなどのデータベース開発ができないのは残念ですが、これは将来のロードマップで対応が予定されています。

　もう一つ大きな制限事項となるのが、分散トランザクションおよび分散クエリがサポートされない点です。

　各エディションのDBサイズの上限が1GB／10GBに制限されているため、複数のDBにまたがったデータ配置をとらざるを得ないケースも想定されますが、初期版ではSQL Azure自身の機能として分散環境に対応していないため、アーキテクチャ設計でうまくデータ分割できるよう工夫した上で、アプリケーション側で複数DBへの制御を行う必要があります。

　DBの最大容量をもっと増やせないのかという要望もよく聞きますが、可用性の確保と自動管理による低コストを優先し、常に3つ程度のレプリケーションで同期をとりながら変更管理されていることから、1TBを超えるような巨大なDBをサポートするのは難しいといえます。

　この点においても、分散トランザクションと分散クエリが将来対応される予定であることおよび上位版のBusiness Editionでは、DBの自動拡張機能も提供されていくことになります。

制約の回避方法と今後のロードマップ

　初期リリースで注意すべき制限事項がいくつかある点はご理解いただけたと思いますが、すでに計画済みの対応策を含め、最後にSQL Azureに関するロードマップについて説明します。

　まず、SQL Serverで先行して機能強化が進んでいるBIやレポーティングなどの機能は今後の機能追加の中で提供されていく予定です。

　分散DBへの対応予定はすでに述べた通りで、SQL Serverとの互換性、および整合性や可用性を重視する現在のアーキテクチャにおいて、汎用的かつ無限のスケーラビリティを確保することは難しいと思われますが、分散クエリと分散トランザクションが将来的に提供されることで、ある程度大規模DBにおけるスケーラビリティ制約の改善が見込まれます。

　さらに、今後のロードマップでは、開発コードネームVelocityという分散メモリキャッシュの提供が予定されています。

　データの読み書きが非常に高速なこの分散メモリキャッシュをフロントに、小分けにしたDB群をバックに配置することで、分散データベース環境における拡張性と整合性、スループットをバランスよく高めることができるようになります。

　Velocityの詳細な仕様、提供時期などについてはまだ発表できる段階にありませんが、マイクロソフトもSQL Azureにおける大規模DB対応に向けて準備を進めている過程にある点をご理解ください。

　もう一つ、クラウド上のSQL Azureを利用する上で、アーキテクチャ設計に大きな自由度をもたらすと期待されているのが開発コード「Huron」と呼ばれるデータ同期サービスです。

　オンプレミスのSQL Serverとクラウド上のSQL Azureの間でHuronがデータ同期を行うことで、クラウドとオンプレミスの利点を組み合わせるマイクロソフトのソフトウエア＋サービス戦略が構造化データ管理の面においても実現されることになります。ユーザーやアプリケーションは裏側でデータがクラウドにあるかどうかを気にすることもありません。

　以上、SQL Azureについて概念的な概要を解説してきました。

　次回はSQL Azureを実際にさわってみる過程を解説し、より理解を深めていただければと思います。