これがCassandra

これがCasandra
またの名を
鬼の哭くシステム

今日話すこと
• 2013年からのCassandraとの戦いの日々と
愚痴を淡々と語るだけです
過度な期待はしないでください

システム構成
• Node数：97台
• サーバスペック
機器：Dell R410、R420
メモリ：64GB
CPU:16コア、24コア
HDD：600GBx4 (RAID-10)
600GBx2(RAID-1)+SSD 512GB(RAID-0)
• クラスタ数：1
• Cassandraのバージョン：1.1.5-2(独自バージョン)
• KeySpace数：8
• ColumnFamily数：156

運用状況とか
Cluseter Writes Request: 32000/sec
Cluseter Reads Request : 58000/sec
1 nodeあたりのデータロードサイズ
約200～230GB

Cassandraの設定
• レプリケーションファクタ：3
データを配置するノード数の合計
• 一貫性レベル：QUORUM
レプリカのあるノードの過半数から応答があった「最新」のデータ
を返す
• ヒープ：８GB
８GBより少ないほうがよいらしい
http://www.datastax.com/docs/1.1/operations/tuning#heap-sizing

運用でよく使うコマンド
・nodetool compact
特定のkey space やcolumn familyに対してcomapctionを実
行
・nodetool repair
障害復旧時等にデータの修復を実行
・nodetool cleanup
tokenレンジが変わった際に不要なデータを削除する為に
実行
・nodetool removetoken
停止中のノードをクラスタから取り除く

バックアップ
• nodetool snapshotで取得
• 8時間毎の差分スナップショットをローカ
ルに保存
• １－３－７…のNodeのスナップショットは
バックアップサーバに定期コピー

ここからは主に2013年に入ってか
らあったことを語ります

1月
・CPU8コアサーバを24コアサーバに筐体交換（6台）
→ 筐体交換でデータの修復するためにrepair祭り
→ repairかけているNodeとその前後Nodeのデータが肥大しまく
る
（2～3倍くらいに膨れ上がる）
主に特定の１つのcolumn familyが激増
・肥大しまくっているデータをなんとか小さくしないとやばい
状態
→ メジャーCompactionすれば容量が減ることが判明
→ メジャーCompaction祭り
※このころのrepairは5時間くらいで終わっていた
※このころはメジャーCompactionは8時間くらいで終わっていた
※肥大しても1台あたりのロードデータは200GBくらいだった
肥大してない場合は100GB以下

２月
2/8
85号機障害
→ SSDがオフライン現象発
生
2/15
89号機障害
生
→ HDDのみの筐体に変更
2/24
85号機障害
→ SSD死亡
→ HDDのみ筐体に変更
2/7
86号機障害
生
→ removetokenに3時間くら
い
2/12
90号機障害
→ SSDが死亡
→ HDDのみの筐体に変更
2/16
86号機障害

２月
• バックアップサーバ（17TB）にスナップショット退避しまくってい
たら容量が足らなくなる
→ 50TBのサーバ借りて助かる
• repairする→余計なデータ増えた状態
→メジャーコンパクションすれば消えたけど、その前に近隣ノードが
障害
→復帰して周囲が余計なデータ持っている状態でrepair
→また余計なデータ増えるの繰り返しで１Nodeのロードデータが
700GB超えた。。。＞＜
（特にでかいのは特定の１つだけ。本来はロードデータ100～200GB程
度のはずなのに。。）
とにかく特定の１つだけがでかい。。
特定の１つだけのSSTableの容量が800GB近くある。。＞＜

2月
• 86－90レンジのノード全部のディスク容量が90%超えに。。＞＜
1回あたりの差分スナップショットの容量が300～400GBくらいに。。。＞＜
（通常は数GBくらいなのに。。）
• 86－90間のノードで同時並列でとにかくメジャーCompactionかけまくる
メジャーCompaction祭り開催
ついでにCleanupもかけまくる
※このころはこのオペやっても問題なかった。。
• 87号機の特定の１つだけのメジャーCompactionが2日たっても終わらない現象発
生。。。
（他Nodeだとだいたい10時間くらいかかる。。）
• 全台再起動やったらレンテンシがちょいちょい跳ねる現象発生。。。
• 実は特定の１つだけの過去データが消えてなかったことが判明。。
本来であれば1カ月以前のデータは自動で消えているはずだった。。orz
アプリ側を修正してもらって、過去データはバッチで徐々に消してもらう。。。

