Cassandra summit JPN 2014

100 node cluster admin operation

自己紹介

id:oranie

@oranie

株式会社 Cyberagent 所属

ざっくり流れ

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

・普段どういう事をやっているか

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

・ここが困るよCassandra

・運用観点からのクラスタ設計

このsessionは

for administrator

的な感じです。

開発者向けの情報は少ないかも。

基本的に内容はVer1.1をベースにしています。

その為、1.2, 2.0系では既に改善している問題やデフォルトだと既に使わないワークフロー等

(vnode使った時とか)も含まれていると思います。

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

サイバーエージェント スマートフォンプラットフォーム

s.amebame.com

なぜ今のサービスでCassandraを使ったのかというと、入社したらあった。、今のシステムでは

サービス規模からデータ量、負荷などを考えるとCassandraを採

用した経緯が。

SPOFの無いマルチマスタ

ノード追加でスケールする

処理能力とデータ保持量

スキーマレスで柔軟な

データ操作

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

Latency

Read / avg 4ms.

Write / avg 0.1~0.7ms

Cluster HW spec

CPU : 16 ~ 24 core (HT enable)

Memory : 64GB

Disk : SAS 600GB RAID 10 ※一部テスト的にSATAだったりSSD入れてみたりのレンジがあり

当初10台(Ver 1.1.1 ?)からスタートし

-> 15(ver.1.1.3) -> 30 -> 45(Ver1.1.5) -> 60-> 90(Ver 1.1.5-2) -> 100

これはノード追加しないと耐え切れなかったというよりは、低レイテンシを維持したかった＋データ量に

対応のため。

但し今考えるとこの増やし方はあまり賢いやり方ではなかった。理由は後ほど・・・。

Daily Operation

おおまかなまとめ

サイバーエージェント 公式エンジニアブログ

http://ameblo.jp/principia-ca/entry-11514557323.html

Build

構築

Chef + fabric + Jenkins

構築の手作業はcassandra.yamlの

token設定のみ

Monitoring

監視

死活・閾値監視

Nagios + Jenkins + Perl Script

to mail & Push notification

死活監視系概要

閾値監視系概要

トレンド監視

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

Proteus-monitor : Real Time OS

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)

Opscenter

GrowthForecast + yohoushi

Pending Checker

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

Pending Checker

Cassandra operation

nodetool cmd!!

major nodetool cmd

(ver 1.1)

show status cmd ring : cluster状況確認。多分人生で一番打つnodetool コマンド。但し1.2系からはstatus cmdが追加されているので、どちらかというとそっちになりそう。

info : node単体の状況確認

cfstats : column family毎の統計情報

tpstats : 各stage毎の統計情報。スローダウンしているとかはまずこれ見る。

show status cmd compactionstats : compaction等のSSTableに対する処理状況を見る。これ見ている時は凄いやきもきする。

gossipinfo : gossipの状況

netstats : repairなど他のノードとデータをやりとりするstream系処理の状況。repair掛けている時はドキドキしながら見る。

cluster operation cmd drain : 書き込みを停止させてプロセスを停止させる

decommission : nodeが正常な状態でクラスタから削除する

move : 対象nodeのtokenを変更する

removetoken : 対象nodeのtokenをクラスタから削除する

data operation cmd flush : memtableをflushする

repair : 自身が持つべきデータを他のノードと情報を交換して修復する

cleanup : 重複データ等を削除する（論理削除のみ)

compact : SSTableをmajor compactionする。（基本やらない方が良い）

scrub : SSTableファイルが破壊された場合に修復を試みる（らしい）

upgradesstables : CassandraのVerアップでSSTableの仕様が変更されている場合に使用する。手順などは該当Ver -> Update verの手順を確認。

node problem operation

障害時などのオペレーション

node down

大半は

/etc/init.d/cassandra restart

で解決 （いや、ログとか色々確認しますよ、ちゃんと）

slow down

再起動で（ｒｙ

（いや、ログとかcfstatsとか色々確認しますよ、ちゃんと）

HW障害時

この場合はnodeの入れ替えが必要。基本的な流れは

datastax @yukimさんの https://gist.github.com/yukim/5086476

