訳：Thoughts on SimpleDB, DynamoDB and Cassandra

NetFlixのAdrian Cockroftの記事。

http://perfcap.blogspot.com/2012/01/thoughts-on-simpledb-dynamodb-and.html

====

DynamoDBについて多くの質問をもらったが、それらは個人的な思考であり、クラウドアーキテクチャにどうフィットするか？というものである。

素晴らしい性能特性を持つ優れた製品であるDynamoDBのリリースを見て興奮している。これはスタートアップとAWS上の新しいクラウド製品のための第一候補になるべきだ。そしてまた、SSDにとってもターニングポイントになると考える。SSDは、新しいDB製品のデフォルトになり、ベンチマークになるだろう。

まだSimpleDBが便利なユースケースが少しはあるが、DynamoDBはすべてのケースを置き換える。私は以前NetFilixでSimpleDBを使っていた歴史を話すが、そｒはDynamoDBの議論と関係がある。

約3年前、Netflixがクラウドへの移行を考えていた頃、AWSでストレージをどうハンドルするか？という内部会議をしていた。MySQLの強力な支持者がいて、SimpleDBはかなり新しく、その他の選択肢は新しいNoSQLプロジェクトか高価なエンタープライズソフトウェアだった。2つの選択肢を調べるプロジェクトを開始し、既存のMySQLアプリをAWSに移植することを決めた。その一方で、クラウドで使えるように Oracle データセンターシステムのデータをSimpleDBにレプリケーションするパイプラインを構築していた。MySQLの経験は、スケーリングのトラブルを我々に見せ、SimpleDBは信頼感が見えた。それで、我々はSimpleDBにデータソースを（そして大きなBlobはS3に）構築することを継続した。

途中、参照のレイテンシを改善するためにSimpleDBとS3の前面にmemcachedを配置した。SimpleDBの耐久性はSimpleDBの最も優れた点である。ここ数年、データセンター内のOracleとSANでのデータ不整合バグを抱えていたが、SimpleDBのデータが不整合になったり欠損することは決してなかった。テーブル・行・属性のサイズ制限・全リクエストに必要なHTTP認証の事前リクエストによるオーバーヘッドなどを制限を回避した。

NoSQLへの第一歩の教訓は、ホストソリューションへ達したことで、それらを実行させるエキスパートチームを作る必要がなくなったこと。そして、どのくらいスケールさせなければならないか？を考える必要がなくなった。話をもとに戻すと、私はおそらくDynamoDBへ行くだろう。それは抵抗が少なく、開発者に優しいソリューションである。

2010年の間に、約20のNoSQLを見て、違いを知るために試して、やがて、プロトタイプの候補としてCassandraに落ち着いた。1週間ちょっとの間、SimpleDBからCassandraに主なデータソースを移行し、新しいアーキテクチャに慣れたり、ベンチマークを走らせたりした。その他も試したが、Cassandraを次の段階へ進ませ、本番のデータソース用に使うことにした。

我々がCassandraを好んだのは、全員JavaエンジニアのチームにおいてJavaで書かれていること、分散システムのアルゴリズムがすべて組み込まれていること、コードのクオリティ、Datastaxから商用サポートを受けられること、スケーラブルであること、そしておまけにマルチリージョンもサポートしていたことである。好きではなかったことにCassandraを運用するスタッフチームが必要という点があったが、数名のDBAを再教育し、Vijay Parthasarathy(Cisco WebexでマルチリージョンのCassandraを開発し、最近Apache Cassandraプロジェクトのコアコミッタになった）を含む優秀なエンジニアを採用した。我々は Hectorクライアントライブラリとも戦い、自分たちも書いた（もうすぐリリース予定）。Cassandraの祝福と呪いは、プロジェクトを速く動かした。安定版を選べないほど新バージョンがものすごく速く来たが、数週間後には我々のパッチがメインストリームリリースに登場した。「Cassandraは〇〇しない」ということは、文句ではなく挑戦だった。もし〇〇が必要なら、Apacheプロジェクトを補って追加した。

DynamoDBがリリースされた今、Netflixが使う予定があるかどうかというのは明らかな質問だ。短い答えはNo。というのも、我々が依存しているCassandraの機能のサブセットであるから。しかし、性能面・スケーラビリティ・レイテンシでSimpleDBから大きく劣ってはいない。新しい客や、MySQL/MongoDBのスケーラビリティで足りない人々にとって、DynamoDBはAWS上のデータソースとして素晴らしい開始点である。管理ゼロの利点は、性能・スケーラビリティ・SSDバックエンドと併せて、説得力がある。

個人的にDynamoDBに一番がっかりしたことは、スナップショットや差分バックアップの機能が無いことだ。データをEMRに抽出してS3に保存できるというのがAWSの答えだ。基本的にはSimpleDBと同じ答えで、テーブルフルスキャンのデータ抽出であり、時間とコストがかかり差分ではない。そのコストを平準化するために我々がCassandraで構築したメカニズムは、Cassandraが不変ファイルに書き、それを圧縮してS3にコピーする。これは極めてオーバーヘッドが小さい。コードのバグでデータ不整合が起きたり、ロールバック・バックアップ・レストアが必要な場合に備え、全ファイルをS3に保管してある。

DynamoDBへの議論は、DynamoDBはAWS専用であり顧客がロックインされることであるが、SimpleDBからDynamoDBとCassandraへのアップグレードが簡単である。DynamoDBとCassandraは同様のスキーマモデル、一貫性オプション、可用性モデルを持つ。Cassandraはより多くの機能を持ち、制約は少ない。SQL言語の方言と機能の複雑さに対応することと、NoSQLの提供するシンプルさを考えると、NoSQL間でデータストアを移行することは、リレーショナルDB間で移行することよりも些細である。インストールから直接的な制御や、マルチリージョンサポートのようなCassandra特有の機能を必要とするなら、Cassandraに切り替えるよりもDynamoDBではじめることは実行可能な戦略である。

アーリーアダプターらしく、最近のクラウド移行に比べて先駆者的なエンジニアリングを必要とした。その過程で、開発を加速さするためにAWSを平準化し、 Cassandra周りで多くの自動化を構築した。SimpleDBがNoSQL界隈でマイナーなプレイヤーだったのに対して、DynamoDBははるかに大きなインパクトがある。Cassandraは昨年で成熟し利用と配備が簡単になったが、スケールダウンしている。もし私がスタートアップにいる単独の開発者なら、サポート不要で安く増やせるコストのDynamoDBに対して開発をはじめられる。我々の最小のCassandraクラスタは 6台のm1.xlargeインスタンスが3ゾーンまたがり3レプリケーション構成になっている。

2012年がNoSQLがメインストリームになると言い続けているが、DynamoDBはもう一つのメジャーな動き(move)になる。標準的なCEO と CIOの会話が移ろっている。2010年「我々のクラウド戦略は何だ？」2011年「我々のビッグデータ戦略は何だ？」2012年「我々のNoSQL戦略は何だ？」