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

Cassandra Meetup in Tokyo Fall 2016

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

アジェンダ 1. Cassandra Summit 2016 keynote summary 2. 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 Industry Standard Community Global

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

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

Cassandra Internals: The Read Path Tyler Hobbs: Datastax

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

以上 感想：ストレージの効率化・高 速化のための工夫を知るのは 面白い。 パフォーマンスやキャパシティ に非常に効いてくるので、よく 理解しておきたい。 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 READ時処理手順 1. Indexから目的のパーティションを見つける 2. 目的のクラスタリングに近いIndexInfoを見つける 3. Dataファイルを読みに行く 28

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

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

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

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

余談

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

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

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

Tuning Speculative Retries to Fight Latency,
Netflix
Speculative retryの説明と実験結果の話
→レイテンシが設定値を超えた場合に追加のノードにデータを取得しにいく機能
> 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';

この設定

38

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

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レイテンシが改善 キャパシティに余裕が無いとパフォーマンスは悪化する可能性があるので注意する

C* Capacity - Planning and Forecasting at scale, Netflix

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

• http://techblog.netflix.com/2016/08/introducing-winston-event-

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

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

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

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

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

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の数

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

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

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

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

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

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

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

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

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

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

Cassandra Meetup in Tokyo, Fall 2016 私たちと、いっしょに働きませんか？ mailto : [email protected]