をベースにオペレーションする。

イメージ

データの肥大化

適切なnode追加

クラスタ分割

が必要。

クラスタ分割は今後予定。

バックアップ

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

バックアップ

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

node down対応の為、repairを掛けるとデータが肥大化してし

まった・・・。

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

repairイメージ

対応策

まずrepairが完了したら、肥大化したCFに対してcleanupを実行し、不要重複データの論理削除を掛ける。この後compactionが発生したら削除される

…..が、大きなSSTableだとそうそうcompactionが掛からない。

でどうするか

nodetool compact

を実行してmajor compactionを

明示的に実行させる

但し

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

なぜ？

major compactionを実行するとそのSSTableは巨大にSSTable

になり、余計に自動的にcompactionが掛かりにくくなるため、また手動でcompactionをす

る必要が・・・

いわゆる

＿人人人人人人人人＿＞　賽の河原状態　＜

￣Y^Y^Y^Y^Y^Y^Y￣

他には

謎のJVM Full GC

よくよく調べると

ある特定のCFに対するcompaction等がトリガーくさい

ログを見ると

INFO [ValidationExecutor:26] 2012-11-09 09:53:14,804

CompactionController.java (line 172) Compacting large row hoge /fuga :313938353330333037 (87368050

bytes) incrementally

※ログ出ている中では少ない方です

要は

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

その為

推測ですが、compactionやdeleteなどをする際にこのデータを一度

memtableに展開し処理が終わるまでは開放されない

+通常処理も入る

memtableは 大サイズがheapの1/3で更にこれをCF単位で取り合う

いわゆる

＿人人人人人人人人＿＞　賽の河原状態　＜

￣Y^Y^Y^Y^Y^Y^Y￣

対応策

肥大化したrowを作らない以外方法は無いのでschema設計超重要です。

また、一つのrowに大量のcolumnを作成しデータを入れる様な設計にすると、row単位でノード毎に分散されるので負荷が偏ります。で、この偏りはノードをいくら追加しても偏りが移動

するだけなので解消出来ないです。

対応策

この時はもうしょうがないので、推奨されていないですがJVMの

heap sizeを8GB -> 12GBとかに変更してしのぎました。

他には

1.2系や2.0系verではあるかどうかわからないですが、今使っているVerでは連続稼働に伴いレ

イテンシが悪化する性能リーク的な挙動がある。

対応策

再起動のみ

その為

Consistency level QUORUM

Replica Factor 3

simple strategy

(1.1系なのでvnode無し)

を考慮した上でアプリケーション側に影響が少ない全台再起動ジョブを作成し、定期

実行しています。

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

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

一部のレンジで検証＋色々な事があり納期の問題でそれまで利用してたSAS Diskでは無くSSDを利用

しました。

ただ、これがRAIDカードとの相性が悪かったらしく地雷でした。

何が起きるか

SSD障害によりノードダウン -> 追加サーバでrepair -> データ肥大化 -> cleanup -> compaction -> 周辺ノードがrepairによるデータ書

き込みトリガーでSSD死亡…

以下ループ

またも

＿人人人人人人人人＿＞　賽の河原状態　＜

￣Y^Y^Y^Y^Y^Y^Y￣

Cassandra云々というより

納期が無いからといって十分な検証が取れていないHWを投入

してはいけない

ここが困るよCassandra

障害時のオペレーションでも触れましたが、repairが結構重い +

データの肥大化が発生する。

その為

node障害から完全にクラスタ復旧するまでにnodeが持つデータ

量に比例して時間が掛かる。

実測値レベルですが

1 node data -> 300~400GB

join / remove -> about 4 ~6 h

repair -> about 24 h ※但しexpire的に不要なCFは見送ったりしている。

compaction -> ?

近実行したログより

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.

426,600sec = 7110 minute = 118.5 hour = about 5 days

(；ﾟДﾟ)

これはcompactionがCF単位で並列化されており、CF内の複数

SSTableについては並列に実行されないため、巨大なSSTableを持つCFでmajor compactionが実行されると恐ろしい時間が掛かります。

※iowait等は発生していませんでした。

但し

multithreaded_compaction

