Cassandra Summit 2016 注目セッション報告

Cassandra Meetup in Tokyo Fall 2016

データ＆サイエンスソリューション統括本部データプラットフォーム本部開発３部部長遠藤禎士（えんどうただし）

2012 年にヤフーに中途入社ちょうど５年目広告のインフラを担当2015 年からデータインフラへ

自己紹介

アジェンダ

1. Cassandra Summit 2016 keynote summary2. SlowQuery 開発秘話

3. Cassandra Summit 2016 注目セッション報告

4. Cassandra 3.x の最新機能

5. Cassandra データモデリング

6. クロージング

7. 懇親会

Cassandra Summit 2016 keynote summary

Industry Standard

Global

Community

Cassandra Summit 2016 keynote summary

IndustryStandard

GlobalCommunity

May 2, 20236

May 2, 2023後藤泰陽 @ono_matope

Cassandra Summit 2016 注目セッション報告 ①

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

7

Cassandra Internals: The Read Path

Tyler Hobbs: Datastax


SELECT 文発行時の Cassanra 内部処理の概要を解説

9


10

• ドライバ• プリペアドステートメント• DC/Token Aware Selection

• コーディネーターノード• メトリクスによるレプリカ選択• Speculative Retry

• レプリカノード• SSTable ファイルの選択・順序付け・検索終了

条件• キャッシュ , インデックス

感想： C* 初心者の方も是非

CQL performance with Apache Cassandra 3.0

Aaron Morton: The Last Pickle

CQL performance with Apache Cassandra 3.0

• C*3.0 の新ストレージエンジンの解説

12

3.0 以前のストレージエンジン

13

Row

Row

KVS 的レイアウト。シンプルだが無駄が多い

従来のフォーマットの問題点

14

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

幅

従来のフォーマットの問題点

15


幅

Pre 3.0 Storage Layout

16


幅

Pre 3.0 Storage Layout

17


幅

Long

3.0 Storage Engine

18

SSTable

Partition: part_aRow: cluster_a

some fooand barno baz

Row: cluster_bsome fooand barno baz

Partition>Row>Cell( カラム ) の階層構造に変更

階層化

19

SSTable



Row: cluster_bsome fooand barno baz

クラスタリングの反復を排除

Cell Bitmap

20

SSTable



SSTable ヘッダでカラム名に番号付け

Row は出現カラムをビットマップで管理

カラム名の反復を排除！columns: [foo, bar, baz... ]

bitmap : 0|1|2...

Variable Int• 時刻のエンコード形式を long(8Byte) から可変長整数 (VarInt) に

変更• 小さい数値は小さいサイズでエンコードできる。• 127 以下なら 1Byte

21

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)

Aggregated Cell Metadata• Row レベルの Timestamp を導入• Cell レベルの Timestamp が Row レ

ベルと同じ場合は省略する

23

SSTable


some fooand barno baz t3

timestamp: t2

以上

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

24

Myths of big partitions

Robert Stupp: DataStax

Myths of big partitions• Big Partition

• パーティション内に大量の Row• CASSANDRA-11206 (C*3.6)

• Big Partition 問題を緩和するコミット

• 何が問題だったのか？• 何を改善したのか？

26

Big Partition Issue• SSTable は BloomFilter, Summary, Index, Data などのファイルで構成

• Data ファイルには Row のデータが格納

• Index ファイルには Data ファイルの全てのパーティションへのオフセットが格納

• 一定間隔でサンプリングされた Row のオフセット位置を示す IndexInfo も格納

27

Big Partition Issue

28

READ 時処理手順

1. Index から目的のパーティションを見つける

2. 目的のクラスタリングに近い IndexInfo を見つける

3. Data ファイルを読みに行く

Big Partition Issue

29

READ 時処理手順

1. Index から目的のパーティションを見つける

2. 目的のクラスタリングに近い IndexInfo を見つける

3. Data ファイルを読みに行く

パーティション内の全てのIndexInfo をヒープにロードしている

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

30

CASSANDRA-11206• 一定サイズを超過する IndexInfo はロードせず、ディスクアクセスするよう変更

• column_index_cache_size_in_kb (default: 2)• GC プレッシャーが大幅に削減され、高速化• 10個の 15GB パーティションをコンパクションしても問題なかった

31

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

32

余談

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

