---
title: Cassandra Summit 2016 注目セッション報告
tags: 
author: [Yahoo!デベロッパーネットワーク](https://www.docswell.com/user/ydnjp)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/LJL99RZQ7R.jpg?width=480
description: 弊社で先日開催させていただいた、Cassandra meetupでの http://datastaxjp.connpass.com/event/41068/ Cassandra Summit 2016の注目セッションに関するプレゼン資料の抜粋です。
published: October 20, 16
canonical: https://www.docswell.com/s/ydnjp/K3DLDZ-2016-10-20%20-143919
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/LJL99RZQ7R.jpg)

Cassandra Meetup in Tokyo
Fall 2016


# Page. 2

![Page Image](https://bcdn.docswell.com/page/47MZZR4KJW.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/P7R66RW6E9.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/PJXMMRPDEX.jpg)

Cassandra Summit 2016 keynote summary
Industry Standard
Global
Community


# Page. 5

![Page Image](https://bcdn.docswell.com/page/3JKGGRDD7D.jpg)

Cassandra Summit 2016 keynote summary
Industry
Standard
Community
Global


# Page. 6

![Page Image](https://bcdn.docswell.com/page/LE3NN8RPE5.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/8EDWWMY37G.jpg)

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


# Page. 8

![Page Image](https://bcdn.docswell.com/page/V7P99R6PJ8.jpg)

Cassandra Internals: The Read Path
Tyler Hobbs: Datastax


# Page. 9

![Page Image](https://bcdn.docswell.com/page/2JVMMR3VJQ.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/5EGGGM31EL.jpg)

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


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4JQXXR5NEP.jpg)

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


# Page. 12

![Page Image](https://bcdn.docswell.com/page/K7466893E1.jpg)

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


# Page. 13

![Page Image](https://bcdn.docswell.com/page/LJ1VV2KZEG.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/GJWLLRD6E2.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/4EZMMRGRJ3.jpg)

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


# Page. 16

![Page Image](https://bcdn.docswell.com/page/Y76NNRY17V.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/G75558GL74.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/9J2NNKY3ER.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/DEYPPNG8EM.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/VJN55XG978.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/YE9YY8W3J3.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/GE8668NL7D.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/LEL99RPQJR.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/4JMZZR2KEW.jpg)

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


# Page. 25

![Page Image](https://bcdn.docswell.com/page/PJR66RM679.jpg)

Myths of big partitions
Robert Stupp: DataStax


# Page. 26

![Page Image](https://bcdn.docswell.com/page/PEXMMRVD7X.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/3EKGGRQDJD.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/L73NN8PP75.jpg)

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


# Page. 29

![Page Image](https://bcdn.docswell.com/page/87DWWML3JG.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/VJP99R2PE8.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/2EVMMRDVEQ.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/57GGGMY17L.jpg)

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


# Page. 33

![Page Image](https://bcdn.docswell.com/page/4EQXXRMN7P.jpg)

余談


# Page. 34

![Page Image](https://bcdn.docswell.com/page/KJ4668V371.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/LE1VV23Z7G.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/GEWLLRP672.jpg)

概要
•
•
運用、チューニング、利用事例に関連するセッションを中心に参
加
下記のセッションを紹介します
•
•
•
•
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)


# Page. 37

![Page Image](https://bcdn.docswell.com/page/47ZMMRKRE3.jpg)

Tuning Speculative Retries to Fight Latency,
Netflix


# Page. 38

![Page Image](https://bcdn.docswell.com/page/YJ6NNRQ1JV.jpg)

Tuning Speculative Retries to Fight Latency,
Netflix
Speculative retryの説明と実験結果の話
→レイテンシが設定値を超えた場合に追加のノードにデータを取得しにいく機能
&gt; DESCRIBE TABLE system.local
CREATE TABLE system.local (
key text PRIMARY KEY,
bootstrapped text,
...
truncated_at map&lt;uuid, blob&gt;
) WITH bloom_filter_fp_chance = 0.01
AND caching = &#039;{&quot;keys&quot;:&quot;ALL&quot;, &quot;rows_per_partition&quot;:&quot;NONE&quot;}&#039;
AND comment = &#039;information about the local node&#039;
AND compaction = {&#039;class&#039;: &#039;org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy&#039;}
AND compression = {&#039;sstable_compression&#039;: &#039;org.apache.cassandra.io.compress.LZ4Compressor&#039;}
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 = &#039;99.0PERCENTILE&#039;;
この設定
38


# Page. 39

![Page Image](https://bcdn.docswell.com/page/GJ5558RLJ4.jpg)

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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/LE3NN8PDE5.jpg)

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


# Page. 41

![Page Image](https://bcdn.docswell.com/page/8EDWWML27G.jpg)

C* Capacity - Planning and Forecasting at scale,
Netflix


# Page. 42

![Page Image](https://bcdn.docswell.com/page/V7P99R2LJ8.jpg)

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


# Page. 43

![Page Image](https://bcdn.docswell.com/page/2JVMMRD6JQ.jpg)

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


# Page. 44

![Page Image](https://bcdn.docswell.com/page/5EGGGMY2EL.jpg)

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


# Page. 45

![Page Image](https://bcdn.docswell.com/page/4JQXXRM9EP.jpg)

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


# Page. 46

![Page Image](https://bcdn.docswell.com/page/K746684RE1.jpg)

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


# Page. 47

![Page Image](https://bcdn.docswell.com/page/LJ1VV24VEG.jpg)

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


# Page. 48

![Page Image](https://bcdn.docswell.com/page/GJWLLRX3E2.jpg)

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


# Page. 49

![Page Image](https://bcdn.docswell.com/page/4EZMMR6GJ3.jpg)

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


# Page. 50

![Page Image](https://bcdn.docswell.com/page/Y76NNR2Q7V.jpg)

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


# Page. 51

![Page Image](https://bcdn.docswell.com/page/G755582274.jpg)

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


# Page. 52

![Page Image](https://bcdn.docswell.com/page/9J2NNK41ER.jpg)

概要
•
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


# Page. 53

![Page Image](https://bcdn.docswell.com/page/DEYPPNM4EM.jpg)

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


# Page. 54

![Page Image](https://bcdn.docswell.com/page/VJN55XW678.jpg)

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


# Page. 55

![Page Image](https://bcdn.docswell.com/page/YE9YY8XRJ3.jpg)

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


# Page. 56

![Page Image](https://bcdn.docswell.com/page/GE86682G7D.jpg)

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


# Page. 57

![Page Image](https://bcdn.docswell.com/page/LEL99R2XJR.jpg)

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


# Page. 58

![Page Image](https://bcdn.docswell.com/page/4JMZZR83EW.jpg)

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


# Page. 59

![Page Image](https://bcdn.docswell.com/page/PJR66R5R79.jpg)

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


# Page. 60

![Page Image](https://bcdn.docswell.com/page/PEXMMRKY7X.jpg)

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


# Page. 61

![Page Image](https://bcdn.docswell.com/page/3EKGGR54JD.jpg)

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


