Cassandra summit JPN 2014 : 100 node cluster admin operation

1. Cassandra summit JPN
2014
100 node cluster
admin operation

2. 自己紹介
id:oranie
@oranie
株式会社 Cyberagent 所属

3. ざっくり流れ
・運用しているシステムについて
・普段どういう事をやっているか
・今までのバッドノウハウ的な奴
・ここが困るよCassandra
・運用観点からのクラスタ設計

4. このsessionは
for administrator
的な感じです。
開発者向けの情報は少ないかも。

5. 基本的に内容はVer1.1をベースにし
ています。
その為、1.2, 2.0系では既に改善して
いる問題やデフォルトだと既に使わな
いワークフロー等
(vnode使った時とか)も含まれていると
思います。

6. 運用しているシステムについて

7. サイバーエージェント スマートフォンプラットフォーム
s.amebame.com

8. なぜ今のサービスでCassandra
を使ったのかというと、入社した
らあった。、今のシステムでは
サービス規模からデータ量、負
荷などを考えるとCassandraを採
用した経緯が。

9. SPOFの無いマルチマスタ
ノード追加でスケールする
処理能力とデータ保持量
スキーマレスで柔軟な
データ操作

10. System Scale
Daily Peak Cluster Request
Read : about 45,000 qps
Write : about 40,000 qps
Total Data: about 35TB + snapshot
1 node avg: 350GB ※RF:3

11. Latency
Read / avg 4ms.
Write / avg 0.1~0.7ms

12. Cluster HW spec
CPU : 16 ~ 24 core (HT enable)
Memory : 64GB
Disk : SAS 600GB RAID 10
※一部テスト的にSATAだったりSSD入れて
みたりのレンジがあり

13. 当初10台(Ver 1.1.1 ?)からスタートし
-> 15(ver.1.1.3) -> 30 -> 45(Ver1.1.5) -> 60->
90(Ver 1.1.5-2) -> 100
これはノード追加しないと耐え切れなかったというよ
りは、低レイテンシを維持したかった＋データ量に
対応のため。
但し今考えるとこの増やし方はあまり賢いやり方で
はなかった。理由は後ほど・・・。

14. Daily Operation

15. おおまかなまとめ
サイバーエージェント 公式エンジニアブログ
http://ameblo.jp/principia-ca/entry-11514557323.html

16. Build
構築

17. Chef + fabric + Jenkins

18. 構築の手作業は
cassandra.yamlの
token設定のみ

19. Monitoring
監視

20. 死活・閾値監視

21. Nagios + Jenkins + Perl Script
to mail & Push notification

22. 死活監視系概要

23. 閾値監視系概要

24. トレンド監視

27. OS monitor
・Cacti :
OS, JVM Resource graph
・Proteus-monitor : Real Time OS
monitor
(cyberagent engineer OSS product)
https://github.com/ameba-proteus/
proteus-monitor-agent

28. Proteus-monitor : Real Time OS

30. Cassandra monitor
・Cassandra Resource graph
GrowthForecast(LINE Engineer OSS product) +
yohoushi (DeNA Engineer OSS product)
・opscenter :Datastax Cassandra cluster status monitor
・Pending Checker :
Real Time Cassandra pending monitor
(cyberagent engeneer OSS prodct)

31. Opscenter

32. GrowthForecast + yohoushi

33. Pending Checker
「WebSocketで監視もリアルタイムに」
http://ameblo.jp/principia-ca/entry-11513826700.html

34. Pending Checker

35. Cassandra operation
nodetool cmd!!

36. major nodetool cmd
(ver 1.1)

37. show status cmd
ring : cluster状況確認。多分人生で一番打
つnodetool コマンド。但し1.2系からはstatus
cmdが追加されているので、どちらかというと
そっちになりそう。
info : node単体の状況確認
cfstats : column family毎の統計情報
tpstats : 各stage毎の統計情報。スローダウ
ンしているとかはまずこれ見る。

