はじめまして。サービスインフラというチームに所属している@oranieと申します。前回の弊社 佐野からCassandra芸人による他のネタも・・・という話があったのでこれ幸いとCassandraネタでお茶を濁そうと思っています。そもそも他にもネタを持っているエンジニアがいる中で僕に執筆依頼を出す時点で、なんて節操の無い寛容な人達だとビックリしました。多分ダーツかなんかで決めたんだと思います。
入社以来、なぜか弊社でデファクトとして使われているデータストアのMySQLにもほとんど触らず、ひたすらCassandra運用とか他には仕事チャット上で一人だけ勝手に盛り上あがって麻呂のAAを貼りつけたり等の社内ピエロ雑用をやっています。おかげさまでエキサイティングな日々を毎日送る事が出来た為、酒の量が一時期増えたのと多少は小ネタを覚えたのでまだ運用していない方に少しでも運用・監視周りのお役に立てれば幸いです。
構築
まずCassandraサーバの構築ですが、弊社ではrpmパッケージ作成チームがいるのとchefでの構築がだいぶ浸透しており、datastaxさんが公開しているrpmを使うのではなく、独自rpm＋chefで一発で構築です。唯一手で変更するところはcassandra.yamlに記述するtokenを状況に応じて記述しています。
そんなレベルなので、正直構築については余り特筆事項が無いんですよね・・・。チューニング周りについてはHWスペックやCassandraへのデータアクセスパターンなどと兼ね合いがあるので、よしなに色々試していますという感じです。
Cassandraを使う上でどんな環境でも共通して出てくる問題としてあえて挙げると、ノード数が増えてきた時に各ノード間のgossipがタイムアウトする自体が発生した為、phi_convict_thresholdを長め（デフォルト8- > 12）に設定しました。ここはある程度のノード数になったらログをチェックした方が良いと思います。
ヒープ領域などはdatastatx製rpm内に色々と設定、計算してくれるcassandra-env.shという起動時に実行するファイルがあり、基本はまずこれで動作をさせてチューニングをするのが一番だと思います。
あと一時期multithreaded_compactionを有効にしていたのですが、これは使用していたVerではまだ不安定な機能だったようで、必ずfalseにしています。
とにかく設定情報が多いのとCassandra特有の設定があるので、datastaxさんの公開しているドキュメントを何度も読んでは忘れるレベルです。
http://www.datastax.com/docs/1.1/configuration/node_configuration
ただこのドキュメントは構築運用時のバイブルに近いモノがあるので、Cassandra運用する方はひと通り読んでは何かあったら該当箇所のパラメータを見直す、というのをやると幸せになれると思います。
運用オペレーション
通常のオペレーションではとにかくnodetoolの使い方を覚えるのが大事ですね。
頻繁に見るものとしては
nodetool ring -> クラスタの状況確認
nodetool compactionstats -> compactionの進捗状況やpendingしているtaskの状況確認
nodetool tpstats -> 各stage毎のスレッド状況やpending状況の確認
nodetool cfstats -> 各column family毎の統計情報確認
辺りをちょこちょこ見たり
nodetool compact (特定のkey space やcolumn familyに対してcomapctionを実行)
nodetool repair (障害復旧時等にデータの修復を実行)
nodetool cleanup （tokenレンジが変わった際に不要なデータを削除する為に実行）
辺りを障害時やノードの状況に応じて実行します。他にも色々と機能があるので、Cassandra運用する場合はまずnodetoolを覚えるのが大事ですね。（大事なことなので二回言いました）
また、全台に対してなんらかのオペレーション（chefの実行とか）についてはjenkinsでジョブを作成して実行しています。
監視
監視については言うまでもなく運用上非常に重要なのですが、どうしても「喉元過ぎれば熱さを忘れる」な事が多く、障害対応が終わると(∩´∀｀)∩ﾜｰｲとなってしまって、結果的にまた同じような障害を引き起こす可能性があるため、
このようなAAをチャットに貼り付けて見たりしてキャッチーなタスクにする事に日々勤しんでいます。
主な監視周りについて
前回の弊社 佐野が作成したツールももちろん使っているのですが、他にもCassandra監視には以下のツールを利用しています。
・Nagios（死活、閾値監視）
・Cacti（リソース監視）
上記二つは有名ですね。なのでツール自体の詳細はすっ飛ばします。
・Opscenter
http://www.datastax.com/what-we-offer/products-services/datastax-opscenter
これはCassandra監視専用ツールで、datastax社が公開しているツールです。データエクスプローラーやクラスタの状況等も確認出来る統合GUIツールで、まずはこれを使うと良いと思います。余談ですが、クラスタ状況を見る時に、ノード間の状況をリング状に見せてくれる画面があるのですが、
http://www.datastax.com/wp-content/uploads/2013/03/opscenter3.png
Tokenレンジがちゃんと設計されていないクラスタを見るとまるで銀河系のような綺麗な画像が見れます。綺麗ですが運用しているエンジニアは死にます。昔遭遇したのですが残念ながら白目を剥いて精神が崩壊するのをなんとか踏みとどまるのが精一杯だった為、画像キャプチャを取っておらず皆様にお見せする事ができないのが一番の心残りです。あと、今のVerだと監視対象のクラスタに監視データを保存するというなかなかドM厳しい仕様でしたが、最新版だと別に保存出来るようになったようです。これで「監視はしたいが監視をすると監視対象の負荷が上がる」という鶏が先か卵が先か的な問題に終止符が打たれるので何よりですね。
・proteus-monitor
https://github.com/ameba-proteus/proteus-monitor-server
https://github.com/ameba-proteus/proteus-monitor-agent
弊社の名村が開発したツールで、その瞬間のサーバ負荷状況が非常に見やすいツールです。Cassandraはcompaction等の処理が走るとかなりサーバに負荷を与える為、レイテンシが悪化した際にどのノードが負荷が高いか等が瞬時に判断出来る様になりました。おかげさまで他の監視ツールと組み合わせる事で、日中は障害が発生してからプロセス再起動するまでのスピードが1分切るレベルになれました。おかげで再起動職人という称号を貰う事が出来たので、そろそろ特殊技能手当の支給が望まれます。
・GrowthForecast
http://kazeburo.github.io/GrowthForecast/
Cassandraの各種統計値をOpsCenterだけで見るとデータ量の問題やそもそもノードが多すぎると表示しきれない問題があるので、普段から良く見るものは個別に取得してグラフ化しています。perlだとNet::GrowthForecastというモジュールがあるので気軽にグラフ作れますね。kazeburo++ tagomoris++
基本的には上記のツールを利用して運用監視を実施しています。冒頭に述べたNagiosでは死活監視、閾値監視として主に
・Cassnadraに対して処理要求を投げて正常に処理されるか
・各stageのactive threadの状況が適切か。スレッドが全て使い切られている等は無いか。
・各stageのpending値が閾値を超えてストールしていないか
・クラスタ全体の健全性に問題が無いか（各ノード間はお互いをちゃんと生きていると判断しているか）
辺りをCassandra側にはjolokiaを仕込み監視側はperlスクリプトを書いて監視しています。もちろん上記の様な現象が発生し、ノード障害になったので取得するようになりました。人間火傷をしないと大切な事になかなか気づきませんね。
余談ですが、インフラエンジニア内ではどの言語で書いても良いのですがpythonがデファクトになりつつあり、今のチームでは僕ぐらいしかperlで書かない為「お前そろそろ今まで書いたスクリプトpythonに書き直しておけよ。明日までな。」って言われるかドキドキしながら毎日perlで書いています。もし言われたら若手に「君の勉強のために書き直しておいてくれ( ｰ`дｰ´)ｷﾘｯ」と言って書いてもらおうと思います。perlでJavaアプリを監視する場合はjmx4perlとか使うとまだ手軽なのでオススメです。というかちょろっとした監視でJavaアプリ書くとかは重量過ぎてドM過ぎる気がします。もちろんJavaアプリで監視プラグインを書くと、Nagios等の監視タイミングで都度都度実行するようなタイプでは起動コストが高すぎるのも一つの理由です。
リソースグラフなど
Cactiは基本のOSリソース状況、JVMのヒープ状況等を取得しています。ここは基本ですね。
GrothForecastで書いているグラフには
・各ホストの統計値
・各column family毎の各種統計値
(mbeanで言うとorg.apache.cassandra.db辺りの値とか)
というのを出していて、その中でもまあ誰もが知りたくなる各column family毎のデータ量とかをGrowthForecastに突っ込むスクリプトを書いて一定時間毎に動作させています。ハードコーディングしている部分が多いですが、ちょっと変えてあげれば他の統計値とかも取れるので、もし良かったら修正してお使い下さい。良かったらpull reqお待ちしております。perlで書いた言っておきながら全部perlで書くのは大変なので、Linuxコマンドやcassandra付属のnodetoolを一部利用しているレベルです。お察し下さい。
https://github.com/oranie/oranie/blob/master/mon/cassandra_cf_diskspace.monitor.pl
※とりあえず自分のgithub貼っておきます。
障害時
正直ベストプラクティスは探り探りだったのですが、個人ブログに色々と書いた所直接コミッターのyukimさんからアンサーブログを頂きました。
https://gist.github.com/yukim/5086476
基本はここを読んでおくと良いと思います。もしこういう風にやっているよ！という情報があればぜひブログを書いて頂いてCassandra運用情報をどんどん盛り上げていけると良いなーと思います。というか、Cassandraへのデータ操作とかは良く情報あるんですが、運用情報ってなかなか日本語では無いんですよね・・・・。海外だとまずはNetflix社の情報がslideshareにも上がっているので一度目を通しておくと良いかなと思います。
http://www.slideshare.net/greggulrich/cassandra-operations-at-netflix
監視項目でこんな物を見ているとかクラスタの規模等も記載されているのでオススメです。
今後はログ周りの監視や解析がまだまだなのでfluentdを組み合わせたりして、より正確、迅速な監視、レポーティングを実現して安定運用・適切なキャパシティプランニングに繋げる事が出来ればと考えております。また、今後取得した各種統計値等を見るための簡単な管理画面の開発等にも着手出来ればと考えておりました。今の所「データ取れているんだからちょちょいで作れるよね？」みたいな感じで言われたのでJavascript基礎文法最速マスターとかをチラッとだけ見て誤魔化していたら、そうすると心あるエンジニアが「うちのサービス監視ツールを作ろう」という話が出てきたのでシメシメとほくそ笑んでいる感じです。
こんな感じで僕だけアレな感じですが、他のエンジニアは戦闘力で言えば僕の53万倍はしっかりしていますので一緒にCassandraやサービスを運用してみたい！というエンジニアの方は是非応募お待ちしております。