マルチテナント・サービスの実現に向けて

Key-Valueストアという選択肢 これまで2回にわたってSQL Azureの特徴を説明してきました。最終回の今回は、SQL Azureが有効なケースを把握するとともに、実際にSQL ServerからSQL Azureへとアプリケーションを移行する手順について解説します。

砂金 信一郎

2009年10月26日 20:00

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ストアが存在しないからです。

この記事のキーワード :

人気記事トップ10

人気記事ランキングをもっと見る

企画広告も役立つ情報バッチリ! Sponsored

ClickHouse Cloudが実現した広告運用SaaS「ATOM」のデータ基盤革新、パフォーマンスを向上しながら、運用負荷とコストを削減 11月11日 6:20 AIで開発が加速する時代、品質保証はどう変わる? Tricentisが示すAIエージェント活用の実像 11月9日 6:45 悪用までの猶予が「1分」に迫るフロンティアAI時代に開発と本番を貫く脆弱性管理が必要 10月29日 8:30 欧州CRA対応とSBOM運用。AI生成コードのOSS混入問題の対策とは ――スニペット単位で検出する「FossID」「Insignary Clarity」によるSBOM運用 9月16日 6:40 PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望 9月7日 6:30 機能安全開発におけるGoogleTestの活用を支援!「Parasoft C/C++test CT」で実現する効率化&AI連携 4月14日 6:30 【CNDW2025】Grafanaが明かす「オブザーバビリティの哲学」ー最小限の労力で実用的なインサイトを得るには 1月23日 6:30 【CNDW2025】プロダクト急増に備える基盤刷新 ーウェルスナビがECSからEKSへの移行で得た知見とは 1月15日 6:30 【CNDW2025】250環境を5人で運用、構築時間は30分に ーKINTOテクノロジーズが語るインフラ基盤組織の作り方 2025年12月18日 6:30 新たな自動化で熱視線! AIエージェントの「推論能力」を支える2つのコンポーネントとは? 2025年11月28日 6:30