評価してください: 

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

2. Windows Azure Table の検証 ~ 目的 ~

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

目次

検証プログラムの概要
パフォーマンス検証の考慮点

※この内容は 2011 年 4 月時点での情報を元に執筆されたものです。


このようなストレージの特徴と踏まえてアプリケーション設計を行うために、Windows Azure Table が実際にどのような特性を示すのか検証しました。
今回の検証の想定アプリケーションは、オンライン Web サービスのリアルタイム処理系を Windows Azure コンピューティング で構築し、その中で永続データの保存先として Windows Azure Table を利用しています。


図 3: 想定アプリケーションとテスト範囲

今回は、Windows Azure コンピューティングの Web Role インスタンスから Windows Azure Table へのアクセスのパフォーマンスをテストします。そのために、Windows Azure Table にアクセスする Web Role インスタンス を測定用のアプリケーションとして作成しています。

ページのトップへ


検証プログラムの概要

検証プログラムでは、下記のようなエンティティを使いました。
プロパティに文字列をセットしてエンティティのサイズを変更し、エンティティ サイズ変更によるパフォーマンスへの影響を見ました


図 4: エンティティ 5

単一スレッドの場合は foreach、複数スレッドの場合は Parallel.ForEach でループ処理を行い、スレッドの並列性は ParallelOptions.MaxDegreeOfParallelism で指定します。


図 5: メイン ループ 6
5 Entity (英語)
6 main loop (英語)

ページのトップへ


パフォーマンス検証の考慮点

実際のアプリケーションからの利用を想定し、Windows Azure Table への アクセスには、Windows Azure Storage Client Library を使います 7

Windows Azure Storage Client Library は、WCF Data Services の上に構築されており、TableServiceContext の実装のほとんどは、System.Data.Services.Client の DataServiceContext にあります。Windows Azure Storage Client Library は、SaveChanges() のリトライ版である “SaveChangesWithRetries()” や、ストレージ アカウント、署名生成などが実装されているだけの、ユーティリティ ライブラリとなっています。

Windows Azure Table の利用にあたっては、マニュアルの System.Data.Services.Client 関連を読んでおくと役に立ちます。


図 6: API の階層構造

Windows Azure Table 自体は非常に単純なものですが、利用にあたっていくつか気をつけることがあります。

1DataServiceContext は、スレッド セーフではありません。マルチ スレッドの場合は、スレッドごとに別のインスタンスを用意する必要があります。
今回は、スレッドと処理毎に DataServiceContext を作成しています。
2DataServiceContext は、エンティティの追跡 (track、cache) をする機能があります。
大量のデータを同一 DataServiceContext で処理する場合は、MergeOption を NoTracking にするなどの工夫が必要です。今回は、処理毎に DataServiceContext を作成しているので、既定 (AppendOnly) のまま使います。DataServiceContext の寿命を長くすると、追跡されるエンティティの管理が難しくなるので、DataServiceContext の寿命を短くすることを推奨します。
3TableServiceContext には、リトライ付きの SaveChangesWithRetries() があります。Windows Azure Table の処理は、ノードのフェイルオーバー、ロード バランシングなどいくつかの要因で失敗することがあります。ほとんどの場合、リトライすることで成功します。自前のリトライ処理を実装したい場合以外は、xxxxWithRetries 版を利用することを推奨します。
4

.NET の HTTP connection の数は既定で 2 です。今回は、十分大きな値に設定しました。

ServicePointManager.DefaultConnectionLimit = 1024;

5

.NET では、POST/PUT リクエストを送るときに、“Expect:100-continue” HTTP ヘッダーを付けます。サーバーは、このヘッダー付きのリクエストを受け取とると、リクエストが受付可能ならば、HTTP ステータス コード 100 (Continue) のレスポンスを返します。クライアントは、このレスポンスを受け取ったらペイロードを送ります。このような動きになるため、”Expect:100-continue” を HTTP ヘッダーに付けると、ターンアラウンドが 1 回増えて、パフォーマンスに悪影響があります。次のコードで、このヘッダーを付けないようにします。

ServicePointManager.Expect100Continue = false;

6

.NET では、TCP/IP 通信の Nagle アルゴリズムが既定で有効になっています。この設定は、レイテンシーの小さいネットワーク環境ではパフォーマンス劣化を引き起こす場合があることが知られています。次のコードで、Nagle アルゴリズムを無効にします。

ServicePointManager.UseNagleAlgorithm = false;

7純粋に Windows Azure Table の性能を測るためだけには Windows Azure Storage Client Library は少々重いようです。ですが、実際のアプリケーションでは本ライブラリを利用するので、今回はこのライブラリを使っています。

ページのトップへ