Download - 読み出し性能と書き込み性能を両立させるクラウドストレージ (OS-117-24)

1 - mycassandra - 11.4.14

大規模なデータを高速に処理する分散データストア NoSQL, Key-Value Store (KVS), Document-oriented DB, GraphDB 例: memcached, Google Bigtable, Amazon Dynamo, Amazon SimpleDB, Apache Cassandra, Voldemort,

Ringo, Vpork, MongoDB, CouchDB, Tokyo Cabinet/Tokyo Tyrant, Flare, ROMA, kumofs, Kai, Redis, Hadoop Hbase, Hypertable, Yahoo! PNUTS, Scalaris, Dynomite, ThruDB, Neo4j, IBM ObjectGrid, Oracle Coherence, Velocity, …　とさまざま

既存データストアと比較した特徴: “省機能 ↔ 大容量・高性能” •  データのアクセスは主キー •  高級な機能はサポートしない (join, transaction) •  大規模なデータ / ノード数についてスケーラブル

クラウドストレージ

東京工業大学情報理工学研究科数理・計算科学専攻中村俊介

2 - mycassandra -

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

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

•  低遅延 vs. 永続性 •  一貫性

•  strong vs. weak •  レプリケーション

•  同期 vs. 非同期 •  データパーティション

•  row vs. column •  分散

•  master/slave vs. decentralized

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


Bigtable, Cassandra, HBase

MySQL, Sherpa

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

B+-Tree [R.Bayer ‘72]

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

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

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

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

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


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

11.4.14 - mycassandra - 6

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

Yahoo! Cloud Serving Benchmark, SOCC ’10

write-optimized

read-optimized write-optimized

read-optimized

Better Better

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

手法 1.  クラウドストレージのストレージエンジンを差し替え可能にした 2.  ストレージエンジンの異なるノードを組み合わせて連携させた

研究の概要

選択

　1.MyCassandra

read-optimized

write-optimized

2.MyCassandra Cluster

read/write-optimized


Apache Cassandra

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

データの主キーのハッシュ値により、そのデータの担当ノードが一意に定まる

Consistent Hashing(非集中分散アルゴリズム)

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


A Z F

N V

key values hash(key) = Q

Q

ノードID空間

primary

レプリカ数N = 3

secondary 1

secondary 2

Google Bigtable由来のストレージエンジン - 書き込み: 速い -

•  Bigtable: 行の差分をディスクにsequential write ディスクへのランダムI/Oは発生しないので非常に高速

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

Commit Log

Memtable

SSTable

Memory Disk

write

Cassandraノード


async

map: <key,ColumnFamily>

<k1, cf1> <k1, cf2>

<k1, cf1+cf2>

Google Bigtable由来のストレージエンジン - 読み出し: 遅い-

keyに対して •  Memtable上の最新value •  SSTable上の複数の古いvalueをマージ

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

Commit Log

Memtable

SSTable

Map <key,ColumnFamily>

read Memory Disk

ディスクへの複数回のランダムI/O

が必要

Cassandraノード

<key, CF1> <key, CF2> <key, CF3>

<k1, CF4>

10 11.4.14 - mycassandra -

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

選択

　MyCassandra

read-optimized

write-optimized


Cassandraのストレージエンジンを差し替え可能に •  Cassandraの分散のしくみ/データモデルはそのまま •  様々なワークロードに適した分散データストアを構築

モジュラーなクラウドストレージ

東京工業大学情報理工学研究科数理・計算科学専攻中村俊介

InnoDB MyISAM Memory

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

Bigtable MySQL Redis

…

…

Consistent Hashing Gossip Protocol

非集中分散ストレージエンジンを差し替え可能

12 11.4.14

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

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

各ストレージエンジンの性能

13 11.4.14

MyCassandra node × 6

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

MyCassandra Cluster

read/write-optimized


基本的なアイデア

•  異なる種類のストレージエンジンに複製を配置 •  リクエストの種類に応じて、それを得意とするストレージエンジンにリクエストを割り振る => 性能のいいとこ取り

•  既存クラウドストレージの整合性の質を保つ Quorum Protocol: (書き込み合意数) + (読み出し合意数) > (複製数)

書き読み両方行うストレージが必要 => メモリベースのストレージエンジンを使う

11.4.14 - mycassandra -

sync async

mem 15

クラスタの構成

W R

RW W

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

RW

RW

R

RW R

W

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

RW

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

互いのストレージエンジン情報を定期的に交換 •  ノードの死活監視に用いるgossip protocolにメタ情報を追加

異なるストレージエンジンのノードにデータの複製を配置 •  リクエストのプロキシがデータの担当ノードを選択 1.  データのプライマリノード (keyのハッシュ値から) 2.  互いに異なるストレージエンジンのセカンダリノード × N-1

Consistent HashingのノードID空間

データの担当ノード gossip

16 11.4.14

(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

11.4.14 17

書き込みの流れ

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

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

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

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

同期で書きこむ

3b) 失敗時、Rも含めた合計ノード

からの書き込みを待ってから、クライアントにACKを返す

- mycassandra - 18

W R

Proxy

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

非同期書き込み

RW

