Cassandraバージョンアップ＆移設の話をまとめました。

1. Cassandra99台を移設してバー
ジョンアップした話
あの鬼の哭くシステムは
その後どうなったのか？

2. こいつを改善した話をします

3. 今日話すこと
• Cassandraとの戦歴
• クラスタ分けた話
• そして移設へ・・・

4. システム構成（2012~2014年頃）
• Node数：99台
• サーバスペック
機器：物理サーバ（DELL）
CPU： 16コア、24コアが混在
メモリ：64GB
HDD:以下構成が混在
600GBx4(RAID-10)
600GBx2(RAID-1)+SSD 512GBx2(RAID-0)
600GBx2(RAID-1)+HDD(SATA) 1TBx2(RAID-1)
• クラスタ数：１
• Cassandraバージョン：1.1.5-2
• 1nodeあたりのデータサイズ：約200～300GB

5. この頃よく起こっていたこと
• SSDがぶっ壊れまくっていた
• Node再構築でRepair→Compaction祭りループ
• Heap使いきってプロセスハングが頻発
詳しくはWebで。。。

6. 対処したこと
• SSD撲滅→HDD（1TB）に交換
→この頃は容量問題があったのでSATA １TBに交換。
→ディスクIOが遅すぎてプロセス再起動に２０~３０分かか
る事案発生。
→容量問題解決してから、順次SASに入れ替える作業して
いくことになる。
・Heapサイズを12GBに変更
→推奨値は8GBだが足らないので増やした。
→とりあえずHeapは安定した。

7. クラスタ分割
• とにかく一番容量でかいcolumn familyをなん
とかしたい。
→このCFのデータ保持期間は約１カ月
→このCFのデータを第１クラスタと第２クラスタで２重書き込み
すれば安全にクラスタ分割できそう

8. 第２クラスタ誕生へ
第１クラスタ 第２クラスタ
第１クラスタ用
リソースAPI
第２クラスタ用
リソースAPI
API郡
・第１クラスタ、第２クラスタ両方
にデータを書き込むようにする。
・第２クラスタでの運用に問題な
いこと確認できた時点で、第１ク
ラスタのCFをTrancate。

9. クラスタ分割した結果。。。
• １Nodeあたりのデータサイズが約３００GB以
上あったのが、１００GBくらいまで削減！！

10. システム構成（2014~2015年頃）
• Node数：
第１クラスタ：99台
第２クラスタ：30台（→１５台に削減）
• サーバスペック
機器：物理サーバ（DELL）
CPU： 16コア、24コアが混在
メモリ：64GB
HDD:600GBx4(RAID-10)
• クラスタ数：2
• Cassandraバージョン：
第１クラスタ：1.1.5-2
第２クラスタ：1.2.13
• 1nodeあたりのデータサイズ
第１クラスタ：約150GB
第２クラスタ：約2GB

11. そして移設へ
• 移設先は物理or仮想？
• データ転送にどれくらい時間かかる？
• バージョンアップする？

12. 物理にするか仮想にするか
• 第１クラスタは物理サーバで決定
• 第２クラスタは仮想でも十分いけそうだったの
で仮想サーバで決定

13. データ転送の時間
• 1nodeあたり約１５０GBくらいデータがあって、
９９台同時に転送しなければならない。。。
• スナップショットの差分を転送することで時間
短縮できそう

14. 移設元DC 移設先DC
Cassandraデータ
スナップショット保管
nodetool snapshotで差分ス
ナップショットを定期取得
旧Cassandraサーバx99台 新Cassandraサーバx99台
スナップショット保管rsyncで
定期コピー
約５分で９９台のデータ転送を実現！

15. バージョンアップするか？
• 1.1.5の運用はもうしたくない。。
• Cassandra止めるチャンスはもう２度とないかもし
れない。。
→バージョンアップやろう！
• バージョンは何にする？
→第２クラスタで1.2系の運用実績がある
→ 1.1系からは1.2系踏まないと２系にはできない
→ 1.2系の最新（1.2.19）でいこう
（DataStaxさんにもこのバージョンの安定性は確認）

16. upgradesstables
• Cassandraバージョンアップ後は
upgradesstablesを実行してデータ構造を1.2用
に変換しないといけない
• upgradesstablesをしないとrepairやJoinなどが
できない（データの読み書きは可能）
• 150GBのデータで約８時間かかる。。。
→メンテ時間内で終わらない。。。

17. upgradesstablesどうしよう
• メンテあけてからやるしかない
• オンラインで実行しても問題ないことを
DataStaxさんに確認
• 負荷かけながら実行しても問題ない（サーバ
負荷や読み書き）ことを検証して確認
• あとupgradesstablesしたデータは1.1の環境で
は読み込めない（プロセス起動できない）
→これ実行後は旧環境にデータ戻せない！

18. 負荷試験
• 旧環境のRead/Writeリクエスト：約9000/sec
• Cassandra-stressを使って負荷生成
→Read/Writeリクエスト：20000/sec
• OSリソースに問題ないことを確認
• Cassandraステータスで問題ないことを確認

19. 第１クラスタ移設手順
• 旧環境でスナップショット取得
• スナップショットを新環境に転送
• md5sumで新旧データ比較
• 新環境にてCassandra1.1で起動
• Cassandra停止して1.2にバージョンアップ
• Cassandra1.2で起動
• OpsCenterでクラスタに問題ないこと確認
↑ここまでの作業時間は約９０分
• メンテあけてからupgradesstablesを実行

20. 第１クラスタ移設で工夫したこと
• 手作業を撤廃→スクリプト化した
• スクリプトを全Node同時に実行するために
Fabricを使用
• Fabric実行はJenkinsでJob化
• 各NodeのCassandraバージョンアップと設定
ファイル配布はChef-zeroで実施

21. 第２クラスタの移設
旧Cassandra
クラスタ
新Cassandra
クラスタ
旧クラスタ用
リソースAPI
新クラスタ用
リソースAPI
API郡
移設元DC 移設先DC ・旧クラスタ、新クラスタ両方に
データを書き込むようにする。
・新クラスタでの運用に問題ない
こと確認できた時点で、旧クラス
タを撤去

22. システム構成（2016年）
• Node数：
第１クラスタ：99台（物理）
第２クラスタ：6台（仮想）
• サーバスペック
CPU： 24コア
メモリ：64GB
HDD:600GBx6(RAID-10)
• クラスタ数：2
• Cassandraバージョン： 1.2.19
1nodeあたりのデータサイズ
第１クラスタ：約150GB
第２クラスタ：約5GB

23. バージョンアップして一番よかったこと
• repair時のデータ肥大化がなくなった
→1.1のときはrepair後はデータ肥大化するの
でメジャーCompaction必須だったが、この
運用がなくなった。

24. 今後やりたいこと
• Node数減らしたい。。。
• 不要データ削減したい。。。