弊社で先日開催させていただいた、Cassandra meetupでの http://datastaxjp.connpass.com/event/41068/ Cassandra Summit 2016の注目セッションに関するプレゼン資料の抜粋です。

1. Cassandra Meetup in Tokyo
Fall 2016

2. データ＆サイエンスソリューション統括本部
データプラットフォーム本部
開発３部 部長
遠藤 禎士（えんどう ただし）
2012年にヤフーに中途入社 ちょうど５年目
広告のインフラを担当
2015年からデータインフラへ
自己紹介

3. アジェンダ
1. Cassandra Summit 2016 keynote summary
2. SlowQuery 開発秘話
3. Cassandra Summit 2016 注目セッション報告
4. Cassandra 3.x の最新機能
5. Cassandra データモデリング
6. クロージング
7. 懇親会

4. Cassandra Summit 2016 keynote summary
Industry Standard
Global
Community

5. Cassandra Summit 2016 keynote summary
Industry
Standard
GlobalCommunity

6. 2016年10月21日
2016年10月21日6
後藤 泰陽 @ono_matope
Cassandra Summit 2016
注目セッション報告 ①

7. Sessions
• Cassandra Internals: The Read Path
• CQL performance with Apache Cassandra 3.0
• Myths of big partitions
7

8. Cassandra Internals: The Read Path
Tyler Hobbs: Datastax

9. Cassandra Internals: The Read Path
SELECT文発行時のCassanra内部処理の概要を解説
9

10. Cassandra Internals: The Read Path
10
• ドライバ
• プリペアドステートメント
• DC/Token Aware Selection
• コーディネーターノード
• メトリクスによるレプリカ選択
• Speculative Retry
• レプリカノード
• SSTableファイルの選択・順序付け・検索終了
条件
• キャッシュ, インデックス
感想：C* 初心者の方も是非

11. CQL performance with Apache Cassandra 3.0
Aaron Morton: The Last Pickle

12. CQL performance with Apache Cassandra 3.0
• C*3.0の新ストレージエンジンの解説
12

13. 3.0以前のストレージエンジン
13
Row
Row
KVS的レイアウト。シンプルだが無駄が多い

14. 従来のフォーマットの問題点
14
1. クラスタリングが反復
2. カラム名が反復
3. タイムスタンプが反復
4. エンコーディングが固定幅

15. 従来のフォーマットの問題点
15
1. クラスタリングが反復
2. カラム名が反復
3. タイムスタンプが反復
4. エンコーディングが固定幅

16. Pre 3.0 Storage Layout
16
1. クラスタリングが反復
2. カラム名が反復
3. タイムスタンプが反復
4. エンコーディングが固定幅

17. Pre 3.0 Storage Layout
17
1. クラスタリングが反復
2. カラム名が反復
3. タイムスタンプが反復
4. エンコーディングが固定幅
Long

18. 3.0 Storage Engine
18
SSTable
Partition: part_a
Row: cluster_a
some foo
and bar
no baz
Row: cluster_b
some foo
and bar
no baz
Partition>Row>Cell(カラム)の階層構造に変更

19. 階層化
19
SSTable
Partition: part_a
Row: cluster_a
some foo
and bar
no baz
Row: cluster_b
some foo
and bar
no baz
クラスタリングの反復を排除

20. Cell Bitmap
20
SSTable
Partition: part_a
Row: cluster_a
some foo
and bar
no baz
SSTableヘッダでカラム名に番号付け
Rowは出現カラムをビットマップで管理
カラム名の反復を排除！
columns: [foo, bar, baz... ]
bitmap : 0|1|2...

21. Variable Int
• 時刻のエンコード形式をlong(8Byte)から可変長整数(VarInt)に変更
• 小さい数値は小さいサイズでエンコードできる。
• 127以下なら1Byte
21

