Next Generation

Apache Cassandra

データ＆サイエンスソリューション統括本部データプラットフォーム本部開発３部KVS

星井祥吾

今日のアジェンダ

• 自己紹介

• Cassandra利用状況

• Cassandra利用事例

• NGCCとは？

• NGCC発表内容

• NGCC重要トピック

• 最後に

2

今日のアジェンダ

• 自己紹介

• Cassandra利用状況

• Cassandra利用事例

• NGCCとは？

• NGCC発表内容

• NGCC重要トピック

• 最後に

3

• Cassandraオペレータ– 広告部署から全社KVSチームに異動 -> サービス側にKVSプラット

フォームを提供、運用

• Cassandra自動デプロイシステムの刷新を担当– Chef

– Jenkins

• Cassandraコントリビュータ– https://github.com/shoshii

• Video gamer– PSN ID: kobuchizawa0102

自己紹介

4

今日のアジェンダ

• 自己紹介

• Cassandra利用状況

• Cassandra利用事例

• NGCCとは？

• NGCC発表内容

• NGCC重要トピック

• 最後に

5

提供サービスMedia

US

Search Video Answer Mail

JP

US

JP

Membership C2C Payment C2C EC B2C EC Local

Search Knowledge search MailNews

YAHUOKU!Premium Wallet Loco

利用データベース

7

300

Systems

Yahoo! JAPAN

Cassandra利用システムは約100

Cassandraクラスタ状況

8

50clusters

30TBusages

1000nodes

300,000

read/sec

100,000

write/sec

2016

10nodes

160nodes

…1

Common

clusters

50Special

clusters

50systems

50systems

3DCs

今日のアジェンダ

• 自己紹介

• Cassandra利用状況

• Cassandra利用事例

• NGCCとは？

• NGCC発表内容

• NGCC重要トピック

• 最後に

9

利用事例 #1 : パーソナルデータ

• 月間3000万のアクティブユーザーID属性

• 弊社プライバシーポリシー[1]に基づき、各サービスに応じて様々な属性を格納

10

個人属性

[1] Yahoo! JAPAN利用規約 第2章 プライバシーポリシー

エンドユーザの趣味嗜好

アプリ通知メッセージ

利用事例 #2 : 行動履歴

• 弊社プライバシーポリシー[1]に基づき、各サービスの履歴データを格納

11

[1] Yahoo! JAPAN利用規約 第2章 プライバシーポリシー

行動履歴

広告クリック履歴・CV履歴

リアルタイム検索ツイート閲覧ログ

利用事例 #3 : コンテンツキャッシュ

• RDBのコンテンツ情報や、集計情報などを格納し、各サービスのスケールアウトに活用

12

メタデータ集計情報

電子書籍：商品ID、レコメ情報

ニュース：テーマID、記事ID、記事内容

今日のアジェンダ

• 自己紹介

• Cassandra利用状況

• Cassandra利用事例

• NGCCとは？

• NGCC発表内容

• NGCC重要トピック

• 最後に

13

Next Generation Cassandra Conference

• Cassandraトップコントリビュータが集まる国際会議

• ほぼDataStax社の主要メンバで構成されるが、最近は外部メンバの取り込みに積極的

• 各自が議題を持ち寄って議論する

– 専任のファシリテータがいないので、待ちの姿勢だと議論に参加できないことも

• 今年で３年目、３回目の開催

• youtube公開動画：資料末尾の付録参照

14

弊社注目ポイント

• （弊社発表分）コネクション過多時の問題の解決

• 巨大パーティション対応

15

今日のアジェンダ

• 自己紹介

• Cassandra利用状況

• Cassandra利用事例

• NGCCとは？

• NGCC発表内容

• NGCC重要トピック

• 最後に

16

How to manage 30,000+ connections

17

What’s the problem?

18

Cassandra process goes down when too many clients connect it

19

Client machine

Apache child process

Client machine

Client machine

• 200 client machines

Cassandra process goes down when too many clients connect it

20

• 200 client machines * 128 apache child processes

Cassandra process goes down when too many clients connect it

21

• 200 client machines * 128 apache child processes * 2 (request + heart beat) =

Cassandra process goes down when too many clients connect it

22

• 200 client machines * 128 apache child processes * 2 (request + heart beat) =

51,200 connections / node

Cassandra process goes down when too many clients connect it

23

Cassandra process goes down when too many clients connect it

24

Client machine

Apache child process

51,200 > 32,768 ( max open file num )

Client machine

Client machine

写真：アフロ

Cassandra process goes down when too many clients connect it

25

Process down

写真：アフロ

Cassandra process goes down when too many clients connect it

26

Process down

写真：アフロ

Our solution

27

Cassandra Proxy

28

写真：アフロ

Our solution ~ Cassandra Proxy

29

Client machine

Apache child process

Cassandra Proxy

Client machine

Client machine

写真：アフロ

• 200 client machines

Our solution ~ Cassandra Proxy

30

• 200 client machines * 128 apache child processes

Our solution ~ Cassandra Proxy

31

• 200 client machines * 128 apache child processes 1 proxy

Our solution ~ Cassandra Proxy

32写真：アフロ

• 200 client machines * 128 apache child processes 1 proxy * 2 (request + heart beat) =

Our solution ~ Cassandra Proxy

33写真：アフロ

• 200 client machines * 128 apache child processes 1 proxy * 2 (request + heart beat)

= 400 connections / node

Our solution ~ Cassandra Proxy

34写真：アフロ

• 51,200 -> 400 connections / node

Our solution ~ Cassandra Proxy

35写真：アフロ

Consequences

36

• Stress test

– 1 msec / request (95%)

