\chapter{分散木構造データーベース Jungle の評価}
前章ではJungleにおける分散データベースの詳細な実装について述べた.
本章では実装を行ったJungleに対してCassandraとの性能比較を行い評価をする.
性能比較の為に簡易な掲示板プログラムをJungleとCassandra それぞれに作成した.
複数のノードに繋がっている状態においても性能を測りたいため, 学科が提供する
VMWareの並列環境を利用する. また, 我々の研究室が利用しているブレードサーバ
上で動いているKVMもクライアントとして利用する.
Jungleは永続性はなく分散だけ実装で測定を行っている.

\section{実験方法}
実験は同じ機能を提供している簡易掲示板プログラムをJungleとCassandraそれぞれで
動かし, HTTPリクエストにより負荷をかけて行う.
レスポンスが返ってくるまでの時間をはかり, 平均時間と標準偏差を求めグラフに出力する.

また, 実験は2つ行う.
まず行う実験は, 複数のクライアントから1つのノードに負荷をかける方法である.

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.70]{figures/cluster_request_server.pdf}
    \caption{実験1 複数のクライアントからサーバ1台への負荷}
    \label{fig:clients_singleserver}
  \end{center}
\end{figure}



次に行う実験は複数のノードに対し複数のクライアントから負荷をかける方法である.
それぞれ大量のHTTPリクエストをだし, 全てのリクエストの処理にかかる時間を測定する.

クライアントの数に比例してノードを増やすことでレスポンスを維持できるか
スケーラビリティを調べるためである.
\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.70]{figures/clients_request_servers.pdf}
    \caption{実験2 複数のクライアントから複数のノードへの負荷}
    \label{fig:clients_servers}
  \end{center}
\end{figure}

\subsection{Torque Resource Manager}
並列環境下にあるマシン全てに命令を出し, タスクを実行させることは非常に大変である.
そのため, 今回の実験において並列環境のマシンに同時にタスクを実行させるために
Torque Resrouce Managerを利用する.
Torque はQueueによりタスクの実行順序を制御する.
Queueにタスクをいれる際には, そのタスクをいくつのノードで
実行するか, いくつのコア数を使用するかといったリソースの設定も行うことができる.


\subsection{weighttp}
最初の実験で1つのノードに負荷をかけるプログラムはウェブサーバの測定ツールであるweighttpを使用する.
weighttpは総リクエスト数, 同時接続数, ネイティブスレッド数をオプションとして指定することができるC言語
でかかれたプログラムである.


\subsection{掲示板プログラム}
今回使用する掲示板プログラムは組み込み用ウェブサーバであるJettyをフロントエンドとして利用し, バックエンド
に Jungle と Cassandra を利用している.

\begin{table}[!htbp]
\caption{簡易掲示板システムで利用したJettyとCassandraのバージョン}
\label{tab:bulletinboard_components}
\begin{center}
\begin{tabular}{|c||c|} \hline
名前 & バージョン \\ \hline \hline
Jetty & 6.1.26 \\ \hline
Cassandra & 2.0.4 \\ \hline
\end{tabular}
\end{center}
\end{table}



\subsection{実験環境}

\subsubsection{サーバノードとクライアントを実行させるサーバの仕様}
使用するVMWareとKVMのクラスタの使用を以下に示す.
クラスタは仕様を表\ref{tab:cluster_spec_vmware}と表\ref{tab:cluster_spec_kvm}に示す.

\begin{table}[!htbp]
\caption{掲示板プログラムを実行させるVMWareクラスタの仕様（クライアントにも利用）}
\label{tab:cluster_spec_vmware}
\begin{center}
\begin{tabular}{|c||c|} \hline
名前 & 概要 \\ \hline \hline
CPU & Intel(R) Xeon(R) CPU X5650@2.67GHz \\ \hline
Memory & 8GB \\ \hline
OS & CentOS 5.8 \\ \hline
HyperVisor & VMWare ESXi \\ \hline
JavaVM & Java(TM) SE Runtime Environment (build 1.7.0-b147) \\ \hline
\end{tabular}
\end{center}
\end{table}

