cassandra 100 node cluster admin operation

7,088 views

Published on

Cassandra summit JPN 2014 : 100 node cluster admin operation

Published in: Technology
0 Comments
18 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,088
On SlideShare
0
From Embeds
0
Number of Embeds
2,355
Actions
Shares
0
Downloads
31
Comments
0
Likes
18
Embeds 0
No embeds

No notes for slide

cassandra 100 node cluster admin operation

  1. 1. Cassandra summit JPN 2014 100 node cluster admin operation
  2. 2. 自己紹介 id:oranie @oranie 株式会社 Cyberagent 所属
  3. 3. ざっくり流れ ・運用しているシステムについて ・普段どういう事をやっているか ・今までのバッドノウハウ的な奴 ・ここが困るよCassandra ・運用観点からのクラスタ設計
  4. 4. このsessionは for administrator 的な感じです。 開発者向けの情報は少ないかも。
  5. 5. 基本的に内容はVer1.1をベースにし ています。 その為、1.2, 2.0系では既に改善して いる問題やデフォルトだと既に使わな いワークフロー等 (vnode使った時とか)も含まれていると 思います。
  6. 6. 運用しているシステムについて
  7. 7. サイバーエージェント スマートフォンプラットフォーム s.amebame.com
  8. 8. なぜ今のサービスでCassandra を使ったのかというと、入社した らあった。、今のシステムでは サービス規模からデータ量、負 荷などを考えるとCassandraを採 用した経緯が。
  9. 9. SPOFの無いマルチマスタ ノード追加でスケールする 処理能力とデータ保持量 スキーマレスで柔軟な データ操作
  10. 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. 11. Latency Read / avg 4ms. Write / avg 0.1~0.7ms
  12. 12. Cluster HW spec CPU : 16 ~ 24 core (HT enable) Memory : 64GB Disk : SAS 600GB RAID 10 ※一部テスト的にSATAだったりSSD入れて みたりのレンジがあり
  13. 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. 14. Daily Operation
  15. 15. おおまかなまとめ サイバーエージェント 公式エンジニアブログ http://ameblo.jp/principia-ca/entry-11514557323.html
  16. 16. Build 構築
  17. 17. Chef + fabric + Jenkins
  18. 18. 構築の手作業は cassandra.yamlの token設定のみ
  19. 19. Monitoring 監視
  20. 20. 死活・閾値監視
  21. 21. Nagios + Jenkins + Perl Script to mail & Push notification
  22. 22. 死活監視系概要
  23. 23. 閾値監視系概要
  24. 24. トレンド監視
  25. 25. 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
  26. 26. Proteus-monitor : Real Time OS
  27. 27. 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)
  28. 28. Opscenter
  29. 29. GrowthForecast + yohoushi
  30. 30. Pending Checker 「WebSocketで監視もリアルタイムに」 http://ameblo.jp/principia-ca/entry-11513826700.html
  31. 31. Pending Checker
  32. 32. Cassandra operation nodetool cmd!!
  33. 33. major nodetool cmd (ver 1.1)
  34. 34. show status cmd ring : cluster状況確認。多分人生で一番打 つnodetool コマンド。但し1.2系からはstatus cmdが追加されているので、どちらかというと そっちになりそう。 info : node単体の状況確認 cfstats : column family毎の統計情報 tpstats : 各stage毎の統計情報。スローダウ ンしているとかはまずこれ見る。
  35. 35. show status cmd compactionstats : compaction等の SSTableに対する処理状況を見る。これ 見ている時は凄いやきもきする。 gossipinfo : gossipの状況 netstats : repairなど他のノードとデータ をやりとりするstream系処理の状況。 repair掛けている時はドキドキしながら 見る。
  36. 36. cluster operation cmd drain : 書き込みを停止させてプロセ スを停止させる decommission : nodeが正常な状態 でクラスタから削除する move : 対象nodeのtokenを変更する removetoken : 対象nodeのtokenをク ラスタから削除する
  37. 37. data operation cmd flush : memtableをflushする repair : 自身が持つべきデータを他のノードと情報を交換し て修復する cleanup : 重複データ等を削除する(論理削除のみ) compact : SSTableをmajor compactionする。(基本やらな い方が良い) scrub : SSTableファイルが破壊された場合に修復を試みる (らしい) upgradesstables : CassandraのVerアップでSSTableの仕様 が変更されている場合に使用する。手順などは該当Ver -> Update verの手順を確認。
  38. 38. node problem operation 障害時などのオペレーション
  39. 39. node down 大半は /etc/init.d/cassandra restart で解決 (いや、ログとか色々確認しますよ、ちゃんと)
  40. 40. slow down 再起動で(ry (いや、ログとかcfstatsとか色々確認しますよ、ちゃんと)
  41. 41. HW障害時 この場合はnodeの入れ替えが必 要。基本的な流れは datastax @yukimさんの https://gist.github.com/yukim/5086476 をベースにオペレーションする。
  42. 42. イメージ
  43. 43. データの肥大化 適切なnode追加 クラスタ分割 が必要。 クラスタ分割は今後予定。
  44. 44. バックアップ nodetool snapshot で生成され たハードリンクを一定期間ノード 上で保持+外部ストレージに バックアップ
  45. 45. 今までのバッドノウハウ的な奴
  46. 46. node down対応の為、repairを 掛けるとデータが肥大化してし まった・・・。
  47. 47. repair時に各node間でmarkle hash tree交換を実行してそこか ら各node間でデータのstreamを 実行するが、本来は持っている データでもmarkle hash tree交 換の処理で持っていないと判断 され新たに取得・送信している。
  48. 48. repairイメージ
  49. 49. 対応策 まずrepairが完了したら、肥大化し たCFに対してcleanupを実行し、 不要重複データの論理削除を掛け る。この後compactionが発生した ら削除される …..が、大きなSSTableだとそうそう compactionが掛からない。
  50. 50. でどうするか nodetool compact を実行してmajor compactionを 明示的に実行させる
  51. 51. 但し この手法は麻薬と呼ばれるような オペレーション
  52. 52. なぜ? major compactionを実行すると そのSSTableは巨大にSSTable になり、余計に自動的に compactionが掛かりにくくなるた め、また手動でcompactionをす る必要が・・・
  53. 53. いわゆる _人人人人人人人人_
 > 賽の河原状態 <
  ̄Y^Y^Y^Y^Y^Y^Y ̄
  54. 54. 他には 謎のJVM Full GC
  55. 55. よくよく調べると ある特定のCFに対する compaction等がトリガーくさい
  56. 56. ログを見ると INFO [ValidationExecutor:26] 2012-11-09 09:53:14,804 CompactionController.java (line 172) Compacting large row hoge /fuga : 313938353330333037 (87368050 bytes) incrementally ※ログ出ている中では少ない方です
  57. 57. 要は 一つのrowでヘタするとGBサイ ズの物があるCFだった
  58. 58. その為 推測ですが、compactionやdelete などをする際にこのデータを一度 memtableに展開し処理が終わるま では開放されない +通常処理も入る memtableは最大サイズがheapの 1/3で更にこれをCF単位で取り合う
  59. 59. いわゆる _人人人人人人人人_
 > 賽の河原状態 <
  ̄Y^Y^Y^Y^Y^Y^Y ̄
  60. 60. 対応策 肥大化したrowを作らない以外方法は無いの でschema設計超重要です。 また、一つのrowに大量のcolumnを作成し データを入れる様な設計にすると、row単位で ノード毎に分散されるので負荷が偏ります。で、 この偏りはノードをいくら追加しても偏りが移動 するだけなので解消出来ないです。
  61. 61. 対応策 この時はもうしょうがないので、推 奨されていないですがJVMの heap sizeを8GB -> 12GBとかに 変更してしのぎました。
  62. 62. 他には 1.2系や2.0系verではあるかどう かわからないですが、今使って いるVerでは連続稼働に伴いレ イテンシが悪化する性能リーク的 な挙動がある。
  63. 63. 対応策 再起動のみ
  64. 64. その為 Consistency level QUORUM Replica Factor 3 simple strategy (1.1系なのでvnode無し) を考慮した上でアプリケーション側に影響 が少ない全台再起動ジョブを作成し、定期 実行しています。
  65. 65. HWの安定性の重要さについて
  66. 66. もしかして見たことがある人が?
  67. 67. 一部のレンジで検証+色々な事が あり納期の問題でそれまで利用し てたSAS Diskでは無くSSDを利用 しました。 ただ、これがRAIDカードとの相性 が悪かったらしく地雷でした。
  68. 68. 何が起きるか SSD障害によりノードダウン -> 追 加サーバでrepair -> データ肥大 化 -> cleanup -> compaction -> 周辺ノードがrepairによるデータ書 き込みトリガーでSSD死亡… 以下ループ
  69. 69. またも _人人人人人人人人_
 > 賽の河原状態 <
  ̄Y^Y^Y^Y^Y^Y^Y ̄
  70. 70. Cassandra云々というより 納期が無いからといって十分な 検証が取れていないHWを投入 してはいけない
  71. 71. ここが困るよCassandra
  72. 72. 障害時のオペレーションでも触 れましたが、repairが結構重い + データの肥大化が発生する。
  73. 73. その為 node障害から完全にクラスタ復 旧するまでにnodeが持つデータ 量に比例して時間が掛かる。
  74. 74. 実測値レベルですが 1 node data -> 300~400GB join / remove -> about 4 ~6 h repair -> about 24 h ※但しexpire的に不要なCFは見送ったりしている。 compaction -> ?
  75. 75. 最近実行したログより 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.
  76. 76. 426,600sec = 7110 minute = 118.5 hour = about 5 days (;゚Д゚)
  77. 77. これはcompactionがCF単位で並 列化されており、CF内の複数 SSTableについては並列に実行さ れないため、巨大なSSTableを持 つCFでmajor compactionが実行 されると恐ろしい時間が掛かります。 ※iowait等は発生していませんで した。
  78. 78. 但し multithreaded_compaction を有効にするとまだ不安定な機 能だったらしくLA高騰など挙動 が悪化しました
  79. 79. なので この辺のオペレーションは可能 な限りCF単位で分割実行出来 るようにjob組んで、少しでもコン トロールしています
  80. 80. 他に よくあるMySQLとの比較で言うと slow query logが無い
  81. 81. 一応 query traceが1.2系から実装さ れている様ですが、もちろん重 いのであくまでもサンプリング的 に出力するのが推奨の様です。
  82. 82. そのため ある閾値を超えたクエリだけを集め てパフォーマンス調査したいとかは 今のところ厳しそう。 なので、アプリケーション側でslow logを実装しておいた方が確実で しょう。
  83. 83. 他に nodetool コマンドの出力結果 フォーマットが1.1系と1.2系で微 妙に変えられた。 nodetool ringとか。
  84. 84. 他に mbeanの格納場所も微妙に変 わったりしている。
  85. 85. そのため nodetool やjolokia経由で値を 取得しているジョブが微妙に動 かなくなる! (まあ、nodetoolの方は お前のパースの仕方が悪いという説もありますが)
  86. 86. あと nodetool cfstatsとかはjsonで初 めから出力するオプションとか欲 しい。 今は自分でperlスクリプトで実行 結果をパースしてゴニョゴニョし ている
  87. 87. 他に mysqldumpの様に一発でその データストアのデータをdumpす る機能に相当するものは無い。
  88. 88. 回避方法として snapshot(SSTableファイル)を bulkloadする為の sstableloaderというツールがあるが まだ未検証 (どれくらい時間掛かるかが結構怖 い)
  89. 89. どちらかというと snapshotをコピーしても cassandra.yamlのcluster name が変更されていたら起動出来な いという仕様を改善して欲しい (チラッ
  90. 90. 以上の事から 凄まじく偏見に満ちた主観的な クラスタ設計
  91. 91. 1 cluster 1 cluster node -> about 50 node ? これ以上のノード数になるとrepairの実行 時間の所でも触れましたが、基本的な ジョブ等でも時間が結構掛かる
  92. 92. また nodeの追加も一気に50台追加とかは出 来ない為、1台ずつ追加するオペレー ションが必要になる。全て完了するのに 何時間掛かるかは・・・?
  93. 93. そして じゃあ、50台に10台だけ追加、とかをやろ うとするとtokenレンジを平準化する為に moveが必要だった為、その処理時間は repairなどと同じだけ掛かってしまう。
  94. 94. あと バックアップの事を考えるとRF3の場合 ・最低限のデータ保全:1/3 ・QUORUMの事を考えると2/3 ・repair無しを考えると3/3 が必要になる為、ストレージの容量も。
  95. 95. 1 node Total data -> Limit 100~200GB? 後々のクラスタ分割や repair + snapshot + compaction等の 運用オペレーションを考慮 snapshotの保存期間とかにもよりますが。1.2系や2.0系でrepair の肥大化が抑えられるのであれば300GBくらいはアリかも。
  96. 96. 各環境にもよりますが AWSの場合EBSの最大ボリュームが1TBなので、 「まあ後でEBSを拡張すれば なんとかなるっしょ(^ω^)」 と思っていると泣きながらクラスタ分割や、なんとか消し 込み作業を行いmajor compactionをせざるを得ない可 能性があります。 (EBSをストライピングするという手も多分ありますが) ※僕はAWS使っていないのでEBSストライピングは妄想です。
  97. 97. CF 1 CFで1 node 200GBとか超えると 後々のコントロールが大変になるので、 50 node で1node 1CF 50GB程度にな るようであれば早めにクラスタ分割や論 理分割を検討? ※分割する際の移行先クラスタへのデータ 移行やCF自体の分割に伴うApp改修など
  98. 98. row 絶対にwide rowはNG Cassandraも運用者も死ぬ なので、最大でも数十MBとかにするよ うな設計・コントロールを。 繰り返しになりますが、大きなrowを持 ち、そこにアクセスが集中するとノード 追加して分散しても回避出来ない。
  99. 99. 一般的なWebサービスで使うなら やはりアーカイブ系やヒストリー系 などデータ量が爆発しやすい所が 一番向いているか? 一時的なイベント系などスキーマレ スが有効に利用できる所も良いか も。
  100. 100. 今後やっていきたい事
  101. 101. 2.0系、2.1系への移行 network topology strategy の導入
  102. 102. 監視系の統合 (かなりツール分散しまくっているので) Netflix先生が出している各種toolの検証 https://github.com/Netflix/Priam
  103. 103. まあ、色々と書きましたが
  104. 104. Cassandraは今まで問題もあったがそ れと同じくらいメリットもあるので、今後 も使い続けるだろう + 社内でも新しいサービスでCassandra を利用する所も続々出ている。 ver的には2.0系のサービス利用も出て いる。
  105. 105. 2.0系からはCQLが強化され、 SQLライクな操作や、 データ操作もCASや Lightweight transactions など強化されている。
  106. 106. 個人的には なんでもかんでもRDBMSから Cassandraに置き換えれば良い 訳では無い あくまでもCassandraが有効に使 えるかどうかを見極めて導入する 事が必要
  107. 107. 運用することも考えてね!
  108. 108. 何か質問があればどうぞ!
  109. 109. 御清聴ありがとうございました

×