Cassandraを利用したサービスのPCクラスタを用いたスケーラビリティの検証

Shoshi TAMAKI , Shinji KONO

University of Ryukyus

研究の目的

インターネット上のサービスで重要なのはスケーラビリティ、つまり、ユーザのアクセスの増大に対して一定のサービス品質を提供することである。

スケーラブルなサービスを提供するために分散Key-Value store Cassandra が注目されている。 RDBの個々のテーブルも、Key-Value store と見ることができる。

本研究では，特に汎用性のある木構造を扱うインターネットサービスに着目する。Cassandra 上に木構造を取り扱うサービスをスケーラブルに提供するフレームワークを設計し実装する。

研究のスケジュール

  • 第１クォーター：Cassandraの検証
  • 第２クォーター：スケーラビリティの高いサービスの設計
  • 第３クォーター：スケーラビリティの高いサービスの実装
  • 第４クォーター：実装したサービスの検証

1Qでは、Cassandra のPCクラスタを用いたスケーラビリティを実験する環境を構築した。

しかし、1対1の環境ではmySQLの方が性能が良かった。

今回はCassandraが実際にスケールすることを確認した。

その結果を元に、木構造をスケーラブルに取り扱うシステムの設計を行なった。

1Qまでのあらすじ

前回の発表では以下のことについて発表を行った．

  • Cassandraの紹介と基本的な使用方法
  • Cassandraを利用したアプリケーション
  • コンシステント・ハッシュ
  • １台のクライアントとサーバーを用いた簡単なベンチマーク

シンプルなベンチマークではMySQLにCassandraでは超えられられなかった

課題として，Cassandraがスケールする条件の検証が残った．

2Qまでのあらすじ

  • スケーラビリティの検証環境をTorqueを使って構築した
  • Cassandraが実際にスケールすることを実験で確認した
  • スケーラビリティの高い木構造を対象としたサービスの設計を行った

3Qの課題としてCassandraのノード数を増やした場合、コア数の多いサーバの場合の検証が必要なこともわかった。

プロタイプ実装でも実験によってスケーラビリティを確認しながら設計/実装を深めていく必要がある。

前回の実験概要

  • Torqueを利用して，任意台数のクラスタ（クライアント）に同時にスクリプトを実行させる
  • スクリプトは，ある時間になると一斉に目的のサーバーに1万回のアクセスを開始する
  • クラスタの台数を変動させCassandraとMySQLサーバーに負荷をかける．
  • 複数台のクラスタが処理に要した時間の平均をグラフ化し比較する．

前回の実験方法

実験環境

ベンチマークを取るために構築した環境

クラスタ MacMini Core i7
クライアント サーバ サーバ
CPU Core Duo 2G (1) Core 2 Duo 2.53G (2) Core i7 3.0G (4)
Memory 1GB 4GB 14GB
OS CentOS 5 OSX 10.6 CentOS 5

このうちクラスタは80台用意されている．

()内はコア数で，Core i7のみ4コア8スレッドである．

前回のベンチマークのまとめ

  • クライアントが複数いるときにCassndraが性能を発揮する．
  • コア数の少ないサーバーでは，性能が落ちる
  • コア数の多いサーバーでは，MySQLより平均時間の増加度が少ない．
  • サーバーの台数を増やすだけでは１台の性能を超えることはできない．
  • Cassandraの性能を活かすことのできる，条件はコア数の多いサーバーでかつ読み書きが頻繁に行われるアプリケーションであるということが分かった．
  • MacMini の性能はここまでか? サーバを増やせば良くなる可能性もある?

Cassandraの特徴・性能を検証できた，ではどのようにシステムを開発すればスケールするのか？

スケーラビリティのあるサービスの開発

クラスタを用いたベンチマークにより, Cassandraの性能とスケーラビリティの検証方法を確認することができた.
これを踏まえた上でCassandraを利用したスケーラビリティのあるサービスを開発する．

スケーラビリティがあるということは？

  • 負荷がかかっても遅くならない
  • サーバーの台数を増やすだけで性能を維持できる

スケーラビリティを高めるためには

[方法1]データの複製を多く用意する

  • 一つのデータにアクセスが集中するとネットワークが遅くなるが，分散させることで避けることができる

