+

中村 俊介　 首藤 一幸 東京工業大学

MyCassandra

+クラウドストレージ

  NoSQL, Key-Value Store (KVS), Document-Oriented DB, GraphDB 例: memcached, Google Bigtable, Amazon Dynamo, Amazon SimpleDB, Apache Cassandra, Voldemort, Ringo, Vpork, MongoDB, CouchDB, Tokyo Tyrant, Flare, ROMA, kumofs, Kai, Redis, LevelDB, Hadoop HBase, Hypertable, Yahoo! PNUTS, Scalaris, Dynomite, ThruDB, Neo4j, IBM ObjectGrid, Oracle Coherence, Velocity, …その他100種類以上

  既存データストアと比較した特徴: 「省機能 ↔ 大容量・高性能」

  データのアクセスは主キーに制限

  join, transactionのような高級な機能はサポートしない

  大規模なデータ / ノード数についてスケーラブル

11.5.26 MyCassandra

大規模なデータを高速に処理する分散データストア

+クラウドストレージの設計指針

 データモデル   key/value vs. multi-dimensional map vs. document vs. graph

 性能   書き込み vs. 読み出し

 低遅延 vs. 永続性 – 全部メモリに置くか、ディスクにfsyncするか

 永続化   同期 vs. 非同期(snapshot)

 レプリケーション   同期 vs. 非同期

 レプリカ間の一貫性   strong vs. weak

 データパーティション   row vs. column

 分散   master/slave vs. decentralized

11.5.26 MyCassandra

3

様々あり、それぞれにトレードオフがある

+クラウドストレージの設計指針

11.5.26 MyCassandra

4

我々は性能に注目  データモデル

  key/value vs. multi-dimensional map vs. document vs. graph

 性能  書き込み vs. 読み出し

 低遅延 vs. 永続性

 永続化   同期 vs. 非同期(snapshot)

 レプリケーション   同期 vs. 非同期

 レプリカ間の一貫性   strong vs. weak

 データパーティション   row vs. column

 分散   master/slave vs. decentralized

+性能のトレードオフ

11.5.26 MyCassandra

5

書き込み性能重視 vs. 読み出し性能重視

永続型クラウドストレージの設計は write/read片方の性能に偏っている

Bigtable, Cassandra, HBase

MySQL, Sherpa

インデックス Log-Structured Merge Tree [P. O’Neil ‘96]

B-Trees [R.Bayer ’70]

diskへの書き込み append (buffering) random

diskへの読み出し n回のrandom I/O + merge 1回のrandom I/O

性能 書き込み性能重視 読み出し性能重視

ストレージエンジン Bigtable由来 MySQL

ストレージエンジンが性能の性質を決める

+どのくらい性能が違うのか？

11.5.26 MyCassandra

6

~ 書き込み性能重視 vs. 読み出し性能重視 ~

- mycassandra -

6

　Write-Heavyワークロードの更新遅延

Yahoo! Cloud Serving Benchmark, SOCC ’10

write-optimized

read-optimized

Better

+

　Read-Heavyワークロードの参照遅延

write-optimized

read-optimized

Better

どのくらい性能が違うのか？

11.5.26 MyCassandra

7

~ 書き込み性能重視 vs. 読み出し性能重視 ~

- mycassandra - Yahoo! Cloud Serving Benchmark, SOCC ’10

+研究の概要

 成果 同じクラウドストレージ内で書き込み/読み出し性能を両立

 手法 1.  クラウドストレージのストレージエンジンを差し替え可能に

2.  ストレージエンジンの異なるノードを組み合わせて連携させる

11.5.26 MyCassandra

8

選択

　1.MyCassandra

read-optimized

write-optimized

2.MyCassandra Cluster

read and write-optimized

+Apache Cassandra

特徴

 複数データセンターにまたがる数百ノードでの動作を想定  単一故障点の無い非集中型クラウドストレージ

 書き込み処理が速い

が作った大規模なクラウドストレージ

dc1 dc2

dc3

複数rack/dcに跨るクラスタ構築 regionを考慮した複製配置

+Apache Cassandra

Consistent Hashing (非集中分散アルゴリズム)   データの主キーのハッシュ値から担当ノードが一意に定まる

11.5.26

10

単一故障点の無い非集中型クラウドストレージ

A Z F

N V

key values

hash(key) = Q

Q

ノードID空間

primary

レプリカ数N := 3

secondary 1

secondary 2

全ノードが全部やる •  request proxy •  データのprimary node •  別データのsecondary node

(A~Zはハッシュ値)

+Google Bigtable由来のストレージエンジン

 データの差分をディスクにsequential write ディスクへのランダムI/Oが発生しないので高速

  Always writable ディスク書き込み時にwrite-lockが不要

