NoSQLの中でGoogle App Engine データストアとWindows Azure TableはACIDトランザクションのサポート、PaaSでのサービスなどの面で似たような立ち位置にある。その比較と、事例を紹介する

1. GoogleのBig TableとAzure Tableの特性比較
と失敗しない使い方
株式会社リード・レックス
開発部 インターネットソリューショングループ
部長 近江 武一
株式会社リード・レックス

2. 概要
NoSQLの中でGoogle App Engine
Datastore(以下 GAE Datastore)とWindows
Azure TableはACIDトランザクションのサ
ポート、PaaSでのサービスなどの面で似た
ような立ち位置にある。その比較と、事例
を通じ失敗しない使い方を紹介する
2012/5/10 (C) ReedRex Co,. LTD. 2

3. TRENDS
2012/5/10 (C) ReedRex Co,. LTD. 3

4. ここ20年ほどの間の流れ
1. ここ20年の間で、データの永続化手段は、
RDBMSとファイルシステムの２つに集約
2. 扱うデータ量が急激に増えた。100万超のサービ
スの通常化、20年前ならYahoo Japanクラスがゴ
ロゴロしている
3. コモディティ化されたハードウェアによって急
激な単価低下（CPU、Memory、HDD)が起きた
4. クラウドの台頭（安価なハードウェアを大量に
用意するタイプのパブリッククラウド）
2012/5/10 (C) ReedRex Co,. LTD. 4

5. 永続化ストレージの2極化
コスト 構造化データ（関係モデル）
ファイルシステム
大容量 トランザクション
柔軟な問い合わせ
SQL
単純さ データの一貫性
扱い易さ セキュリティ
スループット
スケーラビリティ 可用性
2012/5/10 (C) ReedRex Co,. LTD. 5

6. JPIX Backplane のトラフィック遷移 2002-
2012
2012/5/10 (C) ReedRex Co,. LTD. 6

7. ハードウェアのコモディティ化
• 1992年
Windows 3.1, OS/2 2.0, 486 DX2 66MHz, HDD
100MB
• 2012年
Windows 7, Mac OSX, Linux, 2GHz Multi Core, HDD
数100MB~
• パブリッククラウド -- Amazon, Google, Azure
コモディティ化された低価格なハードウェアを大量
に用意してサービスを提供
2012/5/10 (C) ReedRex Co,. LTD. 7

8. 2012/5/10 (C) ReedRex Co,. LTD. 8

9. Gapの増大
• 永続化ストレージモデルの停滞
• 処理データ量の増大
• ハードウェアのコモディティ化
2012/5/10 (C) ReedRex Co,. LTD. 9

10. SQL AlternativeとしてのNoSQL
狭間を埋めるNoSQL
2012/5/10 (C) ReedRex Co,. LTD. 10

11. Gapを埋めるNoSQL
NoSQL A
コスト 構造化データ（関係モデル）
ファイルシステム
トランザクション
NoSQL C
大容量
柔軟な問い合わせ
SQL
単純さ
データの一貫性
扱い易さ セキュリティ
スケーラビリティ 可用性 B
NoSQL
2012/5/10 (C) ReedRex Co,. LTD. 11

12. SQL vs NoSQL ?
• 「SQL」→SQLを問い合わせに使うRDBMS
• 現在の関係データベース管理システムRDBMSは機能が豊富
• 関係モデル
• Codd's 12 Rules
• Transaction 処理
• ACID トランザクション、並行処理時での分離
• Query の最適化
• データの完全性
• 物理・論理データの独立性
• セキュリティ
• リカバリー
2012/5/10 (C) ReedRex Co,. LTD. 12

13. Alternative SQL としてのNoSQL
• 用途を限定すれば、SQLの全機能はいら
ないのでは？
• 使わない機能に払っている隠れたコスト
がある
NoSQLは、SQL以外の代替手段を考えよう
というムーブメント
2012/5/10 (C) ReedRex Co,. LTD. 13

14. NoSQLもいろいろある
• Write Opの同期性
• DISKやReplication先に同期で書くか、
• ジャーナルログを持つか
• 耐障害性
• トランザクションのレベル
• 複数同時アクセス時の一貫性があるか
• Queryの柔軟性がどこまであるのか
• 可用性、対障害性をどう考えるか
• スケーラビリティをどう担保するか
2012/5/10 (C) ReedRex Co,. LTD. 14

