Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
© Hitachi Solutions, Ltd. 2014. All rights reserved.
分散Key-Valueストア 「okuyama」 & 「Riak」 書込み性能検証
株式会社 日立ソリューションズ オープンソース技術開発センタ
2014/7/5
倉又 裕輔
© Hitachi Solutions, Ltd. 2014. All rights reserved.
自己紹介
1
名前:
倉又 裕輔 (くらまた ゆうすけ)
所属:
(株)日立ソリューションズ オープンソース技術開発センタ
担当業務:
OSSのNoSQL技術の調査、検証
・エンタープライズ利用に向けた調査と検証
・技術情報の社内外への発信
© Hitachi Solutions, Ltd. 2014. All rights reserved.
1. 検証の背景
2. ベンチマーク方法
3. ベンチマーク結果
発表の流れ
4. 考察
© Hitachi Solutions, Ltd. 2014. All rights reserved.
1. 検証の背景
なぜ「okuyama」と「Riak」を検証したのか
NoSQL、Key-Value ストアに着目した背景
© Hitachi Solutions, Ltd. 2014. All rights reserved.
1.1 IT技術動向
4
近年のビッグデータへの期待から、IoTへの関心が高まっている
2017年までに20%以上の企業が、
従来の情報機器とは異なるセンサや組み込み機器などを
利用し、ビジネスを取り巻く環境をデジタル化する。
多様な情報を収集、分析することで
製品やサービスをより効果的に提供するために、
モノのインターネットに関する新たな取り組みを行う。
☆引用 : 2014年4月17日 ガートナー ジャパン株式会社 プレスリリース
【 http://www.gartner.co.jp/press/html/pr20140417-01.html 】
© Hitachi Solutions, Ltd. 2014. All rights reserved.
1.2. IoT(センサー)に適するデータストア要件
5
センサーデータの特徴
1) 非構造データ
2) 記録回数/時間: 多
3) センサー数: 大量
4) データ送信頻度: 高
データストアの要件
A) 非構造データの保存
B) 大量データの保存
C) 高速な書込み性能
© Hitachi Solutions, Ltd. 2014. All rights reserved.
しかし、性能に関する情報が不足している
特に書込み性能に注目し
知見を増やすために検証を実施した
1.3. NoSQL適合の課題
6
リレーショナルデータベース(RDB)以外のデータストアの総称
SQLを使用せずにデータを操作する
NoSQL(Not only SQL)
★苦手 ・トランザクション処理
・複雑な検索、集計処理
☆得意 ・非構造データの保存(スキーマレス)
・スケールアウト(大量データの保存)
・高速な書込み、参照処理
データストアの要件に適合
© Hitachi Solutions, Ltd. 2014. All rights reserved.
1.4. 検証対象NoSQLの検討(1/2)
7
NoSQLの分類(データモデル)
ドキュメント指向 ・MongoDB ・CouchDB ・Couchbase Server など
Key-Value ストア (KVS) ・okuyama ・Riak ・memcached ・Redis など
カラム指向 ・Cassandra ・Hbase ・Hypertable など
Key Value
Key Value
データが シンプル
KVSは小さい多数データの蓄積、高速なデータ読み書きが得意
センサーデータに適している
© Hitachi Solutions, Ltd. 2014. All rights reserved.
KVSの分類
1.5. 検証対象NoSQLの検討(2/2)
永続化機能の有無
永続化機能なし(インメモリ) 永続化機能あり
データ分散機能の実装
クライアント側
KVS側
8
okuyama
Riak
memcached Redis
© Hitachi Solutions, Ltd. 2014. All rights reserved.
KVSの分類
1.5. 検証対象NoSQLの検討(2/2)
永続化機能の有無
永続化機能なし(インメモリ) 永続化機能あり
データ分散機能の実装
クライアント側
KVS側
9
okuyama
Riak
memcached Redis
・ KVSのみで データ蓄積可能
・ データ分散や スケールアウトが 容易
「okuyama」と「Riak」を検証対象として選択
© Hitachi Solutions, Ltd. 2014. All rights reserved.
1.6. okuyama の特徴
10
okuyama
開発元 株式会社 神戸デジタル・ラボ
ライセンス GPL v3 (商用ライセンス・サポートあり)
開発言語 Java
分散アーキテクチャ マスタ-スレーブ型
ユースケース ECサイト、検索エンジン、キャッシュサーバ、ログ管理、など
開発元 : 神戸デジタル・ラボ ( http://okuyama-project.com/ja/index.html )
スレーブ マスタ
データ操作 データ振分け データ保存
クライ アント
・冗長化により 単一障害点の無い クラスタを構築可能
・無停止でスケールアウト可能
・データ保存先を選択可能 (ディスク・メモリ・併用)
スレーブ マスタスレーブ型
© Hitachi Solutions, Ltd. 2014. All rights reserved.
1.7. Riak の特徴
11
Riak
開発元 Basho Technologies, Inc.
ライセンス Apache License, Version 2.0 (商用ライセンス・サポートあり)
開発言語 Erlang/C
分散アーキテクチャ P2P型
ユースケース ECサイト、キャッシュサーバ、オブジェクトストレージ、など
開発元 : Basho Technologies ( http://basho.co.jp/riak/ )
・単一障害点なし
・無停止でスケールアウト可能
・データ保存先を選択可能 (ディスク・メモリ・併用)
データ操作 データ振分け・保存
クライ アント ノード
ノード
ノード P2P型
© Hitachi Solutions, Ltd. 2014. All rights reserved.
2. ベンチマーク方法
検証環境、ベンチマークツール ベンチマークの内容
検証の目的、観点
© Hitachi Solutions, Ltd. 2014. All rights reserved.
2.1. 検証の目的
13
同時書込み性能が重要
実際どのくらい速いのか?ベンチマーク実施
スループット (書込み数/秒)と レイテンシ (書込み時間)を計測
KVS
多数のセンサーが 高頻度に大量件数のデータを同時送信
センサー
© Hitachi Solutions, Ltd. 2014. All rights reserved.
2.2. 検証パターン
14
「okuyama」と「Riak」の特性は構成によって異なる
Disk
Key Value
Disk
Value Key
パターン1 【ディスク保存】
パターン2 【メモリ・ディスク併用】
Key Value
パターン3 【インメモリ】
KVS KVS KVS
大量データ保存が要件のため、パターン1と2を検証
データ保存容量 大 小
書込み速度 遅 速
© Hitachi Solutions, Ltd. 2014. All rights reserved.
2.3. 検証の観点
15
観点1:同時書込み性能
観点2:各検証パターンごとの懸念点を検証
Disk
Value Key
【メモリ・ディスク併用】
メモリが無くなるまで書込み、 性能変化を検証
大量データ保存によるメモリ消費時の性能?
Disk
Key Value
【ディスク保存】
書込み速度が遅い?
スケールアウトによる 性能向上を検証
クライ アント
KVS
同時アクセス数を増やして、 性能変化を検証
© Hitachi Solutions, Ltd. 2014. All rights reserved.
okuyama v0.9.5 (1ノード/台)
2.4. 検証環境
16
1台
1~4台
マスタ
スレーブ
Riak v1.4.6 (1ノード/台)
1~4台
ノード
クライ アント
1台 クライ アント
1台
CPU Intel(R) Core(TM) i5 CPU 520
メモリ 4GB
HDD(SATA) 750GB, 5400RPM
OS CentOS 6.5 64bit
※データの複製・レプリケーション無し
© Hitachi Solutions, Ltd. 2014. All rights reserved.
2.5. ベンチマークツール
17
参考: https://github.com/brianfrankcooper/YCSB/wiki
Yahoo! Cloud Serving Benchmark (YCSB)
開発元 Yahoo! Inc.
ライセンス Apache License, Version 2.0
開発言語 Java
使用バージョン 0.1.4
他ベンチマークと比較できるよう、 一般に利用実績のあるベンチマークツールを使いたい
NoSQL用ベンチマークツール
「Yahoo! Cloud Serving Benchmark (YCSB)」 を利用
© Hitachi Solutions, Ltd. 2014. All rights reserved.
2.6. YCSBの動き
18
START
①同時アクセス数(スレッド数)、 書込むデータ件数を指定し実行 ①
②スレッドごとにNoSQLへ接続 ②
③書込み処理開始 全件を処理するまで繰り返し 1件単位のスループットと レイテンシを計測
Key Value ③
YCSB NoSQL
④ ④全件の処理を終えたら終了 スループット・レイテンシの 計測結果を集計し出力
END 書込むデータは、 KeyとValue共に
約25バイト
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3. ベンチマーク結果
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.1. 検証パターンと観点の確認
20
Disk
Key Value
Disk
Value Key
【ディスク保存】 【メモリ・ディスク併用】
KVS KVS
観点1:同時書込み性能 観点1:同時書込み性能
okuyama Riak okuyama Riak
観点2:スケールアウト性能 観点2:メモリ消費時の性能
4つの検証ごとにそれぞれ説明
検証① 検証② 検証③ 検証④
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.2. 検証① okuyama - 【ディスク保存】
21
Disk
Key Value
1ノード
1台
1~4 ノード
マスタ
スレーブ
クライ アント
観点1:同時書込み性能
同時アクセス数を増加
マスタ-スレーブ
観点2:スケールアウト性能
ノード数を増加
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.2. 検証① okuyama - 【ディスク保存】
22
0
20
40
60
80
0 50 100 150 200 250 300
スループット[ o
ps/
sec ]
同時アクセス数
同一条件で大量件数書込み、 平均値をプロット
4ノード
3ノード
2ノード
1ノード
観点1:同時書込み性能 ⇒ピークを取り、その後はほぼ一定
約84ops/sec
観点2:スケールアウト性能 ⇒ノード追加で性能向上
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.2. 検証① okuyama - 【ディスク保存】
23
0
2000
4000
6000
8000
10000
12000
0 50 100 150 200 250 300
レイテンシ[ m
s ]
同時アクセス数
4ノード
3ノード
2ノード
1ノード 観点2:スケールアウト性能 ⇒ノード追加で性能向上
観点1:同時書込み性能 ⇒アクセス増に比例し 性能低下
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.2. 検証① okuyama - 【ディスク保存】
24
わかったこと
1) 同時アクセス性能
同時アクセス数が増加しても、急な性能低下はしない。
リソース使用状況から、ディスクI/Oがボトルネック。
2) スケールアウト性能
ノード追加に対して想定通り性能向上。
3) スループット
最大で約 84 ops/sec (4ノードクラスタ)
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.3. 検証② Riak - 【ディスク保存】
25
Disk
Key Value 1~4 ノード
ノード
P2P
1台 クライ アント
観点1:同時書込み性能
同時アクセス数を増加
観点2:スケールアウト性能
ノード数を増加
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.3. 検証② Riak - 【ディスク保存】
26
0
50
100
150
200
250
0 50 100 150 200 250 300 350 400
スループット[ o
ps/
sec ]
同時アクセス数
4ノード
観点2:スケールアウト性能 ⇒ノード追加で性能向上
3ノード
2ノード
1ノード
観点1:同時書込み性能 ⇒ピークを取り、その後はほぼ一定
約220ops/sec
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.3. 検証② Riak - 【ディスク保存】
27
0
500
1000
1500
2000
2500
0 50 100 150 200 250 300 350 400
レイテンシ[ m
s ]
同時アクセス数
4ノード
3ノード
2ノード
観点2:スケールアウト性能 ⇒ノード追加で性能向上
1ノード
観点1:同時書込み性能 ⇒アクセス増に比例し 性能低下
他と違う 動き?
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.3. 検証② Riak - 【ディスク保存】
28
わかったこと
1) 同時アクセス性能
同時アクセス数が増加しても、急な性能低下はしない。
リソース使用状況から、ディスクI/Oがボトルネック。
2) スケールアウト特性
ノード追加に対して想定通り性能向上。
3) スループット
最大で約 220 ops/sec (4ノードクラスタ)
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.4. 検証③ okuyama - 【メモリ・ディスク併用】
29
1ノード
1台
4ノード
マスタ
スレーブ
クライ アント
観点1:同時書込み性能
同時アクセス数を増加
マスタ-スレーブ
Disk
Value Key
観点2:メモリ消費時の性能
メモリが無くなるまで長時間書込み
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.4. 検証③ okuyama - 【メモリ・ディスク併用】
30
0
5000
10000
15000
20000
25000
30000
0 100 200 300 400 500 600 700
スループット[ o
ps/
sec ]
処理時間[ sec ]
時間と共に性能変化 ⇒平均値ではなく 時間変化を計測
300同時アクセス
100同時アクセス
30同時アクセス
10同時アクセス
他と違う動き? マスタノードの負荷が高い
観点1:同時書込み性能:同時アクセス数を増加
アクセス増に対してピークを取り、その後急に性能低下
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.4. 検証③ okuyama - 【メモリ・ディスク併用】
31
0.1
1
10
100
0 100 200 300 400 500 600 700
レイテンシ[ m
s ]
処理時間[ sec ]
300同時アクセス
100同時アクセス
30同時アクセス
10同時アクセス
アクセス増につれて性能低下
観点1:同時書込み性能:同時アクセス数を増加
© Hitachi Solutions, Ltd. 2014. All rights reserved.
0
5000
10000
15000
20000
25000
0 2000 4000 6000 8000 10000 12000
スループット[ o
ps/
sec ]
処理時間[ sec ]
3.4. 検証③ okuyama - 【メモリ・ディスク併用】
32
JVMのメモリ枯渇のため ディスク書込み 65~85ops/sec
急に性能低下
10,000~6,000ops/sec やや安定
100同時アクセス
観点2:メモリ消費時の性能:メモリが無くなるまで長時間書込み
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.4. 検証③ okuyama - 【メモリ・ディスク併用】
33
1
10
100
1000
10000
0 2000 4000 6000 8000 10000 12000
レイテンシ[ m
s ]
処理時間[ sec ]
20ms 弱
ディスク書込み 1,000ms 強
100同時アクセス
スループットの裏返しの特性 時間と共に性能低下
観点2:メモリ消費時の性能:メモリが無くなるまで長時間書込み
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.4. 検証③ okuyama - 【メモリ・ディスク併用】
34
わかったこと
1) 同時アクセス性能
同時アクセス数が増加すると、データ振分け処理が
ボトルネック。マスタノード追加による負荷分散が必要。
2) メモリ消費時の性能
メモリ消費にともなって、徐々に性能低下。
JVMのメモリを使い切ると、ディスク書込みに切り替わり、
大きく性能低下。
3) スループット(中盤の安定状態)
10,000 ops/sec ⇒ 6,000 ops/sec (4ノードクラスタ)
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.5. 検証④ Riak - 【メモリ・ディスク併用】
35
4ノード
P2P
1台 クライ アント
観点1:同時書込み性能
同時アクセス数を増加
Disk
Value Key
ノード
観点2:メモリ消費時の性能
メモリが無くなるまで長時間書込み
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.5. 検証④ Riak - 【メモリ・ディスク併用】
36
0
1000
2000
3000
4000
5000
0 50 100 150 200 250 300
スループット[ o
ps/
sec ]
処理時間[ sec ]
100同時アクセス
30同時アクセス
性能が伸びない
データ振分けするノードが高負荷
↓
負荷分散が必要
観点1:同時書込み性能:同時アクセス数を増加
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.5. 検証④ Riak - 【メモリ・ディスク併用】
37
4ノード
1台 クライ アント
Disk
Value Key
ノード
構成見直し前 P2P
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.5. 検証④ Riak - 【メモリ・ディスク併用】
38
4ノード
P2P
2台
Disk
Value Key
ノード
クライ アント
均等に 負荷分散
観点1:同時書込み性能
同時アクセス数を増加
観点2:メモリ消費時の性能
メモリが無くなるまで長時間書込み
構成見直し後
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.5. 検証④ Riak - 【メモリ・ディスク併用】
39
0
2000
4000
6000
8000
10000
0 20 40 60 80 100 120 140
スループット[ o
ps/
sec ]
処理時間[ sec ]
100同時アクセス (負荷分散後)
100同時アクセス (負荷分散前)
100同時アクセス以上で 性能が頭打ち
20同時アクセス
40同時アクセス
320同時アクセス
640同時アクセス
負荷分散により 性能向上
観点1:同時書込み性能:同時アクセス数を増加
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.5. 検証④ Riak - 【メモリ・ディスク併用】
40
1
10
100
10 40 70 100 130
レイテンシ[ m
s ]
処理時間[ sec ]
320同時アクセス
100同時アクセス
40同時アクセス
20同時アクセス
640同時アクセス
アクセス増につれて性能低下
観点1:同時書込み性能:同時アクセス数を増加
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.5. 検証④ Riak - 【メモリ・ディスク併用】
41
0
2000
4000
6000
8000
10000
0 2000 4000 6000 8000 10000 12000 14000 16000
スループット[ o
ps/
sec ]
処理時間[ sec ]
物理メモリを使い切ったため Swapへ書込み
2,200ops/sec前後
100同時アクセス 約 8,000ops/sec で安定
観点2:メモリ消費時の性能:メモリが無くなるまで長時間書込み
© Hitachi Solutions, Ltd. 2014. All rights reserved.
1
10
100
1000
10000
0 2000 4000 6000 8000 10000 12000 14000 16000
レイテンシ[ m
s ]
処理時間[ sec ]
3.5. 検証④ Riak - 【メモリ・ディスク併用】
42
15ms弱
Swap書込み 50ms前後
スループットの裏返しの特性 終盤、物理メモリ枯渇につれて性能低下
100同時アクセス
観点2:メモリ消費時の性能:メモリが無くなるまで長時間書込み
© Hitachi Solutions, Ltd. 2014. All rights reserved.
3.5. 検証④ Riak - 【メモリ・ディスク併用】
43
わかったこと
1) 同時アクセス性能
同時アクセス数が増加すると、データ振分け処理が
ボトルネック。クライアントアクセスの負荷分散が必要。
2) メモリ消費時の性能
物理メモリを使い切るまでは安定した性能。
物理メモリを使い切るとSwap書込みとなり、
大きく性能低下。
3) スループット(中盤の安定状態)
平均約 8,000 ops/sec (4ノードクラスタ)
© Hitachi Solutions, Ltd. 2014. All rights reserved.
4. 考察
© Hitachi Solutions, Ltd. 2014. All rights reserved.
4.1. センサーデータ蓄積で使う時のポイント
45
【ディスク保存】
ディスク性能・クラスタ台数を要検討
ディスクI/Oがボトルネック。スケールアウトで性能向上するので、
性能要件に応じて検討すること。
【メモリ・ディスク併用】
1) クライアントからKVSへの書込み負荷分散が重要
2) 残メモリ量に要注意
1) KVSのデータ振分け処理がボトルネックになりやすいので、
負荷分散すること。
2) メモリがなくなると性能が大幅ダウン。
メモリの監視、スケールアウトのタイミングなど、運用を検討すること。
本資料に掲載されている会社名、製品名、サービス名は各社の登録商標、又は商標です。 ・okuyama は、株式会社神戸デジタル・ラボの登録商標です。 ・Riak は、 Basho Technologies, Inc. の登録商標です。 ・Cassandra は、 Apache Software Foundation の商標です。 ・HBase は、 Apache Software Foundation の商標です。 ・MongoDB は、 MongoDB, Inc. の登録商標です。 ・CouchDB は、 Apache Software Foundation の商標です。 ・Intel、Intel Core は、 Intel Corporation の登録商標です。 ・OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。 ・Yahoo! は、 Yahoo! Inc. の登録商標です。 ・その他記載の会社名、製品名は、それぞれの会社の商標もしくは登録商標です。
© Hitachi Solutions, Ltd. 2014. All rights reserved.
【補足】 永続化について
47
※データの保存先にかかわらず、永続化は可能
データ操作の履歴ログ(ジャーナル)を作成し永続化
Disk Disk
Value
Key
・パターン1 KeyとValueをディスク保存
・パターン2 Keyをメモリ、 Valueをディスク保存
Key Value
・パターン3 KeyとValueをメモリ保存
KVS KVS KVS
Disk
ジャーナル
ジャーナル ジャーナル
Key Value
サーバ再起動時はジャーナルから復旧
© Hitachi Solutions, Ltd. 2014. All rights reserved.
【補足】 YCSBの構成
48
参考:http://labs.yahoo.com/files/ycsb-v4.pdf
YCSB
NoSQL
ワークロード
実行処理
スループット レイテンシの
統計処理
ワークロード設定ファイル ・CRUD処理の配分 ・全データ件数 など
コマンドラインパラメータ ・接続先(IP、ポートなど) ・スレッド数(同時アクセス数) など
NoSQLクライアント ・NoSQLへの接続 ・CRUD処理
MongoDB
HBase
・・・
okuyama
Riak
クライアント スレッド生成
「okuyama」と「Riak」用のクライアントを作成
© Hitachi Solutions, Ltd. 2014. All rights reserved.
KVSのJavaライブラリを利用し、クライアントを作成
【補足】 okuyama, Riak クライアント
49
public int insert(String table, String key, HashMap<String, ByteIterator> values) { com.mongodb.DB db = null; try { db = mongo.getDB(database); db.requestStart(); DBCollection collection = db.getCollection(table); DBObject r = new BasicDBObject().append("_id", key); for(String k: values.keySet()) { r.put(k, values.get(k).toArray()); } WriteResult res = collection.insert(r,writeConcern); return res.getError() == null ? 0 : 1; } catch (Exception e) { System.err.println(e.toString()); return 1; } finally { if (db!=null) { db.requestDone(); } } }
public int insert(String table, String key, HashMap<String, ByteIterator> values) { try { boolean setResult = okuyamaClient.setValue(key, key); if (setResult) { System.out.println("setKey = "+key); } else { System.out.println("setValue Result = [Server Error]"); System.exit(1); } } catch(OkuyamaClientException oc) { oc.printStackTrace(); } return 0; }
他NoSQL用のクライアントを流用 okuyamaとRiak用に メソッドを書き換え
書込みベンチマーク用のため、KVS接続処理とInsert処理のみ作成
・okuyama、Riakクライアント共に80行程度 ・書込むデータは、KeyとValue共に約25バイト
・okuyama : okuyama本体に同梱のライブラリ
・Riak : 公式サポートのJavaライブラリ ※入手先:【https://github.com/basho/riak-java-client/tree/1.4.2】
© Hitachi Solutions, Ltd. 2014. All rights reserved.
【補足】 その他 注意点
50
・ベンチマークの間、リソース監視データを出力 リソース状況の確認のため、
YCSBおよびKVSサーバ上でsarコマンドを実行し、
ベンチマーク中のリソースのデータを出力した。
・KVSはテスト毎に再インストール KVS内のテストデータ削除のため、
1テストケース実施ごとに、
KVSのアンインストールと再インストールを実施した。