\begin{table}[!htbp]
\caption{クライアントを実行させるKVMクラスタの仕様}
\label{tab:cluster_spec_kvm}
\begin{center}
\begin{tabular}{|c||c|} \hline
名前 & 概要 \\ \hline \hline
CPU & Intel(R) Xeon(R) CPU X5650@2.67GHz \\ \hline
Memory & 8GB \\ \hline
OS & CentOS 5.8 \\ \hline
HyperVisor & KVM \\ \hline
JavaVM & Java(TM) SE Runtime Environment (build 1.7.0-b147) \\ \hline
\end{tabular}
\end{center}
\end{table}

\subsubsection{ブレードサーバの仕様}
最初の実験ではブレードサーバ1台で掲示板プログラムを動かし, 並列環境から複数のクライアント
で負荷をかける.
ブレードサーバの仕様を表\ref{tab:server_spec_1}に示す
\begin{table}[!htbp]
\caption{サーバノードとして利用するブレードサーバの使用}
\label{tab:server_spec_1}
\begin{center}
\begin{tabular}{|c||c|} \hline
名前 & 概要 \\ \hline \hline
CPU & Intel(R) Xeon(R) CPU X5650@2.67GHz \\ \hline
物理コア数 & 12 \\ \hline
論理コア数 & 24 \\ \hline
Memory & 132GB \\ \hline
OS & Fedora 16 \\ \hline
JavaVM & Java(TM) SE Runtime Environment (build 1.7.0\_51-b13) \\ \hline
\end{tabular}
\end{center}
\end{table}

\subsubsection{Jungle実行時のJavaVMのオプションの設定}
サーバでJungleを実行するときは, JavaVMがデフォルトで設定しているHeapサイズの容量を
大きくする.
Jungleでは非破壊でデータを保持するため, データで使用するメモリの量が大きい.
JavaのHeapサイズをデフォルトのままでベンチマークプログラムを走らせると, 
エラーの\verb|java.lang.OutOfMemoryError: GC overhead limit exceeded|が出力されてプログラムが終了してしまう.
このエラーはFull GCにかかる回数が多いか, プログラムの98\%以上GCに使用されていると出力されるエラーである.
そのため, ブレードサーバでは\verb|-Xmx20g -Xms10g|をつけ, VM側では\verb|-Xmx6g -Xms4g|のオプションを付けて行う.

\subsubsection{サーバの環境}
HTTPによりノードに負荷を掛ける場合気をつけることがある.
それはサーバの設定により最大コネクション数や開くことのできるファイル記述子の数に制限がかかっていることである.
この2つの値はデフォルトでは小さなものとなっており, そのままではカーネル
の設定がネックとなったベンチマーク結果がでる可能性がある.
そこで次のようにコマンドを実行することでコネクション数の制限を増やすことができる.
\begin{lstlisting}[frame=lrbt,label=src:maxconn_up,caption=コネクション数を増やす,numbers=left]
% sudo sysctl -w net.core.somaxconn=10000
\end{lstlisting}
ファイル記述子の制限を増やす場合は次のコマンドを実行する
\begin{lstlisting}[frame=lrbt,label=src:max_up_filedisc,caption=ファイル記述子の制限を増やす,numbers=left]
% ulimit -n 10000
\end{lstlisting}



\section{実験結果1}
複数のクライアントからサーバノード一台に対して負荷をかける実験を行った.
クライアントの数は10台から始まり5台ずつ増やしていき, 最大45台まで増える.
各クライアント以下のオプションをつけたweighttpプログラムが実行される.
\begin{lstlisting}[frame=lrbt,label=src:distributed_weighttp_op,caption=weighttpのオプション（実験1）,numbers=left]
weighttp -n 20000 -c 20 -t 2 -k "http://url"
\end{lstlisting}
このオプションは2つのネイティブスレッドを使用し, 同時に20のコネクションを張り, 通信の間コネクションを切らずに2万件の
HTTP requestを送信することを表している.
Cassandraはサーバノードが一台の為, Replication factor 1でConsistency LevelはONEとなる.


