IoT時代のデータストア・NoSQLの実力は? 書き込み性能から見る活用ポイント第2回

性能検証方法の概要

ここまでは、今回の検証観点についてご説明しました。ここからは、検証環境や性能測定の流れといった、検証の概要についてご説明します。

検証環境

図5：検証環境の構成（クリックで拡大）

今回の検証は、図5のような構成で実施しました。okuyama・Riakともに、物理マシン1台あたり1ノードずつ稼働するようにしています。KVSはクラスタ構成とし、データ書き込み処理を実行するサーバ（図5においてokuyamaではスレーブ、Riakではノードと記載したサーバ）を最大4台まで使用しました。okuyamaとRiakで構成が異なっていますが、これは連載の第1回でもご説明したとおり、それぞれの分散アーキテクチャが異なることに由来しています。

ハードウェアのスペックは、少し旧式のノートPCと同程度の性能です。なお、okuyamaとRiakは可用性を高めるためにデータを複製する機能を持っていますが、今回の検証ではデータ複製機能は使用しておりません。

性能測定の流れ

表1：検証パターンの一覧

No.	データ保存先	対象KVS
1	ディスク保存	okuyama
2		Riak
3	メモリ・ディスク併用	okuyama
4		Riak

上述の通り、今回の検証では表1に示した4通りの検証を実施し、同時アクセス数の増加に対するスループットのピーク性能とレイテンシを検証しました。検証は図6に示したフローで実施しました。

ここで、クライアントプログラムにはNoSQL向けのベンチマークツールであるYahoo! Cloud Serving Benchmark（YCSB）を利用しました。YCSBはマルチスレッドで動作し、NoSQLに対してパラレルにアクセスします。これにより、多数のセンサーからの同時書き込みと同じ状況を作ることができます。NoSQLへのアクセス中はスループットとレイテンシを計測し、アクセスを終了すると計測結果を集計して出力します。

それでは以下に、フローの各ステップでの処理をご説明します。

図6：計測処理フロー（クリックで拡大）

計測処理開始
クライアントに書き込み件数と同時アクセス数（仮想のセンサー台数）を指定し、計測処理を開始します。
KVSへ接続
クライアントは指定された同時アクセス数分のスレッドを生成し、スレッド単位でKVSへ接続します。
同時書き込み
全スレッドから同時にKVSへデータを書き込みます。指定された全件数を処理するまで、連続して繰り返し書き込みます。書き込み中は1件単位のスループットとレイテンシを計測します。なお、書き込むデータサイズはKeyとValueともに約25バイトとしました。
計測処理終了
指定された全件数を書き込み終えると、処理を終了します。スループットとレイテンシの計測結果を集計して出力します。

上記の1回のフローの間、同時アクセス数は一定です。検証では同時アクセス数を段階的に増やして、上記のフローを繰り返し実行しました。またクラスタ台数についても同様にして、1台から4台まで段階的に増やしながら検証しました。

以上、今回の検証での検証観点と、検証の概要についてご説明しました。次回は、いよいよ実際の検証結果についてご説明していきます。また今回の同時書き込み性能から明らかになった、センサーデータ蓄積用途におけるKVS利用のポイントについてもご説明します。