Twitter が Cassandra を選んだ理由 --- MyNoSQL

Twitter が Cassandra を選んだ理由 — MyNoSQL

Posted in NoSQL, Twitter by Agile Cat on March 1, 2010

Cassandra @ Twitter: An Interview with Ryan King

http://nosql.mypopescu.com/post/407159447/cassandra-twitter-an-interview-with-ryan-king

There have been confirmed rumors [1] about Twitter planning to use Cassandra for a long time. But except the mentioned post, I couldn’t find any other references. Twitter is fun by itself and we all know that NoSQL projects love Twitter. So, imagine how excited I was when after posting about Cassandra 0.5.0 release, I received a short email from Ryan King, the lead of Cassandra efforts at Twitter simply saying that he would be glad to talk about these efforts. So without further ado, here is the conversation I had with Ryan King (@rk) about Cassandra usage at Twitter:

ずっと以前から、Twitter が Cassandra の利用を計画しているというウワサ [1] があった。しかし、このポストを除いて、他の情報を得ることは無かった。 Twitter は楽しいし、すべて人々が NoSQL プロジェクトに適していることを知っている。それだけに、Cassandra 0.5.0 のリリースの後に、Ryan King から短いメールをもらった時の感激を想像してほしい。なぜなら、Cassandra で Twitter を推進する彼が、その内容を説明しても構わないと言ってくれたからだ。難しい話は抜きにして、Twitter における Cassandra の用法について、私と Ryan King が交わした会話を紹介する：

ーーーーー

MyNoSQL: Can you please start by stating the problem that lead you to look into NoSQL?

MyNoSQL: まず、NoSQL を検討する際の問題点から説明してもらえるか？

Ryan King: We have a lot of data, the growth factor in that data is huge and the rate of growth is accelerating.

Ryan King: 私たちは大量のデータを有している。それらのデータの成長は、途方も無いものであり、また、急加速している。

We have a system in place based on shared mysql + memcache but its quickly becoming prohibitively costly (in terms of manpower) to operate. We need a system that can grow in a more automated fashion and be highly available.

私たちは共有された mysql + memcache をベースにしてシステムを運用しているが、そのコストは（マンパワーの点で）きわめて大きなものとなる。私たちは、さらに自動化された方式で拡張され、いつでも利用できる、システムを必要としている。

MyNoSQL: I imagine you’ve investigated many possible approaches, so what are the major solutions that you have considered?

MyNoSQL: あらゆるアプローチを調査してきたと思うが、あなたが考えている重要なソリューションとは？

Ryan King:

◦A more automated sharded mysql setup
◦Various databases: HBase, Voldemort, MongoDB, MemcacheDB, Redis, Cassandra, HyperTable and probably some others I’m forgetting.

◦ いま以上に自動化された、共有 MySQL の設定。
◦ HBase／Voldemort／MongoDB／MemcacheDB／Redis／Cassandra／HyperTable といった、各種のデータベースの検討。

MyNoSQL: What kind of tests have you run to evaluate these systems?

MyNoSQL: そこれらのシステムを評価するために、行ったテストは？

Ryan King: We first evaluated them on their architectures by asking many questions along the lines of:

Ryan King: 最初に、以下のような項目で、それらのアーキテクチャを評価した:

◦How will we add new machines?
◦Are their any single points of failure?
◦Do the writes scale as well?
◦How much administration will the system require?
◦If its open source, is there a healthy community?
◦How much time and effort would we have to expend to deploy and integrate it?
◦Does it use technology which we know we can work with? *… and so on.

Asking these questions narrowed down our choices dramatically. Everything but Cassandra was ruled out by those questions. Given that it seemed to be our best choice, we went about testing its functionality (“can we reasonably model our data in this system?”) and load testing.

それらの確認により、私たちの選択枝は大幅に狭まった。そして、Cassandra 以外のすべてが、この質問により除外された。それが、ベスト･チョイスであるという前提のもとで、私たちは機能と負荷についてテストした。それは、私たちのデータを、このシステムでモデル化できるかという確認であった。

The load testing mostly focused on the write-path. In the medium/long term we’d like to be able to run without a cache in front of Cassandra, but for now we have plenty of memcache capacity and experience with scaling traffic that way.

大半の負荷テストは、書き込みに焦点を合わせたものだった。 Cassandra のフロントにキャッシュを置かずに、中長期の運用か可能なのか、その点を調べたかった。しかし、現在では、大量の memcache を持ち、その方式でトラフィックをスケールする方式を有している。

MyNoSQL: If you draw a line, what were the top reasons for going with Cassandra?

MyNoSQL: どこかに線を引くとしたら、Cassandra を採用する最大の理由は何になる？

Ryan King:

◦No single points of failure
◦Highly scalable writes (we have highly variable write traffic)
◦A healthy and productive open source community

MyNoSQL: Will Cassandra completely replace the current solution?

MyNoSQL: Cassandra は、現在のソリューションを完全に置き換えられるか？

Ryan King: Over time, yes. We’re currently moving our largest (and most painful to maintain) table — the statuses table, which contains all tweets and retweets. After this we’ll start putting some new projects on Cassandra and migrating other tables.

