このページの本文へ

Windows Azureでクラウドをはじめよう 第4回

分散処理のための技術とは?

開発時に覚えておきたい「ストレージサービス」の仕組み

2011年04月27日 06時00分更新

文● 塩田紳二

  • この記事をはてなブックマークに追加
  • 本文印刷

前回は、アプリケーションの実行環境である3つのロールを紹介した。続いては、Azure Platformの仕組みを解説する最後として、ストレージサービスについて詳しく解説する。

分散機能を重視するストレージサービス

 第1回でも触れたが、Windows Azureのストレージサービスには、BLOB(Binary Large OBject)とテーブル、キューという大きく3つのデータ構造がある。すべてのデータは、URLで指定が可能で、HTTP/HTTPSによりアクセスが可能だ。このうち、BLOBは単純にバイナリデータを保持するもので、PCでいうファイルとして扱える。このBLOBに関してはCDNにより自動的に分散キャッシングが行なわれる。

 テーブルは、複数の情報を行とし、これを複数まとめたものを扱う機能だ。たとえば、顧客の名前や住所などを記録する顧客情報などを格納するような場合に利用する。1つの情報はプロパティとよばれ、「名前」と「値」の組みになっている。これを複数まとめたものが「エンティティ」(いわゆる「行」)だ。テーブル内では各行の構造が同じである必要はなく、エンティティごとに異なるプロパティを持っていてもかまわない(図1)。たとえば、ある顧客を表わすエンティティには、“電話番号のプロパティ”があってもいいが、他のエンティティには“電話番号のプロパティ”がなくてもかまわない。

図1 ストレージサービスのテーブルの仕組み

 プロパティで扱う値には、文字列、日付時刻、整数、バイナリデータ(64KB以下)などのタイプがある。プロパティは、エンティティ内でユニークな名前と、このデータタイプと値を保持する。また、他のエンティティでは、同じプロパティ名が他のデータタイプを持っていてもかまわない。

 テーブルには、パーティションとよばれるシステム標準のプロパティがある。テーブルデータへのアクセス頻度が高くなると、Windows Azureは、このパーティションプロパティの値を使ってテーブルを扱うVMを複数に分散させる。これにより、テーブルへのアクセスが集中し、処理のボトルネックになることを防いでいる(図2)。

図2 VMを分散させるパーティション

 パーティションプロパティの値はユーザーが自由に設定でき、任意の文字列が利用できる。たとえば、前出の顧客情報の場合、顧客IDなどをパーティションプロパティに設定することで、複数顧客に対する処理を複数のプロセスで平行処理できるようになる。

 キューは、WebロールからWorkerロールへの処理を開始させるものとして使われる(図3)。Webロールがキューに「メッセージ」をポストし、Workerロールはキューから新しいメッセージを取り出して処理を行なう。この時、処理中のメッセージを他のWorkerロールインスタンスから隠すために、有効期間を指定して、メッセージを不可視状態にする。

図3 ストレージサービスのキューの仕組み

 有効期間が指定されるのは、Workerロールが処理を正常に実行できず、終了処理もきちんとできなかった場合を想定してのことだ(図4)。指定された時間が終了すると、メッセージは再び他のWorkerロールから見えるようになり、他のインスタンスが再処理できるようになる。Workerロールは処理を正常に行なったら、キューから処理したメッセージを削除する。なお、メッセージの大きさは8KBで、最大でも1週間しか保存されない。大きなデータを扱う場合には、BLOBやTableを使い、そのアクセス用URLをメッセージに格納しておく。

図4 キューの有効期限

カテゴリートップへ

この連載の記事
ピックアップ