実験の結果はグラフ\ref{fig:singlenode_read_bench}, \ref{fig:singlenode_write_bench}となる.
横軸はクライアントノードの数を表しており, 値が増えるほどリクエストの数も増え負荷が高まる.
縦軸は2万件のリクエスト全てにレスポンスを返し終えた時間を表している（単位：秒）.

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{figures/bldsv12_read_bench.pdf}
    \caption{複数のクライアントから一台への負荷}
    \label{fig:singlenode_read_bench}
  \end{center}
\end{figure}

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{figures/bldsv12_write_bench.pdf}
    \caption{複数のクライアントから一台への負荷}
    \label{fig:singlenode_write_bench}
  \end{center}
\end{figure}
\newpage

\subsection{実験結果1の考察}
読み込み, 書き込みともにJungleのほうが良い結果となっている.
書き込みの差が大きく開いていることに関しては, Cassandraはディスクへと書きだすとき
もあるのも原因の1つと考えられる.
Jungleはオンメモリであることから, やはり差はでてしまう.
しかしディスクに書き出していないこととは別の要因も考えられる.
Jungleは非破壊的木構造なため, ロックをほとんど必要としない.
書き込み時においてもロックが必要なときは木のコピーをとりおえて, ルートノード
を更新するときのみである.
書き込みの速度が早いことはJungleのロックが少ないことも要因の1つとしてあげられる.


\newpage
\section{実験結果2}
学科の並列環境クラスタを用いて分散環境下での実験を行う
学科の提供するVMは48台だが, ブレードサーバ上で動くKVMから12台を利用し, 合計60台を使用する.
JungleとCassandraをそれぞれサーバノード10台, 20台, 30台で動かし, クライアントも10台, 20台, 30台
と増やして負荷をかける.
クライアントとサーバノードの数は1:1となるため, 横軸の値の数が増えると総リクエストは増えても
1台に与えるリクエスト数は変わらない.
縦軸はリクエストに全てに対してレスポンスを返しきった時間を表す（単位：秒）
KVM側はクライアント側だけに利用する.
weighttpに付ける引数は実験1と同じとする.
各クライアントから2万のリクエストを送る.
CassandraはConsistency Level ONEとQUORUMの両方を計測する.
QUORUMのReplication factorは5で設定してある.

測定は読み込みと書き込みの両方を行う.
測定の結果をグラフにしたのを図\ref{fig:distributed_read_bench}, \ref{fig:distributed_write_bench}に示す.
横軸はクライアントとサーバノードの数を表す.


\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{figures/distributed_read_bench.pdf}
    \caption{分散環境下における読み込みベンチマーク結果}
    \label{fig:distributed_read_bench}
  \end{center}
\end{figure}

\newpage

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{figures/distributed_write_bench.pdf}
    \caption{分散環境下における書き込みベンチマーク結果}
    \label{fig:distributed_write_bench}
  \end{center}
\end{figure}


\subsection{実験結果2の考察}
こちらも, JungleのほうがCassandraにくらべて良い結果となっている.
%実験1の結果と比べると全体的にデータのあばれが少なくなっている.
%これはクライアントの数が増加してもサーバノードの数も増加するため, サーバノード一台に対する
%HTTPからの負荷が変わらないためだと考えられる.
特に読み込みに関してはConsistentcy Level QUORUMの場合と比べると3倍以上離れている場合もある.
実験1に比べてJungleとCassandraの差が開いているのはCassandraのConsistency Level
がQUORUMに設定されていることが要因の1つとしてあげられる.
今回CassandraのReplication factorは5と設定している.
そのため, Consistency LevelがQUORUMの場合は, 書き込みは3つのノードに書き込まれたことを確認
し, 読み込みは3つのノードからデータを取得して最新のデータを返す為である.
Jungleの結果が横軸の値が増えても横ばいになっていることにも注目したい.
これはJungleの場合, リクエストが来た際に, それぞれのノードがローカルにある木の情報をすぐに
返すためである.
そのため, クライアントが増え, 総リクエスト数が増加しても一台に対する負荷が増えない限りは
同じレスポンス速度を維持できる.
%1つ気になる点としては, Cassandraは横軸の値が30のときの結果が25の時に比べて下がっている点である.