3月
• 1回暴れた以外は平和だった
• 毎月恒例の全台再起動はやはりレンテンシ上
がる。。orz
1-4-7...の順番で1順やり
2-5-8...の順番で2順目やっていく方式
1順目は大丈夫なのに、2順目以降でレイテンシ
がはねる。。。

4月
04/01
89号機障害
→ ボードとかのHW障害
→ 筐体変更して復活
repairかけたら100GB増加する
処理終わるのに7時間かかる
とにかくrepairしたら容量問題にぶちあたる。。。
04/04
86号機障害
→ SSD死亡
→ HDDのみ筐体に変更

4月
04/11
89号機、repair実行
→ メモリリークで死亡
死ぬ前もモリモリFullGCしまくり
FullGC入っても6GB超のメモリが開放されていない現象発生。。。
ここからFullGC祭りがはじまる。。
82号機障害（R410）
→ SSD死亡
バグフィックスしたパッチあてたバージョンに差し替えはじめ
る
（アプリ側に作ってもらった独自バージョン。世の中に出回っ
てない）

4月
04/16
89号機
→ パッチあてたバージョンでもrepairで死亡
04/18
89号機が明らかにおかしなデータを持っている感じだった
ので89号機のデータ消し去って、クラスタに組み込みなお
す。
repairかける（翌日障害のトリガーになる）。

4月
04/19
→ 88号機応答なし障害
full gcで死亡
※82号機で同じオペレーションしても障害はなかった
今度は90号機が応答なくなったので、再起動。。orz
87号機障害
→ SSD死亡
→ HDDに差し替え
88号機が最後のR420+SSDとなる。。。

4月
04/20
→ 1:03 88号機メモリリークで障害
全部87号機のrepairがトリガー。。。
ヒープを 12GBにして回避する
→ 23:14 88号機障害（SSD死亡）→ HDDに変更
04/23
→ 89号機メモリリークで障害
メジャーCompactionでふっとぶ。。。
4/24
→ 87号機メモリリークで障害
メジャーCompactionでふっとぶ。。。

4月
原因切り分け（特定レンジの問題なのかクラスタ全体の問題な
のか）のため
63号機をデータ消して、クラスタに組み込みなおし、障害頻発
するレンジと同じオペレーション（repairやComapction）やって
みる
→ 問題はおきなかった
→ メモリリークは後半レンジ特有問題と判明
あとついでにSSDからHDDに変更しておいた
全台をバージョンアップして再起動
ヒープも全台戻す
（8GBより少ないほうがよいらしいので）

5月
05/07
90号機メモリリークで障害
cleanupでふっとぶ。。
87号機（R420）を97号機（R410）と差し替えてみたが、メモリリーク
発生
OSと機種特有の問題ではないことがわかった。。
toke-1でJoinさせてからremoveをやったが、remove時間は変わらず。。
orz
ノード障害への対処の推奨方法はtoken-1で新NodeをJoinさせてから障
害NodeをRemoveするのがよいらしい
http://wiki.apache.org/cassandra/Operations_JP#A.2BMM4w.2FDDJlpxbszB4
MG5b.2FlHm-
97号機をrepair。。。（翌日障害のトリガーとなる。。。）

5月
05/08
88，89号機メモリリークで障害
再起動しても復旧せず
ヒープを12GBにして再起動で復旧
05/09-10
83－90の間に予備機7台をクラスタにJoinさ
せてデータを分散させる

今後
• バージョンアップする（1.2系へ）
• クラスタを分割（でかいCFが負荷高いの
で他に逃がしたい）
• 検証（障害頻発環境を再現させてバー
ジョンアップ等で改善するかと
か。。。）

Cassandraとの付き合い方
・JIRAを読む！
https://issues.apache.org/jira/browse/CASSANDRA
自分が使っているバージョンがどんな地雷踏む可能性があるか把握
しておくこと
・ソースを読む！
ソースコードがマニュアルです
・なんかあったら再起動！
大抵これで直ります^^/
・とにかく祈る！
暴れないように日々祈りをささげる

あなたはそれでも
Cassandraを使いますか？

これがCassandra

More Related Content

What's hot (20)

これがCassandra