38. show status cmd
compactionstats : compaction等の
SSTableに対する処理状況を見る。これ
見ている時は凄いやきもきする。
gossipinfo : gossipの状況
netstats : repairなど他のノードとデータ
をやりとりするstream系処理の状況。
repair掛けている時はドキドキしながら
見る。

39. cluster operation cmd
drain : 書き込みを停止させてプロセ
スを停止させる
decommission : nodeが正常な状態
でクラスタから削除する
move : 対象nodeのtokenを変更する
removetoken : 対象nodeのtokenをク
ラスタから削除する

40. data operation cmd
flush : memtableをflushする
repair : 自身が持つべきデータを他のノードと情報を交換し
て修復する
cleanup : 重複データ等を削除する（論理削除のみ)
compact : SSTableをmajor compactionする。（基本やらな
い方が良い）
scrub : SSTableファイルが破壊された場合に修復を試みる
（らしい）
upgradesstables : CassandraのVerアップでSSTableの仕様
が変更されている場合に使用する。手順などは該当Ver ->
Update verの手順を確認。

41. node problem operation
障害時などのオペレーション

42. node down
大半は
/etc/init.d/cassandra restart
で解決
（いや、ログとか色々確認しますよ、ちゃんと）

43. slow down
再起動で（ｒｙ
（いや、ログとかcfstatsとか色々確認しますよ、ちゃんと）

44. HW障害時
この場合はnodeの入れ替えが必
要。基本的な流れは
datastax @yukimさんの
https://gist.github.com/yukim/5086476
をベースにオペレーションする。

45. イメージ

46. データの肥大化
適切なnode追加
クラスタ分割
が必要。
クラスタ分割は今後予定。

47. バックアップ
nodetool snapshot で生成され
たハードリンクを一定期間ノード
上で保持＋外部ストレージに
バックアップ

48. 今までのバッドノウハウ的な奴

49. node down対応の為、repairを
掛けるとデータが肥大化してし
まった・・・。

50. repair時に各node間でmarkle
hash tree交換を実行してそこか
ら各node間でデータのstreamを
実行するが、本来は持っている
データでもmarkle hash tree交
換の処理で持っていないと判断
され新たに取得・送信している。

51. repairイメージ

52. 対応策
まずrepairが完了したら、肥大化し
たCFに対してcleanupを実行し、
不要重複データの論理削除を掛け
る。この後compactionが発生した
ら削除される
…..が、大きなSSTableだとそうそう
compactionが掛からない。

53. でどうするか
nodetool compact
を実行してmajor compactionを
明示的に実行させる

54. 但し
この手法は麻薬と呼ばれるような
オペレーション

55. なぜ？
major compactionを実行すると
そのSSTableは巨大にSSTable
になり、余計に自動的に
compactionが掛かりにくくなるた
め、また手動でcompactionをす
る必要が・・・

56. いわゆる
＿人人人人人人人人＿
＞ 賽の河原状態 ＜
￣Y^Y^Y^Y^Y^Y^Y￣

57. 他には
謎のJVM Full GC

58. よくよく調べると
ある特定のCFに対する
compaction等がトリガーくさい

59. ログを見ると
INFO [ValidationExecutor:26]
2012-11-09 09:53:14,804
CompactionController.java (line 172)
Compacting large row hoge /fuga :
313938353330333037 (87368050
bytes) incrementally
※ログ出ている中では少ない方です

60. 要は
一つのrowでヘタするとGBサイ
ズの物があるCFだった

61. その為
推測ですが、compactionやdelete
などをする際にこのデータを一度
memtableに展開し処理が終わるま
では開放されない
+通常処理も入る
memtableは最大サイズがheapの
1/3で更にこれをCF単位で取り合う

62. いわゆる
＿人人人人人人人人＿
＞ 賽の河原状態 ＜
￣Y^Y^Y^Y^Y^Y^Y￣

63. 対応策
肥大化したrowを作らない以外方法は無いの
でschema設計超重要です。
また、一つのrowに大量のcolumnを作成し
データを入れる様な設計にすると、row単位で
ノード毎に分散されるので負荷が偏ります。で、
この偏りはノードをいくら追加しても偏りが移動
するだけなので解消出来ないです。

