More Related Content
Similar to Cassandra における SSD の活用 (20)
Cassandra における SSD の活用
- 1. Cassandra における SSD の活用
10 Oct, 2018
NVM Casual Talks #1
Yuji Ito
Principal Software Engineer at Scalar, Inc.
1
- 2. © 2018 Scalar, inc.
Confidential
Self introduction
• プロセッサの研究 @ U-Tokyo
– Transactional Memory: 並列プログラムの容易化、高速化
• SSD 開発を5年 @ Hitachi, Fixstars
– ファームウェア開発が中心 (一時期は上位連携アクセラレーションとかも)
– エンタープライズ向け (SAS, SATA, NVMe), コンシューマ向け (NVMe), モバ
イル向け (UFS)
• 2年半前〜現在、分散台帳に用いる分散ストレージ周り @ Orb, Scalar
2
- 3. © 2018 Scalar, inc.
Confidential
Contents
• Scalar DLT
• Cassandra
– 特徴
– Write
– Read
– CAS (LWT: Lightweight transaction)
– SSD の活用
• Scalar DB with Cassandra
– Transaction
– Benchmark
3
- 4. © 2018 Scalar, inc.
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
- 5. © 2018 Scalar, inc.
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
- 6. © 2018 Scalar, inc.
Confidential
Cassandra: 特徴
• Scalability
– ノード数を増やすとスループットが向上
• Availability
– 一部ノードに障害があっても引き続きサービスを提供可能
• CAS (Lightweight transactions)
– 1レコードのアトミックな更新が可能
6
- 7. © 2018 Scalar, inc.
Confidential
Cassandra
• いずれのノードでもリクエストを受け取れる
7
C*
cluster
node
node node
node node
Requester
Requester
Requester Requester
Requester
- 8. © 2018 Scalar, inc.
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’
- 9. © 2018 Scalar, inc.
Confidential
Write (inside a node)
• NAND Flash SSD と同様に、追記でデータを書き込む
– 直接、間接的に大小のシーケンシャル・ライトが発生
9
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlHowDataWritten.html
- 10. © 2018 Scalar, inc.
Confidential
Write (inside a node)
• メモリ上
– memtable
– ライト・キャッシュのようなもの
– リード対象
• ディスク上
– commitlog
– レコード更新情報ログ
– 不正電源遮断後の再起動時に使用
– SSTable
– memtable 上の書き込みデータをまとめて永続化して作られる (後述)
– リード対象
10
- 11. © 2018 Scalar, inc.
Confidential
commitlog sync
11
• Write 毎 commitlog に書き込み完了しなければ本来永続化されない
– デフォルト設定で、 commitlog_sync: periodic だと消える可能性あり
– 以降では、即座に永続化する commitlog_sync: batch であるとする
• 更新情報ログとして書き込むのでシーケンシャル・ライト
– レコード・サイズや並列数によるが、ページ・サイズ 4KB 程度
• 不正電源遮断で memtable が消えても commitlog から復活 (Replay)
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlHowDataWritten.html
- 12. © 2018 Scalar, inc.
Confidential
memtable flush
• memtable が一杯になったら新しい SSTable を作る
– 複数の更新データをまとめて永続化するので、大サイズのシーケンシャル・ラ
イトになる
– 古いデータを持つ SSTable に上書きするわけではないので、SSTable は
たくさんできる
12
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlHowDataWritten.html
- 13. © 2018 Scalar, inc.
Confidential
Compaction
• Cassandra データの GC のような処理
– 追記で書き込むので、上書きされた無効なデータが SSTable 残っている
– SSTable が大量にあると Read 時にたくさんの SSTable を走査する必要が
あり、Read 性能が低下する
– 色々な compaction strategy が設定可能
• 複数の SSTable を読み込み、まとめる
– 大サイズのシーケンシャル・リード/ライトが発生
13https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlHowDataMaintain.html
- 14. © 2018 Scalar, inc.
Confidential
Read (inside a node)
14
• 色々な情報を参照して目的のデータを SSTable から読み出す (詳細割愛)
– memtable 上に存在する場合はそれを読み出す
– 基本的にはランダム・リードが発生
https://docs.datastax.com/en/cassandra/3.0/cassandra/dml/dmlAboutReads.html
- 15. © 2018 Scalar, inc.
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回更新
- 16. © 2018 Scalar, inc.
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 -
- 17. © 2018 Scalar, inc.
Confidential
I/O パターンの整理
• Throughput (MB/s) が重要 (大サイズのシーケンシャルアクセス)
– memtable flush
– Compaction
• IOPS & レイテンシ が重要 (小サイズのアクセス)
– commitlog sync
– 特に CAS 操作
– Read a record
17
- 18. © 2018 Scalar, inc.
Confidential
SSD の活用
• 各レコードの read 処理では、ランダム・アクセスで効果あり
• 現状、write スループットは CPU ネックになる
– 多並列でも数十 KIOPS もいかない
– 多並列になるほどまとめて書き込みやすくなる
– 追記型なので、シーケンシャル・ライトでディスク(HDD, SSD)に優しい I/O
– ただし、レイテンシは重要
– きちんと永続化させるなら commitlog を書くまでリクエストは完了しな
い
– CAS では特に顕在化する
18
- 19. © 2018 Scalar, inc.
Confidential
Ref. GroupCommitLog
• commitlog sync での IOPS 増加を和らげる施策: GroupCommitLog
– Cassandra コミュニティに提案、コミット済み [CASSANDRA-13530]
– Cassandra 4.0 (未リリース) から使用可能
– Write リクエストを待たせて commitlog への永続化を一定時間毎にまとめ
て行う
– periodic と異なり、永続化完了までリクエストを待たせるので、データ消
失の可能性なし
– batch に比べて、まとめて永続化するので、ディスクへの I/O 数が減る
19
- 21. © 2018 Scalar, inc.
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
- 22. © 2018 Scalar, inc.
Confidential
Scalar DB
• トランザクション機能を提供
– Cassandra の Scalability, Availability を活かしつつ、ACID トランザ
クションを実行可能
– Cassandra のテーブル作成時にメタカラムを追加
– アプリケーション側で Java ライブラリ API を呼び出すだけ
– データ自体はすべて Cassandra で管理されるので、Spark などの既存の
解析ツールも使える
• CAS を多用するため、小サイズ write は増加する → commitlog 用には SSD
の使用を推奨
22
- 23. © 2018 Scalar, inc.
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
- 24. © 2018 Scalar, inc.
Confidential
TPS (Transaction per second)
• 200 秒測定
– クラスタ構成はほぼ最小構成
– これをベースに scale-up, scale-out 可能
– CPU ネック
24
- 25. © 2018 Scalar, inc.
Confidential
Disk read (48 hours)
• IOPS, throughput ともに compaction によって時々高くなる
25
- 26. © 2018 Scalar, inc.
Confidential
Disk write (48 hours)
• IOPS: commitlog が中心
• Throughput: flush や compaction で時々高くなる
26
- 27. © 2018 Scalar, inc.
Confidential
まとめ
• Cassandra
– ライトはシーケンシャル・アクセスが主で、大小サイズが混在
– リードはランダム、シーケンシャル混在
– リクエストするアプリケーションによるが、Throughput, IOPS ともに必要とす
るため、SSD の使用が好ましい
• Scalar DB
– Cassandra で ACID トランザクション可能
– CAS のためにある程度 IOPS も必要とするので SSD 推奨
27
- 28. Scalar DB
10 Oct. 2018 (本日)
オープンソースとして公開
https://github.com/scalar-labs/scalardb
28
Editor's Notes
- コンポーネント、ネーミング修正
要件はここに