Cassandra における SSD の活用

Cassandra における SSD の活用
10 Oct, 2018
NVM Casual Talks #1
Yuji Ito
Principal Software Engineer at Scalar, Inc.
1

© 2018 Scalar, inc.
Confidential
Self introduction
• プロセッサの研究 @ U-Tokyo
– Transactional Memory: 並列プログラムの容易化、高速化
• SSD 開発を5年 @ Hitachi, Fixstars
– ファームウェア開発が中心 (一時期は上位連携アクセラレーションとかも)
– エンタープライズ向け (SAS, SATA, NVMe), コンシューマ向け (NVMe), モバ
イル向け (UFS)
• 2年半前〜現在、分散台帳に用いる分散ストレージ周り @ Orb, Scalar
2

Confidential
Contents
• Scalar DLT
• Cassandra
– 特徴
– Write
– Read
– CAS (LWT: Lightweight transaction)
– SSD の活用
• Scalar DB with Cassandra
– Transaction
– Benchmark
3

Confidential
4
Distributed Database
Spanner• Finality
• Consistency
• Scalability
• Availability
• Performance
Blockchain
• Tamper-Evidence
• Determinism
• Decentralization
Scalar DLT
Distributed Ledger Platform
toward a fusion of
Distributed Database and Blockchain
Scalar DLT – Blockchain-inspired Distributed Ledger Platform
Finality
Consistency
Scalability
Availability
Performance
Tamper-Evidence
Determinism
Decentralization

Confidential
Scalar DLT Software Architecture
5
Scalar DB
Scalar DL
Master-less Distributed Transaction Manager
Tamper-Evident Distributed Ledger with SmartContract
Scalar DM
Distributed Deterministic-ordering Manager
Scalar DLT
Oracle On-Premise
Distributed Storage
Finality
Consistency
Scalability
Availability
Performance
Tamper-Evidence
Decentralization
Tamper-Evidence
Determinism
Decentralization

Confidential
Cassandra: 特徴
• Scalability
– ノード数を増やすとスループットが向上
• Availability
– 一部ノードに障害があっても引き続きサービスを提供可能
• CAS (Lightweight transactions)
– 1レコードのアトミックな更新が可能
6

Confidential
Cassandra
• いずれのノードでもリクエストを受け取れる
7
C*
cluster
node
node node
node node
Requester
Requester
Requester Requester
Requester

Confidential
Cassandra
• Replication factor 分のノードが同じデータを持つ
– ただし、一貫性保証は consistency level による
8
C*
cluster
node
node node
node node
Requester
AA’
A
A
Replication factor = 3
A’
A’
A’
Requester
A’

Confidential
Write (inside a node)
• NAND Flash SSD と同様に、追記でデータを書き込む
– 直接、間接的に大小のシーケンシャル・ライトが発生
9
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlHowDataWritten.html

Confidential
Write (inside a node)
• メモリ上
– memtable
– ライト・キャッシュのようなもの
– リード対象
• ディスク上
– commitlog
– レコード更新情報ログ
– 不正電源遮断後の再起動時に使用
– SSTable
– memtable 上の書き込みデータをまとめて永続化して作られる (後述)
– リード対象
10

Confidential
commitlog sync
11
• Write 毎 commitlog に書き込み完了しなければ本来永続化されない
– デフォルト設定で、 commitlog_sync: periodic だと消える可能性あり
– 以降では、即座に永続化する commitlog_sync: batch であるとする
• 更新情報ログとして書き込むのでシーケンシャル・ライト
– レコード・サイズや並列数によるが、ページ・サイズ 4KB 程度
• 不正電源遮断で memtable が消えても commitlog から復活 (Replay)

Confidential
memtable flush
• memtable が一杯になったら新しい SSTable を作る
– 複数の更新データをまとめて永続化するので、大サイズのシーケンシャル・ラ
イトになる
– 古いデータを持つ SSTable に上書きするわけではないので、SSTable は
たくさんできる
12

Confidential
Compaction
• Cassandra データの GC のような処理
– 追記で書き込むので、上書きされた無効なデータが SSTable 残っている
– SSTable が大量にあると Read 時にたくさんの SSTable を走査する必要が
あり、Read 性能が低下する
– 色々な compaction strategy が設定可能
• 複数の SSTable を読み込み、まとめる
– 大サイズのシーケンシャル・リード/ライトが発生
13https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlHowDataMaintain.html

Confidential
Read (inside a node)
14
• 色々な情報を参照して目的のデータを SSTable から読み出す (詳細割愛)
– memtable 上に存在する場合はそれを読み出す
– 基本的にはランダム・リードが発生
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutReads.html

