Participation report of data stax accelerate 2019

Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.
2019年7⽉25⽇
ヤフー株式会社
システム統括本部サービスプラットフォーム本部データベース部 NoSQL
⼭下郁⽮
Datastax Accelerate 2019
参加報告

⾃⼰紹介
2
⼭下郁⽮ 2018年ヤフー新卒⼊社
・Cassandra構築・運⽤
・Configuration Management
・監視システムの開発・検証
研究は⽣産管理、深層学習(CV)等
学⽣時代
主な業務

⾃⼰紹介
3
(多分)3.11.5と3.0.19でリリース予定

4
• 3⽇間通して1000⼈くらい︖
(専⽤アプリ内から推定)
• セッションは、OSS Cassandraの内容もあったが、
DSE（商⽤版Cassandra）を⽤いた内容も多かった
画像引⽤︓https://www.datastax.com/accelerate

5
オープニングイベントの様⼦

セッションの⼤枠
6
■ Innovating with Apache Cassandra Cassandraのチューニングや機能改善、4.0についてなど
■ Building Modern Applications アプリケーションのためのシステム設計やスキーマ設計など
■ Succeeding with Operations and Administration 運⽤保守のための最適な構成など
■ Deploying in the Cloud: Hybrid, Public, Private クラウドハイブリッドなデータベースを実現するための課題など
■ Exploring Transformational Use Cases
Cassandraを⽤いて、
商⽤アプリケーションを刷新していくユースケースなど
■ Going Beyond Core Cassandra with
Graph, Search, and Analytics
データドリブン領域でのCassandra利⽤など
■ Accelerating Transformation in the Public Sector 公共利⽤におけるCassandraのユースケースなど

Keynote Session
7
Accelerating Innovation in a Cloud World
■ データの場所、サイズ、フォーマット…
→これらに関係なく機能するアプリこそ、現代で使われるもの
■ これらをどんなアプローチでビジネス展開、変⾰を⾏っていくか
Accelerating Development with Datastax, Cassandra, and the Cloud
■ Cassandraのこれまで、そしてこれから(4.0)について
Learning to Think Like hackers with Innovation and Creativity
■ 実は、ハッカー達がイノベーション促進している
→脆弱性を突き、技術を進化させる
■ ハッカー⽂化のクリエイティブな側⾯を受け⼊れる

イベント内での個⼈的トピックス①
8
The 2019 Stax Awards
画像引⽤︓https://www.datastax.com/2019/05/datastax-announces-the-2019
-stax-awards-and-partner-of-the-year-winners
Sony PlayStationが受賞
The Best Use of DataStax in a Hybrid/Multi-Cloud Environment Award
• ハイブリッドかつマルチクラウドな環境
• ⾃社DCとAWSを⽤いて数百ノードのDSEを運⽤
Ø 毎秒30万以上のread/write
Ø データ量は数⼗テラバイト
• 各種⾃動化
Ø 構築、スケールアウト、復旧
• PS4の各種コンテンツのバックボーンにDSEを採⽤

イベント内での個⼈的トピックス②
9
AppleのCassandra利⽤推移
2014 2019
ノード数 75000+ ?
データ量数⼗PB ?
クラスタ数 1000+ 1000+

イベント内での個⼈的トピックス②
10
AppleのCassandra利⽤推移
2014 2019
ノード数 75000+ 160000+
データ量数⼗PB 数百PB
クラスタ数 1000+ 1000+

Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.Copyright (C) 2019 Yahoo Japan Corporation. All Rights Reserved.
セッションの⼀部紹介

その①
オンプレDSEから
クラウドDSEに引っ越しした話

その①︓オンプレからクラウドに引っ越しした話
13
Migrating 500 Nodes from Rackspace to Google Cloud with Zero Downtime
Gilberto Müller, Paul Chandler - Metronom
• 複数クラスタある
• 1クラスタは1度で移動する
• ダウンタイムは起こさない
• 91クラスタ移動した
• 6ヶ⽉かかった
• ダウンタイムは起きなかった
• ⾃動化はしたほうが良い
結
果
• DCの引っ越しをしたい
どういう⼿順で実施したのか…︖

14
Step1︓system系のkeyspaceのトポロジに新DCを追加する
ALTER KEYSPACE system_auth, system_schema, ...
S
S
current_dc
new_dcこの時点で新DCにノードはまだ無い
ʻclassʼ : ʼNetworkTopologyStrategyʼ, ʻcurrent_dcʼ : 3
ʻclassʼ : ʼNetworkTopologyStrategyʼ, ʻcurrent_dcʼ : 3, ʼnew_dcʼ : 3
seed

15
Step2︓新DCにノードを追加する
■ノード数は任意（現⾏DCに合わせなくて良い）
→ cluster_nameは同⼀に
→ seedsは現⾏DCのノードを指定
■system系のkeyspaceはすぐに同期される
S
S
current_dc
new_dc
同期完了
✔ system_auth
✔ system_schema
✔ dse_leases
✔ system_distributed
✔ dse_perf
✔ system_traces
✔ dse_security
接続は、まだしちゃダメ

