Windows Azureエンタープライズアプリケーション開発技法

Windows Azureストレージ・サービスとAppFabric
―― 第2章 Windows Azureプラットフォーム概要 2.3.3/2.3.4 ――

日本マイクロソフト株式会社 コンサルティングサービス統括本部
赤間 信幸
2011/12/12
Page1 Page2

本コーナーは、日経BP社発行の書籍『Windows Azureエンタープライズアプリケーション開発技法』の中から、特にInsider.NET読者に有用だと考えられる章や個所をInsider.NET編集部が選び、同社の許可を得て転載したものです。基本的に元の文章をそのまま転載していますが、レイアウト上の理由などで文章の記述を変更している部分(例:「上の図」など)や、図の位置などを本サイトのデザインに合わせている部分が若干ありますので、ご了承ください。『Windows Azureエンタープライズアプリケーション開発技法』の詳細は「目次情報ページ」や日経BP社のサイトをご覧ください。

ご注意:本記事は、書籍の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどは@ITのそれとは一致しません。あらかじめご了承ください。

2.3.3 Windows Azureストレージサービス

 Windows Azureストレージサービスは、TB級のデータを格納することができる、大規模ストレージサービスである*1

*1 Windows Azureという名を冠しているが、前述のWindows Azureコンピュートサービスとは全くの別物である(すなわち、Windows Azureコンピュートサービスが使っているサーバーとは完全に別のサーバーが使われている。Windows Azureコンピュートサービスの各物理マシンが保有するハードディスクを使っているというわけではない)。

Windows Azureストレージサービスの内部構造

 概念図を図 2-21 に示す。内部的には複数サーバーでデータを分散・冗長化して保持しながらも、外部から見た場合にはあたかも単一の巨大ストレージシステムであるかのように見えるというのが、このWindows Azureストレージサービスの特徴である。SQL Azureデータベースサービスと同様、実際のデータは少なくとも3つのノードに複製格納されているため、1つのサーバーがクラッシュしても、データは生き残ることが可能になっている*2

*2 この3多重複製の仕組みは、同一データセンター内で行われる。執筆時点では、データセンターまたがりの複製(Geo-Replication)はサポートされていない。

図 2-21  Windows Azureストレージサービス

 このWindows Azureストレージサービスと前述のSQL Azureデータベースサービスとで大きく異なるのは、そのデータ容量である。SQL Azureデータベースサービスでは、ある特定のデータベースのデータが、特定のノード(プライマリサーバー)に集中的に保存される(そしてそれが3多重化される)。これに対して、このWindows Azureストレージサービスでは、特定のストレージのデータが、最初から複数の物理ノードに分散格納される(そしてそれが3多重化される)。このため、巨大なデータを保持することができるようになっており、執筆時点では1アカウント当たり100TBまでのデータ保存が可能となっている。半面、複数の物理ノードにデータを分散格納しているため、キー値に基づくデータの一意検索以外の検索は、(複数の物理ノードにまたがる分散検索処理となるため)比較的苦手である。また、JOINなどの高度な加工処理もできない。

Windows Azureストレージサービスの典型的な用途

 Windows Azureストレージサービスの典型的な用途は、各種のログデータの保存である。SQL Azureに比べてデータ容量が大きいこと、また、(SQL Azureもデータベースとしては相当に安価ではあるがそれに比較してもさらに)データ保持コストが安いことがその理由である*3。一方、前述したように、データの高度な検索やJOIN処理などを必要とする業務データは、SQL Azureデータベースサービスに保存しておくのが適切である。このため、実際のシステムでは、図 2-22のように2つのストレージを使い分けてシステムを構築することとなる。

図 2-22  SQL AzureデータベースサービスとWindows Azureストレージサービスの使い分け

*3 大ざっぱな金額感としては、SQL Azureの場合は1GB当たり\873.23/月、ストレージサービスの場合は1GB当たり\13.11/月(執筆時点)。詳細な課金方式については後述。