15. Gapを埋めるNoSQL
構造化データ（関係モデル）
コスト
柔軟な問い合わせ パフォーマンス
単純さ
MongoDB
セキュリティ
SQL
スケーラビリティ
大容量
Bigtable/Azure Table可用性
データの一貫性
扱い易さ
トランザクション
2012/5/10 (C) ReedRex Co,. LTD. 15

16. 典型的な例
• Bigtable-like
• 動機：Googleの検索、gmail など
• Pros:大量データの保持、トランザクション
• Cons：高レイテンシー、
• Casandra
• 動機：Facebook で検索のために開発
• Pros：大量データの保持、リアルタイムな更新、結果整合性
• Cons：一貫性、トランザクション
• MongoDB
• 動機：DoubleClick のメンバーが中心となって開発
• Pros：Read パフォーマンス、柔軟なIndex,Query柔軟性
• Cons：一貫性、トランザクション
2012/5/10 (C) ReedRex Co,. LTD. 16

17. 例: Bigtable/Azure Table
分散ストレージ、トランザクション処理、K/V Store
1. 複数エンティティのトランザクション処理
2. 高いスケーラビリティ
3. 高いコンカレンシー
4. 貧弱なQuery
5. 書き込みはDISKと同期、replication 先も同様
6. レイテンシー 読み書きは、20-30msのレイテン
シー
2012/5/10 (C) ReedRex Co,. LTD. 17

18. 例：MongoDB
読み込み性能に特化したドキュメント指向のNoSQL
1. 読み込みは、memcachedなみ
2. 柔軟なQuery （Indexあり）
3. 書き込みは、Disk と同期しない
4. 書き込みは、同時実行１
5. リプリケーションは非同期のみ
6. トランザクションは、同一ドキュメントのみ
7. Shading は、migrate コストが高い
8. ShadeをまたがったQueryはできない。
2012/5/10 (C) ReedRex Co,. LTD. 18

19. 注目すべき特性
GAE Datastore/Azure Table
2012/5/10 (C) ReedRex Co,. LTD. 19

20. Bigtable-like / GAE Datastore, HBase, Azure
Table
とても似てる
• GAE Datastore
• Google App Engine Datastore, Bigtableがベース
• Windows Azure Table
• Microsoft の実装のBigtable
• HBase
• Bigtable clone、Apache HBase
2012/5/10 (C) ReedRex Co,. LTD. 20

21. GAE Datastore/Azure Table 共通の特徴(1)
1. 分散データストア
2. Key/Value Store
3. トランザクション（制限あり）
4. 追記型（LSM-tree)
5. 複数ストレージへの書き込みでバックアッ
プを作成している
6. データセンターを跨ったリプリケーション
をしている
2012/5/10 (C) ReedRex Co,. LTD. 21

22. GAE Datastore/Azure Table 共通の特徴(2)
1. 複数エンティティのトランザクション処理
2. 高いコンカレンシー
3. 書き込みはDISKと同期、replication 先も同
様
4. 高いスケーラビリティ
5. 高いレイテンシー
6. 制限されたQuery
2012/5/10 (C) ReedRex Co,. LTD. 22

23. Bigtable と Azure Table の基本の比較
基本構成
Azure Table は、 Bigtable とGFS の組み合わせに類似し
ている。
(1) GFS ではレプリカ間の緩やかな整合性が許可され、
すべてのレプリカのビット単位の同一性を保証して
いないが、Azure Table はこれを保証
(2) Bigtable はtabletの書き込みの コミット ログを2 つ
の GFS ファイルに並行して書き込むことで GFS の
障害を回避。Azure Tableでは Stream Layerの
Journaling で耐障害性を担保
2012/5/10 (C) ReedRex Co,. LTD. 23

24. 2012/5/10 (C) ReedRex Co,. LTD. 24

25. ポイント
• 分散ストレージ vs.トランザクション
同一ロケーションのトランザクションが基
本
分散トランザクションはコストが高い
（☓Azure Table)
• 高コンカレンシー vs. 高レイテンシー
複数のリクエストを同時に発行して処理全
体の時間を短縮
2012/5/10 (C) ReedRex Co,. LTD. 25