Confidential
CAS (LWT: Lightweight transactions)
• あるレコードについて、複数ノード(replication factor分)で同じ値を持っているこ
とを保証する
– Paxos ベースのコンセンサス・アルゴリズムを利用
– ざっくり言えば、過半数ノードが同じ値で読み書きできたら成功
– 処理過程で Paxos state を逐一 write している (小サイズ)
– CAS Read では 1回、CAS Write では 3 回の Paxos テーブル更新
write が必要
→ CAS Read でも 1 回の write が発生、CAS Write ではユーザテーブ
ルと合わせ、4 回 write が発生
15
Paxos-ID State
a1-1111 proposed
Key Val
a1 A’
Paxos table User table
3回更新 1回更新

Confidential
I/O パターンの整理
16
I/O pattern Seq. read Seq. write Rnd. read Rnd. write
commitlog sync - Small size - -
memtable flush - Large size - -
Compaction Large size Large size - -
Read a record - - Small size -
CAS - Small size Small size -

Confidential
I/O パターンの整理
• Throughput (MB/s) が重要 (大サイズのシーケンシャルアクセス)
– memtable flush
– Compaction
• IOPS & レイテンシが重要 (小サイズのアクセス)
– commitlog sync
– 特に CAS 操作
– Read a record
17

Confidential
SSD の活用
• 各レコードの read 処理では、ランダム・アクセスで効果あり
• 現状、write スループットは CPU ネックになる
– 多並列でも数十 KIOPS もいかない
– 多並列になるほどまとめて書き込みやすくなる
– 追記型なので、シーケンシャル・ライトでディスク(HDD, SSD)に優しい I/O
– ただし、レイテンシは重要
– きちんと永続化させるなら commitlog を書くまでリクエストは完了しな
い
– CAS では特に顕在化する
18

Confidential
Ref. GroupCommitLog
• commitlog sync での IOPS 増加を和らげる施策: GroupCommitLog
– Cassandra コミュニティに提案、コミット済み [CASSANDRA-13530]
– Cassandra 4.0 (未リリース) から使用可能
– Write リクエストを待たせて commitlog への永続化を一定時間毎にまとめ
て行う
– periodic と異なり、永続化完了までリクエストを待たせるので、データ消
失の可能性なし
– batch に比べて、まとめて永続化するので、ディスクへの I/O 数が減る
19

Scalar DB
Master-less Distributed Transaction Manager
20

Confidential
Cassandra はトランザクション機能なし
• CAS の対象は 1 レコードのみなので、複数のレコードをアトミックに更新できない
21
a = cassandra.get(keyA);
b = cassandra.get(keyB);
a.balance -= 100;
b.balance += 100;
cassandra.put(a);
cassandra.put(b);
c = cassandra.get(keyC);
b = cassandra.get(keyB);
c.balance -= 500;
b.balance += 500;
cassandra.put(c);
cassandra.put(b);
TX1 (A から B への送金) TX2 (C から B への送金)
time
TX1, TX2 ともに b の
balance は更新前なので
1000
TX1 により b の balance は
1100 へ更新
TX2 により b の balance は
1500 へ更新
(TX1 がなかったことになる)
b の balance は 1000

Confidential
Scalar DB
• トランザクション機能を提供
– Cassandra の Scalability, Availability を活かしつつ、ACID トランザ
クションを実行可能
– Cassandra のテーブル作成時にメタカラムを追加
– アプリケーション側で Java ライブラリ API を呼び出すだけ
– データ自体はすべて Cassandra で管理されるので、Spark などの既存の
解析ツールも使える
• CAS を多用するため、小サイズ write は増加する → commitlog 用には SSD
の使用を推奨
22

Confidential
Benchmark
• Node machine
– AWS EC2 i3.xlarge
– 4 vCPUs, 30.5 GB RAM, NVMe SSD 950 GB
• Cassandra cluster
– 3 nodes
– Replication factor: 3
• Workload
– A transaction transfers an amount from an account to another one
– 100,000 accounts
23

Confidential
TPS (Transaction per second)
• 200 秒測定
– クラスタ構成はほぼ最小構成
– これをベースに scale-up, scale-out 可能
– CPU ネック
24

Confidential
Disk read (48 hours)
• IOPS, throughput ともに compaction によって時々高くなる
25

Confidential
Disk write (48 hours)
• IOPS: commitlog が中心
• Throughput: flush や compaction で時々高くなる
26

Confidential
まとめ
• Cassandra
– ライトはシーケンシャル・アクセスが主で、大小サイズが混在
– リードはランダム、シーケンシャル混在
– リクエストするアプリケーションによるが、Throughput, IOPS ともに必要とす
るため、SSD の使用が好ましい
• Scalar DB
– Cassandra で ACID トランザクション可能
– CAS のためにある程度 IOPS も必要とするので SSD 推奨
27

Scalar DB
10 Oct. 2018 (本日)
オープンソースとして公開
https://github.com/scalar-labs/scalardb
28

Cassandra における SSD の活用

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Cassandra における SSD の活用

Ähnlich wie Cassandra における SSD の活用 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (10)

Cassandra における SSD の活用

Hinweis der Redaktion