この連載「はじめてのWindows Azure」は、ひとまず今回で最終回としたい。最終回は、Windows AzureのストレージとCDNを取り上げる。
Webロールから永続データを扱いたいときに、SQL Azureを利用することには疑問はないだろう。だが、保存するデータが画像や動画といった容量の大きなファイルならRDBは適さない。そこで、データの保存先としてWindows Azureストレージを使うという方法がある。さらに、Windows Azure CDNを有効にすると、ストレージに保存したコンテンツを効率よく世界中に配信することが可能になる。今回は、この2つのサービスについて確認してみよう。
Windows Azureストレージには4種類のサービスを用意
クラウドにおけるストレージサービスで、重要になるのが「可用性」だろう。単にファイルをインターネット経由で取得したければ、自前のNASを構築すれば安価だし「拡張性」に制限もない。しかし、停電やシステムトラブルに対して、管理者自らが対応しなければならないし、セキュリティの問題もある。
Windows Azureストレージなら、単にデータを保存するだけに利用できるし、他のAzureのサービスとも連携できる。特にWebロールやWorkerロールとSQL Azureを利用している場合、Windows Azure ストレージを安価なデータ保存先として組み合わせることで、料金を節約しながら大容量データを扱うことが可能になる。
Windows Azureストレージは、Windows Azure Platformの中では、ホスティング環境などと同じWindows Azureのカテゴリに属する（図1）。このストレージアカウントを取得することで、「ブロブ」「テーブル」「キュー」「ドライブ」の4種類のストレージサービスを利用できる。まずは、この4種類のストレージサービスの特徴を簡単に解説しておこう。
最初の「ブロブ」は、Binary Large OBjectを意味する。つまり、画像や動画といった大容量のバイナリデータを格納するために最適化されたストレージだ。2011年12月現在、1ブロブ当たり最大1Tバイトまで保存できる。
「テーブル」は、表形式でデータを格納するストレージだ。ただし、SQL AzureのようなRDBの「テーブル」とは構造が異なる点に注意が必要だ。
クラウドでは、大きなデータを「分散キーバリューストア」で扱うことが多い。分散キーバリューストア（KVS）とは、「キー（Key）」と「値（Value）」のペアでデータを管理するストレージのことで、巨大な連想配列（HashMap）のようなものと考えれば理解しやすいだろう。RDBでいうところの「レコード」は「エンティティ」と呼ばれ、1エンティティあたり1Mバイトまで利用できる。
「テーブル」はシンプルな構造ゆえに、分散化や高可用性の実現に適している。だが、テーブル同士の結合や複雑な検索、集計、トランザクション管理などは、自分でプログラムしなければならない。
「キュー」は、プログラム間のメッセージデータの受け渡しに利用される。1メッセージ当たり8Kバイトまで利用可能だ。主に、WebロールとWorkerロール間でのデータの受け渡しに、このキューを利用することで、処理を非同期にすることができる。
最後の「ドライブ」は、仮想的なNTFSボリュームとして機能する。Windows Azureストレージのブロブを利用する場合、専用のAPIでデータのアップロードやダウンロードを行う。これを「ドライブ」ストレージをマウントすることで、アプリケーションからはローカルなファイルシステムと同じ手法でアクセスできるようになる。これで従来のアプリケーションを、最小限のコード変更でクラウドに移行することが可能になる。