26. トランザクション
どちらも、Entity Group Transaction と呼ばれ
るトランザクションをサポート
• GAE Datastore
同一 Entity Group に属する複数のEntity をト
ランザクション処理可能
• Azure Table
同一 Table, PartitionKeyのデータは、 トラン
ザクション処理可能
2012/5/10 (C) ReedRex Co,. LTD. 26

27. Data Location – 配置
データの配置のモデルが重要
分散ストレージにどのようにデータを配置するか。分散トランザク
ションにしないため、同じロケーションであることが必要
• Bigtable
エンティティ作成時に親となるエンティティを決めて、Entity Group
を作成。同一Entity Groupは、同じロケーションに配置される。
• Azure Table
エンティティ、作成時に、Table, PartitionKey で指定。両者が同じエ
ンティティは、同じロケーションに置かれる。
2012/5/10 (C) ReedRex Co,. LTD. 27

28. 重要
ロケーションが違うと、一貫性の欠如の問題が
発生する（結果整合）
• GAE Datastore
結果整合になっても機能を提供す
• secondary index, cross group transaction
• Azure Table
Case by case なので、アプリケーションで
実装してもらう。
2012/5/10 (C) ReedRex Co,. LTD. 28

29. Google App Engine Datastoreと、Azure Tableの違い
相違点
2012/5/10 (C) ReedRex Co,. LTD. 29

30. 5つの違い
1. Secondary index
別記
2. Cross group transaction
GAE Datastoreだけにある。参加できるグループは5つまで
3. 3. Backup/restore
GAE Datastoreだけにある。
4. 4. Transactional Task Enqueuing
GAE Datastoreだけにある
https://developers.google.com/appengine/docs/go/datastore/transactions?
hl=ja#Transactional_Task_Enqueuing
5. 分離と整合性
別記
2012/5/10 (C) ReedRex Co,. LTD. 30

31. Propertyで検索
GAE Datastoreではカラムの属性で検索する場合に
Indexが作成されるが、Azure Tableではストレージ
でIndexを作成する機能は無い
• GAE Datastore
トランザクションに癖がある
https://developers.google.com/appengine/articles/
transaction_isolation
• Windows Azure
自作が必要。作ってみるとGAE Datastoreと同じ
ような制限が出てしまう。
2012/5/10 (C) ReedRex Co,. LTD. 31

32. Entity Group 内の並列性
• GAE Datastore
同一Entity Group内では同時には１つのトラ
ンザクションしか実行されない。同一Group
内は分離レベルSERIALIZABLE
• Azure Table
同一 Table, Partition Key 内のトランザク
ションはスナップショットアイソレーショ
ンで実行。分離レベルREAD COMMITTED
2012/5/10 (C) ReedRex Co,. LTD. 32

33. 事例
2012/5/10 (C) ReedRex Co,. LTD. 33

34. 某社スマートフォン向けID/
課金管理 プラットフォーム
1000万ユーザーを越えるスケール
を想定してID/課金管理のシステム
をWindows Azure Tableで構築
クラウド環境の利点を生かして、
上記想定スケールでのパフォーマ
ンステストを実施
2012/5/10 (C) ReedRex Co,. LTD. 34

35. Azure Table３つの魅力
1. PaaS（Platform as a Service）
使った分だけ従量制で課金、インストール、運用の手間が無い
必要に応じて任意のスケールテストが可能
常時３台のバックアップと自動フェイルオーバー
2. 一貫性保障の構造化データストア
トランザクション処理をサポート
高いスケーラビリティ
3. 低コスト
¥0.88/ストレージ トランザクション 10,000 回
¥10.93/GB/月
© Reed Rex Corp. 35

36. データモデル ー 方針
単一テーブルに複数クラスを入れる
Table Name 内容
MetaData オブジェクトのメタデータ（予約）
Data オブジェクトのデータ
Index インデックス
Log APIログなどのデータ
2012/5/10 (C) ReedRex Co,. LTD. 36

