Post on 24-Jun-2015
description
CyberAgent, Inc.
第10回 Solr勉強会
SolrCloud導入事例
株式会社サイバーエージェント
アメーバ事業本部 弘瀬 健
自己紹介
• 弘瀬 健(ひろせ けん)
• ~2011年 業務系WEBシステム構築
• 2011年~ サイバーエージェントで検索システム構築
• 今までに関わったサービス
• Ameba検索
• アメーバニュース検索
• プロフィール検索
• グルっぽ検索
• Candy検索
• Simplog検索
1 CyberAgent, Inc. 2013/03/27
アジェンダ
2 CyberAgent, Inc. 2013/03/27
• SolrCloudの概要
• 導入事例(Simplog検索)
• Simplogとは
• システム構成
• その他
• まとめ
SolrCloud概要
• Solr4.0からの新機能
• クラウドによる分散検索/インデクシング
• zookeeperを使ってクラウド情報を管理
3 CyberAgent, Inc. 2013/03/27
http://wiki.apache.org/solr/SolrCloud
SolrCloud概要
4 CyberAgent, Inc. 2013/03/27
• SolrCloudの構成要素
要素 説明
collection 1まとまりの検索対象を表す。1個以上のshardにより構成される。 zookeeperにより管理されるsolrの設定ファイルはcollection単位で適用される。
shard collectionを分割したもの。1個以上のcoreにより構成される。
node 1JVMインスタンスで起動されているSolr。 ポートを分ければ1サーバ内で複数nodeを起動することも可能。
core shardを構成する最小の単位。 1node内で複数のcoreを管理することもできる。
導入事例(Simplog検索)
5 CyberAgent, Inc. 2013/03/27
• Simplogとは
• スマホ用のブログサービス
• 実績(2013/3/26現在)
• Solr 4.1
• 検索対象ドキュメント数 : 295万投稿
• データサイズ : 1.5GB
• 検索への反映時間 : 5分
• 負荷
• クエリ数 : 3~10万 query/day
• ピーク帯のスループット : ~3qps
• 平均レスポンスタイム : 50msec
http://spapps.ameba.jp/simplog/
• システム構成
simplog simplog_bk
node
導入事例(Simplog検索)
6 CyberAgent, Inc. 2013/03/27
LB
api 2台
node 3台 node 3台
batch 2台
Simplog DB
zookeeper 3台
導入事例(Simplog検索)
7 CyberAgent, Inc. 2013/03/27
• サーバ環境
• api (OpenStackによる仮想環境)
• OS : Linux CentOS 6.2
• メモリ : 4GB
• CPU : 4core
• disk : 30GB
• ファイルシステム : ext3
• node (OpenStackによる仮想環境)
• OS : Linux CentOS 6.2
• メモリ : 8GB
• CPU : 4core
• disk : 30GB
• ファイルシステム : ext3
導入事例(Simplog検索)
8 CyberAgent, Inc. 2013/03/27
• サーバ環境
• zookeeper (OpenStackによる仮想環境)
• OS : Linux CentOS 6.2
• メモリ : 4GB
• CPU : 4core
• disk : 30GB
• ファイルシステム : ext3
• batch (OpenStackによる仮想環境)
• OS : Linux CentOS 6.2
• メモリ : 4GB
• CPU : 4core
• disk : 30GB
• ファイルシステム : ext4
導入事例(Simplog検索)
9 CyberAgent, Inc. 2013/03/27
• コレクション構成
• simplogコレクション
• 6shard
• 3node
• 4core/node
• node1
• shard1(leader)
• shard2(leader)
• shard5
• shard6
• node2
• shard1
• shard2
• shard3(leader)
• shard4(leader)
• node3
• shard3
• shard4
• shard5(leader)
• shard6(leader)
simplog
shard1
●node1_core1
node2_core1
shard2
●node1_core2
node2_core2
shard3
●node2_core3
node3_core3
shard4
●node2_core4
node3_core4
shard5
●node3_core5
node1_core5
shard6
●node3_core6
node1_core6
導入事例(Simplog検索)
10 CyberAgent, Inc. 2013/03/27
• コレクション構成
• simplog_bkコレクション
• 6shard
• 3node
• 2core/node
• node1
• shard1(leader)
• shard2(leader)
• node2
• shard3(leader)
• shard4(leader)
• node3
• shard5(leader)
• shard6(leader)
simplog
shard1 ●node1_core1
shard2 ●node1_core2
shard3 ●node2_core3
shard4 ●node2_core4
shard5 ●node3_core5
shard6 ●node3_core6
導入事例(Simplog検索)
11 CyberAgent, Inc. 2013/03/27
• その他
• SolrCloudの性能について
• 平均レスポンスタイム50msec!?
• リクエスト数、データサイズの割には性能が出ていない?
• 検索/更新を同時に行った際の性能を、node数/shard数を変えながら調べてみた
• その他
• テスト環境システム構成
batch 1台
test
node 1~6台
node
api 1台
導入事例(Simplog検索)
12 CyberAgent, Inc. 2013/03/27
テストサーバ
test DB
zookeeper 3台
導入事例(Simplog検索)
13 CyberAgent, Inc. 2013/03/27
• その他
• テスト環境ノード用サーバ(仮想環境)
• OS : Linux CentOS 6.4
• メモリ : 14GB
• CPU : 4core
• disk : 160GB
• ファイルシステム : ext4
• テストデータ
• ドキュメント数 : 26万
• データサイズ : 850MB
• テスト内容
• テストサーバからJMeterで30分ほど200req/secの検索負荷をかける
• バッチサーバから更新を行う(約65000レコード)
• 以降のテストケースに対する試行回数は時間の都合で1回となってます
導入事例(Simplog検索)
14 CyberAgent, Inc. 2013/03/27
• その他
• テストケース1
• shard数1、node数1~6の場合の検索/更新
• 1core/node
• shardのleaderはnode1
test shard1
●node1_core1
node2_core1
node3_core1
node4_core1
node5_core1
node6_core1
test shard1 ●node1_core1 ・・・
導入事例(Simplog検索)
15 CyberAgent, Inc. 2013/03/27
• その他
• テストケース1
• shard数1、node数1~6の場合の検索/更新
• 1core/node
• shardのleaderはnode1
• テスト結果
• node数が増えるにしたがって検索性能が向上
• 更新性能は劣化
CPU %user (node1) response
テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min)
1 1 1 1 35.29 58.4 27 12 80 1037 200.1 13
2 21.17 47.74 21 11 23 6317 199.4 22
3 19.01 42.28 13 10 16 939 200.1 22
4 19.55 43.32 16 10 17 5424 199.8 22
5 20.55 46.46 12 10 16 574 200.1 22
6 21.06 43.77 12 10 15 538 200.2 22
導入事例(Simplog検索)
16 CyberAgent, Inc. 2013/03/27
• その他
• テストケース2
• shard数2、node数1~6の場合の検索/更新
• 2core/node
• 各shardのleaderはnode1に集約
test
shard1
●node1_core1
node2_core1
node3_core1
node4_core1
node5_core1
node6_core1
shard2
●node1_core2
node2_core2
node3_core2
node4_core2
node5_core2
node6_core2
test
shard1 ●node1_core1
shard2 ●node1_core2 ・・・
導入事例(Simplog検索)
17 CyberAgent, Inc. 2013/03/27
• その他
• テストケース2
• shard数2、node数1~6の場合の検索/更新
• 2core/node
• 各shardのleaderはnode1に集約
• テスト結果
• shard数1の場合に比べて検索/更新性能が劣化
• 1nodeの場合の検索性能は特に劣化
• shard数1の場合と同様にnode数が増えるにしたがって検索性能は向上
• 更新性能はnode数が増えるにしたがって劣化
CPU %user (node1) response
テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min)
2 2 1 2 67.38 90.98 1403 1449 1650 8116 134 19
2 42.13 85.82 509 426 1033 8625 192.1 26
3 34.03 64.65 121 55 261 4439 199.4 26
4 31.12 58.63 85 28 200 3673 199.7 27
5 29.52 55.67 61 24 158 3766 200.1 27
6 28.34 50.75 61 23 148 5881 199.7 27
導入事例(Simplog検索)
18 CyberAgent, Inc. 2013/03/27
• その他
• テストケース3.1
• shard数3、node数1,3,6の場合の検索/更新
• 3core/node
• 各shardのleaderはnode1に集約
test
shard1
●node1_core1
node2_core1
node3_core1
node4_core1
node5_core1
node6_core1
shard2
●node1_core2
node2_core2
node3_core2
node4_core2
node5_core2
node6_core2
shard3
●node1_core3
node2_core3
node3_core3
node4_core3
node5_core3
node6_core3
test
shard1 ●node1_core1
shard2 ●node1_core2
shard3 ●node1_core3
・・・
導入事例(Simplog検索)
19 CyberAgent, Inc. 2013/03/27
• その他
• テストケース3.2
• shard数3、node数3の場合の検索/更新
• 3core/node
• 各shardのleaderは各nodeに分散
test
shard1
●node1_core1
node2_core1
node3_core1
shard2
node1_core2
●node2_core2
node3_core2
shard3
node1_core3
node2_core3
●node3_core3
導入事例(Simplog検索)
20 CyberAgent, Inc. 2013/03/27
• その他
• テストケース3.1
• shard数3、node数1,3,6の場合の検索/更新(3core/node、leader集約)
• テストケース3.2
• shard数3、node数3の場合の検索/更新(3core/node、 leader分散)
• テスト結果
• shard数2の場合に比べて検索/更新性能が劣化
• 1nodeの場合の検索性能は特に劣化
• shard数2の場合と同様にnode数が増えるにしたがって検索性能は向上
• 更新性能はnode数が増えるにしたがって劣化
• leaderを各nodeに分散させた場合の影響は判別不可(3.1、3.2)
CPU %user (node1) response
テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min)
3.1 3 1 3 73.37 91.77 1561 1611 1885 7375 121.3 20
3.1 3 37.56 79.9 232 170 475 5108 197.2 28
3.2 3 35.65 90.52 203 141 388 16014 195.3 30
3.1 6 32.23 70.93 110 26 218 8192 196.9 30
導入事例(Simplog検索)
21 CyberAgent, Inc. 2013/03/27
• その他
• テストケース4.1
• shard数4、node数1,3,6の場合の検索/更新
• 4core/node
• 各shardのleaderはnode1に集約
test
shard1
●node1_core1
node2_core1
node3_core1
node4_core1
node5_core1
node6_core1
shard2
●node1_core2
node2_core2
node3_core2
node4_core2
node5_core2
node6_core2
shard3
●node1_core3
node2_core3
node3_core3
node4_core3
node5_core3
node6_core3
shard4
●node1_core4
node2_core4
node3_core4
node4_core4
node5_core4
node6_core4
test
shard1 ●node1_core1
shard2 ●node1_core2
shard3 ●node1_core3
shard4 ●node1_core4
・・・
導入事例(Simplog検索)
22 CyberAgent, Inc. 2013/03/27
• その他
• テストケース4.2
• shard数4、node数3の場合の検索/更新
• 各shardのleaderは各nodeに分散
• node1
• shard1(laeder)
• shard2(laeder)
• node2
• shard1
• shard3(laeder)
• shard4
• node3
• shard2
• shard3
• shard4(laeder)
test
shard1
●node1_core1
node2_core1
shard2
●node1_core2
node3_core2
shard3
●node2_core3
node3_core3
shard4
●node3_core4
node2_core4
導入事例(Simplog検索)
CyberAgent, Inc. 2013/03/27
• その他
• テストケース4.3
• shard数4、node数4の場合の検索/更新
• 2core/node
• 各shardのleaderは各nodeに分散
test
shard1
●node1_core1
node2_core1
shard2
●node2_core2
node3_core2
shard3
●node3_core3
node4_core3
shard4
●node4_core4
node1_core4
導入事例(Simplog検索)
24 CyberAgent, Inc. 2013/03/27
• その他 • テストケース4.1 : shard数4、node数1,3,6の場合の検索/更新(4core/node、 leader集約)
• テストケース4.2 : shard数4、node数3の場合の検索/更新(node1=2core、node2,3=3core、leader分散)
• テストケース4.3 : shard数4、node数4の場合の検索/更新(2core/node、leader分散)
• テスト結果
• shard数3の場合に比べて検索/更新性能が劣化
• 1nodeの場合の検索性能は特に劣化
• shard数3の場合と同様にnode数が増えるにしたがって検索性能は向上
• 更新性能はnode数が増えるにしたがって劣化
• shard数、node数が同じ場合、各node内のcore数が少ない方が検索/更新性能は良い
(4.1 node3、4.2)
• nodeを増やすより1nodeあたりのcore数を減らす方が検索/更新性能が良くなる場合もある
(4.3、4.1 node6)
CPU %user (node1) response
テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min)
4.1 4 1 4 76.19 92.96 1738 1785 2159 8203 109.6 22
4.1 3 40.95 87.97 548 459 1068 10010 189 31
4.2 3 2、3 29.28 78.14 228 163 428 9040 195.2 30
4.3 4 2 28.53 80.2 122 39 256 7352 198.2 28
4.1 6 4 33.77 88.28 179 79 373 10889 194.6 32
導入事例(Simplog検索)
25 CyberAgent, Inc. 2013/03/27
• その他
• テストケース5.1
• shard数6、node数3の場合の検索/更新
• 2core/node
• simplog_bkコレクション同等の構成
test
shard1 ●node1_core1
shard2 ●node1_core2
shard3 ●node2_core3
shard4 ●node2_core4
shard5 ●node3_core5
shard6 ●node3_core6
導入事例(Simplog検索)
26 CyberAgent, Inc. 2013/03/27
• その他
• テストケース5.2
• shard数6、node数3の場合の検索/更新
• 4core/node
• simplogコレクション同等の構成
test
shard1
●node1_core1
node2_core1
shard2
●node1_core2
node2_core2
shard3
●node2_core3
node3_core3
shard4
●node2_core4
node3_core4
shard5
●node3_core5
node1_core5
shard6
●node3_core6
node1_core6
導入事例(Simplog検索)
27 CyberAgent, Inc. 2013/03/27
• その他
• テストケース5.3
• shard数6、node数6の場合の検索/更新
• 2core/node
• node1
• shard1(leader)
• shard2(leader)
• node2
• shard3(leader)
• shard4(leader)
• node3
• shard5(leader)
• shard6(leader)
• node4
• shard1
• shard2
• node5
• shard3
• shard4
• node6
• shard5
• shard6
test
shard1
●node1_core1
node4_core1
shard2
●node1_core2
node4_core2
shard3
●node2_core3
node5_core3
shard4
●node2_core4
node5_core4
shard5
●node3_core5
node6_core5
shard6
●node3_core6
node6_core6
導入事例(Simplog検索)
28 CyberAgent, Inc. 2013/03/27
• その他 • テストケース5.1 : shard数6、node数3の場合の検索/更新(2core/node、 simplog_bkコレクション同等の構成)
• テストケース5.2 : shard数6、node数3の場合の検索/更新(4core/node、 simplogコレクション同等の構成)
• テストケース5.3 : shard数6、node数6の場合の検索/更新( 2core/node 、simplog_bkコレクションにレプリカを追加した状態の構成)
• テスト結果
• shard数4の場合と同様にnode数が増えるにしたがって検索性能は向上(5.1、5.3)
• 更新性能はnode数が増えるにしたがって劣化
• shard数、node数が同じ場合1nodeあたりのcore数が少ない方が検索/更新性能は良い
(5.1、5.2)
CPU %user (node1) response
テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min)
5.1 6 3 2 42.05 77.33 152 99 317 5103 199.3 20
5.2 3 4 38.7 87.5 713 644 1340 10457 180.5 30
5.3 6 2 24.59 73.12 96 28 206 4668 199.1 27
導入事例(Simplog検索)
29 CyberAgent, Inc. 2013/03/27
• その他
• テスト結果(shard数による違い)
• node数/1nodeあたりのcore数に関係なく、collection内のshard数が少ない方が検索性能が良い
• 更新性能については判別不可
CPU %user (node1) response
テストケース shard数 node数 core数/node avg max avg (ms) median (ms) 90% line (ms) max (ms) Throughput (req/sec) update time(min)
2 2 3 2 34.03 64.65 121 55 261 4439 199.4 26
5.1 6 3 2 42.05 77.33 152 99 317 5103 199.3 20
2 2 4 2 31.12 58.63 85 28 200 3673 199.7 27
4.3 4 4 2 28.53 80.2 122 39 256 7352 198.2 28
4.1 4 3 4 40.95 87.97 548 459 1068 10010 189 31
5.2 6 3 4 38.7 87.5 713 644 1340 10457 180.5 30
2 2 6 2 28.34 50.75 61 23 148 5881 199.7 27
5.3 6 6 2 24.59 73.12 96 28 206 4668 199.1 27
導入事例(Simplog検索)
30 CyberAgent, Inc. 2013/03/27
• その他
• テスト結果(まとめ)
• 1nodeあたりのcore数は少ないほど検索/更新性能が良い
• 1collectionあたりのshard数は少ないほど検索性能が良い
• 1node内のcore数が同じ場合、nodeが多いほど検索性能が良い
• 更新性能はnode数が少ない方が良い
• node数と1nodeあたりのcore数
• nodeを増やすより1nodeあたりのcore数を減らす方が検索/更新性能が良くなる場合もある
まとめ
31 CyberAgent, Inc. 2013/03/27
• SolrCloudの利点
• Solrの設定ファイルをコレクション内で一元管理できる
• 検索/更新クライアントは各コレクション内のnodeを意識しなくてよい
• コレクション内のnode(レプリカ)を追加しても検索/更新クライアントの変更は不要
• SolrCloud利用時の注意点
• shardの分割機能はまだないのでコレクション作成時のデータサイズの見積もりに注意
• shardを増やす場合は合わせてnode数も検討
• コレクション情報が壊れると検索/更新できなくなる
• 更新処理の必須条件
• 全shardのleader nodeのステータスがactiveであること
• 検索処理の必須条件
• 各shardに最低1つのnode(core)が割り当てられていること
• shardが1つでも欠落するとそのコレクションに対しては検索不可
• shardsパラメータで検索対象shardを明示的に指定した場合は可能
• パフォーマンスは素のSolrの方が良い
ご清聴ありがとうございました
32 CyberAgent, Inc. 2013/03/27