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