MyCassandra

11

書き込み処理が速い: O(1)

memory

disk

Commit Log

Memtable

SSTable 1 SSTable 2 SSTable 3

write path sync async flush

sequential write

<k1, obj (v1+v2)>

<k1, v1>, <k1, v2>

<k1,obj1>

<k1,obj3>

<k1,obj2>

LSM-Tree [P. O’Neil ‘96]

disk mem

SSTableごとに木を構成

+Google Bigtable由来のストレージエンジン

  Keyに対して   Memtable上の最新value

  SSTable上の複数の古いvalueをマージ

ディスクへの複数回のランダムI/Oが発生するため、読み出し性能は犠牲になる

MyCassandra

12

読み出し処理は遅い

Commit Log

Memtable

SSTable 1 SSTable 2 SSTable 3

merge client

<k1,obj>

<k1,obj1>

<k1,obj2>

<k1,obj3>

<k1,obj+obj1~3>

複数回のランダムI/O 複数回のランダムI/O

memory

disk mem disk

disk上の各部分木を探索

+ Cassandraの読み書き性能 13

ベンチマーク実行時の読み書きの遅延 (平均 / 99.9%)

Nu

mb

er o

f qu

erie

s

Latency (ms)

Better read

avg. 6.16 ms

write

avg. 0.69 ms

書き込み遅延の平均が読み出し遅延の1/9

累積グラフ write

read

Latency (ms)

99.9 percentile

write: 2.0 ms read: 86.9 ms

+

11.4.14 14

選択

　1.MyCassandra

read-optimized

write-optimized

1.ストレージエンジンの差し替え

+ MyCassandra: モジュラークラウドストレージ

 Cassandraの分散のしくみ/データモデルはそのまま  様々なワークロードに適した分散データストアを構築

MyCassandra

15

Cassandraのストレージエンジンを差し替え可能に

InnoDB MyISAM Memory …

ストレージエンジンを差し替え可能

Consistent Hashing Gossip Protocol

非集中分散

Bigtable MySQL Redis …

ストレージエンジンを差し替え可能な非集中型クラウドストレージ

Bigtable 選択

選択

+ MyCassandra: モジュラークラウドストレージ

 Cassandraの分散のしくみ/データモデルはそのまま  様々なワークロードに適した分散データストアを構築

MyCassandra

16

Cassandraのストレージエンジンを差し替え可能に

Bigtable MySQL Redis …

ストレージエンジンを差し替え可能な 非集中型クラウドストレージ

選択

InnoDB MyISAM Memory …

ストレージエンジンを差し替え可能 選択

Consistent Hashing Gossip Protocol

非集中分散 Bigtable

+ MyCassandra – 概要

11.5.26 MyCassandra

17

クエリの受理とストレージの間に インタフェースを用意

分散部分はノータッチ

インタフェースを 実装することで

ストレージエンジンを追加可能

選択

11.5.26 MyCassandra

18

ストレージエンジンの性能 :書き込み性能重視なCassandraのストレージ

: 読み出し性能重視. JDBC API / stored procedure : メモリベースのkey-value store

•  ….

+

11.4.14 19

2.MyCassandra Cluster

read and write-optimized

2.ストレージエンジンが異なるノードの連携

- mycassandra -

20

 異なる種類のストレージエンジンに複製を配置

 クエリの種類に応じて、それを得意とするストレージエンジンに クエリを同期的に割り振る → 性能のいいとこ取り

 既存クラウドストレージの整合性の強さを保つ

Quorum Protocol: (書き込み合意数) + (読み出し合意数) > (複製数)

 最新のデータを最低一つを取得できることを保証 読み書き両方を同期的に行うノードが必要

→ メモリベースのストレージエンジンを使う

基本的なアイデア

W R

W R

sync async

RW

write read

write query

•  W: 書き込み性能重視 •  R: 読み出し性能重視 •  RW: メモリベース

クラスタの構成

W R

N=3のときのクラスタ構成

RW W

RW

ストレージエンジンの異なるMyCassandraノードを組み合わせ   書き込み性能重視(W) / 読み出し性能重視(R) / メモリベース(RW)

互いのストレージエンジン情報を定期的に交換   ノードの死活監視(join/dead)に用いるgossip protocolにメタ情報として追加

異なるストレージエンジンのノードにデータの複製を配置   リクエストのプロキシがデータの担当ノードを選択

1.  データのプライマリノード (keyのハッシュ値から) 2.  互いに異なるストレージエンジンのセカンダリノード × N-1

マシン1台に異なる3種類のノードを配置しリソースを有効に扱う

gossip

21

データ担当ノード

W R RW RW

Proxy

primary secondary secondary

書き込みの流れ

