TwitterがCassandraを使った理由と移行方法

相変わらずの意訳な上に要点のみの抜き出しです。
間違っていたらTwitterでもコメントでいいのでがんがん指摘してください。

===============
Twitterではデータ量、データ増加量が急加速している。
今まではMySQLとmemcashedで運用してきたが、特に運用要員の面で費用が莫大になってしまった。
その為により自動的でより高い分散容易性、より高い可用性を必要とした。

選択肢として上ったのが下記の二つ。

・MySQL Clusterの今以上の自動化
・KVS(HBase、Voldemort、MongoDB、MemcacheDB、Redis、Cassandra、HyperTable)への移行

次の検証を行う事で選択肢の絞り込みを行った

・新規Node追加の容易性
・SPoFの有無
・Scalingに伴いデータ書き込みもScalingするか
・管理作業はどれ程必要か
・OSSである場合、健全な運営団体を伴っているか
・準備、移行に必要な時間と労力はどれ程か
・それを取り扱う為に新たな技術を学ぶ必要があるか

等々

結果的にCassandraに絞られ、Cassandraの検証を開始した。
検証では特に書き込みに重点を置いた。
現在大量のmemcachedを利用しているが、中長期的にみてDBの前にCacheを置かずに運用出来るかも検証した。

結果、Cassandra採用の要因となったのは

・SPoFがない事
・書き込み能力がScalingする事
・Cassandraを支える母体が健全である事

今後Twitterの全てのシステムをCassandraに載せ替えるつもりだが完全移行までには時間がかかる。現段階では維持が最も重要で最も維持が困難なTweetとReTweetのテーブルをCassandraに移行している。これが追われた後は簡単だ。

この既存データの移行に関しては元々Twitter側にそれに適したシステムがあるのでそれを利用する。この機能を利用して漸進的に機能拡張を行っていく。

Twitterが今後行う移行作業は次の通り

1.CassandraとMySQLの両方にデータを書き込む。同時に各々の書き込みが即停止出来る様にしておく
2.徐々にCassandraへの書き込みを行う
3.バグの調査
4.Cassandraへの書き込みの停止
5.新規システムのバグ修正を行い、再度適用を行う
6.2へ戻る

上記作業が終了した次を行う

1.MYSQLのバックアップ
2.Cassandraへのデータインポート ※1
3.データのインポートが終わったら読込をCassandraから行う様にする
4.満足がいく性能がでれば徐々にCassandraからの読込に切り替え、MySQLの利用を停止していく。駄目ならMySQLに戻して再度調整を行う。

※1 BinaryMemtableを利用したが高速すぎてネットワークI/Oを食いつぶしてしまう為にやめて通常のThriftに戻した。この状態だと一週間かかる。もし無限のネットワーク帯域があれば7時間で終わるだろう。

上記手段を用いて移行を完遂する。

元ネタ
■Cassandra @ Twitter: An Interview with Ryan King