分散 Database Jungle に関する研究

概要

ウェブサービスにおけるデータベースの重要性

ウェブサービスへの負荷が高まることは、データベースへの負荷が高まることでもある。

データベースの性能が低ければ負荷に耐え切れずサービスはダウンする

そのため、データベースにはスケーラビリティが必要

スケーラビリティとは

システムが負荷の増大に対して柔軟に拡張して対応できる性質

主に次の2つの方法によりシステムはスケールされる

• スケールアップ：
  高価な単一マシンによる性能アップ


• スケールアウト：
  汎用的なマシンを複数台用意することで性能アップ

分散システムにおいてはスケールアウトによりスケーラビリティを高める

データベースのスケーラビリティ

データベースのスケーラビリティを考えるとき、どういう用途で使用するかを考えるのが重要。

ウェブサービスにおいても、どのようなサービスを行うかによってスケーラビリティの確保の仕方も変わってくる。

本研究で開発しているデータベースはコンテンツマネジメントシステム（CMS）を対象としている。

コンテンツマネジメントシステム(CMS)

Webコンテンツを構成するテキストや画像などのデジタルコンテンツを管理し配信するシステム。

『分散』コンテンツマネジメントシステムに求められること。

データ全体の整合性に遅延がある結果整合性でも問題なく。書き込みや読み込みを優先としたデータベースが必要。

そこで、非破壊的木構造データベースJungleの提案を行った。

非破壊的木構造データベースJungle

JungleはスケーラビリティのあるCMSの設計を目指して当研究室で開発されているデータベース。

データを木構造で、さらに非破壊で保持する。

まず、破壊的木構造と非破壊的木構造について説明する。

破壊的木構造

木構造の通常のデータ表現

破壊的木構造は、木構造により保持しているデータの編集をデータを直接書き換えることで行う

破壊的木構造

破壊的木構造ではデータの編集中にそのデータを読むことができない

編集が完了するまでまたなければならない

非破壊的木構造

非破壊的木構造は一度作成したデータは変更しない

新しい木構造を作成することでデータの編集を行う

非破壊的木構造におけるデータ編集

目的とするノード5ををコピーして内容を編集する。ノード100となる

ルートノードから目的のノード5までに続くルートノードとノード2のコピーとりノード100と繋げる

非破壊的木構造におけるデータ編集と読み込み

新しく作成したルートノードに変更を加えていないノードへの参照を持たせる。新しい木構造のデータができる

最新のルートノードの登録を新しく作成した側のルートノードへと登録する

非破壊的木構造の利点

非破壊的木構造は通常の木構造である破壊的木構造に比べ、以下のような利点を持つ

• 一度作成したデータは変更されない
• データが変更されないため自由にコピーを作ることができる(いつでも読み込みが可能)
• ロックがすくない。ロックが必要なのは最新のルートノードを登録するときだけ

ロックが少なく、いつでもコピーが可能なことから、非破壊的木構造はスケーラブルなシステムに有用となる

Jungleの分散設計:分散版管理システム

Jungleは分散設計を行うにあたってGitやMercurialといった分散版管理システムを意識している

分散版管理システムとは多人数によるソフトウェア開発において変更履歴を管理するシステム

分散版管理システムは次の特徴とAPIを持つ

• 開発者それぞれがリポジトリのクローンを持ち、開発はローカルのリポジトリを通すことで行われる
• ローカルのリポジトリは独立に存在し、サーバ上ある他人のリポジトリから変更履歴をとることができる。また自身の変更履歴を伝えることもできる
• データ更新時に先に別の更新が入っていた(衝突)場合はMergeによりデータの整合性をとる

Jungleの分散設計:分散版管理システム

分散版管理システムAPI

• commit:データに変更を加えたことをリポジトリに登録
• push:ローカルのリポジトリで行った変更履歴を他のリポジトリへまとめて送る
• pull:他のリポジトリからの変更履歴をまとめて受け取る

Jungleの分散設計:分散版管理システム

Jungleと分散版管理システムには似通った点がある

同じAPIを実装することで、分散版管理システムと同じく高いスケーラビリティが期待できる

具体的には

• pushやpullによる定期的なデータの更新
• Mergeによる更新データ衝突の解決

Jungleの分散実装

ここまでJungleの分散設計について説明した。

これらのシステムを実装する為にまずはJungleのノード同士でネットワークトポロジーを 組み、その上でデータをやりとりする機構が必要になる。

そこで、ネットワートポロジーを組みログによるデータの分散を行う仕組みをJungleに実装した。

また、Mergeの例として掲示板プログラムにおけるMergeの実装も行った。

Jungleの分散実装：ログによるデータ分散

今回Jungleの分散実装は以下のように行った

ツリートポロジーを形成	commit log伝搬によるデータ分散

サーバノード同士でツリートポロジーを形成する。データ編集をどのように行ったのかを示すログ commit log を伝搬させデータの分散を行う。

Jungleの分散実装:掲示板システムにおけるMerge

Mergeとはデータ更新の衝突が起きた際の解決方法

