Windows  Azure  Table

@takekazuomi  2011/1/26

Scalable  Service  with  Cloud

•  想定ユーザー数１００万～  •  ０から始まって、短期間に数百万に  •  販売したアイテムの管理（＝ＯＬＴＰ系）  •  初期コストを押さえて、スケールに合わせたコスト感でいけるように  

•  Scalable  Service  =>  Windows  Azureを使おう  

Windows  Azureの理由 •  Azure  Tableという大規模分散ストレージサービスがあったから  –  Google  App  Engine  

•  BigTable由来の大規模分散ストレージが使える  •  インスタンス共有で、spin-­‐down/upが評価し辛い（他もろもろ）  

–  Amazon  SimpleDBは、一貫性が弱い  •  2010/2/24  に ConsistentRead  が付いた    hKp://www.atmarkit.co.jp/news/201002/25/aws.html  •  複数エンティティのトランザクションができない  

–  CondiPonal  Put  and  Deleteと、OpPmisPc  Concurrency  Controlで実装できる（？）

–  Casandra/HBaseだとサービス構築が必要  •  どちらかというとHBase向き  

Windows  Azure  Tableとは

•  Open  Data  Protocol  (OData)  – HTTP,  Atom  Pub  （JSONなし）  

•  hKp://www.odata.org/  

•  Distributed  Storage  System  for  Structured  Data  – BigTable/Casandra  の仲間（NoSQL)  

•  楽観的ロック  •  ＡＣＩＤトランザクション  

CAP定理との折り合い 1.  一貫性 (Consistency)  

–  行内のオペレーションと、同一パーテーション、同一テーブルで操作では、強い一貫性を保証  

2.  可用性 (Availability)  –  ３つのバークアップノードへの自動書き込み。  –  ノードのフェールオーバーは、自動的に行われるが、フェールオー

バー中はサービスは見えなくなる。  

3.  分割耐性(ParPPon  Tolerance)  –  他のパーテーションで起きた障害は、サービス全体に影響しない。  

Ｃ、Ｐ重視で、Ａ切り捨てのサービス    BigTableと同じ

シェーディングの戦略

•  パーテーションキーとテーブル名が同じものは同じパーテーションに置かれる。  

•  パーテーションの負荷で自動的にロードバランシングされる  

•  ノードの障害は自動フェイルオーバーされる  •  レンジパーテーションは無い  •  同一パーテーション内のみレンジクエリーが利用可能  

•  リプリケーションは同期のみ  –  Consistencyの為（？）    

事前の検証

•  パーテーションが増えてもパフォーマンスが落ちないのか？  –  100万パーテーションでも一件あたりの処理時間は同じ  

•  同一パーテションにデータを入れ続けるとどうなるのか？  –  300万件程度入っても一件あたりの処理時間は同じ  

•  アクセス数が増えたときにどこまでスケールするか？  –  1,000  item/sec  ぐらいは処理可能（上限は5,000ぐらいらしい、未確認）  

 ※  今回、限界点までの負荷テストをすることが出来ていません。この程度のパフォーマンスは出るという参考程度としてください。  

設計上の留意点

•  トランザクションの制限  –  任意の組み合わせでトランザクションを利用することはできない。基本、同一Table,  同一パーテーションキーのデータのみ  

•  レイテンシーが大きい  –  ストレージとのやりとりは最低限にする  

•  Azure  TableのTableは、RDBMSのテーブルと違う  –  スキマーレス、なんでも入る  –  データのグループ名みたいなもの    

•  ストレージコストに置いておくだけなら安い  –  ストレージ =  14.7  円/GB/月　（18万円/TB/年）  

デザインパターン

•  複数のクラスを単一のテーブルへシリアライズする  

•  パーテーションの単位を最初に決める  – コンシューマー向けのサービスなら Person    

•  複数のトランザクションになるものは、  – 最初のトランザクション内でLogを書いて、Queue  で繋ぎ、Idenpotent  で recover  できるようにする  

– 補償トランザクションでrecover  

 

アプリレベルの負荷テスト結果

•  確認したのは、新規登録、購入などの重めの更新処理  –  参照だとキャッシュも使えるので違ってくる  

•  個々のリクエストのレスポンスは500ms  –  1s    –  原因  

•  ストレージのレイテンシーが大きい。5  –  7回  =    200ms  程度。  •  海を超えると、150ms  –  200ms程度レイテンシーがある  

•  同時接続数とコア数が比例  –  Small  instance  (1  core)だと、 同時接続数15までは、90  PercenPle  が同じ 、それ以降はだんだん遅延したリクエストが増えてくる  

–  1  、2、4  、8  core  でも、同一の傾向  –  15/coreは少ない気がする。多分、コーディングが同期ＡＰＩを使っているからではないかと思う　（未検証）  

※どこかで（64  coreぐらい？）、ストレージの上限にあたるはずだが（未検証）  

※  64  core  を使うと600万/年ぐらい。      

MEMO •  Windows  Azure  Storage  Abstrac4ons  and  their  Scalability  Targets  

–  h9p://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-­‐azure-­‐storage-­‐abstrac4ons-­‐and-­‐their-­‐scalability-­‐targets.aspx  

•  Windows  Azure  Storage  Architecture  Overview  –  hKp://blogs.msdn.com/b/windowsazurestorage/archive/2010/12/30/

windows-­‐azure-­‐storage-­‐architecture-­‐overview.aspx  •  Performance  in  Windows  Azure  and  Azure  Storage  

–  hKp://convecPve.wordpress.com/2010/10/08/performance-­‐in-­‐windows-­‐azure-­‐and-­‐azure-­‐storage/  

•  Azurescope:  Benchmarking  and  Guidance  for  Windows  Azure  –  hKp://azurescope.cloudapp.net/Default.aspx  

•  DynamicJSON  –  @neuecc    –  hKp://dynamicjson.codeplex.com/