16
Step3︓ユーザkeyspaceのトポロジに新DCを追加する
■このタイミングでINSERTされるデータは
ちゃんとreplicateされていく
■古いデータはまだreplicateされない
ALTER KEYSPACE user_ks
ʻclassʼ : ʼNetworkTopologyStrategyʼ, ʻcurrent_dcʼ : 3
ʻclassʼ : ʼNetworkTopologyStrategyʼ, ʻcurrent_dcʼ : 3, ʼnew_dcʼ : 3
S
S
current_dc
new_dc
new
new
new
new
new
new
new
接続は、まだしちゃダメ

17
Step4︓新DCのノードをrebuildする
■新ノードでnodetool rebuildを順番に実⾏していく
S
S
current_dc
new_dc
OK!
token range
○○○○~△△△△
token range
○○○○~△△△△
データをコピー

18
Step5︓現⾏DCのdecommission
■seedsを現⾏DCから新DCのノードに変更
■アプリケーションの接続先をカバー新DCに変更
■現⾏DCのノードを順次decommissionする
■全keyspaceのトロポジから現⾏DCを削除
■引っ越し完了︕
current_dc
S
S
new_dc

19
⾃動化フロー
ノード追加/削除とかトポロジ変更等
→puppet
Rebuildとdecommission
→jenkins

20
今回の引っ越しにおけるTips
ネットワークパフォーマンス
⼗分な帯域幅を︕
→今回DC間の帯域幅は14.7Gbpsだったらしい(?)
ヒープサイズ
データのストリーミングとCompactionで使い果たす
GCが⽌まる⼼配はないよ︕
ヒープサイズは増やせるよ︕
Compaction
Compactionはラグるよ︕
⼩さいSSTableがめっちゃ出来るよ︕
Compactionのスループットは上げよう︕
ストリーミングスループット
必要なら下げよう︕
→今回はDC間のスループットを下げたらしい

21
■クラスタの分離をする時
■non-trivialな設定をアップデートする時(num_token等)
■OSアップデート時
この⼿法は引っ越し以外でも使える
このセッションの締め

その②
Cassandra4.0の新機能
トラフィックキャプチャ

その②︓4.0新機能- トラフィックキャプチャ
23
Cassandraのトラフィックキャプチャは何故必要か︖
テストデバッグシャドウィング
Live Traffic Caputure and Replay in Cassandra 4.0
Vinay Chella - Netflix

24
これまでのアプローチ
tcpdump, cqltrace, wireshark, …
■ディスクを圧迫する
■カスタムバイナリプロトコルの分析が⼤変
■ネットワークレベルでトラフィックを複製するのは困難

25
Cassandraのトラフィックキャプチャに必要なもの
■全てのリクエストを記録
■全てのリクエストを再利⽤・リプレイ
■記録したトレースをいつでも再利⽤
■トレーシングをいつでも開始/停⽌できる
■パフォーマンスに影響を与えないこと

26
BinLog
■OpenHFTのChronicle-Queueを採⽤
■No GC - Off heap
■⾼速で低コストなロギング
■リングバッファを採⽤

27
Full Query Logging(FQL)
■BinLogベース
■全てのCQLリクエストを記録
■⾼パフォーマンス
■バイナリフォーマット出⼒
■リーダブルなfqltool

28
How to use …?
nodetool enablefullquerylog --path /path/to/fqllog
ロギングが始まる
nodetool disablefullquerylog
ロギングが⽌まる
nodetool resetfullquerylog
ログを消す

29
How to use …?
fqltool dump --path /path/to/fqllog
取ったログをdump

30
How to use …?
fqltool replay –target <node> /path/to/fqllog –store-queries /path/to/fqlreplaylog
ロギングしていたクエリを他ノードでリプレイ
（リプレイ先のログも別で保存する）
fqltool compare –queries /path/to/fqlreplaylog /path/to/fqllog
リプレイ元のクエリとリプレイ先のクエリを⽐較

31
テスト
デバッグ
シャドウィング
fqltool replay → fqltool compare
nodetool enablefullquerylog
nodetool enablefullquerylog → fqltool replay
✔
✔
✔

32
画像引⽤:https://www.slideshare.net/VinayKumarChella/live-traffic-capture-and-replay-in-cassandra-40-147315678

33
画像引⽤:https://www.slideshare.net/VinayKumarChella/live-traffic-capture-and-replay-in-cassandra-40-147315678

34画像引⽤: http://cassandra.apache.org/blog/2018/10/29/audit_logging_cassandra.html
補⾜
監査ログ機能もある
■(多分)FQLの後発
■FQLだけじゃ⾜りない情報をカバー
ログ関連の詳しい議論については下記JIRA参照
■CASSNADRA-12151
■CASSANDRA-13983

