雲の上のリレーショナルデータベース
SQL Azureの提供メニューと価格体系
ここで、まだあまりご存じない方のために、SQL Azureで提供されるメニューと価格体系について、簡単に紹介します。
SQL Azureは当初2つのエディションが提供される予定です。比較的小規模なWebサイトでの利用を想定したWeb Edition（月額$9.99）と、より本格的なリレーショナルデータベースが求められるユースケースを想定したBusiness Edition（月額$99.99）です。主な違いはデータベースサイズの上限で、それぞれ1GB、10GBとなっています。
正式サービス開始以降は、カスタマーポータルからSQL Azureの利用手続きを行うことで、すぐにSQL Serverと互換性の高いリレーショナルデータベースが利用できるようになります。これまでのようなサーバーの構築もインストールもパッチの適用も不要です。
また、月額利用料の中には、SQL ServerやWindows Serverに相当するソフトウエアライセンスだけでなく、サーバー、ストレージ、ネットワーク機器などのハードウエア利用料、サーバーや空調の電気代などデータベースを運用するすべての費用を含んでいます。
唯一、ほかに必要なコストとしてネットワーク帯域への課金があり、1GBあたりの入出力でそれぞれ$0.1、$0.15が加算されますが、過度なデータ入出力をコスト面から抑制するための措置といえます。ストリーミングサイトなどを除く標準的な利用であれば、通常運用時の金額がそれほどかさむものではありません。
手間やコスト面での環境構築の手軽さも確かに魅力的ですが、SQL Azureの最大のメリットは自動運用にあります。
稼働率99.9%のSLAを維持するため、SQL Azureではデータベースのレプリケーションをはじめとする管理作業をクラウドのインフラ上で自動化しています。これにより、データベースの管理に工数を割いてきた技術者はDBA業務から開放され、ほかのタスクに時間を使えるようになります。
しかし、すでにSQL Serverやほかのリレーショナルデータベースを自社運用している方からすると、設定されているデータベースあたりの上限サイズが思いのほか小さいな、と感じる方も少なくないと思いますが、これは小さいデータベースを複数並べて利用するアーキテクチャとなっているためです。
なお、データサイズにはトランザクションログなどの容量は含まれず、純粋にユーザーが利用するデータのみが課金対象となります。
もっと大きなデータベースでなければ情報洪水によるデータ量爆発に耐えられない、という場合には、次回以降で詳細を述べる、Azure Storage Serviceとの併用や使い分けを推奨しています。
マイグレーションには多少の手間がかかりますが、データ容量上限の制約を気にしなくてよいだけでなく、単位容量あたりのコストがSQL Azureと比べ1／60以下であり、バイナリファイルやログなどをこちらに移すだけで大幅にコストを削減できる可能性もあるのです。
SQL Azureにできること≒SQL Server
SQL Azureでは、クラウドのインフラ上にSQL Serverの機能を再現しています。したがって、通常のSQLはもちろん、T-SQLで記載されたプロシージャーを作成、実行することも可能です。
試しにSQL Azureに接続して
> select @@ version
とバージョンを尋ねると、
Microsoft SQL Server 2008 (RTM) - 10.0.9006.81 (X64) Aug 6 2009 12:43:32 Copyright (c) 1988-2008 Microsoft Corporation CloudDB on Windows NT 5.2
という答えが返ってくることからも、SQL Server 2008とほぼ同等の挙動が期待できます。
接続や操作方法については次回で詳しく述べますが、SQL Serverの管理ツールであるSQL Server Management Studio（SSMS）からも、オブジェクトエクスプローラーが表示されないなど若干の制限事項がありながらほぼ通常通り接続、操作することができます。
表面上はオンプレミスで利用するSQL Server 2008と見分けがつきにくいのですが、可用性やマルチテナンシーを自動運用で担保するためのインフラ面は、クラウド的なアーキテクチャで支えられています。
SQL Azureは数百台におよぶサーバー群を束ねたファブリックの上に分散して展開されています。ユーザーが作成したDBは冗長性を持たせるために3つ程度のレプリケーションを作成しますが、これらのDBは別々のサーバーに配置されます。
一見データの管理が複雑になりそうな構成ではありますが、レプリケーションは負荷分散ではなく、あくまで冗長化のためだけに存在しており、データのアクセスはマスターDBを持つノードに対して行うことで複雑性を回避しています。
万が一、プライマリノードに障害が発生した場合、即座にレプリケーションDBを持つホットスタンバイノードからセカンダリを選出してフェイルオーバーすることで可用性を保つことができます。
また、1台の物理サーバーには通常複数のDBが混在していますが、どれか一つのDB処理による負荷が高まった場合、同じサーバーに同居するほかのDBを別ノードに移動することである程度処理性能を保つこともできます。もちろん無限ではありませんが、拡張性においても比較的低コストで実現できる現実的な解を提供しています。
このようなクラウド上のリレーショナルデータベースに対し、同じくクラウド側のWindows Azure上に配置したアプリケーションからアクセスすることも、オンプレミス側に配置したアプリケーションからADO.netやODBCでクラウド上のSQL Azureを利用することもできます。
まさにSQL Serverにアクセスをしていたアプリケーションの接続文字列を書き換えるだけで、SQL Azureに対応させることができるのです。