ストレージへのアクセス(読み書き)

 Windows Azureストレージサービスは、HTTP RESTプロトコルと呼ばれる特殊なHTTPプロトコルを使って、データの読み書きを行うようになっている。

 このHTTP RESTプロトコルを直接取り扱うのは大変だが、幸い、C#やVBなどでアプリケーションを開発する場合には、Windows Azureストレージサービスへアクセスするためのライブラリが用意されている。このため、データ読み書きの実装作業は比較的容易である*4

*4 .NET以外でも、JavaやPHP向けのライブラリがオープンソースで開発されている。

3種類のストレージ

 Windows Azureストレージサービスでは、データの入出力や操作を容易化するため、格納可能なデータ構造を3つに分類し、以下の3種類のストレージを提供している(表 2-6)。

表 2-6  Windows Azureストレージサービスの種類

それぞれのストレージの特徴は以下の通りである。

  • BLOBストレージサービス(図 2-23)
    • 巨大なバイナリファイルの格納に最適化されたストレージシステムである。
    • 典型的には、.wmvファイル、.wavファイル、.jpgファイルなどのマルチメディア系のファイルや、.vhdファイル、.zipファイルなどの巨大なバイナリデータファイルなどを格納するのに利用する。
    • 外部から見ると、あたかも1階層のファイルシステムであるかのように扱える。
    • フォルダーごとにパブリックアクセスを可能とするか否かを設定することができる。パブリックアクセス可能としたフォルダーは、HTTP GETプロトコルで直接ファイルを取得することができるようになる。このため、巨大なファイルの一般配布などにも利用することができる*5 *6
図 2-23  BLOBストレージサービスの構造

*5 さらにこれに加えてCDNを併用し、広帯域でのファイル配布を実現することもできる。
*6 通常の設定(パブリックアクセス不可)の場合には、共有キーを使わないとデータの読み出しができない一方、パブリックアクセスを可とした場合には、逆に誰でもアクセスできるようになり、アクセス制御が一切できなくなる。このため、もしユーザー認証やアクセス制御を行いたい場合には、BLOBストレージの手前にWebロールサーバーを配し、ここでユーザー認証やアクセス制御を行うように設計する必要がある。
  • Tableストレージサービス(図 2-24)
    • プレインオブジェクト*7を分散格納する、Key-Value型ストレージシステムである。
    • 内部のデータ構造は、「複数のお盆に、キーを付けたオブジェクトを分散保持する」形になっている*8
    • データを格納・取得する場合には、PartitionKey(お盆を決めるためのキー)と、RowKey(各お盆の中で一意になるキー)の2つを指定する必要がある。
図 2-24  Tableストレージサービスの構造

*7 プレインオブジェクトとは、値フィールド(プロパティ値)のみを持つように定義されたオブジェクトのこと。図 2 24中のコードで例示したようなクラスのことを指す。構造体クラス、POCO(Javaの場合はPOJO)などと呼ばれることもある。
*8 なお、1つの「お盆」に保存されたデータは、物理的には必ず1つの物理ノード(サーバー)上に保存されるようになっている。
  • Queueストレージサービス(図 2-25)
    • 非常にシンプルなメッセージキューを提供するストレージシステムである。
    • 機能は限定的だが、プログラミングが単純化されているため、サーバー間などでメッセージデータのやり取りを行う際に簡単に利用できる。
    • オンライン処理が主体のWebアプリケーションなどではあまり使われない*9
図 2-25  Queueストレージサービスの構造

*9 本書では紹介の意味を兼ねて採り上げたが、Queueストレージは、BLOB、Tableストレージとは異なり、実際の業務システムではほとんど使われない。理由はいくつかあるが、最も大きな理由は、キューを使ってサーバー間通信を行うと、非同期通信処理の設計・実装が必要になり、開発が大変になるからである。ほとんどのシステムではBLOBストレージとTableストレージしか使わないので、Queueストレージについてはその存在を知っていれば十分である。

