Windows Azure Table の利用 ~ 特性とパフォーマンスの検証

1. Windows Azure Table を使う

更新日:2011 年 9 月 16 日
執筆者:株式会社リード・レックス
近江 武一
高木 俊一

目次

特徴 ~ 導入 ~
特徴 ~ 利用 ~
アーキテクチャー
Windows Azure Table と CAP 定理


ここ数年の間で容易にクラウド コンピューティングを利用できるようになり、システム構築時の検討事項、費用対効果のバランスなど多くのものがドラスティックに変わりつつあります。 特に、現在注目を集めているスマートフォンや SNS 向けのソーシャル ゲームなどのコンシューマー向けのシステムでは、下記の点から考えてもクラウドは最適な方法だと言えます。

スケーラビリティ: 新規のサービスでユーザー数 0 の状態から、短期間 (数ヶ月) で数 100 万のユーザー数になることがあります。そのような規模の急激な増加が起きた場合に迅速な対応が要求されます。
信頼性: これらのシステムは、アイテム課金の処理など一貫性を求められる処理があり、OLTP (オンライン トランザクション処理)が必要な部分を含んでいます。また、低価格なものを大量に販売するモデルであることが多く、システム的なトランザクション単価が安くなければいけません。
可用性: また、ユーザー満足度の観点から、短いダウン タイムで運用されることが要求されます。ハードウェア故障などでサービスが停止することは望ましくありません。

このようなシステムにおいては、高度なスケーラビリティ、信頼性と低単価のトランザクションという目的を果たす必要があります。弊社では従来、トランザクション処理には SQLServer、Oracle、MySQL などの RDBMS (リレーショナル データベース管理システム) を利用してきました。しかし、RDBMS を使ったアプローチで上記の問題を挑むには、いくつか問題がありました。

対応するスケールを数千ユーザーから数 100 万ユーザーという範囲にしようとすると、どうしてもユーザー数の上限をターゲットにした設計となり、結果的には RDBMS の利点が損なわれるようなアーキテクチャー設計となる傾向があります。システムとしては、最初は少ないユーザーから始めるので、ほとんどの仕組みは当初は必要ではありません。クラスター対応の RDBMS と大規模な FC (ファイバー チャネル) ストレージの利用で、RDBMS の利点を生かしたままスケールさせる方法もありますが、運用面、コスト面などで課題があります。このような状況を考えると樹来はスケーラブルなアーキテクチャー設計は非常に難しく、要求されるスケールに合わせてアーキテクチャーを切り替えて段階的にスケールさせることが現実的な方法でした。

そのような状況の中、Windows Azure のような PaaS (Platform as a Service) 型クラウド サービスが、新しい選択肢として登場しました。Windows Azure を使うことで、ソフトウェア アーキテクチャーに一貫性を持たせたまま、数万から数 100 万のユーザーに対してサービスを提供でき、さらに事前に想定ユーザー数に合わせたスケールでテストすることができます。中でも、ストレージのスケーラビリティ問題に対するソリューションとして、Windows Azure Table は魅力的です。Windows Azure Table のトランザクション、スケーラビリティを利用することでスケーラブルなシステムを設計、構築でき、事前に任意のスケールでのテストをすることができます。このことは、Windows Azure を使うことで、スケーラブルで品質が保証された高度なサービスを構築することができることを意味します。クラウドを利用することでテスト可能な領域が広がったのです。

アーキテクチャーの連続性を維持して大きくスケールできること、要求されたスケールに応じたテストが可能なことは、システムの品質を保証し、ビジネス要求に柔軟に対応していくためには非常に重要です。この文書では、我々が商用サービスで Windows Azure Table を利用した経験を元に、その特性、パフォーマンスを紹介します。

ページのトップへ


特徴 ~ 導入 ~

Windows Azure では、4 つのストレージ サービス (SQL Azure Database、Windows Azure Table、Windows Azure Blob、Windows Azure Queue) を提供しています。いずれも、Microsoft 社が Windows Azure データ センター内で運用し、利用者に提供しているものです。
その中で、Windows Azure Table は、スケーラビリティに優れた構造化ストレージ サービスいう位置付けです。スケーラブルなストレージを使いたい場合、機能面だけでなく、インストール、運用、コストなどの非機能要件について配慮することが重要です。Windows Azure Table は、これらすべての面で優れています。