を有効にするとまだ不安定な機能だったらしくLA高騰など挙動

が悪化しました

なので

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

トロールしています

他に

よくあるMySQLとの比較で言うと

slow query logが無い

一応

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

そのため

ある閾値を超えたクエリだけを集めてパフォーマンス調査したいとかは

今のところ厳しそう。

なので、アプリケーション側でslow logを実装しておいた方が確実で

しょう。

他に

nodetool コマンドの出力結果フォーマットが1.1系と1.2系で微

妙に変えられた。

nodetool ringとか。

他に

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

そのため

nodetool やjolokia経由で値を取得しているジョブが微妙に動

かなくなる！ （まあ、nodetoolの方は

お前のパースの仕方が悪いという説もありますが）

あと

nodetool cfstatsとかはjsonで初めから出力するオプションとか欲

しい。

今は自分でperlスクリプトで実行結果をパースしてゴニョゴニョし

ている

他に

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

回避方法として

snapshot（SSTableファイル）をbulkloadする為の

sstableloaderというツールがあるがまだ未検証

（どれくらい時間掛かるかが結構怖い）

どちらかというと

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

（ﾁﾗｯ

以上の事から

凄まじく偏見に満ちた主観的なクラスタ設計

1 cluster

1 cluster node -> about 50 node ?

これ以上のノード数になるとrepairの実行時間の所でも触れましたが、基本的な

ジョブ等でも時間が結構掛かる

また

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

そして

じゃあ、50台に10台だけ追加、とかをやろうとするとtokenレンジを平準化する為にmoveが必要だった為、その処理時間は

repairなどと同じだけ掛かってしまう。

あと

バックアップの事を考えるとRF3の場合

・ 低限のデータ保全：1/3

・QUORUMの事を考えると2/3

・repair無しを考えると3/3

が必要になる為、ストレージの容量も。

1 node

Total data -> Limit 100~200GB？

後々のクラスタ分割や

repair + snapshot + compaction等の

運用オペレーションを考慮 snapshotの保存期間とかにもよりますが。1.2系や2.0系でrepair

の肥大化が抑えられるのであれば300GBくらいはアリかも。

各環境にもよりますが

AWSの場合EBSの 大ボリュームが1TBなので、

「まあ後でEBSを拡張すれば

なんとかなるっしょ(＾ω＾)」

と思っていると泣きながらクラスタ分割や、なんとか消し込み作業を行いmajor compactionをせざるを得ない可

能性があります。

（EBSをストライピングするという手も多分ありますが）

※僕はAWS使っていないのでEBSストライピングは妄想です。

CF

1 CFで1 node 200GBとか超えると後々のコントロールが大変になるので、

50 node で1node 1CF 50GB程度になるようであれば早めにクラスタ分割や論

理分割を検討？

※分割する際の移行先クラスタへのデータ移行やCF自体の分割に伴うApp改修など

row

絶対にwide rowはNG

Cassandraも運用者も死ぬ

なので、 大でも数十MBとかにするような設計・コントロールを。

繰り返しになりますが、大きなrowを持ち、そこにアクセスが集中するとノード

追加して分散しても回避出来ない。

一般的なWebサービスで使うなら

やはりアーカイブ系やヒストリー系などデータ量が爆発しやすい所が

一番向いているか？

一時的なイベント系などスキーマレスが有効に利用できる所も良いか

も。

今後やっていきたい事

2.0系、2.1系への移行

network topology strategy

の導入

監視系の統合

（かなりツール分散しまくっているので）

Netflix先生が出している各種toolの検証

https://github.com/Netflix/Priam

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

Cassandraは今まで問題もあったがそれと同じくらいメリットもあるので、今後

も使い続けるだろう

＋

社内でも新しいサービスでCassandraを利用する所も続々出ている。

ver的には2.0系のサービス利用も出ている。

2.0系からはCQLが強化され、SQLライクな操作や、

データ操作もCASやLightweight transactions

など強化されている。

個人的には

なんでもかんでもRDBMSからCassandraに置き換えれば良い

訳では無い

あくまでもCassandraが有効に使えるかどうかを見極めて導入する

事が必要

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

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

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