リニアには性能が上がらない

　Cassandraのスループットの変化を調べた結果を図2に示した。Cassandraのノード（サーバー）数が2、4、6台のそれぞれにおいて、実行する検証用アプリケーションのスレッド数を徐々に増やした。各スレッドで、書き込み、または読み出しを繰り返し実行し、スレッド数を増やしていくことで、Cassandraの負荷を高めていった。

図2●アクセス負荷を変えたときのスループットの変化

Cassandraに対する負荷を高めていくと、スループットは曲線を描いて向上していくことが分かった。負荷の増加に対して、十分に性能が向上しなくなったポイントを探し、2、4、6ノードの場合を比較した。検証用の機器は、プリファードインフラストラクチャーから貸与を受けた

[画像のクリックで拡大表示]

　まず分かったのは、アクセス負荷を高めたとき、Cassandraのスループットは曲線を描いて、向上していくことだ。RDBなど多くのデータベースは負荷を高めていくと、スループットはほぼリニアに伸び、あるしきい値に達したときに一気に性能が劣化する。場合によってはシステム全体がダウンすることもある。増加したアクセスをデータベースがさばき切れなくなるからである。

　Cassandraのスループットをよく見てみると、あるスレッド数に達したところで、伸びが落ち込むことが分かった。Cassandraはその時点でレイテンシーが大きくなり、要件によっては十分な応答性能が出せなくなるだろう。そこでここでは、そのときのスループットを、各ノード数でのCassandraの限界性能と見なした。

　結果、書き込み時には、ノード数が4台のときは2台のときの1.4倍、6台のときは2.3倍の性能となった。読み出し時はそれぞれ1.4倍、2.1倍である。ノード数を2倍、3倍にしても、性能は2倍、3倍にはならないことが分かった。

図3●Cassandraで各ノードの負荷がほぼ均等になる仕組み

各ノードのハッシュ値と、データのキーのハッシュ値を計算して、保存するノードを決定する。キーのハッシュ値はランダムに変わるため各ノードの負荷はほぼ均等になり、ノード数の増加に合わせてスループットが向上する

[画像のクリックで拡大表示]

　Cassandraは元々、適切なキーを選べば、各ノードの負荷が均等になり、高いスケーラビリティーを実現できる仕組みを持っている。図3にその仕組みを示した。

　Cassandraでは、ノードとキーのハッシュ値をそれぞれ計算し、どのノードにキーを保存するかを決める。キーを基にハッシュ値はランダムに変わるため、データの各ノードへの配置はほぼ均等になる。このためノード数を増やすほど、ノード1台当たりのアクセス数は少なくなり、全体としてより多くのアクセスを処理可能になる（スループットが向上する）。しかし検証結果を見ると、ノード数が増えると何らかのオーバーヘッドが発生し、リニアには性能が向上しないようだ。

　もっともCassandraは、Facebookが150台程度で運用したという実績がある。高性能のサーバーに置き換えるスケールアップでしか性能を高めづらいRDBでは、とても達成できない台数だ。Cassandraはノード数をさらに増やしていくことで、RDBを大きく上回るスループットを比較的低コストで達成できると考えられる。