37. データモデル ー データの格納
• Person, Friends, Paymentsなどのアプリケーショ
ンのファーストクラスオブジェクトはDataに入る
• Data内には複数のClassのインスタンスが入るの
で、Typeで区別を付ける(Typeは、Rowkeyの
prefixに)
• Indexには、Entity Groupを跨ったsecondary
indexを入れる。
注：同一Entity Group 内に入るIndexはDataへ
• Logは、APIのログなどログデータを年月をキー
にして入れる。
2012/5/10 (C) ReedRex Co,. LTD. 37

38. Entity Group とは？
• 関連性の高いデータが同一Entity Group にな
るようにする。
• Entity Group＝分散の単位
• Entity Groupが大きいと上手く分散されない
• Entity Groupが小さすぎると、分散トランザ
クションが頻発してパフォーマンスが出な
い
• Entity Groupの決め方が重要
2012/5/10 (C) ReedRex Co,. LTD. 38

39. Entity Group
• Entity Group＝同一テーブル、Partitionkey
• ユーザー毎にPartitionkeyを決めて、
「Table」Dataに入れる
• ユーザー内の処理はトランザクションで処
理、ユーザー間の処理は分散トランザク
ションで処理
※コンシューマー向けのシステムでは最初に検
討すべきパターン
2012/5/10 (C) ReedRex Co,. LTD. 39

40. SQL との違い
この使い方では、Azure Tableの「Table」は、
SQLでいうとtablespace (file group)に似た
扱い
同一領域（Data）に複数のクラスをシリア
ライズすることが可能（スキーマレス）
Table と partitionkey が同じときだけトラン
ザクションが可能
2012/5/10 (C) ReedRex Co,. LTD. 40

41. 疑問
• パーティションを分けることで分散スト
レージとして利用できる
?
• どれぐらいパーテーションを分割しても
大丈夫なのか
2012/5/10 (C) ReedRex Co,. LTD. 41

42. スケーラビリティ
• 大量のパーティションを作成してもパ
フォーマンスは変わらない
• 4億件ほど作成して確認
• ユーザー毎にパーティションを作れば、
ユーザーデータのレスポンスは、ユー
ザー数が増えても変わらない
© Reed Rex Corp. 42

43. データ件数と処理時間遷移
100 2000
90 1800
80 1600
70 1400
Throughput [Entities/s]
60 1200
Avg [ms]
50 1000
40 800
Avg
30 600
Throughput
20 400
10 200
0 0
0 50 100 150 200 250 300 350 400
Data Count In Storage [x106]
© Reed Rex Corp. 43

44. 実装上の工夫
• パーティションを跨いだ処理
ユーザー毎にパーティションを分けると、月次の売上処理が遅く
なる。
• 多くのパーティションをまたぐので
• 別テーブルを作る
売上用の月次、日時で、パーティションを切ったテーブルを別途
用意して書き込む
• 別トランザクションにする
Azure Queueを使って別途行う。
• パーティションを跨いだトランザクションはサポートされていない
• 集計データなので同期で書きこむ必要はない（＝レスポンスを早く返せ
る）
© Reed Rex Corp. 44

45. 2012/5/10 (C) ReedRex Co,. LTD. 45

46. ポイント
• Azure Tableは大量のパーティションを扱う
ことができる
• パーテーションを分散することで、パ
フォーマンス劣化無しで、大量データが扱
える
• コストは、トランザクション単価＋スト
レージ使用料の従量制
• パーティションを跨いだ処理は別途データ
を用意する
© Reed Rex Corp. 46

47. mixi xmas 2011
日本最大規模のソーシャルイベン
ト
11/30 ～ 12/25 の期間に利用可能
な、アプリ上でくつしたを飾っ
て、友人のベルを鳴らし合った
り、イベントに参加したりするこ
とでレベルアップ、プレゼントに
応募できる仕組み
また、mixi の決済機能を用いて、
友人へギフトを送ったりすること
ができる機能もある
2009/2010は、GAE
2011は、Windows Azure でサービ
ス提供
2012/5/10 (C) ReedRex Co,. LTD. 47