Ryan King: Yes。ただし、時間がかかる。現時点では、その維持が最も困難なテーブル、つまり、すべての tweets と retweets 取り込んだテーブルを移行している。この処理が終われば、新しいプロジェクトに Cassandra で対応できるし、その他のテーブルも移行できる。

MyNoSQL: How do you plan to migrate existing data?

MyNoSQL: 既存データの移行については、どのように計画している？

Ryan King: We have a nice system for dynamically controlling features on our site. We commonly use this to roll out new features incrementally across our user base. We use the same system for rolling out new infrastructure.

Ryan King: 私たちは、ダイナミックな制御が可能な、素晴らしいシステムを手元に有している。私たちは、それを用いて、ユーザーのための新しい機能を、漸進的に拡張していく。また、インフラストラクチャに対しても、同じシステムを使用していく。

So to roll out the new data store we do this:

したがって、新しいデータ･ストアを達成するために、以下の項目を実施する:

1.Write code that can write to Cassandra in parallel to Mysql, but keep it disabled by the tool I mentioned above
2.Slowly turn up the writes to Cassandra (we can do this by user groups “turn this feature on for employees only” or by percentages “turn this feature on for 1.2% of users”)
3.Find a bug
4.Turn the feature off
5.Fix the bug and deploy
6.GOTO #2

1. Cassandra にはパラレルで書き込み、また、MySQL にも書き込みを行うコードを書く。ただし、それらを停止すための手段を、前述の方式で確保しておく。
2. Cassandra への書き込みを、段階的にチューンアップしていく。たとえば、“turn this feature on for employees only” や、“turn this feature on for 1.2% of users” というような感じで。
3. バグの調査。
4. この機能を停止する。
5. バグ･フィックスとディプロイ。
6. GOTO #2

Eventually we get to a point where we’re doing 100% doubling of our writes and comfortable that we’re going to stay there. Then we:

最終的に、書き込み能力を倍増するために、上記の手順を完璧に（100%）に行う。そこが、私たちが目標とするポイントだ。続いて、以下を行う:

1.Take a backup from the mysql databases

1. MySQL データベースのバックアップを作成する。

2.Run an importer that imports the data to cassandra

2. Cassandra にデータをインポートするためのプログラムを実行する。

Some side notes here about importing. We were originally trying to use the BinaryMemtable[2] interface, but we actually found it to be too fast — it would saturate the backplane of our network. We’ve switched back to using the Thrift interface for bulk loading (and we still have to throttle it). The whole process takes about a week now. With infinite network bandwidth we could do it in about 7 hours on our current cluster.

ここで、インポートについて付け加えておく。私たちは最初に、BinaryMemtable [2]インターフェイスを使おうとしたが、それで速すぎることに気づいた。つまり、私たちのネットワーク･バックプレーンを飽和させてしまう。そのため、バルク･ロードのために、Thrift インターフェイスを使うように戻した（それでも調整が必要になる）。すべてのプロセスには、1週間が必要になる。無限のネットワーク帯域幅があれば、現時点のクラスタ上で、約 7時間で処理できるだろう。

3.Once the data is imported we start turning on real read traffic to Cassandra (in parallel to the mysql traffic), again by user groups and percentages.

3. データがインポートされたら、Cassandra における現実の読み込みトラフィックを、user groups や percentages に応じて再びチューンアップしていく。

4.Once we’re satisfied with the new system (we’re using the real production traffic with instrumentation in our application to QA the new datastore) we can start turning down traffic to the mysql databases.A philosophical note here — our process for rolling out new major infrastructure can be summed up as “integrate first, then iterate”. We try to get new systems integrated into the application code base as early in their development as possible (but likely only activated for a small number of people). This allows us to iterate on many fronts in parallel: design, engineering, operations, etc.

4. この新しいシステム（新しいデータストアに関する QA を実現するために、アプリケーションにおける実際のトラフィックを利用している）に満足できるようになったら、MySQL へのデータベース･トラフィックを停止し始める。新しいインフラストラクチャを達成するためのプロセスは、 “integrate first, then iterate” という発想に要約することができる。私たちは、以前に開発されたアプリケーション･コードをベースにして、新しいシステムを統合しようと試みる（それを出来る人は限られている）。しかし、そうすることで、デザイン／エンジニアリング／オペレーションなどのプロセスを、並列的に繰り返せるようになる。

MyNoSQL: Please include anything I’ve missed.

MyNoSQL: なにか足りないことがあったら、補足してほしい。

Ryan King: I can’t really think of anything else.

Ryan King: あまり、他のことは考えていない。

MyNoSQL: Thank you very much!

MyNoSQL: どうも有難う！

References

◦[1] The ☞ Up and running with Cassandra is probably one of the most detailed posts on the internet about Cassandra. MyNoSQL has also a post listing the best resources available for Cassandra documentation. It contains a fair amount of details about using Cassandra for storing Twitter data. (↩)

◦[2] If you remember our post Cassandra in Production @ Digg, Digg is using Hadoop and Cassandra’s BinaryMemtable to load preserialized data. (↩)