インストール、運用: Windows Azure Table は PaaS として提供されおり、ハードウェアの手配やインストール、運用などを利用者が行う必要はありません。
コスト: Amazon S3 (Simple Storage Service) や Windows Azure Blob などの、クラウド上の非構造化ストレージ サービスと同等な価格で提供されており、非常にリーズナブルです。

ページのトップへ


特徴 ~ 利用 ~

プログラムの観点で Windows Azure Table を見ると、下記のような特徴を持っています。

  1. Open Data Protocol (OData): HTTP、AtomPub (XML のみ、JSON なし)
  2. 分散構造化ストレージ (Distributed Storage System for Structured Data): BigTable、Cassandra の仲間 (NoSQL)
  3. ACID トランザクション
  4. 楽観的ロックによる排他制御

OData

Windows Azure Table は、RESTful API でアクセスするストレージ サービスで、データの読み書きの API は OData プロトコル (英語) に準じています。
このサービスは、特定のプラットフォーム向けのものでなく、Java、PHP など多くのプラットフォームからからアクセスが可能です。Microsoft 社より各種ライブラリや支援ツール (開発環境) が提供されています。
>> Windows Azure and Interoperability (英語)

分散構造化ストレージ

ストレージの大まかな分類では、俗にいう NoSQL (Not Only SQL) の仲間で、スキーマレスな Key/Value ストレージ (KVS) です。


図 1: Windows Azure Table のコンセプト

各データは、キー (PartitionKey、RowKey の 2 つのキー) とValue を持つエンティティとして保存されます。エンティティの参照は、キー (PartitionKey、RowKey の 2 つのキーの組み合わせ) で行います。RowKey は昇順に並んでおり、範囲クエリを利用可能です。Value には 252 個までの任意のプロパティを保持でき、エンティティ毎に異なったプロパティにすることができます。
Windows Azure Table の基本的なアーキテクチャーは 、分散構造化ストレージ (Distributed Storage System for Structured Data) であり、PartitionKey が異なるデータは、別のノードに保存されることがあります。但し、実際のノードとパーティション (同じ PartitionKey を持つエンティティの集合) の関係は、サービス内で自動的に最適化が行われ決定されるため、プログラムで変更することはできません。

ACID トランザクション

同一テーブル、同一パーティションに保存されているデータは、ACID トランザクションの中で作成、更新することができます。複数パーティションにわたるデータを ACID トランザクションに参加させること、つまり分散トランザクションはサポートされていません。(もう少し正確に言うと、パーティションとテーブルが同じ場合にだけ、トランザクションを実行可能です。)

楽観的ロック

同時並行処理を排他制御するためのロック機構として、楽観的ロックを利用できます。Windows Azure Table のサービスとしては、Timestamp と、ETag の自動更新、ETag を使った条件付き更新が提供されています。

ページのトップへ


アーキテクチャー

Windows Azure ストレージを利用する際に参考になるので、(あまり公開された情報はありませんが) そのアーキテクチャーについて簡単に触れます 1。3 種類の Windows Azure ストレージ (Blob、Table、Queue) は、同一のアーキテクチャーとコンセプトの上に構築されています。

1アーキテクチャーは、 Windows Azure Storage Team Blog Windows Azure Storage Architecture Overview (英語) が参考になります。

3 層構造

ストレージは、下記のような 3 つの基本的な層で構成されています。

  1. フロンエンド (FE) レイヤー
    このレイヤーでリクエストを受け付けて、パーティション マップに基づいてパーティション レイヤーのパーティション サーバーにルーティングします。
  2. パーティション レイヤー
    パーティションは 1 つのパーティション サーバーで処理されます (1 つのパーティション サーバーが複数のパーティションを扱うこともあります)。このレイヤーで、パーティションのパーティション サーバーへの割り当てと、パーティションのロード バランシングを管理しています。
  3. 分散複製ファイル システム (Distributed and replicated File System: DFS) レイヤー
    このレイヤーは、データの分散とレプリケーションを行います。すべての DFS サーバーは、すべてのパーティション サーバーからアクセスすることができます。

図 2: Windows Azure ストレージのレイヤー

このような構成から、トランザクション処理やクエリなどは、パーティション サーバーが実行しており、単一パーティション サーバーの処理性能には上限 (スケール限界) があるのではないかと推測されます。スケーラビリティを確保するためには、如何に複数の パーティション サーバーを使って処理させるかが課題となります。レスポンスについては DFS レイヤーの性能の影響が大きいのではないかと予測しています。

2 Azure Storage Architecture Overview - 3 Layer Architecture (英語) より