64. 対応策
この時はもうしょうがないので、推
奨されていないですがJVMの
heap sizeを8GB -> 12GBとかに
変更してしのぎました。

65. 他には
1.2系や2.0系verではあるかどう
かわからないですが、今使って
いるVerでは連続稼働に伴いレ
イテンシが悪化する性能リーク的
な挙動がある。

66. 対応策
再起動のみ

67. その為
Consistency level QUORUM
Replica Factor 3
simple strategy
(1.1系なのでvnode無し)
を考慮した上でアプリケーション側に影響
が少ない全台再起動ジョブを作成し、定期
実行しています。

68. HWの安定性の重要さについて

69. もしかして見たことがある人が？

70. 一部のレンジで検証＋色々な事が
あり納期の問題でそれまで利用し
てたSAS Diskでは無くSSDを利用
しました。
ただ、これがRAIDカードとの相性
が悪かったらしく地雷でした。

71. 何が起きるか
SSD障害によりノードダウン -> 追
加サーバでrepair -> データ肥大
化 -> cleanup -> compaction ->
周辺ノードがrepairによるデータ書
き込みトリガーでSSD死亡…
以下ループ

72. またも
＿人人人人人人人人＿
＞ 賽の河原状態 ＜
￣Y^Y^Y^Y^Y^Y^Y￣

73. Cassandra云々というより
納期が無いからといって十分な
検証が取れていないHWを投入
してはいけない

74. ここが困るよCassandra

75. 障害時のオペレーションでも触
れましたが、repairが結構重い +
データの肥大化が発生する。

76. その為
node障害から完全にクラスタ復
旧するまでにnodeが持つデータ
量に比例して時間が掛かる。

77. 実測値レベルですが
1 node data -> 300~400GB
join / remove -> about 4 ~6 h
repair -> about 24 h
※但しexpire的に不要なCFは見送ったりしている。
compaction -> ?

78. 最近実行したログより
INFO [CompactionExecutor:1709]
2014-01-03 00:33:56,625
CompactionTask.java (line 221) Compacted
to [/var/lib/cassandra/data/ hoge /fuga /
hoge-fuga-he-16636-Data.db,].
352,943,576,048 to 70,536,103,035 (~19% of
original) bytes for 139,068 keys at
0.157685MB/s. Time: 426,599,477ms.

79. 426,600sec = 7110 minute =
118.5 hour = about 5 days
(；ﾟДﾟ)

80. これはcompactionがCF単位で並
列化されており、CF内の複数
SSTableについては並列に実行さ
れないため、巨大なSSTableを持
つCFでmajor compactionが実行
されると恐ろしい時間が掛かります。
※iowait等は発生していませんで
した。

81. 但し
multithreaded_compaction
を有効にするとまだ不安定な機
能だったらしくLA高騰など挙動
が悪化しました

82. なので
この辺のオペレーションは可能
な限りCF単位で分割実行出来
るようにjob組んで、少しでもコン
トロールしています

83. 他に
よくあるMySQLとの比較で言うと
slow query logが無い

84. 一応
query traceが1.2系から実装さ
れている様ですが、もちろん重
いのであくまでもサンプリング的
に出力するのが推奨の様です。

85. そのため
ある閾値を超えたクエリだけを集め
てパフォーマンス調査したいとかは
今のところ厳しそう。
なので、アプリケーション側でslow
logを実装しておいた方が確実で
しょう。

86. 他に
nodetool コマンドの出力結果
フォーマットが1.1系と1.2系で微
妙に変えられた。
nodetool ringとか。

87. 他に
mbeanの格納場所も微妙に変
わったりしている。

88. そのため
nodetool やjolokia経由で値を
取得しているジョブが微妙に動
かなくなる！
（まあ、nodetoolの方は
お前のパースの仕方が悪いという説もありますが）