22. Delta Encoding
• SSTableヘッダにminTimestampを格納する
• Timestampを、絶対時刻からminTimestamp
からの相対時刻表現に変更する
• VarIntと合わせてデータ量が削減
22
SSTable
Partition: part_a
minTimestamp: t1
Row: cluster_a
some
foo
varint(t2 - t1)
and bar varint(t2 - t1)
no baz varint(t3 - t1)

23. Aggregated Cell Metadata
• RowレベルのTimestampを導入
• CellレベルのTimestampがRowレベルと同じ
場合は省略する
23
SSTable
Partition: part_a
Row: cluster_a
some
foo
and bar
no baz t3
timestamp: t2

24. 以上
感想：ストレージの効率化・高
速化のための工夫を知るのは
面白い。
パフォーマンスやキャパシティ
に非常に効いてくるので、よく
理解しておきたい。
24

25. Myths of big partitions
Robert Stupp: DataStax

26. Myths of big partitions
• Big Partition
• パーティション内に大量のRow
• CASSANDRA-11206 (C*3.6)
• Big Partition問題を緩和するコミッ
ト
• 何が問題だったのか？
• 何を改善したのか？
26

27. Big Partition Issue
• SSTableは BloomFilter, Summary, Index, Data などのファイルで構成
• DataファイルにはRowのデータが格納
• IndexファイルにはDataファイルの全てのパーティションへのオフセットが格納
• 一定間隔でサンプリングされたRowのオフセット位置を示すIndexInfoも格納
27

28. Big Partition Issue
28
READ時処理手順
1. Indexから目的のパーティションを見つける
2. 目的のクラスタリングに近いIndexInfoを見つける
3. Dataファイルを読みに行く

29. Big Partition Issue
29
READ時処理手順
1. Indexから目的のパーティションを見つける
2. 目的のクラスタリングに近いIndexInfoを見つける
3. Dataファイルを読みに行く
パーティション内の全ての
IndexInfoをヒープにロードしている

30. Big Partition Issue
• 2GBのパーティションの場合、32,768 IndexInfo (42万Java Objects)
• GCプレッシャーが高まり不安定に
• バイナリサーチにより 15 IndexInfoしか使わないのに。無駄！
30

31. CASSANDRA-11206
• 一定サイズを超過するIndexInfoはロードせず、ディスクアクセスするよう変更
• column_index_cache_size_in_kb (default: 2)
• GCプレッシャーが大幅に削減され、高速化
• 10個の15GBパーティションをコンパクションしても問題なかった
31

32. CASSANDRA-9754
• SSTableのIndexのレイアウトそのものを改良するチケット
• B+Treeベースの独自フォーマット
• Cassandra 4.xでのマージを目指している
32

33. 余談

34. CASSANDRA-12731
• 帰国後、#11206パッチに無駄なIndexInfo配列のアロケーションを発見
• 削除したところ2,30%ほど高速化
• パッチを送ったらマージしてもらえたので、3.10に入ります 😀
• 感想
• 早く3.x入れたい!! Production Readyはいつ…?
34

35. 2016年10月21日
2016年10月21日35
鄭 中翔
Cassandra Summit 2016
注目セッション報告 ②

36. 36
概要
• 運用、チューニング、利用事例に関連するセッションを中心に参
加
• 下記のセッションを紹介します
• Tuning Speculative Retries to Fight Latency, Netflix
• C* Capacity - Planning and Forecasting at scale, Netflix
• How we built user specific search using C* without Solr, Sony
• Always On: Building Highly Available Applications on Cassandra,
The Weather Company (IBM)

37. Tuning Speculative Retries to Fight Latency,
Netflix

38. 38
Tuning Speculative Retries to Fight Latency,
Netflix
> DESCRIBE TABLE system.local
CREATE TABLE system.local (
key text PRIMARY KEY,
bootstrapped text,
...
truncated_at map<uuid, blob>
) WITH bloom_filter_fp_chance = 0.01
AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
AND comment = 'information about the local node'
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND dclocal_read_repair_chance = 0.0
AND default_time_to_live = 0
AND gc_grace_seconds = 0
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 3600000
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99.0PERCENTILE';
Speculative retryの説明と実験結果の話
この設定
→レイテンシが設定値を超えた場合に追加のノードにデータを取得しにいく機能