– 1 Cassandra Proxy can send 300 requests/sec to C*

Consequences

37写真：アフロ

• Production– 370 client machines – 33 Cassandra nodes

– 3,000 read requests / sec (cluster)• To be 100,000 read requests / sec

– Advertisement platform

– Available on datastax cpp driver

Consequences

38

• In the future?

– Cassandra Proxy could become one of the functions of datastax cpp driver?

Consequences

39

今日のアジェンダ

• 自己紹介

• Cassandra利用状況

• Cassandra利用事例

• NGCCとは？

• NGCC発表内容

• NGCC重要トピック

• 最後に

40

Large partition in Cassandra

41

remark

• This is a summary of following tickets:– https://issues.apache.org/jira/browse/CASSANDRA-11206

– https://issues.apache.org/jira/browse/CASSANDRA-9738

Agenda

• Recap the read path

• What’s the problem?

• Solutions

High level: read path

Row Cache

Key Cache

SSTables Mem Table

1. Check row cache before going to key cache

2. Check the key cache to get the offsets to data

3. Find the offsets to data and retrieve data

4. Merge data from sstables and memtable

5. Populate row cache with new row returned

http://docs.datastax.com/en/cassandra/3.x/cassandra/dml/dmlAboutReads.html

Pattern 1. The row is in row cache

PartitionSummary

Disk

Mem Table

CompressionOffsets

Bloom Filter

Row Cache

Heap Off Heap

Key Cache

PartitionIndex

Data

1. read request

2. return row when that is in row cache

Pattern 2. The key is in key cache

PartitionSummary

Disk

Mem Table

CompressionOffsets

Bloom Filter

Row Cache

Heap Off Heap

Key Cache

PartitionIndex

Data

1. read request

2. Check bloom filters 3. Check the partition key is in key cache

4. Find the offset to the result set

5. Access the result set

Pattern 3. The key is not cached

PartitionSummary

Disk

Mem Table

CompressionOffsets

Bloom Filter

Row Cache

Heap Off Heap

Key Cache

PartitionIndex

Data

1. read request

2. Miss -> Check bloom filters

3. Check the partition key is in key cache

4. Miss -> Bsearch the close location of index

5. Disk scan to find the offsets 6. Find the offset into the result set

7. Access the result set

8. Update key cache

What’s the problem?

• GC pressure by key cache when a large partition is read

Partition Index Recap

• http://distributeddatastore.blogspot.jp/2013/08/cassandra-sstable-storage-format.html

RowIndexEntry• Partition size < 64 kb

– RowIndexEntry• Position• Seriarized size of data

• Partition size > 64 kb– IndexedEntry

• Position• Seriarized size of data• IndexInfo[]

– Seriarize method– Offset– width– Etc.

Approximation on 16 byte value

1mb : 3kb / > 200 objects4mb : 11kb / > 800 objects64mb : 180kb / > 13k objects512mb : 1.4mb / > 106k objects

3. The key is not cached

PartitionSummary

Disk

Mem Table

CompressionOffsets

Bloom Filter

Row Cache

Heap Off Heap

Key Cache

PartitionIndex

Data

1. read request

2. Miss -> Check bloom filters

3. Check the partition key is in key cache

4. Miss -> Bsearch the close location of index

5. Disk scan to find the offsets 6. Find the offsets into the result set

7. Access the result set

8. Update key cache

9. GC, GC, GC…

Current solution

• If partition size < column_index_cache_size_in_kb(configurable)– IndexedEntry is kept on heap

• Otherwise– Always read from disk when needed

• https://issues.apache.org/jira/browse/CASSANDRA-11206

• https://www.youtube.com/watch?v=qa84vABqftM

Other possible solutions

• IndexInfo never be kept on heap– Read from disk when needed

– degrades performance when small partition is read

Other possible solutions

• Migrate key cache to be fully off heap– https://issues.apache.org/jira/browse/CASSANDRA-9738

– Serialization & deserialization cost so much when large partition is read

• Will Birch help us to solve this problem?

– https://issues.apache.org/jira/browse/CASSANDRA-9754

What we go for

• 来年もNGCCに呼んでもらえるように頑張ろう！

そのためには？: Cassandraコミュニティに貢献する

1. 日本で一番Apache Cassandraを使っている会社になる。

2. Cassandraのコード改善や問題提起の活動を継続する。

3. Cassandraコミュニティの人と仲良くなる。

55

DAY3 ?

• 3日目（おまけ）

56

今日のアジェンダ

• 自己紹介

• Cassandra利用状況

• Cassandra利用事例

• NGCCとは？

• NGCC発表内容

• NGCC重要トピック

• 最後に

57

最後に

58

D I S T R I B U T E D

大規模分散処理

H A R D W A R E

ハードウエア分野

N E T W O R K

ネットワーク分野

mailto:kvs-pj-recruit@mail.yahoo.co.jp

ご清聴ありがとうございました

59

付録：NGCC動画集• Next-Gen Schema

– https://www.youtube.com/watch?v=eAWRj0kqpvU

• Change Data Capture– https://www.youtube.com/watch?v=Y0fOxa3tC98

• Explicit support for time series data– https://www.youtube.com/watch?v=CmsQNNdDuSA

• Automated Repair– https://www.youtube.com/watch?v=8sGUn6Q2bUU

• Storage format and key cache changes to support large partitions– https://www.youtube.com/watch?v=qa84vABqftM

• SASI update– https://www.youtube.com/watch?v=yUFoSAg6rA4

• Instagram’s use cases– https://www.youtube.com/watch?v=VwhovoqavT4

• Lightning Talks– https://www.youtube.com/watch?v=6y5UV4OTawg

60