Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

はじめるCassandra

4,549 views

Published on

Cassandra Meetup in Tokyo, Summer 2015でお話してきた奴

Published in: Technology
  • Be the first to comment

はじめるCassandra

  1. 1. はじめるCassandra
  2. 2. who are you
  3. 3. いわながかける twitter@kakerukaeru ゆとりインフラ園児にあ @CyberAgent Amebaの認証、課金、画像配信基盤の面倒見るマン Cassandra歴:1年弱... 緊張してます オエーー!!!! ___     ___/   ヽ    /  / /͡ヽ|   / (゚)/ / /   /   ト、/。͡ヽ。
  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 • ネィティブアプリ用基盤 • 生まれて1年弱の基盤 • 認証、課金、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. ご清聴ありがとうございました なにかあれば懇親会の時に是非!(^ω^)

×