39. • Cassandra: 12nodes(8cores/60GB RAM) / 120GB data per node
• Client: 6 (8cores/30GB RAM)
• tcコマンドで1ノードにパケット遅延を発生させネットワーク障害を
シミュレート
39
Tuning Speculative Retries to Fight Latency,
Netflix
実験

40. 40
Tuning Speculative Retries to Fight Latency,
Netflix
Speculative Retry なし 95percentile
スループット 50K reads/sec,
3K writes/sec
30K reads/secに低下
write 言及なし
平均レイテンシ 0.5ms 1ms
95th/99th レイテンシ スパイクが2~10倍に増加
• 高負荷な場合
Speculative Retry なし 95percentile
スループット 18K reads/sec,
1K writes/sec
20+K reads/secに増加
write 言及なし
平均レイテンシ 0.5ms 1ms
95th/99th レイテンシ レイテンシ低下
スパイクなし、安定
• 低負荷な場合
→キャパシティを余分に確保しSpeculative Retryを有効にすることで95/99thレイテンシが改善
キャパシティに余裕が無いとパフォーマンスは悪化する可能性があるので注意する

41. C* Capacity - Planning and Forecasting at scale,
Netflix

42. C* Capacity - Planning and Forecasting at scale,
Netflix
• Metrics → Atlas → pagerduty
• メトリクス間の複雑な関係のチェックができない
• ハードウェア障害による誤検知が発生する
• Winston
• Atlas→Winston→pagerduty
• メトリクス間の関係性をチェック
• 誤検知を削減
• http://techblog.netflix.com/2016/08/introducing-winston-event-
driven.html
42

43. C* Capacity - Planning and Forecasting at scale,
Netflix
• アラートを受けたときにはもう遅いかも
→予測して事前に通知させたい
• ARIMA(Auto Regressive Integrated Moving Average
• : 自己回帰和分移動平均)モデルで予測して通知
43
→

44. How we built user specific search using C*
without Solr, Sony

45. How we built user specific search using C*
without Solr, Sony
• 購入履歴のデータは複数のサービスからリアルタイムで必要とされた
→高可用性、速さ、スケールのしやすさが必要
→RDBの前にC*を置いて解決
• しかしCQLではJoin、トランザクション、検索ができない
• 各ユーザのデータに対するクエリがほとんどだった→joinはできなくても大丈夫
→購入履歴を非正規化してjson形式でCassandraに保持
主キーはアカウント、一つの購入履歴が1つのカラム
45
PlayStation StoreのRDBに対するクエリの一部をCassandraで受ける
話
Account1 Json 1 Json 2 …. Json n
クエリをから要件を確認

46. 46
How we built user specific search using C*
without Solr, Sony
検索、ソート、フィルタはどのように実現するか？
• セカンダリインデックス
→スケールしない、いろいろつらい
• データをすべてロードしてメモリ内で処理
→できなことはない
• Solr
→ユースケースに合わない

47. 47
How we built user specific search using C*
without Solr, Sony
Account1 Json 1 Json n Version
ユーザ毎にLuceneでインデックスを作成しCassandraに格納
• 行内のすべてを検索できる
• インデックスのサイズも小さい
• クエリのたびにインデックスを引くのは非効率
• 同じ行に異なるサーバから書き込まれると？
しかし

48. 48
How we built user specific search using C*
without Solr, Sony
Account
1
Version
Account
2
Version
Account
3
Version
Account
4
Version
Account
5
Version
Account
6
Version
Account1 jsons Version
Account2 jsons Version
Account3 jsons Version
Account4 jsons Version
Account5 jsons Version
…. … … …
Account n jsons Version
Instance 1
Instance 2
Instance 3
Cassandra
Cassandraの前に分散キャッシュを置いて解決