Jungleではアプリケーション毎にMergeアルゴリズムを設計

後述する性能比較に用いた掲示板システムにおけるMergeの実装を考える

掲示板システムにおけるデータ構造を以下に示す

Jungleの分散実装:掲示板システムにおけるMerge

分散データベースJungleの評価

分散データベースとしてJungleの性能を評価する。

分散Key-ValueデーターべースCassandraと比較を行う。

比較方法は、Jungle, Cassandra をそれぞれバックエンドとした簡易掲示板を作成する。

掲示板に対してHTTP Requestで並列に読み込みと書き込みの負荷をかけ計測する。

レスポンスが返る平均時間と標準偏差を求めグラフ化する

JungleとCassandraの比較方法

実験は以下の2つを行う

実験1:サーバ単体への負荷	実験2:複数台のサーバに対する負荷
複数のクライアントから単体のサーバへ負荷をかける	複数のクライアントから複数のサーバへ負荷をかける

サーバ単体の性能と, 分散環境下における性能の2つを調べる。

分散環境下におけるノードは全て繋がっている

実験に使用するサーバの仕様

実験1:単体サーバへの負荷

実験1：単体サーバへの負荷（読み込み）

ブレードサーバ一台に対して複数のクライアントからの負荷

読み込みの実験結果

JungleがCassandraより良い結果を示している

クライアントが55台のときのJungleの最速とCassandraの最遅は3倍近く離れている

実験1：単体サーバへの負荷（書き込み）

ブレードサーバ一台に対して複数のクライアントからの負荷

書き込みの実験結果

読み込み同様Jungleのほうが良い結果を示している

読み込みよりJungleとCassandraの結果が重なる部分が減っている

実験1の考察

読み込み、書き込みともにJungleの性能がよく。平均だけみても2倍以上早い部分もある。

特に書き込みに関してはクライアントの数が増えるにつれ差が開いている。

これはJungleが全体的にロックが少ないことが要因としてあげられる。

Jungleは非破壊でデータの保持をするため、読み込みは自由に行える。書き込み時には木のコピーをとりルートノードを入れ替える ときのみロックが発生する。

実験2:分散環境下における負荷

実験2：分散環境下における読み込み

読み込みの実験結果

CassandraはConsistency Level ONE(赤)とQUORUM(緑)両方を測定

Jungleは1秒から5秒をキープ

実験2：分散環境下における書き込み

書き込みの実験結果

CassandraはConsistency Level ONE(赤)とQUORUM(緑)両方を測定

Jungleは5.5秒から7.3秒をキープ

実験2の考察

こちらもJungleがCassadraより良い結果を示した。実験1よりも差がでている。

Jungleのグラフが横ばいになっていることに注目したい。

Jungleはリクエストに対し手元にあるデータを返す。そのためノードの数が増えてもレスポンスの早さを維持できる。

Cassandraはデータを持っている数台のノードに読み込みに行くという作業が入るためJungleより遅くなってしまう

Jungleは同期を取らないためデータ全体の整合性は落ちるが、分散管理システムを参考にした設計の有用性を示すことができた。

まとめ

本研究では非破壊的木構造Jungleに分散データベースの実装を行った

非破壊的木構造における利点を述べ、スケーラビリティの高い分散版管理システムとの類似性を述べた

Mergeアルゴリズムの1つとして掲示板プログラムにおけるMergeについて設計・実装を行った

性能比較の実験のためJungle、Cassandraで利用できる簡易掲示板の作成を行った

実験は単体サーバと分散環境下において行い、どちらともCassandraよりよい結果をえることができた

今後の課題

push/pull方式による分断耐性の実装

• 現実装ではJungleはデータ編集が行われた際に発生するログを非同期で他サーバノードへと送信している
• だがこの方法では接続が切れた際に再接続を行ったノードが全てのデータをとることができない
• そこで非同期とは別に同期をとり他ノードとに差分となるデータを送るということを行いたい
• これは分散管理システムにおけるpush/pull APIにあたる

今後の課題

データ分割の実装

• 現在の実装は全てのノードで全てのデータを持たせている
• この方法ではメモリの使用量が高いこととネットワーク帯域への負荷が懸念される
• ノード単位で保持するデータを分ける実装が必要
• その場合、木構造単位でノード毎にデータを分ける
• 持っていないデータの要求が来た場合は、データを持っているノードに取りに行くようにする

今後の課題

Mergeアルゴリズムの設計

• JungleはMergeを使うことで更新データ衝突の問題を解決する。
• 今回実装した掲示板プログラムにおけるMergeは単純なもの。
• 他のアプリケーションではどのようにMergeを行うのか考察が必要。

今後の課題

過去のデータの掃除について

• Jungleは非破壊でデータを保持するため過去のメモリの使用量が大きい
• ある程度の単位で過去のデータの掃除を行いたい
• そのためにはどのノードがどのデータを持っているかという情報を扱うことが必要
• どれくらいデータが古くなると掃除を行うか判断が必要

分散Key-ValueストアCassandraの特徴