スケーラビリティを高めるためには

[方法2]データの伝搬にはポーリングを利用する

  • データに更新があったとき，すべてのコピーデータに通知すると通信量が膨大になる．
  • 実際には必要なときに更新すればよいため，通知するのではなく見に行く(ポーリング)を行えばよい．(頻度が低く範囲が小さいと期待される)

提案するシステムのアーキテクチャ

CassandraとWebサーバーが直接通信するのではなく, 間にサービスのAPIを提供するサーバーを挟む

テストをサービスAPIの段階で行える

PHP, Grails, Servlet 等にも対応可能

システムのアーキテクチャ

  • 開発言語はJavaを利用
  • APIを提供するためにCassandraも利用しているRPCである，Thriftを使用する
  • SEDAを採用するか，しないかは未定 (採用すると、性能は出るが複雑になる)
  • スケーラビリティは検証してみないと確認できない
  • そのため，プロトタイプを作成してその性能を検証しながら開発をすすめる

データ構造

スケールするサービスを開発するためにはスケールするデータ構造を考える必要がある

サービスのデータ構造として木構造を利用したい，しかし，これがスケールする必要がある

  • 通常の木構造（破壊的木構造）
    • データを書き換えて木を編集する
  • 非破壊的木構造
    • データを書き換えず，コピーして編集する

今回は非破壊的木構造を使用して開発を行う

非破壊的木構造

編集する木構造の内容を変更せずに, 変更するノードのコピーと変更がないノードで新しく木構造を作る

コピーの場合の比較（破壊的木構造）

[方法1]に則ってスケールするためには，複製を作成しやすいデータ構造である必要がある．
破壊の場合は変更を複製全部に通知する必要がある

コピーの場合の比較（非破壊的木構造）

非破壊の場合は自由に複製を作って良い

ポーリングの場合の比較

[方法2]に則って変更の通知をポーリングでやりやすいデータ構造を選択する必要がある．

破壊的変更の場合はポーリングでは木全体を見る必要がある．なので通知の方が現実的

非破壊の場合は木の先頭を見れば更新されているかどうかがわかる(ポーリングのアクセスの集中を防ぐ工夫は必要)

非破壊的木構造

  • 利点
    • ロックを必要としない
    • 複製を自由に作成することができる（変更を伝搬する必要はなく，複製先が監視すればよい）
  • 欠点
    • 次々に複製を作成するため，メモリ使用量が多い
    • 編集するための計算量が多い（編集対象のノードまでのパスの長さまで複製するため）

ロックを必要としない・複製を自由に作成できるという利点からスケールするのではないかと考えられる

非破壊木構造Editorの実装

  • イメージとしては分散リポジトリ（Git,Mercurial)
  • APIとしてcommit,push,pull,update,discard,mergeがある。
  • 木構造をコピーし、ローカルへ保存して編集しリモートへ更新する。（非破壊的）
  • 更新は変更をコミットする際に検出する。（ポーリングの利用）

非破壊木構造Editorの実装

非破壊木構造Editorの実装

  • このEditorを各ステージ（ブラウザ上、APIサーバー上、Cassandra）において実装する。
  • こうすることで非破壊構造を分散して構築することが出来る。

OnMemory上の非破壊木構造の実装

これは書くの必要ですか？

Cassandra上での非破壊構造の実装

これは書くの必要ですか？

リンクの実装

  • 非破壊木構造の特性上、ルートノードに負荷がかかる。
  • そのため、リンクを導入しある部分で親ノードに更新が伝搬しないようにする。
  • リンクされた先をルートノードとし編集することでリンクの親ノードへ更新は伝搬されない。

まとめ

  • 非破壊木構造Editorは分散リポジトリを参考にした構造。
  • ローカルにコピーし、それを非破壊的に変更していく。
  • 複数ステージにおいてツリーをコピーし、それぞれの段階で非破壊的に編集する。
  • ルートノードの負荷分散のためにリンクを導入する。

今後の課題

  • 実装したEditorを使ったベンチマークテスト
  • 引き続きEditorの実装
  • レンダリングエンジンの実装

ご清聴ありがとうございました