Client

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

データ担当ノード

11.4.14

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

基本的な書き込み遅延: max (W, RW)

読み出しの流れ

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

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

タを取得し、整合性を確認 3a)整合性がとれていれば結果を返す 3b) 読み出し失敗 or 不整合があれば、Wも含めた合計ノードの整合性のとれ

たデータを待ち結果を返す 4)  残りノードからのデータの取得を待ち、不整合があれば、Proxyが非同期で不整合を解決 (Cassandraのread repair機能)

- mycassandra - 19

W R

Client

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

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

Proxy

RW

データ担当ノード

11.4.14

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

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

基本的な書き込み遅延: max (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でスループットとクエリ種類別のレイテンシを計測


YCSBワークロードの種類

•  以下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.2 0.4 0.6 0.8

1 avg. write-latency Cassandra

MyCassandra

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

0

2

4

6

8

10

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

avg. read-latency

Cluster

Better

Better 85.2%減 88.5%減

49.7%増

write:100%

read:0%

write:0%

read:100% read:95%

write:5% write:50%

read:50%

11.5~23.5%の差

(ms)

(ms)


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

書き込み比率が高いと増加

MySQL + Redisによる性能向上

0

5000

10000

15000

20000

25000

30000

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

max. qps for 40 clients Cassandra MyCassandra

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

(query/sec)

Read Heavy Write Heavy

Cluster

Better 1.49倍

6.53倍

0.62倍

0.99倍

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

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


スループット: HDD vs. SSD

0

5000

10000

15000

20000

25000

30000 Cassandra HDD

SSD

(qps) 0

5000 10000 15000 20000 25000 30000 MyCassandra

Cluster HDD SSD

(qps)

(1) 書き込み比率が高いときはHDD/SSDは同じ (2) スループットが伸びないワークロードで、性能が向上し、互いに差は縮まる (3) 優劣には変化がみられない

IOZone benchmark

HDD: Western digital SSD: Crucial

sequential write 86,277 qps 96,401 qps sequential 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

(1)

(２) (２) (3)

(3)

24

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

 Read-Heavyなワークロードにおいて、 •  読み出し遅延を最大88.5%削減し、 •  最大6.53倍のスループットを達成

=> 書き込み性能重視のストレージエンジンが苦手とする読み出し性能を読み出し性能重視/メモリベースのストレージエンジンで補うことができた

 一方、Write-Heavyなワークロードにおいて、 •  元のCassandraよりも性能が劣化してしまう

評価・まとめ


 Write-Heavyなワークロードでの性能劣化の分析・対処 •  MySQLへの非同期の大量の書き込み処理が、並行して行う同期的な読み出し処理の性能に影響

•  現在: リクエストとストレージエンジンの種類に応じて静的にリクエストを割り振る

•  解決策: 以下を考慮したリクエストの割り振り •  データノードごとのアクセス負荷 •  各ノードにおける参照の局所性例) データを書きこんですぐ読む場合は読み出しもwrite-optimizedノードから取得

今後の課題 (1/2)

0 1 2 3 4

write latency read latency

Cassandra MyCassandra

0

5000

10000

15000

throughput

write-heavy

cluster

26 11.4.14

書き込み性能は変わらない

　読み出し性能が劣化

　全体のスループットが劣化

 Amazon EC2などの大規模クラスタ上で評価 •  1台のプロキシ/N台のデータノードというアクセスパスは変わらないのでノード数の影響は受けないと予測

 クラスタ構成/ルーティングに以下を考慮 •  ラック/データセンターのネットワーク近接性 •  アプリの読み書き比率に応じて、最適なスループットが得られるストレージエンジンの構成比率

•  アプリケーションに応じたデータのアクセス特性

今後の課題 (2/2)


  FD-Tree: Tree Indexing on Flash Disks, VLDB ’10 •  書き込み性能と読み出し性能を両立する索引アルゴリズム •  B+tree並の検索速度 + LSM-tree並の更新速度 •  対象がSSDに限られるが、クラウドストレージへの応用が期待

  モジュラーなデータストア •  MySQL: RDBMS •  Anvil, SOSP ’09: 1ノードを対象 •  Cloudy, VLDB ’10: 実験評価はされていない •  Dynamo, SOSP ‘07: 遅延 vs. 永続性 •  MyCassandra (本研究): 読み出し vs. 書き込み

関連研究


本研究: 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 (memory) yes consistency weak (eventual, quorum) replication sync / async data partition row node organization

decentralized

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

本手法の使いどころ

アクセスパターンの異なるデータを共通キーで扱う従来: 構造を分ける

1) パターンが異なるデータごとに正規化して、それぞれのテーブルを最適化

2) MySQL + memcached 本手法: MyCassandra Cluster

- アクセスパターンの異なるデータを１つのデータ構造で扱える - 性能はストレージの割合を変えて調整

11.4.14 - mycassandra - 30

movie-id name thumb-name tag count 704122313 movieA EY37lHk5bgU sport, succer, FIFA, … 169,374

704122314 movieB Zk3BSYMWjzQ music, jazz, … 472,803

Write-Heavy Read-Heavy

動画サイトのTable