はじめるCassandra

はじめるCassandra

1. 1. はじめるCassandra
2. 2. who are you
3. 3. いわながかける twitter@kakerukaeru ゆとりインフラ園児にあ @CyberAgent Amebaの認証、課金、画像配信基盤の面倒見るマン Cassandra歴：１年弱... 緊張してます オエーー!!!! ＿＿_     ＿＿_／   ヽ    ／  ／ ／͡ヽ|   / (ﾟ)/ ／ /   /   ﾄ､/｡͡ヽ。
4. 4. 最初に
5. 5. 今回の資料は
6. 6. For administrator
7. 7. だ
8. 8. よ
9. 9. はい
10. 10. ということで 今回のお話の内容としては 以下の事を重点的にお話しようかと思います • 運用していく上で、見るべき点 • 定常的に行うべきオペレーション • 初めてCassandraを運用してみての所感
11. 11. agenda
12. 12. agenda • about CyberAgent&Service • why Cassandra • Operation • Build,Monitoring,Backup etc... • about Troubleshooting • まとめ
13. 13. about CyberAgent
14. 14. blog
15. 15. pigg
16. 16. game
17. 17. Entertainment
18. 18. Entertainment
19. 19. about Cassandra in CyberAgent
20. 20. about Cassandra in CyberAgent • Cassandra Version：1.1.5, 1.2.13 • Production Cluster：3 • Production nodes： about 150node • Total about qps Read&Write： 50000qps • Total about data size：15TB
21. 21. about Service
22. 22. use at Cyberagent Smartphone Platform1 1 ブラウザのPlatformな
23. 23. なの
24. 24. です
25. 25. が
26. 26. 今回お話するのは、
27. 27. 既存ではなく 新しく作ったClusterのお話
28. 28. です
29. 29. For Native App iOS & Android auth payment logging
30. 30. For Native App • ネィティブアプリ用基盤 • 生まれて１年弱の基盤 • 認証、課金、loggingのapiを提供 • Cassandraの使用は主にid管理の部分 • idに紐付けて、課金＆loggingなどのbackendのSystemに繋 げている
31. 31. why Cassandra
32. 32. why Cassandra • 担当になったら既にあった • SPOFがない • 急激なデータ増に耐えられるscalability • ノード追加による、スケールアウト • 弊社Smartphone Platformでの運用実績
33. 33. about System
34. 34. Cassandra setting • Version：2.0.8 • Replication Factor：3 • Consistency Level：QUORUM • use vnode：256 • use CQL,nodejs用独自ドライバ実装 • https://github.com/suguru/cql-client
35. 35. Request • Peak Request • Read：about 9,000 qps • Write：about 3,000 qps • Data size • Total：600GB • 1node avg：50GB
36. 36. Latency • Read：avg 2ms • Write：avg 0.1ms
37. 37. HW Spec • private Cloud Instance • CPU：24core • Memory：94GB、heap 8GB • Disk；1TB • 12node • 1 Cluster
38. 38. HW Spec • 相当に贅沢なサーバ • 基盤としてもこれからデカくなることを見越してのサーバ • Resource的にはまだまだ余裕がある • node減らしても大丈夫そ • privateCloudのInstance typeのラインナップにより、この Specになった
39. 39. about Operation
40. 40. Cassandra全景
41. 41. Build
42. 42. Build • Cassandraサーバの構築 • Jenkins & ansible • 手作業はCluster join時のCassandra プロセスの起動のみ • vnode(Cassandra ver1.2~)を使用 しているため、手作業でのtokenの 計算＆割り当てが必要なく単純な 起動でOK
43. 43. Monitoring
44. 44. Monitoring • threshold • use sensu • how to check • Community&Original sensu plugin • how to notify • mail & hipchat
45. 45. Monitoring • trend • use OpsCenter • data size&latency • use sensu & influxdb & grafana • how to check • Community&Original sensu plugin
46. 46. Monitoring • check • OS Resource • cpu,memory,disk&nw latency,fd • JVM • heap,gc
47. 47. Monitoring • check • Cassandra • read&write_qps,latency • thread pool • ReadStage • FlushWriter • Compaction • HintedHandoff...
48. 48. Monitoring どうやってCassandraの動向を追うの？＿？ • CassandraStatusread&writeの動向を追う • Write&ReadStage、MutationStage、FlushWrite • Compaction_status • Cassandra_Clusterのhealth確認したい • Gossiptimeowt、hintedhandoff
49. 49. Operation
50. 50. Operation • repair & cleanup • about 20h / weekly • backup & restore • snapshot & sstableloader • restore CI • ?? h / weekly
51. 51. Operation • repair & cleanup • レプリカの不整合を防ぐために定期的なrepairを実行 • データの復活を防ぐために同時にcleanupも実行 • 実行周期は 7days ＜ gc grace seconds(default:10days)2 2 gc grace seconds：TombstoneのGarbageCollection実行までの時間
52. 52. Operation • backup • 2h毎に各nodeでsnapshotを作成しSwiftに保存。 • restore • test-clusterにて定期的にrestoreが出来ているか確認 • sstableloaderを使い空Clusterにdataを流し込こむ3 3 ただsstableloaderめっちゃ時間かかるから、実際のrestore作業はsnapshot直置きの復旧になるかも
53. 53. about Troubleshooting
54. 54. 何かあった時によく使うnodetool • nodetool status • nodeの状態をささっと見たい • nodetool tpstats • 実行中のthreadの監視 • nodetool netstats • streamの情報を見る
55. 55. 何かあった時によく使うnodetool • nodetool cfstats • cf毎に情報を見たい4 • nodetool disablegossip,disablethrift,disablebinary,flush • disable* : 各protocol無効化 • flush：memtableからflushさせる 4 Cassandra全体でSlowdownしてるのか、特定cfで詰まってるのか確認したいよね
56. 56. 何かあった時によく使うnodetool なので予定していたnodeの再起動などは下記を使ったりする $ nodetool disablegossip && nodetool disablethrift && nodetool disablebinary && nodetool flush && /etc/init.d/cassandra restart
57. 57. しかし実際には 突発的にnodeに何か問題が発生した場合、 nodetoolの結果が返ってこない事がほとんど その場合はどうするか
58. 58. 諦めて再起動5 /etc/init.d/cassandra restart 5 用法用量を守って正しくお使いください。ちゃんとlog、metricsをみて判断してますよ、、、
59. 59. その他、困ったこと
60. 60. NW障害6 6 もう既に怖いですね
61. 61. 具体的には？
62. 62. おきたこと、対応したこと • 瞬断が続きL2レベルでの完全なる断になる • Cluster的には全nodeが独立した状態に。 • max hint window ms (default:3h)を超えた(!!)のでhint7 の情報 は全て破棄されリセットされる形に。 • NW復旧後に全nodeでrepairをかけて、Clusterの復旧に。 7 hint:他nodeがダウンした際に書き込まれるはずだったデータを他のレプリカが保持する max_hint_window_ms:↑ のhintを破棄するまでの時間
63. 63. ふりかえると • データロストは無し • 瞬断が続く形でもhintを保持してる限り自動的にレプリカの 整合性を整えることが可能 • hintがなくてもnodeさえ潰れなければClusterの復旧が可能8 • NW断にも耐えられた 8 hintもないnodeもダウンとなると、救えないデータ出てくる。当たり前か
64. 64. その他先人の知見
65. 65. その他先人の知見9 • slow queryを見ることが出来ないので、困る前にアプリ側に slow logを実装する • スキーマ設計大事問題 • wide rowを避ける。事前分割出来るならちゃんとしよう • Cassandraに限った話でないけれど... 9 先人の軌跡 http://www.slideshare.net/oranie/cassandra-summit-jpn-2014-100-node-cluster-admin-operation
66. 66. まとめ • 最低限の事を抑えておけば運用は楽 • Cassandra、ｺﾜｸﾅｲﾖ • 先人の知見をありがたくいただこう • そして自分たちも蓄積して共有しよう。 • Cassandra Communityに貢献的なね • 1.xx系とはお別れをしよう。したい（白目
67. 67. これからのこと • これからのCluster設計 • そのまま仮想？物理？＿？ • PITRに近しいこと、したい、、、 • データセンター機能を使って、Backup専用のCluster作成 • Backup時だけ、データセンター間のレプリを止めて、書き 込みのない状態でBackupを取るという妄想をしている。
68. 68. ご清聴ありがとうございました なにかあれば懇親会の時に是非！（＾ω＾）