0
GoogleのBig TableとAzure Tableの特性比較         と失敗しない使い方  株式会社リード・レックス        開発部 インターネットソリューショングループ                       部長 近...
概要NoSQLの中でGoogle App EngineDatastore(以下 GAE Datastore)とWindowsAzure TableはACIDトランザクションのサポート、PaaSでのサービスなどの面で似たような立ち位置にある。その...
TRENDS2012/5/10   (C) ReedRex Co,. LTD.   3
ここ20年ほどの間の流れ1. ここ20年の間で、データの永続化手段は、   RDBMSとファイルシステムの2つに集約2. 扱うデータ量が急激に増えた。100万超のサービ   スの通常化、20年前ならYahoo Japanクラスがゴ   ロゴロし...
永続化ストレージの2極化            コスト                    構造化データ(関係モデル)ファイルシステム            大容量                                 トランザクシ...
JPIX Backplane のトラフィック遷移 2002-20122012/5/10      (C) ReedRex Co,. LTD.   6
ハードウェアのコモディティ化•     1992年      Windows 3.1, OS/2 2.0, 486 DX2 66MHz, HDD      100MB•     2012年      Windows 7, Mac OSX, Li...
2012/5/10   (C) ReedRex Co,. LTD.   8
Gapの増大• 永続化ストレージモデルの停滞• 処理データ量の増大• ハードウェアのコモディティ化2012/5/10   (C) ReedRex Co,. LTD.   9
SQL AlternativeとしてのNoSQL   狭間を埋めるNoSQL2012/5/10              (C) ReedRex Co,. LTD.   10
Gapを埋めるNoSQL                                                    NoSQL A            コスト         構造化データ(関係モデル)ファイルシステム      ...
SQL vs NoSQL ?•       「SQL」→SQLを問い合わせに使うRDBMS•       現在の関係データベース管理システムRDBMSは機能が豊富    •       関係モデル        •    Codds 12 Ru...
Alternative SQL としてのNoSQL• 用途を限定すれば、SQLの全機能はいら  ないのでは?• 使わない機能に払っている隠れたコスト  があるNoSQLは、SQL以外の代替手段を考えようというムーブメント2012/5/10   ...
NoSQLもいろいろある•       Write Opの同期性    •       DISKやReplication先に同期で書くか、•       ジャーナルログを持つか    •       耐障害性•       トランザクションのレ...
Gapを埋めるNoSQL            構造化データ(関係モデル)                                                     コスト            柔軟な問い合わせ         ...
典型的な例•       Bigtable-like    •       動機:Googleの検索、gmail など    •       Pros:大量データの保持、トランザクション    •       Cons:高レイテンシー、•   ...
例: Bigtable/Azure Table分散ストレージ、トランザクション処理、K/V Store1. 複数エンティティのトランザクション処理2. 高いスケーラビリティ3. 高いコンカレンシー4. 貧弱なQuery5. 書き込みはDISKと...
例:MongoDB読み込み性能に特化したドキュメント指向のNoSQL1. 読み込みは、memcachedなみ2. 柔軟なQuery (Indexあり)3. 書き込みは、Disk と同期しない4. 書き込みは、同時実行15. リプリケーションは非...
注目すべき特性   GAE Datastore/Azure Table2012/5/10     (C) ReedRex Co,. LTD.   19
Bigtable-like / GAE Datastore, HBase, AzureTableとても似てる• GAE Datastore   •        Google App Engine Datastore, Bigtableがベース...
GAE Datastore/Azure Table 共通の特徴(1)1. 分散データストア2. Key/Value Store3. トランザクション(制限あり)4. 追記型(LSM-tree)5. 複数ストレージへの書き込みでバックアッ   プ...
GAE Datastore/Azure Table 共通の特徴(2)1. 複数エンティティのトランザクション処理2. 高いコンカレンシー3. 書き込みはDISKと同期、replication 先も同   様4. 高いスケーラビリティ5. 高いレ...
Bigtable と Azure Table の基本の比較基本構成Azure Table は、 Bigtable とGFS の組み合わせに類似している。(1) GFS ではレプリカ間の緩やかな整合性が許可され、    すべてのレプリカのビット単...
2012/5/10   (C) ReedRex Co,. LTD.   24
ポイント• 分散ストレージ vs.トランザクション  同一ロケーションのトランザクションが基  本  分散トランザクションはコストが高い  (☓Azure Table)• 高コンカレンシー vs. 高レイテンシー  複数のリクエストを同時に発行...
トランザクションどちらも、Entity Group Transaction と呼ばれるトランザクションをサポート• GAE Datastore  同一 Entity Group に属する複数のEntity をト  ランザクション処理可能• Az...
Data Location – 配置データの配置のモデルが重要分散ストレージにどのようにデータを配置するか。分散トランザクションにしないため、同じロケーションであることが必要• Bigtableエンティティ作成時に親となるエンティティを決めて、...
重要ロケーションが違うと、一貫性の欠如の問題が発生する(結果整合)• GAE Datastore  結果整合になっても機能を提供す   •        secondary index, cross group transaction• Azu...
Google App Engine Datastoreと、Azure Tableの違い   相違点2012/5/10                (C) ReedRex Co,. LTD.   29
5つの違い1.     Secondary index       別記2.     Cross group transaction       GAE Datastoreだけにある。参加できるグループは5つまで3.     3. Backup...
Propertyで検索GAE Datastoreではカラムの属性で検索する場合にIndexが作成されるが、Azure TableではストレージでIndexを作成する機能は無い• GAE Datastore   トランザクションに癖がある   h...
Entity Group 内の並列性• GAE Datastore  同一Entity Group内では同時には1つのトラ  ンザクションしか実行されない。同一Group  内は分離レベルSERIALIZABLE• Azure Table  同...
事例2012/5/10   (C) ReedRex Co,. LTD.   33
某社スマートフォン向けID/課金管理 プラットフォーム1000万ユーザーを越えるスケールを想定してID/課金管理のシステムをWindows Azure Tableで構築クラウド環境の利点を生かして、上記想定スケールでのパフォーマンステストを実施...
Azure Table3つの魅力1.    PaaS(Platform as a Service)     使った分だけ従量制で課金、インストール、運用の手間が無い     必要に応じて任意のスケールテストが可能     常時3台のバックアップ...
データモデル ー 方針単一テーブルに複数クラスを入れる    Table Name   内容    MetaData     オブジェクトのメタデータ(予約)    Data         オブジェクトのデータ    Index       ...
データモデル ー データの格納• Person, Friends, Paymentsなどのアプリケーショ  ンのファーストクラスオブジェクトはDataに入る• Data内には複数のClassのインスタンスが入るの  で、Typeで区別を付ける(...
Entity Group とは?• 関連性の高いデータが同一Entity Group にな  るようにする。• Entity Group=分散の単位• Entity Groupが大きいと上手く分散されない• Entity Groupが小さすぎる...
Entity Group• Entity Group=同一テーブル、Partitionkey• ユーザー毎にPartitionkeyを決めて、  「Table」Dataに入れる• ユーザー内の処理はトランザクションで処  理、ユーザー間の処理は...
SQL との違いこの使い方では、Azure Tableの「Table」は、SQLでいうとtablespace (file group)に似た扱い同一領域(Data)に複数のクラスをシリアライズすることが可能(スキーマレス)Table と par...
疑問•       パーティションを分けることで分散スト        レージとして利用できる                   ?•       どれぐらいパーテーションを分割しても        大丈夫なのか2012/5/10     (...
スケーラビリティ• 大量のパーティションを作成してもパ  フォーマンスは変わらない• 4億件ほど作成して確認• ユーザー毎にパーティションを作れば、  ユーザーデータのレスポンスは、ユー  ザー数が増えても変わらない           © R...
データ件数と処理時間遷移            100                                                                           2000            90  ...
実装上の工夫•       パーティションを跨いだ処理        ユーザー毎にパーティションを分けると、月次の売上処理が遅く        なる。    •    多くのパーティションをまたぐので•       別テーブルを作る      ...
2012/5/10   (C) ReedRex Co,. LTD.   45
ポイント• Azure Tableは大量のパーティションを扱う  ことができる• パーテーションを分散することで、パ  フォーマンス劣化無しで、大量データが扱  える• コストは、トランザクション単価+スト  レージ使用料の従量制• パーティシ...
mixi xmas 2011                                   日本最大規模のソーシャルイベン                                   ト                      ...
スケール11/30 サービススタート後、 49時間で100万人に到達。12/20 時点で 250 万ユーザーが利用しました。12/16~18 にはテレビ CM と連動したキャンペーンが展開され、Windows Azure の拡張性を活用して柔軟...
課題1. ストレージへのピーク時のアクセスの軽減   •        ピーク時の想定アクセス数からストレージへのア            クセス頻度を計算するとAzure Storageのパ            フォーマンス目標値を超える2...
対策(1) memcachedの利用• memcachedと、K/V Sは相性が良い• Readは、どちらもKeyでValueを持ってくるだけ• Writeは、Keyを使って、Valueを更新するので書  き込みをフックしてmemcached側...
対策(2) ストレージ系チューニングの小技• 複数パーテーションに対するQueryは同  時に実行する• LINQ式は、IQueryable を有効利用• 実際投げられているhttp requestをログに  書いて確認2012/5/10   ...
2012/5/10   (C) ReedRex Co,. LTD.   52
ポイント• Windows Azure Storage にはパフォーマン  ス上限がある• memcached を使うことでストレージへのア  クセスが減らせる• K/V Sは、memcached と相性が良く、同期  が取りやすい• Stor...
sociobridge                               Facebookページ統合運用管理ツール                               投稿管理                         ...
ストレージへの要求• 国内1,000万、全世界で8億を超える  Facebook ユーザーの負荷に耐えられるス  ケーラビリティ• 投稿管理、ワークフローを実装するトラ  ンザクション処理2012/5/10   (C) ReedRex Co,....
Windows Azure Table/Blobを利用• パーテーション   • サブスクリプション毎に分割   • Entity Group Transactionが必要なデータは、     同一Tableに保存• Secondary Ind...
レイテンシー問題• 一回のTableの読み書きは、最低でも  20msかかる• ページの表示は、3秒以内で行う• ページを分割して、ajaxで並列化2012/5/10   (C) ReedRex Co,. LTD.   57
2012/5/10   (C) ReedRex Co,. LTD.   58
モデル ー マルチテナント• テナント毎にパーテーションを分割  Entity Group が Subscription になるよう  に• 不特定多数のユーザーからのアクセス  は、Blobで担保2012/5/10      (C) Reed...
トランザクション• 一括書き込みのパフォーマンス向上にBatch  Requestを多用• Azure TableのEntity Group Transaction は、http  POSTの content-type multipart/mi...
End            ご清聴ありがとうございました。2012/5/10        (C) ReedRex Co,. LTD.   61
Upcoming SlideShare
Loading in...5
×

NoSQL Bigtable and Azure Table

9,214

Published on

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

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
9,214
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
15
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Transcript of "NoSQL Bigtable and Azure Table"

  1. 1. GoogleのBig TableとAzure Tableの特性比較 と失敗しない使い方 株式会社リード・レックス 開発部 インターネットソリューショングループ 部長 近江 武一 株式会社リード・レックス
  2. 2. 概要NoSQLの中でGoogle App EngineDatastore(以下 GAE Datastore)とWindowsAzure TableはACIDトランザクションのサポート、PaaSでのサービスなどの面で似たような立ち位置にある。その比較と、事例を通じ失敗しない使い方を紹介する2012/5/10 (C) ReedRex Co,. LTD. 2
  3. 3. TRENDS2012/5/10 (C) ReedRex Co,. LTD. 3
  4. 4. ここ20年ほどの間の流れ1. ここ20年の間で、データの永続化手段は、 RDBMSとファイルシステムの2つに集約2. 扱うデータ量が急激に増えた。100万超のサービ スの通常化、20年前ならYahoo Japanクラスがゴ ロゴロしている3. コモディティ化されたハードウェアによって急 激な単価低下(CPU、Memory、HDD)が起きた4. クラウドの台頭(安価なハードウェアを大量に 用意するタイプのパブリッククラウド)2012/5/10 (C) ReedRex Co,. LTD. 4
  5. 5. 永続化ストレージの2極化 コスト 構造化データ(関係モデル)ファイルシステム 大容量 トランザクション 柔軟な問い合わせ SQL 単純さ データの一貫性 扱い易さ セキュリティ スループット スケーラビリティ 可用性2012/5/10 (C) ReedRex Co,. LTD. 5
  6. 6. JPIX Backplane のトラフィック遷移 2002-20122012/5/10 (C) ReedRex Co,. LTD. 6
  7. 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. 8. 2012/5/10 (C) ReedRex Co,. LTD. 8
  9. 9. Gapの増大• 永続化ストレージモデルの停滞• 処理データ量の増大• ハードウェアのコモディティ化2012/5/10 (C) ReedRex Co,. LTD. 9
  10. 10. SQL AlternativeとしてのNoSQL 狭間を埋めるNoSQL2012/5/10 (C) ReedRex Co,. LTD. 10
  11. 11. Gapを埋めるNoSQL NoSQL A コスト 構造化データ(関係モデル)ファイルシステム トランザクション NoSQL C 大容量 柔軟な問い合わせ SQL 単純さ データの一貫性 扱い易さ セキュリティ スケーラビリティ 可用性 B NoSQL2012/5/10 (C) ReedRex Co,. LTD. 11
  12. 12. SQL vs NoSQL ?• 「SQL」→SQLを問い合わせに使うRDBMS• 現在の関係データベース管理システムRDBMSは機能が豊富 • 関係モデル • Codds 12 Rules • Transaction 処理 • ACID トランザクション、並行処理時での分離 • Query の最適化 • データの完全性 • 物理・論理データの独立性 • セキュリティ • リカバリー2012/5/10 (C) ReedRex Co,. LTD. 12
  13. 13. Alternative SQL としてのNoSQL• 用途を限定すれば、SQLの全機能はいら ないのでは?• 使わない機能に払っている隠れたコスト があるNoSQLは、SQL以外の代替手段を考えようというムーブメント2012/5/10 (C) ReedRex Co,. LTD. 13
  14. 14. NoSQLもいろいろある• Write Opの同期性 • DISKやReplication先に同期で書くか、• ジャーナルログを持つか • 耐障害性• トランザクションのレベル• 複数同時アクセス時の一貫性があるか• Queryの柔軟性がどこまであるのか• 可用性、対障害性をどう考えるか• スケーラビリティをどう担保するか2012/5/10 (C) ReedRex Co,. LTD. 14
  15. 15. Gapを埋めるNoSQL 構造化データ(関係モデル) コスト 柔軟な問い合わせ パフォーマンス 単純さ MongoDB セキュリティ SQL スケーラビリティ 大容量 Bigtable/Azure Table可用性 データの一貫性 扱い易さ トランザクション2012/5/10 (C) ReedRex Co,. LTD. 15
  16. 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. 17. 例: Bigtable/Azure Table分散ストレージ、トランザクション処理、K/V Store1. 複数エンティティのトランザクション処理2. 高いスケーラビリティ3. 高いコンカレンシー4. 貧弱なQuery5. 書き込みはDISKと同期、replication 先も同様6. レイテンシー 読み書きは、20-30msのレイテン シー2012/5/10 (C) ReedRex Co,. LTD. 17
  18. 18. 例:MongoDB読み込み性能に特化したドキュメント指向のNoSQL1. 読み込みは、memcachedなみ2. 柔軟なQuery (Indexあり)3. 書き込みは、Disk と同期しない4. 書き込みは、同時実行15. リプリケーションは非同期のみ6. トランザクションは、同一ドキュメントのみ7. Shading は、migrate コストが高い8. ShadeをまたがったQueryはできない。2012/5/10 (C) ReedRex Co,. LTD. 18
  19. 19. 注目すべき特性 GAE Datastore/Azure Table2012/5/10 (C) ReedRex Co,. LTD. 19
  20. 20. Bigtable-like / GAE Datastore, HBase, AzureTableとても似てる• GAE Datastore • Google App Engine Datastore, Bigtableがベース• Windows Azure Table • Microsoft の実装のBigtable• HBase • Bigtable clone、Apache HBase2012/5/10 (C) ReedRex Co,. LTD. 20
  21. 21. GAE Datastore/Azure Table 共通の特徴(1)1. 分散データストア2. Key/Value Store3. トランザクション(制限あり)4. 追記型(LSM-tree)5. 複数ストレージへの書き込みでバックアッ プを作成している6. データセンターを跨ったリプリケーション をしている2012/5/10 (C) ReedRex Co,. LTD. 21
  22. 22. GAE Datastore/Azure Table 共通の特徴(2)1. 複数エンティティのトランザクション処理2. 高いコンカレンシー3. 書き込みはDISKと同期、replication 先も同 様4. 高いスケーラビリティ5. 高いレイテンシー6. 制限されたQuery2012/5/10 (C) ReedRex Co,. LTD. 22
  23. 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. 24. 2012/5/10 (C) ReedRex Co,. LTD. 24
  25. 25. ポイント• 分散ストレージ vs.トランザクション 同一ロケーションのトランザクションが基 本 分散トランザクションはコストが高い (☓Azure Table)• 高コンカレンシー vs. 高レイテンシー 複数のリクエストを同時に発行して処理全 体の時間を短縮2012/5/10 (C) ReedRex Co,. LTD. 25
  26. 26. トランザクションどちらも、Entity Group Transaction と呼ばれるトランザクションをサポート• GAE Datastore 同一 Entity Group に属する複数のEntity をト ランザクション処理可能• Azure Table 同一 Table, PartitionKeyのデータは、 トラン ザクション処理可能2012/5/10 (C) ReedRex Co,. LTD. 26
  27. 27. Data Location – 配置データの配置のモデルが重要分散ストレージにどのようにデータを配置するか。分散トランザクションにしないため、同じロケーションであることが必要• Bigtableエンティティ作成時に親となるエンティティを決めて、Entity Groupを作成。同一Entity Groupは、同じロケーションに配置される。• Azure Tableエンティティ、作成時に、Table, PartitionKey で指定。両者が同じエンティティは、同じロケーションに置かれる。2012/5/10 (C) ReedRex Co,. LTD. 27
  28. 28. 重要ロケーションが違うと、一貫性の欠如の問題が発生する(結果整合)• GAE Datastore 結果整合になっても機能を提供す • secondary index, cross group transaction• Azure Table Case by case なので、アプリケーションで 実装してもらう。2012/5/10 (C) ReedRex Co,. LTD. 28
  29. 29. Google App Engine Datastoreと、Azure Tableの違い 相違点2012/5/10 (C) ReedRex Co,. LTD. 29
  30. 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_Enqueuing5. 分離と整合性 別記2012/5/10 (C) ReedRex Co,. LTD. 30
  31. 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. 32. Entity Group 内の並列性• GAE Datastore 同一Entity Group内では同時には1つのトラ ンザクションしか実行されない。同一Group 内は分離レベルSERIALIZABLE• Azure Table 同一 Table, Partition Key 内のトランザク ションはスナップショットアイソレーショ ンで実行。分離レベルREAD COMMITTED2012/5/10 (C) ReedRex Co,. LTD. 32
  33. 33. 事例2012/5/10 (C) ReedRex Co,. LTD. 33
  34. 34. 某社スマートフォン向けID/課金管理 プラットフォーム1000万ユーザーを越えるスケールを想定してID/課金管理のシステムをWindows Azure Tableで構築クラウド環境の利点を生かして、上記想定スケールでのパフォーマンステストを実施2012/5/10 (C) ReedRex Co,. LTD. 34
  35. 35. Azure Table3つの魅力1. PaaS(Platform as a Service) 使った分だけ従量制で課金、インストール、運用の手間が無い 必要に応じて任意のスケールテストが可能 常時3台のバックアップと自動フェイルオーバー2. 一貫性保障の構造化データストア トランザクション処理をサポート 高いスケーラビリティ3. 低コスト ¥0.88/ストレージ トランザクション 10,000 回 ¥10.93/GB/月 © Reed Rex Corp. 35
  36. 36. データモデル ー 方針単一テーブルに複数クラスを入れる Table Name 内容 MetaData オブジェクトのメタデータ(予約) Data オブジェクトのデータ Index インデックス Log APIログなどのデータ2012/5/10 (C) ReedRex Co,. LTD. 36
  37. 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. 38. Entity Group とは?• 関連性の高いデータが同一Entity Group にな るようにする。• Entity Group=分散の単位• Entity Groupが大きいと上手く分散されない• Entity Groupが小さすぎると、分散トランザ クションが頻発してパフォーマンスが出な い• Entity Groupの決め方が重要2012/5/10 (C) ReedRex Co,. LTD. 38
  39. 39. Entity Group• Entity Group=同一テーブル、Partitionkey• ユーザー毎にPartitionkeyを決めて、 「Table」Dataに入れる• ユーザー内の処理はトランザクションで処 理、ユーザー間の処理は分散トランザク ションで処理※コンシューマー向けのシステムでは最初に検討すべきパターン2012/5/10 (C) ReedRex Co,. LTD. 39
  40. 40. SQL との違いこの使い方では、Azure Tableの「Table」は、SQLでいうとtablespace (file group)に似た扱い同一領域(Data)に複数のクラスをシリアライズすることが可能(スキーマレス)Table と partitionkey が同じときだけトランザクションが可能2012/5/10 (C) ReedRex Co,. LTD. 40
  41. 41. 疑問• パーティションを分けることで分散スト レージとして利用できる ?• どれぐらいパーテーションを分割しても 大丈夫なのか2012/5/10 (C) ReedRex Co,. LTD. 41
  42. 42. スケーラビリティ• 大量のパーティションを作成してもパ フォーマンスは変わらない• 4億件ほど作成して確認• ユーザー毎にパーティションを作れば、 ユーザーデータのレスポンスは、ユー ザー数が増えても変わらない © Reed Rex Corp. 42
  43. 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. 44. 実装上の工夫• パーティションを跨いだ処理 ユーザー毎にパーティションを分けると、月次の売上処理が遅く なる。 • 多くのパーティションをまたぐので• 別テーブルを作る 売上用の月次、日時で、パーティションを切ったテーブルを別途 用意して書き込む• 別トランザクションにする Azure Queueを使って別途行う。 • パーティションを跨いだトランザクションはサポートされていない • 集計データなので同期で書きこむ必要はない(=レスポンスを早く返せ る) © Reed Rex Corp. 44
  45. 45. 2012/5/10 (C) ReedRex Co,. LTD. 45
  46. 46. ポイント• Azure Tableは大量のパーティションを扱う ことができる• パーテーションを分散することで、パ フォーマンス劣化無しで、大量データが扱 える• コストは、トランザクション単価+スト レージ使用料の従量制• パーティションを跨いだ処理は別途データ を用意する © Reed Rex Corp. 46
  47. 47. mixi xmas 2011 日本最大規模のソーシャルイベン ト 11/30 ~ 12/25 の期間に利用可能 な、アプリ上でくつしたを飾っ て、友人のベルを鳴らし合った り、イベントに参加したりするこ とでレベルアップ、プレゼントに 応募できる仕組み また、mixi の決済機能を用いて、 友人へギフトを送ったりすること ができる機能もある 2009/2010は、GAE 2011は、Windows Azure でサービ ス提供2012/5/10 (C) ReedRex Co,. LTD. 47
  48. 48. スケール11/30 サービススタート後、 49時間で100万人に到達。12/20 時点で 250 万ユーザーが利用しました。12/16~18 にはテレビ CM と連動したキャンペーンが展開され、Windows Azure の拡張性を活用して柔軟にスケールアウトさせることにより、突発的なアクセス増加にも対応しています2012/5/10 (C) ReedRex Co,. LTD. 48
  49. 49. 課題1. ストレージへのピーク時のアクセスの軽減 • ピーク時の想定アクセス数からストレージへのア クセス頻度を計算するとAzure Storageのパ フォーマンス目標値を超える2. レスポンスの改善 • 必要な、mixi api のアクセス、ストレージのアク エス数からレスポンスタイムを計算すると規定の 時間を超える2012/5/10 (C) ReedRex Co,. LTD. 49
  50. 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. 51. 対策(2) ストレージ系チューニングの小技• 複数パーテーションに対するQueryは同 時に実行する• LINQ式は、IQueryable を有効利用• 実際投げられているhttp requestをログに 書いて確認2012/5/10 (C) ReedRex Co,. LTD. 51
  52. 52. 2012/5/10 (C) ReedRex Co,. LTD. 52
  53. 53. ポイント• Windows Azure Storage にはパフォーマン ス上限がある• memcached を使うことでストレージへのア クセスが減らせる• K/V Sは、memcached と相性が良く、同期 が取りやすい• Storageのチューニングはrequestを見てやる のが基本2012/5/10 (C) ReedRex Co,. LTD. 53
  54. 54. sociobridge Facebookページ統合運用管理ツール 投稿管理 「内容作成」「公開承認」など運用管理 フロー内での作業範囲に合わせて、各担 当者別に権限を設定可能 投稿監視 管理画面上でタスクの依頼も設定でき、 担当者間の連携が可能 オリジナルページ ユーザーとのコミュニケーションを活性 化させるオリジナルページの生成が可能 Windows Azure Platformを利用2012/5/10 (C) ReedRex Co,. LTD. 54
  55. 55. ストレージへの要求• 国内1,000万、全世界で8億を超える Facebook ユーザーの負荷に耐えられるス ケーラビリティ• 投稿管理、ワークフローを実装するトラ ンザクション処理2012/5/10 (C) ReedRex Co,. LTD. 55
  56. 56. Windows Azure Table/Blobを利用• パーテーション • サブスクリプション毎に分割 • Entity Group Transactionが必要なデータは、 同一Tableに保存• Secondary Indexは自前で実装2012/5/10 (C) ReedRex Co,. LTD. 56
  57. 57. レイテンシー問題• 一回のTableの読み書きは、最低でも 20msかかる• ページの表示は、3秒以内で行う• ページを分割して、ajaxで並列化2012/5/10 (C) ReedRex Co,. LTD. 57
  58. 58. 2012/5/10 (C) ReedRex Co,. LTD. 58
  59. 59. モデル ー マルチテナント• テナント毎にパーテーションを分割 Entity Group が Subscription になるよう に• 不特定多数のユーザーからのアクセス は、Blobで担保2012/5/10 (C) ReedRex Co,. LTD. 59
  60. 60. トランザクション• 一括書き込みのパフォーマンス向上にBatch Requestを多用• Azure TableのEntity Group Transaction は、http POSTの content-type multipart/mixed。• 2つの特性がある 1. ACIDトランザクションで実行 2. ラウドトリップタイムの削減• 複数のSaveChanges()を集約することで、リクエ スト数を少なくしてパフォーマンスが向上2012/5/10 (C) ReedRex Co,. LTD. 60
  61. 61. End ご清聴ありがとうございました。2012/5/10 (C) ReedRex Co,. LTD. 61
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×