第10回solr勉強会 solr cloudの導入事例

第10回 Solr勉強会

SolrCloud導入事例

株式会社サイバーエージェント
アメーバ事業本部弘瀬健

CyberAgent, Inc.

自己紹介

• 弘瀬健(ひろせけん)
• ～2011年業務系WEBシステム構築
• 2011年～サイバーエージェントで検索システム構築
• 今までに関わったサービス
• Ameba検索
• アメーバニュース検索
• プロフィール検索
• グルっぽ検索
• Candy検索
• Simplog検索

2013/03/27 CyberAgent, Inc. 1

アジェンダ

• SolrCloudの概要
• 導入事例(Simplog検索)
• Simplogとは
• システム構成
• その他
• まとめ


SolrCloud概要

• Solr4.0からの新機能
• クラウドによる分散検索/インデクシング
• zookeeperを使ってクラウド情報を管理

http://wiki.apache.org/solr/SolrCloud


SolrCloud概要

• SolrCloudの構成要素
要素説明

collection 1まとまりの検索対象を表す。1個以上のshardにより構成される。
zookeeperにより管理されるsolrの設定ファイルはcollection単位で適用される。
shard collectionを分割したもの。1個以上のcoreにより構成される。
node 1JVMインスタンスで起動されているSolr。
ポートを分ければ1サーバ内で複数nodeを起動することも可能。
core shardを構成する最小の単位。
1node内で複数のcoreを管理することもできる。


導入事例(Simplog検索)

• Simplogとは

• スマホ用のブログサービス

• 実績(2013/3/26現在)
• Solr 4.1
• 検索対象ドキュメント数： 295万投稿
• データサイズ： 1.5GB
• 検索への反映時間： 5分
• 負荷
• クエリ数： 3～10万 query/day
• ピーク帯のスループット：～3qps
• 平均レスポンスタイム： 50msec

http://spapps.ameba.jp/simplog/



• システム構成
LB

api 2台

node
simplog_bk simplog
zookeeper 3台
node 3台 node 3台

batch 2台

Simplog DB

6
2013/03/27 CyberAgent, Inc.


• サーバ環境
• api （OpenStackによる仮想環境)
• OS ： Linux CentOS 6.2
• メモリ： 4GB
• CPU ： 4core
• disk ： 30GB
• ファイルシステム： ext3

• node （OpenStackによる仮想環境)
• CPU ： 4core
• disk ： 30GB



• サーバ環境
• zookeeper （OpenStackによる仮想環境)
• CPU ： 4core
• disk ： 30GB

• batch （OpenStackによる仮想環境)
• CPU ： 4core
• disk ： 30GB



●node1_core1
• コレクション構成 shard1
node2_core1
• simplogコレクション
• 6shard ●node1_core2
• 3node shard2
node2_core2
• 4core/node
• node1
●node2_core3
• shard1(leader)
shard3
• shard2(leader)
node3_core3
• shard5
simplog
• shard6
●node2_core4
• node2
shard4
• shard1
node3_core4
• shard2
• shard3(leader)
●node3_core5
• shard4(leader)
shard5
• node3
node1_core5
• shard3
• shard4
●node3_core6
• shard5(leader)
shard6
• shard6(leader)
node1_core6



• コレクション構成
• simplog_bkコレクション
• 6shard shard1 ●node1_core1
• 3node
• 2core/node shard2 ●node1_core2
• node1
• shard1(leader) shard3 ●node2_core3
• shard2(leader) simplog
• node2 shard4 ●node2_core4
• shard3(leader)
• node3
• shard6(leader)



• その他
• SolrCloudの性能について
• 平均レスポンスタイム50msec！？
• リクエスト数、データサイズの割には性能が出ていない？

• 検索/更新を同時に行った際の性能を、node数/shard数を変えながら調
べてみた



• その他
• テスト環境システム構成テストサーバ

api 1台

node
test
zookeeper 3台
node 1～6台

batch 1台

test DB
12


• その他
• テスト環境ノード用サーバ（仮想環境）
• CPU ： 4core
• disk ： 160GB

• テストデータ
• ドキュメント数： 26万
• データサイズ： 850MB

• テスト内容
• テストサーバからJMeterで30分ほど200req/secの検索負荷をかける
• バッチサーバから更新を行う(約65000レコード)

• 以降のテストケースに対する試行回数は時間の都合で1回となってます



• その他
• テストケース１
• shard数１、node数1～6の場合の検索/更新
• 1core/node
• shardのleaderはnode1 ●node1_core1

node2_core1

node3_core1
test shard1 ●node1_core1
・・・ test shard1
node4_core1

node5_core1

node6_core1



• その他
• テストケース１
• shard数１、node数1～6の場合の検索/更新
• 1core/node
• shardのleaderはnode1
• テスト結果
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

• node数が増えるにしたがって検索性能が向上
• 更新性能は劣化



• その他
• テストケース2 ●node1_core1
• shard数2、node数1～6の場合の検索/更新
node2_core1
• 2core/node
node3_core1
• 各shardのleaderはnode1に集約 shard1
node4_core1

node5_core1

shard1 ●node1_core1 node6_core1
test
shard2 ●node1_core2
・・・ test
●node1_core2

node2_core2

node3_core2
shard2
node4_core2

node5_core2

node6_core2



• その他
• テストケース2
• shard数2、node数1～6の場合の検索/更新
• 2core/node
• 各shardのleaderはnode1に集約
• テスト結果
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

• shard数1の場合に比べて検索/更新性能が劣化
• 1nodeの場合の検索性能は特に劣化

