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

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

また, 実験は2つ行う.
まず行う実験は, 複数のノードで起動してるうちの1つのノードに負荷をかける方法である.
これはノードの数に比例してレスポンスが遅くなっていないか確かめるためである.
\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.70]{figures/jungle_experiment.pdf}
    \caption{複数起動中のJungle の1ノードへの負荷}
    \label{fig:jungle_exp}
  \end{center}
\end{figure}

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=0.70]{figures/cas_experiment.pdf}
    \caption{複数起動中のCassandra の1ノードへの負荷}
    \label{fig:cas_exp}
  \end{center}
\end{figure}

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

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

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


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


\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
\end{tabular}
\end{center}
\end{table}



\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台から50台まで10台単位でweighttpにより負荷をかけ測定した.
weighttpに付けたオプションは以下のとおりである
\begin{lstlisting}[frame=lrbt,label=src:weighttp_op,caption=weighttpのオプション,numbers=left]
weighttp -n 1000000 -c 1000 -t 10 -k "http://url"
\end{lstlisting}
ネイティブスレッドを10個生成し, 同時接続は1000までで, 百万リクエストを送るオプションとなっている.

実験の結果を示す.
縦軸は全てのリクエストに対してレスポンスが返ってくるのにかかった時間(秒), 横軸は
サーバノード数を表す.
Jungle と, Cassandra のコンシステンシー・レベルをQUORUM, ONEと両方の結果を測定した.
Cassandraのレプリケーションは5である.

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{figures/read_bench.pdf}
    \caption{読み込みベンチマーク結果}
    \label{fig:read_cassandra}
  \end{center}
\end{figure}

\begin{figure}[htpb]
  \begin{center}
    \includegraphics[scale=1.0]{figures/write_bench.pdf}
    \caption{書き込みベンチマーク結果}
    \label{fig:write_cassandra}
  \end{center}
\end{figure}

読み込み, 書き込み, どちらともJungleが3倍以上早くレスポンスを返していることが確認できる.
また, CassandraもJungleもノードの数が増えてもレスポンスを返す時間が遅くならないことも分かる.




\section{実験結果2}
学科の並列環境クラスタを用いて分散環境下での実験を行う
学科の提供するVMは48台だが, ブレードサーバ上で動くKVMから12台を利用し, 合計60台を使用する.
JungleとCassandraをそれぞれサーバノード10台, 20台, 30台で動かし, クライアントも10台, 20台, 30台
と増やして負荷をかける.
KVM側はクライアント側だけに利用する.
weighttpに付けたオプションを以下の通りである.
\begin{lstlisting}[frame=lrbt,label=src:distributed_weighttp_op,caption=weighttpのオプション（実験2）,numbers=left]
weighttp -n 50000 -c 200 -t 2 -k "http://url"
\end{lstlisting}
クライアント1台からはそれぞれ5万のHTTPリクエストが送られる.
実験1に比べ同時接続数とネイティブスレッド数が少ないのはVMの環境に合わせてあるからである.

測定は読み込みと書き込みの両方を行う.
測定の結果をグラフにしたのを図\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}

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