Azureストレージの話は、次のURLでの「おすすめコンテンツ」に全て書いてある。AzureストレージのQueueは、WorkerRoleとWebRoleとの通信を行う。ストレージのキューは違うんだ!Queueから取り出したメッセージが正しく処理できなかったら、Queueに戻す辺りは既存のQueueと一緒だがQueueに格納したメッセージは「どういった順番でキューから取ってくるか分からない」、「同じメッセージが二度帰ってくるかもしれない」というのが大きな罠。ストレージ、Blobについて語ってやる!Blobは名前から想像する人間も多いだろうが、バイナリデータの格納を主な役割としているぜ!アカウント⇒コンテナ⇒ブロブ⇒ブロックと言った階層関係を持っているが、アプリケーション開発者が意識するのはブロブまでだ!例えば、私が画廊的なアプリケーションを作成しようとした場合「アカウント(normalian)⇒コンテナ(gallery)⇒ブロブ(ファイル名)」という有様になる!語弊は多々あるが、大凡間違ってない!一回のPUTで格納できるブロブのサイズは64MBだが、ブロブの最大サイズは50GBになっている。見て更新操作の制御を行っている。複数のユーザーが同時に更新しようとしたとしても、片方のユーザが更新した段階で別のユーザは更新できない。AzureストレージのTableはKey-Value-Storeだ!だまされてはいけない!!Tableの用途としてデータの永続化はもちろんだが、一番肝となるのはユーザのセッションデータを格納する処理だ!!WindowsAzureがRoleのインスタンス数を可変にする事でスケーラビリティを提供しているのはご存知かと思うが、Sessionオブジェクトはインスタンス毎になる。AzureストレージTableには特異なプロパティが複数存在するRowKeyとPartitionKeyだ!!(Timestamp等のプロパティも別途有るが、ここでは含めないここで一瞬だけRDBでのテーブル設計を思い起こして欲しいのだが、テーブルにとって重要なプロパティが複数存在する事が有ると思う重要なプロパティが一つ⇒PartitionKeyのみ設定、二つ⇒PartionKey+RowKeyを設定、それ以上⇒PartionKeyに一つ目、RowKeyに複数格納("_"等でアプリ開発者が分割して入れる必要がある)上記の様に設計して欲しいのだが、その主な理由はPartionKeyがスケールアウトのカギを握っているからだ!データはPartitionKeyに応じて分割され、永続化データとして格納される。PartitionKeyの設計を誤ると「クラウドだからスケールアウトするよね〜♪」と能天気に言えなくなるぞ!次にRowKeyの説明をする事をサボる事は出来ない。ストレージのTableを使う場合に避けては通れない道だ!RowKeyに対する説明を一言でするなら、永続化データが格納される順番を教えるキーとでも言えば良いのだろうかTableのデータはParitionKeyによって分割され、RowKeyによって辞書順に並びかえられて格納される。