ページのトップへ

Windows Azure Table と CAP 定理

ストレージの特性を理解する上で重要なので、Windows Azure Table を CAP 定理の側面から考えてみます。 CAP 定理 3 を簡単に説明すると、Consistency (一貫性)、Availability (可用性)、Partition Tolerance (分割耐性) の 3 つを同時に満足するとこはできず、同時には 2 つしか満たせないというものです。これは、スケーラブルなアプリケーションを構築する上で避けることができない問題です。

C. 一貫性 (Consistency)
1 つのエンティティ、並びに同一テーブル、パーテーションのデータのクエリは、スナップショット分離となり、ダーティー リード (uncommitted read) は発生しません。
A. 可用性 (Availability)
Windows Azure Table では、3 つの異なるサーバー/ディスクへ書き込みを行い、障害時はバックアップへ自動フェイルオーバーします。
P. 分割耐性 (Partition Tolerance)
ネットワーク的な分離が起きた場合、該当テーブルでは可用性が失われますが、フェールオーバーされます。また、あるパーティションで起きた障害は、他のパーティションに影響しません。
3 BrewersCapTheorem - ブリュワーの CAP 定理
Brewer's CAP Theorem 原文 (英語)

障害が起きたときの挙動 4

ノード障害が起きたときの挙動は、下記のようになります。

フロントエンド サーバーの障害
フロントエンド サーバーのレスポンスがなくなった場合、ロード バランサーは該当 VIP へリクエストを別の稼働しているサーバーに切り替えます。
パーティション サーバーの障害
ストレージ システムがパーティション サーバーの不在に気がつくと、すぐに別のパーティション サーバーにパーティションを割り当て、フロントエンド サーバーが使うパーティション マップを更新します。注意: パーティション サーバーが変更されても、DFS 内のデータの移動は起こりません。DFS 内のすべてのデータは、どのパーティション サーバーからもアクセスできるので、移動する必要は無いからです。
DFS サーバーの障害
ストレージ システムが DFS サーバーの不在を確認した場合、パーティション レイヤーは不在の間 DFS サーバーの読み書きを一時停止し、代わりに複製されたデータを持っている、他の DFS サーバーを使います。もし DFS サーバーの不在が長期にわたる場合は、健全なレプリケーション数になるようにサーバーを追加します。

CAP 定理の 3 つを同時に満たせないという制約に、上手く対応しています。

Windows Azure Table は、複数セッションからのアクセスがあっても、必ず最新のデータが返され、一貫性 (Consistency) を保ちます。また、同一テーブル、同一パーティションという条件付きで、ACID トランザクションをサポートします。

パーティション サーバーの障害では、一旦可用性 (Availability) を失いエラーを返しますが、このような状態になっても、障害ノードはバックアップに切り替わるのでリトライすれば成功します。DFS サーバーに障害が起きた場合は、代替サーバーに切り替わるまで処理が遅延します。
このような可用性 (Availability) が失われた状態は、パーティション毎に発生し、他のパーティションに影響することはありません。

パーティション、テーブルが異なるデータに関しては、一貫性を持った更新ができません (ACID トランザクションのサポートがありません)。この場合、パーティション、テーブルが異なるデータが別々のノードに保存されるので、ノード障害が起きた場合でも障害ノードにあるデータ以外は、通常通りアクセスできます。

Windows Azure Table は、CAP 定理との折り合いを付けるため、パーティションとテーブルという分割の粒度を設けています。そして、同一テーブル、同一パーティションという条件下では一貫性を保証し、ストレージ全体としては一貫性に制限があるが分割耐性と可用性があるシステムとして振舞うように設計されています。

この特性はトランザクション処理が要求されるアプリケーションの設計に重要で、コンシューマー向けのスケーラビリティが要求されるシステムに良く合っています。なぜならば、コンシューマー向けのシステムでは、各個人のデータ内の整合性が重要であり、各人の間の通信 (メールなど) は、BASE (Basically Available, Soft state, Eventually consistent) 整合性で構いません。サービスとしては、個人の集合に対して可用性が保たれていれば問題はなく、各個人のオペレーションは可用性より一貫性が重要だからです。

4 Windows Azure Storage Architecture Overview - Fault Domains and Server Failures (英語)
ここでは省略していますが、上記文書によると、ハードウェア障害が起きたときに影響を受けるサーバーができるだけ少なくなるように、フォルト ドメインをまたがってサーバーを展開するなどの工夫をしているようです。

ページのトップへ