Tableストレージに関する注意点

 前述の3つのストレージ構造のうち、Tableストレージについては違和感があるかもしれないので、以下に若干の補足説明を加える。

 Tableストレージは、前述したように、「値を持つオブジェクトを、キーを付けて、複数のお盆に分散格納するストレージ」である。なぜこれが「テーブル」と呼ばれるのかというと、オブジェクトを「行」、各オブジェクトが持つプロパティ値を「列」と捉えると、複数のお盆に分散格納されたデータがあたかもテーブルデータであるかのようにみなせるためである(図 2-26)。

図 2-26  Tableストレージ内のデータを表形式に書き換えてみた場合

 しかしこれはあくまで「モノの例え」に過ぎず、物理的なデータ格納構造は、図 2-26の左側に示すような「お盆のような構造での保存」である。より正確な形で図示すると、図 2-27のようになる。すなわち、「外から見るとテーブルのように見えるが、実態としては複数の物理ノード(サーバー)にデータを分散保持する」形になっている*10

図 2-27  Tableストレージの内部構造

*10 この図には示していないが、さらに各お盆のデータが3多重化されて保持されている。

 このような内部構造になっているため、Tableストレージは名称こそ「テーブル」であるが、いわゆるRDBMSの「テーブル」とは全く異なるものになっている。主な相違点としては、以下のようなポイントが挙げられる。

  • テーブル間にリレーションシップを定義できない
  • JOIN処理ができない
  • トランザクション処理が基本的にできない
  • 任意の列にインデックスを付与することができない
  • 1つのテーブルに、異なる構造のオブジェクトを格納することができる*11
*11 例えば、1つのテーブルに、「Author」オブジェクトと、「Title」オブジェクトといった、異なるオブジェクトを格納することができてしまう(この場合、無理に表形式に書き直すと、「歯抜け」になった表になってしまう。しかし、内部的には別に歯抜け表形式でデータが保存されているわけではない)。

 このことからわかるように、Tableストレージは、RDBMSのテーブルの代替機能として使うべきものではない。あくまでKey-Value型ストレージ(オブジェクトにキーを付けて出し入れする辞書型のストレージ)として利用すべきものである。

Windows Azure Diagnostics(WAD)

 さて、ここで解説したWindows Azureストレージサービスは、各種のログデータの保存に利用するが、この際によく利用するのが、Windows Azure Diagnostics(WAD)と呼ばれる機能である。WADを使うと、Windows Azureコンピュートサービスの各サーバーインスタンスから、各種のログデータ(IISログやパフォーマンスログ、イベントログなど)を、簡単な構成設定のみでストレージサービスに転送することができるようになる。

 大まかな内部動作イメージを図 2-28に示す。Windows Azureコンピュートサービスの各サーバー(Webロールサーバー、Workerロールサーバー、VMロールサーバー)には、WADランタイムがあらかじめ導入されている。このWADランタイムが、各マシン内のログデータを収集し、Windows Azureストレージサービスに転送する。転送の内容は柔軟に調整することができ、例えばフィルタリング転送やオンデマンド転送などを行うことができる。転送可能なログファイルの種類と、転送先となるストレージの種類を表 2-7に示す。

図 2-28  Windows Azure Diagnostics(WAD)

表 2-7  Windows Azure Diagnosticsで転送可能なログファイルの種類

 Windows Azureストレージサービスの基本的な説明は以上である。SQL Azureデータベースサービスに業務データを、Windows Azureストレージサービスにログデータを格納する、という基本的な使い分けを押さえていただければ幸いである。

 さて、ここまでに解説した3つのサービス(Windows Azureコンピュートサービス、SQL Azureデータベースサービス、Windows Azureストレージサービス)がWindows Azure Platformにおいて最も基本となるサービスであるが、実際のシステム構築では、さらにいくつかのサービスを利用することが多い。中でも重要なものとして、以下の4つについて解説する。

  • Windows Azure AppFabric
  • Windows Azure Virtual Network
  • Windows Azure Traffic Manager
  • フェデレーション認証

 INDEX
  [書籍転載]Windows Azureエンタープライズアプリケーション開発技法
  Windows Azureストレージ・サービスとAppFabric
  1.Windows Azureストレージ・サービス
    2.Windows Azure AppFabric

インデックス・ページヘ 「Windows Azureエンタープライズアプリケーション開発技法」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間