1) データ担当ノードにリクエストをマルチキャスト

2) W, RWから成る合計 ノードへ

の書き込みを待ち、成功すればクライアントにACKを返す

3a) 成功時、残り ノードに

は非同期で書きこむ

3b) 失敗時、Rも含めた合計ノードからの書き込みを待ってから、クライアントにACKを返す

- mycassandra -

22

WR

Proxy

２ノードの書き込みACKを確認して成功とみなす

非同期書き込み

RW

Client =3, =2

W:RW:R = 1:1:1の場合

データ担当ノード

11.5.26

•  : 書き込み性能重視 •  R: 読み出し性能重視 •  RW: メモリベース

書き込み遅延: max (W, RW)

読み出しの流れ

1) データ担当ノードにリクエストを マルチキャスト

2) R, RWから成る合計 ノードから

データを取得し、整合性を確認

3a)整合性がとれていれば結果を返す

3b) 失敗 or 不整合があれば、 Wも含めた整合性のとれた ノード

のデータを待ち、結果を返す

4) 残り ノードからのデータの取得. 不整合があれば、非同期で解決 (Cassandraのread repair機能)

- mycassandra -

23

Client

整合性をチェックして 結果を返す

非同期で整合性をチェック

Proxy

データ担当ノード

11.5.26

•  : 書き込み性能重視 •  R: 読み出し性能重視 •  RW: メモリベース

=3, =2 W:RW:R = 1:1:1の場合

読み出し遅延: max (R, RW)

W R RW

+性能評価

 比較対象   MyCassandra Cluster: 6×3 = 18ノード / 6ホスト (W:R:RW = 6 : 6 : 6)   Cassandra: 6ノード / 6ホスト

 レプリケーション   レプリカ数: = 3, 書き込み・読み出し合意数: = = 2

 ストレージエンジン: Bigtable (W), MySQL / InnoDB (R), Redis (RW)

測定手段: YCSB (Yahoo! Cloud Serving Benchmark) [SOCC ’10]  ベンチマーク内容

1.  MyCassandra/Cassandra×6台、YCSB Client×1台用意 2.  1KBのvalues(100[Bytes]×10[columns])+keyから成るレコードを1,000万件ロード 3.  測定するワークロードでメモリ上キャッシュのウォームアップ 4.  YCSBの各ワークロードを実行 5.  YCSB Statでスループットとクエリ種類別のレイテンシを計測

11.5.26 - mycassandra -

24

読み出し/書き込み性能の両立ができるかを確認

+YCSBワークロードの種類

11.5.26 - mycassandra -

25

以下4種類を測定 Workload Application

Example Operation Ratio

Record Selection

Write-Only Log Read: 0% Write: 100%

Zipfian(※)

Write-Heavy Session Store Read: 50% Write: 50%

Read-Heavy Photo tagging

Read: 95% Write: 5%

Read-Only Cache Read: 100% Write: 0%

Write Heavy

Read Heavy

(※) Zipfian分布: アクセス頻度が, 鮮度とは関係なく決まる 一部がヘッド / 大多数がテール

0

0.5

1

1.5 avg. write-latency Cassandra MyCassandra Cluster

リクエスト数/秒を固定した時の遅延時間

0

2

4

6

8

10

12

Write-Only Write-Heavy Read-Heavy Read-Only

avg. read-latency

Better

Better 82.6%減 84.9%減

35.7%減

write:100%

read:0%

write:0%

read:100% read:95%

write:5% write:50%

read:50%

(ms)

(ms)

26

9.3%増 26.2%増 46.2%増

最大で0.36ms増加

読み出し比率の高いワークロードで最大84.9%遅延が減少

MySQL + Redisによる性能向上

最大で8.59ms減少

11.5.26 - mycassandra -

0 2000 4000 6000 8000

10000 12000 14000 16000 18000 20000

Write-Only Write-Heavy Read-Heavy Read-Only

max. qps for 40 clients Cassandra MyCassandra Cluster

クライアント数を固定した時の最大スループット

(query/sec)

Read Heavy Write Heavy

Better

1.54倍

6.49倍

0.93倍

0.90倍

[100:0] [50:50] [5:95] [0:100] [write:read]

•  読み出し比率の高いワークロードで最大6.49倍のスループット •  書き込み比率が高くなるとスループットが出ない

27

- mycassandra - 11.5.26

+考察1: 書き込み遅延増加の原因

  Cassandra   Nノード中、任意の ノードに同期的に書く

  MyCassandra Cluster   メモリベースノード: 読み書きを必ず同期的に行う

  書き込み性能重視ノード: 同期的な書き込み処理が集中する

ただし、読み出し性能向上と比較すると十分に無視できる

11.5.26 - mycassandra -

