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

CyberAgent, Inc.

第10回 Solr勉強会

SolrCloud導入事例

株式会社サイバーエージェント

アメーバ事業本部弘瀬健

自己紹介

• 弘瀬健(ひろせけん)

• ～2011年業務系WEBシステム構築

• 2011年～サイバーエージェントで検索システム構築

• 今までに関わったサービス

• Ameba検索

• アメーバニュース検索

• プロフィール検索

• グルっぽ検索

• Candy検索

• Simplog検索

1 CyberAgent, Inc. 2013/03/27

アジェンダ


• 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/

• システム構成

simplog simplog_bk

node



LB

api 2台

node 3台 node 3台

batch 2台

Simplog DB

zookeeper 3台



• サーバ環境

• 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




• コレクション構成

• 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_bkコレクション

• 6shard

• 3node

• 2core/node

• node1

• shard1(leader)

• shard2(leader)

• node2

• shard3(leader)

• shard4(leader)

• node3

• shard5(leader)

• shard6(leader)

simplog

shard1 ●node1_core1








• その他

• SolrCloudの性能について

• 平均レスポンスタイム50msec！？

• リクエスト数、データサイズの割には性能が出ていない？

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

• その他

• テスト環境システム構成

batch 1台

test

node 1～6台

node

api 1台



テストサーバ

test DB

zookeeper 3台



• その他

• テスト環境ノード用サーバ（仮想環境）



• CPU ： 4core

• disk ： 160GB


• テストデータ

• ドキュメント数： 26万

• データサイズ： 850MB

• テスト内容

• テストサーバからJMeterで30分ほど200req/secの検索負荷をかける

• バッチサーバから更新を行う(約65000レコード)

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



• その他

• テストケース１

• shard数１、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 ・・・



• その他

• テストケース１

• shard数１、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



• その他

• テストケース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


shard2 ●node1_core2 ・・・



• その他

• テストケース2

• shard数2、node数1～6の場合の検索/更新

• 2core/node


• テスト結果

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

• 1nodeの場合の検索性能は特に劣化

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

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



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



• その他

• テストケース3.1

• shard数3、node数1,3,6の場合の検索/更新

• 3core/node


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




・・・



• その他


• 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



• その他


• shard数3、node数1,3,6の場合の検索/更新(3core/node、leader集約)


• shard数3、node数3の場合の検索/更新(3core/node、 leader分散)

• テスト結果





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



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



• その他


• shard数4、node数1,3,6の場合の検索/更新

• 4core/node


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





・・・



• その他




• 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


CyberAgent, Inc. 2013/03/27

• その他



• 2core/node


test

shard1

●node1_core1

node2_core1

shard2

●node2_core2

node3_core2

shard3

●node3_core3

node4_core3

shard4

●node4_core4

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分散)

• テスト結果





• shard数、node数が同じ場合、各node内のcore数が少ない方が検索/更新性能は良い

(4.1 node3、4.2)

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

(4.3、4.1 node6)



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



• その他



• 2core/node

• simplog_bkコレクション同等の構成

test









• その他



• 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



• その他



• 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



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


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

(5.1、5.2)



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数による違い)

• node数/1nodeあたりのcore数に関係なく、collection内の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



• その他

• テスト結果(まとめ)

• 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の導入事例

Technology

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