cassandraを運用していて困っていること
※2013/03/05に追記
Yuki Morishita(@yukim)さんより以下のエントリについてアンサーを貰いました！！！
https://gist.github.com/yukim/5086476
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
なんか呟いたら「m9(^Д^)ﾌﾟｷﾞｬｰ」な意味なのかRTとかがついたので、まとめておこう。きっと「これやれば解決するのに・・・プークスクス！」って教えて貰えるに違いない。半分くらい僕の技術力の低さから来ているのが多いので、Cassandra特有の問題から外れている気がするけど気にしない。
前提条件として
HW：CPU12core メモリ64GB Disk:SSDやHDD(RAID10)を使用（詳細な構成は割愛）
Cassandra 1.1.5
JDK 1.6.0_33-1
Simple Strategyを使用
1ノード辺り100〜200GB程度のデータを想定
クラスタの数とかは言っていいか分からないのと他は面倒臭いのでその他詳細は割愛します。
repairとcompactionのコストが高すぎる
もしノードが故障し、そのデータがサルベージできないとかの場合カラの状態でcassandraを既存クラスタに組み込んでノード数を元に戻す必要がある。この時にjoining⇢repairという流れで処理を実行する必要があるが、この処理が糞重い。まずjoiningする際に周辺からデータを貰うが、まずここで4〜5時間掛かる。そして、次にjoining中に変更があった箇所を完全に同期する為にrepairをやって周辺ノードからデータを貰って完全に完了する訳だが、これがjoiningより重い。そしてこの辺のデータを貰ってきてSSTableに書いて・・・とやっているとcompaction処理によるSSTableのマージ処理が同時に走り、まあ重いわけですよ！HWが良ければLA高騰などは比較的抑えることができるけど、処理時間が長いのはそこまで変わらない。というか、内部処理が重すぎてHWが良くてもあんまり変わらないと思う。
removeも重い
壊れたノードを外すためにremoveをする必要があるが、この処理も重い。今のところ実績ベースだが3〜5時間掛かる。この時にさらに連番でノードが壊れる可能性は低いのと、レプリカファクターでその辺の冗長化は調整できるのでまああれだけど、新しいノードを追加する作業が準備は出来ているのに数時間待つことになる。すげー無駄。もちろんremoveしないですぐに復活出来ればrepairで済むけど、それはそれでまた上に書いた通り。
ノード追加分の性能向上や負荷分散はノードが増えるほどコストが高くなる
これは単純にそのままなんですが、クラスタの処理性能を倍にするのに、5台で運用していている時と40台で運用している時では8倍のノードが必要ですよ、という点と追加するのもtokenの変更などを伴う場合はデータの受け渡しやtokenの変更通知を行うためにサクサク追加とかは出来ない。という事は1台追加するjoining+repair処理が5時間なら、40台追加する際には200時間掛かるという事だ。一気にやることは出来ない。そしてどの程度なら並列に実行出来るかもドキュメントが無いので手探りだ。
nodetool repairについて
"-pr"をつけた場合first rangeとのみ同期するrepair処理になるようだけど、イマイチ使いドコロが分かっていない。基本的にはtoken rangeが変更無くてすぐに復帰できた時に修復をする時のためなのかな？でもNetflixのcassandra担当者は逆って書いているらしい。ソースはチャットが流れてしまっているので自分でも探している。→もういっかい教えてもらった http://comments.gmane.org/gmane.comp.db.cassandra.user/28641
nodetool の仕様とかもソース読まないと分からん。これはもうそのまま。あとは、repair処理がファックなのか明らかに不要にデータを貰ってきている可能性が高い。そうすると余計なデータを削除する為にcompactionを実行する必要があるが、これがデータ量に依存するので（お察し下さい
Cassandra JIRA読まないとまず駄目
他のオープンソースでもそうだけど、何かあった際にまずJIRAで該当Bugが無いかを探さないと駄目。なんでかというとそれ以外情報は見つからないと思った方が良い。日本語の情報なんてまず無い。で、結構なレベルで最新VerでもエグいBug見つかる。おいおい、そんな攻めた機能を追加するぐらいなら一回安定版出せよ！とか思うけど、それは作る人の自由なのでしょうがない。ただJIRAはもちろん英語なので、Google翻訳を駆使しても僕には辛い。幸いソース読む、JIRAも読んで教えてくれるというスーパーな人がいるのでいつも助けて貰っています(´Д⊂
JVMで動作するアプリ、という点を理解しないといけない
Javaな人からしたら別にどうってことない点ですが、Javaアプリの運用とかチューニングやった事がないと、そもそもそこの勉強しないと「MySQLならメモリ増やせば良いから同じっしょ」と考えて「あれ・・どこいじれば良いの・・・」ってなって泣きながらヒープとかGCの勉強から始めることになる。まあ、逆に言うとメモリとGC以外はそんなにイジる所はそんなに無いかな・・。デフォルトでもその辺を色々と考えたcassandra-env.shというのがあるし。
とまあいま思いつく限りの事を書いてみた。他にも色々あった気がするけど、思い出したら追記しよう。
で、この辺のオペレーションコストを考えると
・1ノード辺り100GB程度
・1column family辺り20〜30GB程度
に収めるのがオペレーション的にアレかなぁ。
で、CassandraといえばNetflix社なのでこの辺の話をガッツリ聞いてみたいっす。