• shard数1の場合と同様にnode数が増えるにしたがって検索性能は向上
• 更新性能はnode数が増えるにしたがって劣化



• その他 ●node1_core1

node2_core1
• テストケース3.1
node3_core1
• shard数3、node数1,3,6の場合の検索/更新 shard1
node4_core1
• 3core/node
node5_core1
• 各shardのleaderはnode1に集約
node6_core1

●node1_core2


node3_core2
・・・ test shard2
node4_core2
node5_core2

node6_core2

●node1_core3

node2_core3

node3_core3
shard3
node4_core3

node5_core3

node6_core3



• その他
• shard数3、node数3の場合の検索/更新
• 3core/node
• 各shardのleaderは各nodeに分散

●node1_core1

shard1 node2_core1

node3_core1

node1_core2


node3_core2

node1_core3

shard3 node2_core3

●node3_core3



• その他
• shard数3、node数1,3,6の場合の検索/更新(3core/node、leader集約)
• shard数3、node数3の場合の検索/更新(3core/node、 leader分散)
• テスト結果
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



• leaderを各nodeに分散させた場合の影響は判別不可（3.1、3.2)

●node1_core1

node2_core1

• その他 node3_core1
shard1
• テストケース4.1 node4_core1

node5_core1
• shard数4、node数1,3,6の場合の検索/更新
node6_core1
• 4core/node ●node1_core2

• 各shardのleaderはnode1に集約 node2_core2

node3_core2
shard2

node5_core2
node6_core2
test
・・・ test
●node1_core3

node2_core3
node3_core3
shard3
node4_core3

node5_core3

node6_core3

●node1_core4

node2_core4

node3_core4
shard4
node4_core4

node5_core4

node6_core4



• その他
• node1
●node1_core1
• shard1(laeder) shard1
• shard2(laeder) node2_core1

• node2 ●node1_core2
shard2
• shard1 node3_core2
• shard3(laeder) test
●node2_core3
• shard4 shard3
node3_core3
• node3
• shard2 ●node3_core4
shard4
• shard4(laeder)



• その他
• 2core/node
●node1_core1
shard1
node2_core1

●node2_core2
shard2
node3_core2
test
●node3_core3
shard3
node4_core3

●node4_core4
shard4
node1_core4



• その他
• テストケース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分散)

• テスト結果

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

• shard数、node数が同じ場合、各node内のcore数が少ない方が検索/更新性能は良い
(4.1 node3、4.2)
• nodeを増やすより1nodeあたりのcore数を減らす方が検索/更新性能が良くなる場合もある
(4.3、4.1 node6)


• その他
• 2core/node
• simplog_bkコレクション同等の構成


test





• その他
• 4core/node
• simplogコレクション同等の構成
●node1_core1
shard1
node2_core1

●node1_core2
shard2
node2_core2

●node2_core3
shard3
node3_core3
test
●node2_core4
shard4
node3_core4

●node3_core5
shard5
node1_core5

●node3_core6
shard6
node1_core6



• その他
• shard数6、node数6の場合の検索/更新 ●node1_core1
shard1
• 2core/node
node4_core1
• node1
• shard1(leader) ●node1_core2
• shard2(leader) shard2
node4_core2
• node2
• shard3(leader) ●node2_core3
• shard4(leader) shard3
• node3 node5_core3
• shard5(leader) test
●node2_core4
• shard6(leader)
shard4
• node4 node5_core4
• shard1
• node5 shard5
node6_core5
• shard3
• node6 shard6
• shard6


• その他
• テストケース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コレクションにレプリカを追
加した状態の構成）

• テスト結果
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

• shard数4の場合と同様にnode数が増えるにしたがって検索性能は向上(5.1、5.3)

• shard数、node数が同じ場合1nodeあたりのcore数が少ない方が検索/更新性能は良い
(5.1、5.2)



• その他
• テスト結果(shard数による違い)
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

• node数/1nodeあたりのcore数に関係なく、collection内のshard数が少ない方が検
索性能が良い
• 更新性能については判別不可



• その他
• テスト結果(まとめ)
• 1nodeあたりのcore数は少ないほど検索/更新性能が良い

• 1collectionあたりのshard数は少ないほど検索性能が良い

• 1node内のcore数が同じ場合、nodeが多いほど検索性能が良い
• 更新性能はnode数が少ない方が良い

• node数と1nodeあたりのcore数
• nodeを増やすより1nodeあたりのcore数を減らす方が検索/更新性能が良くなる場合もあ
る


まとめ

• SolrCloudの利点
• Solrの設定ファイルをコレクション内で一元管理できる
• 検索/更新クライアントは各コレクション内のnodeを意識しなくてよい
• コレクション内のnode(レプリカ)を追加しても検索/更新クライアントの変更は不要

• SolrCloud利用時の注意点
• shardの分割機能はまだないのでコレクション作成時のデータサイズの見積もり
に注意
• shardを増やす場合は合わせてnode数も検討
• コレクション情報が壊れると検索/更新できなくなる
• 更新処理の必須条件
• 全shardのleader nodeのステータスがactiveであること
• 検索処理の必須条件
• 各shardに最低１つのnode(core)が割り当てられていること
• shardが１つでも欠落するとそのコレクションに対しては検索不可
• shardsパラメータで検索対象shardを明示的に指定した場合は可能
• パフォーマンスは素のSolrの方が良い


ご清聴ありがとうございました


第10回solr勉強会 solr cloudの導入事例

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à 第10回solr勉強会 solr cloudの導入事例

Similaire à 第10回solr勉強会 solr cloudの導入事例 (20)

Dernier

Dernier (9)

第10回solr勉強会 solr cloudの導入事例