49. Always On: Building Highly Available Applications on
Cassandra, The Weather Company (IBM)

50. Always On: Building Highly Available Applications on Cassandra, The
Weather Company (IBM)
• トポロジーの設定
• 一つのラックにすべてノードを置かない
• Multi-DCクラスタにおいて非LocalなConsistency Levelは避ける等
• Cassandraに適したデータモデル
• 主キーが異なるデータをまとめて書き込む際にbatchは使わない
• 複数のパーティションにまたがるようなクエリを投げない等
• 監視で注目した方がよい点
• C*はSEDAなのでスレッドプールの状態に注意
• コンパションが遅れていないか
• Size-TieredではSStableの数
• LeveledではL0のSStableの数
50
可用性を高めるためにするべきこと、するべきではないことが一通りまとめられてい
る

51. 2016年10月21日
2016年10月21日51
今野 賢
Cassandra Summit 2016
注目セッション報告 ③

52. 概要
• Cassandra Summitでの弊社実績について講演
セッションは、C*の応用や仮想化などを中心に参加
• 下記のセッションを紹介します
• Cassandra @ Yahoo, Yahoo! JAPAN
• CassieQ: The distributed message queue built on
cassandra, Curalate
• Running Cassandra on Apache Mesos Across Multiple
Datacenters at Uber, Uber
52

53. Cassandra @ Yahoo, Yahoo! JAPAN
• 弊社の運用課題、OSS貢献について講演
53

54. CassieQ: The distributed message queue built on cassandra, Curalate
• C*(Cassandra)ベースのMQ(MessageQueue)実装
54

55. CassieQ: The distributed message queue built on cassandra, Curalate
• C*ベースの利点
マスターレス、高可用性、高分散性など
→ アトミック処理実装には軽量トランザクションを利用
• C*ベースのMQは他にも …
Netflix : Astyanax recipe
Comcast : CMB
→ (ただし基本実装はRedis、永続化にC*を利用)
55

56. CassieQ: The distributed message queue built on cassandra, Curalate
• 関連セッション① : One Billion Black Friday Shoppers on a
Distributed Data Store, Bazaarvoice
EmoDB : C*ベースの高機能(SoR)データストア
→ スナップショット機能や、CRDTデータ型サポート
56

57. CassieQ: The distributed message queue built on cassandra, Curalate
• 今後、C*の分散基盤ソフトウェアとしての活用にも注目
• 関連セッション② : Clock Skew, and other annoying realities in
distributed systems, PagerDuty
→ 分散システムとしてのC*の整合性、独立性、
原子性など動作についての講演
57
Master Slave
Master
Less

58. Running Cassandra on Apache Mesos Across Multiple Datacenters at Uber, Uber
• 発表者は元Google、 Borg(Kubernetes)論文の第一著者
• Mesos採用理由
高可用性、リソース抽象化、線形スケラビリティなど
• C*採用理由
高可用性、水平スケラビリティ、低遅延など
58

59. Running Cassandra on Apache Mesos Across Multiple Datacenters at Uber, Uber
• Custom Seed Provider
ノード増設時に既存Seedノード応答用のAPIを準備
59

60. Running Cassandra on Apache Mesos Across Multiple Datacenters at Uber, Uber
• Cassandra on Mesosの導入が進む?
• 関連セッション① : Infrastructure for Fast
Delivery, Mesosphere
→ Mesosphereによるベンダー講演
• 関連セッション② : Cassandra @ Yahoo,
Yahoo! JAPAN
→ OpenStack Troveへの取り組み紹介
• 関連情報 : Thousand Instances of
Cassandra using Kubernetes Pet Set
60

61. Cassandra Meetup in Tokyo, Fall 2016
私たちと、いっしょに働きませんか？
mailto : nosql-jobs@mail.yahoo.co.jp