89. あと
nodetool cfstatsとかはjsonで初
めから出力するオプションとか欲
しい。
今は自分でperlスクリプトで実行
結果をパースしてゴニョゴニョし
ている

90. 他に
mysqldumpの様に一発でその
データストアのデータをdumpす
る機能に相当するものは無い。

91. 回避方法として
snapshot（SSTableファイル）を
bulkloadする為の
sstableloaderというツールがあるが
まだ未検証
（どれくらい時間掛かるかが結構怖
い）

92. どちらかというと
snapshotをコピーしても
cassandra.yamlのcluster name
が変更されていたら起動出来な
いという仕様を改善して欲しい
（ﾁﾗｯ

93. 以上の事から
凄まじく偏見に満ちた主観的な
クラスタ設計

94. 1 cluster
1 cluster node -> about 50
node ?
これ以上のノード数になるとrepairの実行
時間の所でも触れましたが、基本的な
ジョブ等でも時間が結構掛かる

95. また
nodeの追加も一気に50台追加とかは出
来ない為、1台ずつ追加するオペレー
ションが必要になる。全て完了するのに
何時間掛かるかは・・・？

96. そして
じゃあ、50台に10台だけ追加、とかをやろ
うとするとtokenレンジを平準化する為に
moveが必要だった為、その処理時間は
repairなどと同じだけ掛かってしまう。

97. あと
バックアップの事を考えるとRF3の場合
・最低限のデータ保全：1/3
・QUORUMの事を考えると2/3
・repair無しを考えると3/3
が必要になる為、ストレージの容量も。

98. 1 node
Total data -> Limit 100~200GB？
後々のクラスタ分割や
repair + snapshot + compaction等の
運用オペレーションを考慮
snapshotの保存期間とかにもよりますが。1.2系や2.0系でrepair
の肥大化が抑えられるのであれば300GBくらいはアリかも。

99. 各環境にもよりますが
AWSの場合EBSの最大ボリュームが1TBなので、
「まあ後でEBSを拡張すれば
なんとかなるっしょ(＾ω＾)」
と思っていると泣きながらクラスタ分割や、なんとか消し
込み作業を行いmajor compactionをせざるを得ない可
能性があります。
（EBSをストライピングするという手も多分ありますが）
※僕はAWS使っていないのでEBSストライピングは妄想です。

100. CF
1 CFで1 node 200GBとか超えると
後々のコントロールが大変になるので、
50 node で1node 1CF 50GB程度にな
るようであれば早めにクラスタ分割や論
理分割を検討？
※分割する際の移行先クラスタへのデータ
移行やCF自体の分割に伴うApp改修など

101. row
絶対にwide rowはNG
Cassandraも運用者も死ぬ
なので、最大でも数十MBとかにするよ
うな設計・コントロールを。
繰り返しになりますが、大きなrowを持
ち、そこにアクセスが集中するとノード
追加して分散しても回避出来ない。

102. 一般的なWebサービスで使うなら
やはりアーカイブ系やヒストリー系
などデータ量が爆発しやすい所が
一番向いているか？
一時的なイベント系などスキーマレ
スが有効に利用できる所も良いか
も。

103. 今後やっていきたい事

104. 2.0系、2.1系への移行
network topology strategy
の導入

105. 監視系の統合
（かなりツール分散しまくっているので）
Netflix先生が出している各種toolの検証
https://github.com/Netflix/Priam

106. まあ、色々と書きましたが

107. Cassandraは今まで問題もあったがそ
れと同じくらいメリットもあるので、今後
も使い続けるだろう
＋
社内でも新しいサービスでCassandra
を利用する所も続々出ている。
ver的には2.0系のサービス利用も出て
いる。

108. 2.0系からはCQLが強化され、
SQLライクな操作や、
データ操作もCASや
Lightweight transactions
など強化されている。

109. 個人的には
なんでもかんでもRDBMSから
Cassandraに置き換えれば良い
訳では無い
あくまでもCassandraが有効に使
えるかどうかを見極めて導入する
事が必要

110. 運用することも考えてね！

111. 何か質問があればどうぞ！

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