マルチテナント・サービスの実現に向けて
Key-Valueストアという選択肢
これまで2回にわたってSQL Azureの特徴を説明してきました。最終回の今回は、SQL Azureが有効なケースを把握するとともに、実際にSQL ServerからSQL Azureへとアプリケーションを移行する手順について解説します。
SQL Azureを利用するにあたっては、別の選択肢として、Azure Storage Servicesを検討することをお勧めします。
Windows Azureプラットフォームは、SQL Azureのほかに、標準で3つのデータストア構造を提供しています。テーブル（Table）、ブロブ（Blob）、キュー（Queue）です。ここでは簡単に、それぞれのデータストア構造の違いを紹介します。
すでに述べてきたように、SQL Azureはクラウド上で稼働しているリレーショナル・データベースで、その挙動はSQL Serverと似通っています。一方、Azure Storage Servicesに含まれるTable、Blob、Queueは、これまで慣れ親しんだデータストアとはその仕組みや特性が異なります。
Blob（画像などバイナリ形式の大容量データを保管する）や、Queue（処理をメッセージで疎結合する際に一般的に使う）については、それほど深く説明する必要はないでしょう。ここでは、クラウドの世界で利用する機会が多いと思われるTableについて簡単に解説します。
Tableは、データの永続化を目的としたKey-Valueストアであり、名前と値をペアにしたプロパティを保存します。プロパティの持ち方に決まったスキーマはなく、異なるスキーマのデータを混在させて保管することもできます。このプロパティをいくつかまとめたエンティティはPartition KeyとRow Keyを持ち、これらのキーの値によって、データは自動的に分散配置されます。
Tableという名称ではありますが、リレーショナル・データベースにおけるテーブルとは概念が大きく異なります。スキーマがなくリレーションも管理しないためJOIN演算ができません。データの整合性もエンティティ単位でしか保証されません。レコードの順番や更新時の参照整合性にセンシティブなアプリケーションでの利用には向きません。
その代わり、データを分散配置するアーキテクチャーによって、配置場所を増やしていくことにより、性能を過度に落とすことなく無限にスケールアウトさせることができます。
※Azure Storage Servicesの詳細は、こちらのホワイトペーパー（http://msdn.microsoft.com/ja-jp/azure/cc994380.aspx）をご覧ください。
クラウドアプリの新規開発か、既存アプリのSaaS化か
図1は、単位容量あたりの価格とデータベース1つあたりの上限サイズ、整合性のクリティカル度などを判定基準に、Windows Azure Platform上でどのデータストアを使うべきかの判断を支援するフローチャートです。最終的に4つの選択肢のいずれかに至る思考プロセスが、最初から大きく2つに分かれていることに注意してください。
データモデルや物理設計に影響を及ぼすアプリケーションの要求設計自体がデータストアの選定において重要なのはもちろんです。ですが、よりシンプルに考えると、今あるアプリケーションをクラウド化したいのか、それとも、これからまったく新規にクラウドのスケーラビリティを前提としたアプリケーションを設計したいのかによって、使うべきデータストアが決まります。
端的に言って、新規にクラウド上で企画／設計／開発するアプリケーションにおいては、SQL Azureを積極的に利用すべきケースは少ないでしょう。クラウドを前提としたアプリケーションは、そもそもデータの整合性に制限があることを前提とし、スケーラビリティを最重視するアーキテクチャー設計を採用することが多いからです。
一方、既存のアプリケーションをPaaS基盤に配置して簡便にSaaS化しようとする場合、SQL Azureを使う機会は多くなるでしょう。この場合、1つあたりのデータベース・サイズの制限によって、WebエディションとBusinessエディションのいずれかを選択することになります。これは、アプリケーション全体でのデータ総量ではなく、データ分割可能な単位の上限となります。
また、将来的に、いったんクラウドに移行／構築したデータストアをオンプレミス（社内設置）に戻す可能性があるのであれば、Azure StorageではなくSQL Azureを選択しておくべきです。Azure Storageで提供されているTableと互換性のあるオンプレミス向けのKey-Valueストアが存在しないからです。
