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を大きく上回るスループットを比較的低コストで達成できると考えられる。

Amazon EC2上でも試してみた

 今回のCassandraの検証は、米Amazon Web ServicesのIaaS「Amazon EC2」でも実施してみた。データのコピー数を変えるなど、異なるパターンでも試したが、本文で示したオンプレミスでの検証とほぼ同じような結果になった。ノード数を増やすとスループットは曲線を描いて向上し、一貫性の設定を変えると同じように性能が変化した。

 気付いたのは、検証する時間帯や、立ち上げる仮想マシンによって結果がばらつく傾向があったこと。このため本記事ではオンプレミスでの検証結果を紹介した。

 EC2を利用して感じたのは、Cassandraのようなデータベースを利用する場合、クラウドサービスが非常に有効ということだ。システムの負荷が上がったとき、クラウドサービスなら直ちにサーバー数を増やせる。負荷が下がったときに、サーバー数を減らしてコストを下げることも可能である。

出典:日経SYSTEMS 2011年7月号 pp.53-54
記事は執筆時の情報に基づいており、現在では異なる場合があります。