48. スケール
11/30 サービススタート後、 49時間で100万人
に到達。
12/20 時点で 250 万ユーザーが利用しました。
12/16～18 にはテレビ CM と連動したキャン
ペーンが展開され、Windows Azure の拡張性
を活用して柔軟にスケールアウトさせることに
より、突発的なアクセス増加にも対応していま
す
2012/5/10 (C) ReedRex Co,. LTD. 48

49. 課題
1. ストレージへのピーク時のアクセスの軽減
• ピーク時の想定アクセス数からストレージへのア
クセス頻度を計算するとAzure Storageのパ
フォーマンス目標値を超える
2. レスポンスの改善
• 必要な、mixi api のアクセス、ストレージのアク
エス数からレスポンスタイムを計算すると規定の
時間を超える
2012/5/10 (C) ReedRex Co,. LTD. 49

50. 対策(1) memcachedの利用
• memcachedと、K/V Sは相性が良い
• Readは、どちらもKeyでValueを持ってくるだけ
• Writeは、Keyを使って、Valueを更新するので書
き込みをフックしてmemcached側をメンテする
ことが可能
• SQLだとselectや、updateが柔軟すぎてエンティ
ティのキャッシュは難しく、Query（SQL文）を
キーにして結果をcacheすることになる。更新側
をフックしてcacheをメンテするのも難しいの
で、cacheの有効性が低くなりがち。
2012/5/10 (C) ReedRex Co,. LTD. 50

51. 対策(2) ストレージ系チューニングの小技
• 複数パーテーションに対するQueryは同
時に実行する
• LINQ式は、IQueryable を有効利用
• 実際投げられているhttp requestをログに
書いて確認
2012/5/10 (C) ReedRex Co,. LTD. 51

52. 2012/5/10 (C) ReedRex Co,. LTD. 52

53. ポイント
• Windows Azure Storage にはパフォーマン
ス上限がある
• memcached を使うことでストレージへのア
クセスが減らせる
• K/V Sは、memcached と相性が良く、同期
が取りやすい
• Storageのチューニングはrequestを見てやる
のが基本
2012/5/10 (C) ReedRex Co,. LTD. 53

54. sociobridge
Facebookページ統合運用管理ツール
投稿管理
「内容作成」「公開承認」など運用管理
フロー内での作業範囲に合わせて、各担
当者別に権限を設定可能
投稿監視
管理画面上でタスクの依頼も設定でき、
担当者間の連携が可能
オリジナルページ
ユーザーとのコミュニケーションを活性
化させるオリジナルページの生成が可能
Windows Azure Platformを利用
2012/5/10 (C) ReedRex Co,. LTD. 54

55. ストレージへの要求
• 国内1,000万、全世界で８億を超える
Facebook ユーザーの負荷に耐えられるス
ケーラビリティ
• 投稿管理、ワークフローを実装するトラ
ンザクション処理
2012/5/10 (C) ReedRex Co,. LTD. 55

56. Windows Azure Table/Blobを利用
• パーテーション
• サブスクリプション毎に分割
• Entity Group Transactionが必要なデータは、
同一Tableに保存
• Secondary Indexは自前で実装
2012/5/10 (C) ReedRex Co,. LTD. 56

57. レイテンシー問題
• 一回のTableの読み書きは、最低でも
20msかかる
• ページの表示は、3秒以内で行う
• ページを分割して、ajaxで並列化
2012/5/10 (C) ReedRex Co,. LTD. 57

58. 2012/5/10 (C) ReedRex Co,. LTD. 58

59. モデル ー マルチテナント
• テナント毎にパーテーションを分割
Entity Group が Subscription になるよう
に
• 不特定多数のユーザーからのアクセス
は、Blobで担保
2012/5/10 (C) ReedRex Co,. LTD. 59

60. トランザクション
• 一括書き込みのパフォーマンス向上にBatch
Requestを多用
• Azure TableのEntity Group Transaction は、http
POSTの content-type multipart/mixed。
• ２つの特性がある
1. ACIDトランザクションで実行
2. ラウドトリップタイムの削減
• 複数のSaveChanges()を集約することで、リクエ
スト数を少なくしてパフォーマンスが向上
2012/5/10 (C) ReedRex Co,. LTD. 60

61. End
ご清聴ありがとうございました。
2012/5/10 (C) ReedRex Co,. LTD. 61