• 早く 3.x 入れたい !! Production Ready はいつ… ?

34

May 2, 202335

May 2, 2023鄭　中翔

Cassandra Summit 2016

注目セッション報告 ②

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)

Tuning Speculative Retries to Fight Latency,

Netflix

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 ノードにパケット遅延を発生させネットワーク障害をシミュレート


実験

40


Speculative Retry なし 95percentileスループット 50K reads/sec,

3K writes/sec30K reads/sec に低下write 言及なし

平均レイテンシ 0.5ms 1ms95th/99th レイテンシスパイクが 2~10倍に増加

• 高負荷な場合

Speculative Retry なし 95percentileスループット 18K reads/sec,

1K writes/sec20+K reads/sec に増加write 言及なし

平均レイテンシ 0.5ms 1ms95th/99th レイテンシレイテンシ低下

スパイクなし、安定

• 低負荷な場合

→キャパシティを余分に確保し Speculative Retry を有効にすることで 95/99th レイテンシが改善キャパシティに余裕が無いとパフォーマンスは悪化する可能性があるので注意する

C* Capacity - Planning and Forecasting at

scale,

Netflix

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

C* Capacity - Planning and Forecasting at scale,Netflix

• アラートを受けたときにはもう遅いかも→予測して事前に通知させたい

• ARIMA(Auto Regressive Integrated Moving Average• : 自己回帰和分移動平均 ) モデルで予測して通知

43

→

How we built user specific search using C*

without Solr, Sony

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


検索、ソート、フィルタはどのように実現するか？• セカンダリインデックス　→スケールしない、いろいろつらい

• データをすべてロードしてメモリ内で処理

　→できなことはない• Solr　→ユースケースに合わない

47


Account1 Json 1 Json n Version

ユーザ毎に Lucene でインデックスを作成し Cassandra に格納

• 行内のすべてを検索できる• インデックスのサイズも小さい

• クエリのたびにインデックスを引くのは非効率• 同じ行に異なるサーバから書き込まれると？

しかし

48


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 の前に分散キャッシュを置いて解決

Always On: Building Highly Available

Applications on Cassandra, The Weather

Company (IBM)

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

可用性を高めるためにするべきこと、するべきではないことが一通りまとめられている

May 2, 202351

May 2, 2023今野賢

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

53

Cassandra @ Yahoo, Yahoo! JAPAN

• 弊社の運用課題、 OSS貢献について講演

54

CassieQ: The distributed message queue built on cassandra, Curalate

• C*(Cassandra) ベースの MQ(MessageQueue)実装　

55


• C* ベースの利点

マスターレス、高可用性、高分散性など　→ アトミック処理実装には軽量トランザクションを利用

• C* ベースの MQ は他にも …

Netflix : Astyanax recipeComcast : CMB　→ ( ただし基本実装は Redis 、永続化に C* を利用 )

56


• 関連セッション① : One Billion Black Friday Shoppers on a Distributed Data Store, Bazaarvoice

EmoDB : C* ベースの高機能 (SoR) データストア　→ スナップショット機能や、 CRDT データ型サポート

57


• 今後、 C* の分散基盤ソフトウェアとしての活用にも注目

• 関連セッション② : Clock Skew, and other annoying realities in distributed systems, PagerDuty　→ 分散システムとしての C* の整合性、独立性、　　原子性など動作についての講演

Master Slave

Master Less

58

Running Cassandra on Apache Mesos Across Multiple Datacenters at Uber, Uber

• 発表者は元Google 、 Borg(Kubernetes)論文の第一著者• Mesos採用理由

高可用性、リソース抽象化、線形スケラビリティなど• C*採用理由

高可用性、水平スケラビリティ、低遅延など

59


• Custom Seed Providerノード増設時に既存 Seed ノード応答用の API を準備

60


• Cassandra on Mesos の導入が進む ?• 関連セッション① : Infrastructure for Fast

Delivery, Mesosphere　→ Mesosphere によるベンダー講演

• 関連セッション② : Cassandra @ Yahoo, Yahoo! JAPAN　→ OpenStack Trove への取り組み紹介

• 関連情報 : Thousand Instances of Cassandra using Kubernetes Pet Set

Cassandra Meetup in Tokyo, Fall 2016

私たちと、いっしょに働きませんか？

mailto : [email protected]

Technology

Cassandra Summit 2016 注目セッション報告