その③
オートスケーリング苦労話

その③︓オートスケーリング苦労話
36
Automation for Cassandra scaling
Serban Teodorescu - Adobe
Cassandraの⾃動化がなかなかに⾟いという話
AdobeのCassandra利⽤状況
・250TBのデータ
・150億 req/day
・34クラスタ
・500ノード以上

37
Cassandra構築に⽤いているもの
・AWS(パブリッククラウド)
・Terraform(インフラ構成ツール)
・Lightweight AMI(Amazonマシンイメージ)
・Puppet(構成管理ツール)
・Ansible(構成管理ツール)
Cassandra監視に⽤いているもの
・Prometheus(メトリクス収集・監視)

38
スケールイン/アウトにおける問題点
■たまにEC2インスタンスが⽴ち上がらない（AWS APIエラー）
■ネットワーク帯域幅が狭くてCassandra joinがメチャクチャ遅い（最⾼8時間）
■⽴ち上げ/削除直後に、たまにアラートが誤検知する
■decommissionが遅い
■とにかく諸々遅い

39
Cassandra死活監視における問題点
■インスタンスが追加/削除されたばかりなのに気づかず、誤アラートを出す
■誤アラートは⼀旦停⽌できるが、その間のガチアラートに気づかない
■スケーリングに時間がかかると監視⽌まりっぱなしで危険な状態に

40
更に…
■ノードのreplaceは⾼速だけど⾃動化してない…
→ 簡単だけど、退屈だし、頻繁だし…(週に2インスタンスのペース)
■新しいクラスタのbootstrapを100％⾃動化してない

41
AWXを使ったよ
そこで…
Ansible TowerのOSS版
・WebUIでplaybookを簡単管理
・実⾏結果を可視化
・ホストごとに結果を管理
・ジョブのスケジューリング
・ジョブの集中管理
・ロールベースでアクセスコントロール
・ユーザ認証
・ユーザの権限分離
・チーム作成
なにそれ︖
参考︓https://thinkit.co.jp/article/11736
なにそれ︖

42
なんでAWX︖
■既にplaybookを持ってるから
■時間がかかる(でもちゃんと動く)playbookは頼りないから、しっかり管理したい

43
アラート制御の整備
AWX
Terraform
Prometheus
tag : ignore_alert=yes or no
rule not to scrape when tag is yes
switch tag to no after Cassandra started or yes on decommission

44
結果
■AWX導⼊後、12クラスタをスケールイン/アウトし、87ノードを追加/削除した
→ 30時間かかるクラスタもあった
→ 2,3⽇で7クラスタのペース
■誤アラートの発⽣を防⽌した
■Cassandra replace部分をplaybook化した

45
AWXを導⼊してよかったこと
■⻑時間かかるplaybookも、放置できる
■AWXのサポートが⼿厚い
■playbookを集中管理できる
→ 監査できる
→ environmentのコントロールができる
→ AWSの呼び出し回数を減らせる
→ ジョブテンプレートを使ってエラーの余地を減らせる
■他のツールと統合しやすい

46
この発表で伝えたかったこと(⾃分なりの解釈)
■ネットワーク帯域やスケーリングが遅い問題は根本解決してない
→ この辺はどうしようもないので、せめてAWXで静観できるようにした
■監視の誤検知は、どうにか⼯夫して解決した(playbook化した)
■100%⾃動化はまだできていない
→ future workにて、更なる⾃動化を〜と⾔っていたので
■これからはAWXを使って諸々解決していくつもり

その他

その他のセッション
48
Glimpse of Cassandra 4.0
Vinay Chella, Netflix
■ノード間通信を改善した
■Hybrid Speculationを利⽤してSLOを満たす
■num_tokenのデフォルト値を減らした
Capacity Planning with Facebook Prophet
Pedro Vidigal, Valerie Parham-Thompson, Pythian
■Cassandraのキャパプラにおいて、compactionを考慮したリソース管理が必要
■明確に定義されたパフォーマンス要件が必要
■何が⾒えてどこに⾏く必要があるか、に基づいてリソースを調整を繰り返す
■Facebook Prophetを⽤いてシーズナルな影響やヒストリカルなデータを扱う

総括

総括 - イベントの感想 -
50
著しいクラウド化
運⽤の苦しみから少しでも逃れられるように
※オンプレとのハイブリッドも推されているので、⼀概には⾔えないけど…
やっぱり⾃動化は難しい
特に、⼤規模運⽤してしまっている所では…
スケールアウトしてこそのCassandra
テックジャイアントと呼ばれる企業は、バシバシスケールアウトして⼤規模化

EOP

Participation report of data stax accelerate 2019

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Participation report of data stax accelerate 2019

Ähnlich wie Participation report of data stax accelerate 2019 (20)

Participation report of data stax accelerate 2019