28

ロードバランスが原因

W R RW

write read write read

Cassandra MyCassandra

Cluster

同期的な処理が Nノードに均等に分散

同期的な処理が R,Wノードに固定

+考察2: メモリベースノード

Q. 容量が制限されないか？

A.ノード自体がLRU likeなcacheノードとして働く。 Swapされて消失したデータはread repairにより他の永続ノード上のデータを使って非同期で復元する。

11.5.26 myCassandra

Q. ノードが死んだときの対応

A. 1) 代替のノードに変更点を書き込み、ノード復帰時にその値で整合性を解決できる

2) Redisの場合、非同期でfsyncする方法があるので、それを用いる (ただし、遅延とのトレードオフがある)

29

+まとめ

複数種類のストレージエンジンを組み合わせによって 読み書き性能を両立する手法を提案・評価

Read-Heavyなワークロードにおいて

  読み出し遅延を最大84.9%削減

  最大6.49倍のスループットを達成

既存手法が苦手とする読み出し性能を 読み出し性能重視 +メモリベースのストレージエンジンで

補えることを確認

11.5.26 - mycassandra -

30

11.5.26 - mycassandra -

31 関連研究  読み出しと書き込みを両立させるindex algorithm

  FD-Tree: Tree Indexing on Flash Disks, VLDB ’10   書き込み性能と読み出し性能を両立する索引アルゴリズム

  B+tree並の検索速度 + LSM-tree並の更新速度

  対象がSSDに限られるが、クラウドストレージへの応用が期待

  Fractal-Tree / TokuDB (MySQLのストレージエンジン)

 モジュラーなデータストア   MySQL: RDBMS

  Anvil, SOSP ’09: 1ノードを対象

  Cloudy, VLDB ’10: 実験評価はされていない

  Dynamo, SOSP ‘07: 遅延 vs. 永続性

  MyCassandra (本研究): 読み出し vs. 書き込み + 両立

+

Webの動画サイトのTable

本手法の使いどころ

  従来: 構造を分ける

1.  パターンが異なるデータごとに正規化して、それぞれのテーブルを 最適化 → 得られる性能の恩恵は小さい

2.  多段構成 (MySQL + memcached) → 分散・プロキシはアプリレイヤーで独自で実装しなければならない → スケーラブルな分散配置の構成をアプリ側で書くのは現実的でない

 本手法: MyCassandra Cluster   アクセスパターンの異なるデータを扱える

  性能はストレージの割合を変えて調整

11.5.26 - mycassandra -

32

アクセスパターンの異なるデータを扱う際に有効

movie-id name thumb-name tag count

704122313 movieA EY37lHk5bgU sport, succer, FIFA, 169,374

704122314 movieB Zk3BSYMWjzQ music, jazz, … 472,803

参照頻度が高い 更新頻度が高い

宣伝

+宣伝: オープンソースとして公開 (準備中)

11.5.26 - mycassandra -

34

5月下旬~6月上旬を予定

twitter: @MyCassandraJP

本研究: MyCassandra/MyCassandra Cluster

Cassandra 1. MyCassandra 2. MyCassandra Cluster

data model multi-dimensional map (Column Family)

throughput write write or read write and read

latency low lower in case lower

persistence yes yes or no yes

consistency weak (eventual, quorum)

replication sync / async

data partition row

node organization

decentralized

クラウドストレージのthroughput, latencyに着目した研究

- mycassandra - 11.5.26

35

(1) 1ノード / 1ホスト →不採用 ☓ ワークロードによって、ホストの負荷が不均一 ☓ 資源を十分に生かしきれない

(2) 1ノード / k 個のストレージエンジン→不採用 ID空間上に仮想ノード [Amazon Dynamo, SOSP ’07]として配置

☓ ストレージエンジンの追加・削除の運用が難しい

(3) 1ホストに複数種類のノードを配置 →採用 ◯ アクセスパターンに応じたノードの増減が容易

負荷分散を考慮したノード配置

virtual node

k nodes / host 1 storage / node

(2) (1)

1storage / 1node / 1 host

1 node / host k storages / node

(3)

host

node

storage

Fault Torelance (FT) space FT space FT space

36

スループット: HDD vs. SSD

0

5000

10000

15000

20000

25000 Cassandra HDD

SSD

(qps) 0

5000

10000

15000

20000 MyCassandra Cluster

HDD

SSD

(qps)

IOZone benchmark

HDD: Western digital

SSD: Crucial

seq. write 86,277 qps 96,401 qps

seq. read 108,914 qps 216,099 qps

random write 2,485 qps 29,045 qps

random read 926 qps 21,751 qps

- mycassandra - 11.4.14

Better

性能の性質・優劣に変化は見られない