特集：デビッド・チャペル氏への特設インタビュー クラウドとWindows Azureの“もやもや”解消！ デジタルアドバンテージ　一色 政彦 2009/11/10
Page1 Page2 Page3 Page4

■Windows Azure開発における技術選択に関して

●既存システムをWindows Azureへ移行するときの問題は？

――　既存のアプリケーションをWindows Azureに移行してもコスト削減メリットは得られない可能性があるという話はありましたが、ここでは実際に移行するという話になったとします。例えばSQL Server＋ASP.NETで作られた既存のシステムをSQL Azure＋Windows Azureへ移行するときに、何か難しい問題はありますか？

デビッド　データベースについては、いくつかあります。SQL ServerからSQL Azureへ移行するときの大きな問題は、SQL Azure Databaseのデータベース容量が1GBytesもしくは10GBytes未満に制限されることです。しかしながら、ほとんどのアプリケーションのデータベースは、10GBytesもあれば十分ではないでしょうか。

　また、SQL Serverが持つ、いくつかの機能がサポートされていません。例えばSQL CLRや空間データ型（geography型やgeometry型）などです（※SQL Azure Databaseがサポートしないデータ型についてはこちら（英語）を参照）。

　次にアプリケーション・コードについてですが、ASP.NETで作られたアプリケーションは何の問題もなく動作します。ただし、2点だけ考慮しておく必要があります。

　1つは、「Windows Azure上のアプリケーションは基本的にステートレスでなければならない」ということです。Windows Azureファブリックのロード・バランサ（＝負荷分散装置）はセッション・アフィニティ（＝セッションの関係性維持機能）を使用しません。つまり、ユーザーからのリクエストがすべて同じWebロール・インスタンスに送られることが保証されないということです。

　従って、HTTPクッキー（Cookie）を利用したインプロセス・モード（＝インメモリ）のセッションは利用できません。同様に、インプロセス・モードのSessionオブジェクトも利用できません。*1。Windows Azureでは、スティッキー・セッション（Sticky Session：セッションを維持している間は、固定のWebロール・インスタンスにリクエストを送り届けるロード・バランサの機能）は利用できないのです。

*1 筆者注：インプロセス・モードのSessionオブジェクトが使えない問題を回避するには、Windows Azureストレージを活用してセッション状態を管理するための「AspProviders」とアプリケーション・サンプル「AspProvidersDemo」がWindows Azure SDKに含まれているので、これを活用する。また、SQLServerモードで、つまりSQL Azure上でセッション管理を行うことでも回避できると考えられる（※筆者自身は試していないので、実際にWindows Azure上で正常に動作するかは不明）。

　もう1つは、「Windows Azure上ではログ出力（Logging）するコードの書き方が変わる」ということです*2。

*2 筆者注：Windows Azure上では、例えば次のようなコードでログ出力する。 RoleManager.WriteToLog("Information", "ログ・メッセージをここに。");

　こういった制約はあるものの、あまり恐れる必要はないと思います。これまで多くの企業に既存アプリケーションのWindows Azureへの移行について講演してきましたが、それらの企業のすべてがまったく同じことをいっていました。「想像していたより簡単だった」と。

――　例えばASP.NET 2.0で導入されたメンバシップ・フレームワークのプロファイル機能（＝ユーザー情報とログインを管理する機能）を使っている場合は、移行が難しいのではないでしょうか？

デビッド　いいえ、難しくはないでしょう。なぜなら、SQL Serverと同じ仕様のSQL Azure Databaseが使えますので、ASP.NETプロファイル機能は難なく使えるはずです。また、SQL Azure Databaseでユーザーとパスワードを独自に管理することもできます*3。

*3 筆者注：ちなみに、ASP.NETプロファイル機能を（SQL Azure Databaseではなく）Windows Azureテーブル・ストレージで利用するためのライブラリ・サンプル「AspProviders」とアプリケーション・サンプル「AspProvidersDemo」（＝前述したものと同じ）がWindows Azure SDKに含まれている。

――　SQL ServerからSQL Azureへ移行する際、既存のデータはどうやって移行すればよいのでしょうか？

デビッド　SQL ServerからSQL Azureにデータを移すだけならとても簡単です。SQL Azure Databaseはクラウドの中にあるSQL Serverですので、オンプレミスのSQL Server間のデータ移行ツール（例えばBulk Copyツール：BCPユーティリティ）が、まったくそのまま使えます。

　しかし、SQL ServerからWindows Azureテーブル・ストレージにデータを移すのであれば、移行するためのコードを自分自身で書く作業が必要になるなど、より複雑です。

――　Oracle Databaseを使っている場合は、どうなのでしょうか？

デビッド　オンプレミスでOracle DatabaseからSQL Serverにデータを移行する場合はどうでしょうか？ 恐らくSSIS（SQL Server Integration Services）というSQL Server付属のデータ変換ツールを使いますよね。オンプレミスで使うSSISが、やはり、まったくそのまま使えます。

●RDBとKVSのどちらを使えばよいのか？

――　RDB（リレーショナル・データベース）とKVS（Key-Valueストア）、つまりSQL Azure DatabaseとWindows Azureテーブル・ストレージ（以下、テーブル）は、どちらを使えばよいのでしょうか？ 使い分けの基準はありますか？

デビッド　まず、テーブルではなく、Windows Azureブロブ・ストレージ（以下、ブロブ）を選択する基準は明快です。大容量のファイルやバイナリ・データを格納したい場合は、ブロブが最適です。

　しかし、「SQL Azure Databaseを使うか？」「テーブルを使うか？」を決定するには、3つほど検討項目があります。

　1つ目が機能性です。SQL Azure Databaseは、クエリ、スキーマなどSQL全般の機能が使えます。一方、テーブルには、スキーマ機能はなく、クエリ言語も極めてシンプル、JOIN句による結合も行えません。このように両者には機能性に大きな違いがあります。

　2つ目はスケーラビリティです。SQL Azure Databaseには、1GBytes、10GBytesという容量制限があり、つまりスケーラビリティに限界があります。テーブルでは、単一のテーブルでテラ・バイト（TBytes）級の格納が可能です。非常に高いスケーラビリティが必要とされる場面では、テーブルが最適です。

　3つ目は価格です。テーブルは前述したように、ギガ・バイト（GBytes）単位で月たったの0.15米ドル（＝15セント）と、非常に安価です。一方のSQL Azure Databaseはギガ・バイト（GBytes）単位で月に9.99米ドルです。両者の価格差はとても大きい（66.6倍）のです。

――　テーブルがこれだけ安くなっているのは、マイクロソフトが「テーブルを使ってほしい」と考えているからでしょうか？

デビッド　そんなふうには思いません。考えるに、テーブルやブロブの機能性は、データベースというよりも、ファイル・システムに近い。それに対し、SQL Azure Databaseはまさしくデータベースです。ファイル・システムとデータベースには、大きな違いがあります。だからこそ、価格がここまで違うのでしょう。

――　SQL Azure Databaseは10GBytesまでに容量が制限されていますが、将来的にその容量はもっと増えていく予定なのでしょうか？

デビッド　あくまでわたしの意見で、マイクロソフトによる公式見解ではありませんが、将来的にはより増えていくと思っています。SQL Azureを構築した製品チームと以前に話したことがあるのですが、今回はSQL Azure Database初版ということもあり、用心しながら、保守的に、注意深く、容量制限を決めたとのことです。初版でのこの容量制限は、スケール可能で信頼性が高いデータ・ストアを、すべての顧客に対して提供できるようするためのものです。この容量制限が将来的に増えなかったとしたら、逆にわたしはものすごく驚きます。

　……。でも実際にはわたしには分かりません。行方を見守りましょう。

平野　SQL Azureに関しては、日本の企業の間でも注目度が高いと感じています。10GBytesの容量制限を超えてしまうことが予想される場合には、いままでSQL Serverに格納していたデータの中で、例えば仕訳伝票のようなマスタ・データ（＝基本データ）はテーブルやブロブに格納し、そのトランザクション・データ（＝マスタ・データを集計・加工した後の集合データ）だけをSQL Azure Databaseに格納するという方法で、SQL Azure Databaseのデータベース容量を圧縮できるのではないかと考えています。

――　両者のメリット、デメリットなどは理解しました。ですが、やはり業務アプリケーションでは、テーブルではなく、SQL Azure Databaseが使われるのではないでしょうか？

デビッド　これについても分かりません。これまで多くの人と話した経験では、一般的な開発者はRDBやSQL言語に慣れていますから、みんなどちらかというとSQL Azureを使う方向だと話していました。もしSQL Azure Databaseに10GBytesの制限がなく、安かったなら、やはり誰もがSQL Azure Databaseを使いますよね。

　しかしながら、SQL Azure Database初版時点では容量制限と高価格というマイナス面もあるので、いくつかの分野ではテーブルの方が魅力的なことは間違いありません。実際にビジネス領域でどちらが使われていくのかは、その行方を見守るしかないでしょう。わたしが好き勝手に予言するなら、5年後には、ほとんどの業務アプリケーションが（テーブルよりも）SQL Azureを使っているのかもしれません。本当にそうなるかは分かりませんが。

INDEX
	[特集] デビッド・チャペル氏への特設インタビュー
	クラウドとWindows Azureの“もやもや”解消！
	1．クラウド時代は来るのか？／Windows Azureの経済的なメリットは？
	2．Windows Azure向きアプリとは？／米国事情は？／IT Proは仕事を失う？
	3．既存システム移行時の問題は？／RDBか？ Key-Valueストアか？
	4．SOAPか？ RESTか？／MapReduceは必要なのか？／開発者へのアドバイス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）