第10回solr勉強会 solr cloudの導入事例
- 1. 第10回 Solr勉強会 SolrCloud導入事例 株式会社サイバーエージェント アメーバ事業本部 弘瀬 健 CyberAgent, Inc.
- 2. 自己紹介 • 弘瀬 健(ひろせ けん) • ～2011年 業務系WEBシステム構築 • 2011年～ サイバーエージェントで検索システム構築 • 今までに関わったサービス • Ameba検索 • アメーバニュース検索 • プロフィール検索 • グルっぽ検索 • Candy検索 • Simplog検索 2013/03/27 CyberAgent, Inc. 1
- 3. アジェンダ • SolrCloudの概要 • 導入事例(Simplog検索) • Simplogとは • システム構成 • その他 • まとめ 2013/03/27 CyberAgent, Inc. 2
- 4. SolrCloud概要 • Solr4.0からの新機能 • クラウドによる分散検索/インデクシング • zookeeperを使ってクラウド情報を管理 http://wiki.apache.org/solr/SolrCloud 2013/03/27 CyberAgent, Inc. 3
- 5. SolrCloud概要 • SolrCloudの構成要素 要素 説明 collection 1まとまりの検索対象を表す。1個以上のshardにより構成される。 zookeeperにより管理されるsolrの設定ファイルはcollection単位で適用される。 shard collectionを分割したもの。1個以上のcoreにより構成される。 node 1JVMインスタンスで起動されているSolr。 ポートを分ければ1サーバ内で複数nodeを起動することも可能。 core shardを構成する最小の単位。 1node内で複数のcoreを管理することもできる。 2013/03/27 CyberAgent, Inc. 4
- 6. 導入事例(Simplog検索) • Simplogとは • スマホ用のブログサービス • 実績(2013/3/26現在) • Solr 4.1 • 検索対象ドキュメント数 ： 295万投稿 • データサイズ ： 1.5GB • 検索への反映時間 ： 5分 • 負荷 • クエリ数 ： 3～10万 query/day • ピーク帯のスループット ： ～3qps • 平均レスポンスタイム ： 50msec http://spapps.ameba.jp/simplog/ 2013/03/27 CyberAgent, Inc. 5
- 7. 導入事例(Simplog検索) • システム構成 LB api 2台 node simplog_bk simplog zookeeper 3台 node 3台 node 3台 batch 2台 Simplog DB 6 2013/03/27 CyberAgent, Inc.
- 8. 導入事例(Simplog検索) • サーバ環境 • 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 2013/03/27 CyberAgent, Inc. 7
- 9. 導入事例(Simplog検索) • サーバ環境 • 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 2013/03/27 CyberAgent, Inc. 8
- 10. 導入事例(Simplog検索) ●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 2013/03/27 CyberAgent, Inc. 9
- 11. 導入事例(Simplog検索) • コレクション構成 • 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) • shard4(leader) shard5 ●node3_core5 • node3 • shard5(leader) shard6 ●node3_core6 • shard6(leader) 2013/03/27 CyberAgent, Inc. 10
- 12. 導入事例(Simplog検索) • その他 • SolrCloudの性能について • 平均レスポンスタイム50msec！？ • リクエスト数、データサイズの割には性能が出ていない？ • 検索/更新を同時に行った際の性能を、node数/shard数を変えながら調 べてみた 2013/03/27 CyberAgent, Inc. 11
- 13. 導入事例(Simplog検索) • その他 • テスト環境システム構成 テストサーバ api 1台 node test zookeeper 3台 node 1～6台 batch 1台 test DB 12 2013/03/27 CyberAgent, Inc.
- 14. 導入事例(Simplog検索) • その他 • テスト環境ノード用サーバ（仮想環境） • OS ： Linux CentOS 6.4 • メモリ ： 14GB • CPU ： 4core • disk ： 160GB • ファイルシステム ： ext4 • テストデータ • ドキュメント数 ： 26万 • データサイズ ： 850MB • テスト内容 • テストサーバからJMeterで30分ほど200req/secの検索負荷をかける • バッチサーバから更新を行う(約65000レコード) • 以降のテストケースに対する試行回数は時間の都合で1回となってます 2013/03/27 CyberAgent, Inc. 13
- 15. 導入事例(Simplog検索) • その他 • テストケース１ • 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 2013/03/27 CyberAgent, Inc. 14
- 16. 導入事例(Simplog検索) • その他 • テストケース１ • 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数が増えるにしたがって検索性能が向上 • 更新性能は劣化 2013/03/27 CyberAgent, Inc. 15
- 17. 導入事例(Simplog検索) • その他 • テストケース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 2013/03/27 CyberAgent, Inc. 16
- 18. 導入事例(Simplog検索) • その他 • テストケース2 • shard数2、node数1～6の場合の検索/更新 • 2core/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) 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数が増えるにしたがって劣化 2013/03/27 CyberAgent, Inc. 17
- 19. 導入事例(Simplog検索) • その他 ●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 shard1 ●node1_core1 node2_core2 node3_core2 test shard2 ●node1_core2 ・・・ test shard2 node4_core2 shard3 ●node1_core3 node5_core2 node6_core2 ●node1_core3 node2_core3 node3_core3 shard3 node4_core3 node5_core3 node6_core3 2013/03/27 CyberAgent, Inc. 18
- 20. 導入事例(Simplog検索) • その他 • テストケース3.2 • shard数3、node数3の場合の検索/更新 • 3core/node • 各shardのleaderは各nodeに分散 ●node1_core1 shard1 node2_core1 node3_core1 node1_core2 test shard2 ●node2_core2 node3_core2 node1_core3 shard3 node2_core3 ●node3_core3 2013/03/27 CyberAgent, Inc. 19
- 21. 導入事例(Simplog検索) • その他 • テストケース3.1 • shard数3、node数1,3,6の場合の検索/更新(3core/node、leader集約) • テストケース3.2 • shard数3、node数3の場合の検索/更新(3core/node、 leader分散) • テスト結果 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 • shard数2の場合に比べて検索/更新性能が劣化 • 1nodeの場合の検索性能は特に劣化 • shard数2の場合と同様にnode数が増えるにしたがって検索性能は向上 • 更新性能はnode数が増えるにしたがって劣化 • leaderを各nodeに分散させた場合の影響は判別不可（3.1、3.2) 2013/03/27 CyberAgent, Inc. 20
- 22. 導入事例(Simplog検索) ●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 shard1 ●node1_core1 node4_core2 node5_core2 shard2 ●node1_core2 node6_core2 test shard3 ●node1_core3 ・・・ test ●node1_core3 node2_core3 shard4 ●node1_core4 node3_core3 shard3 node4_core3 node5_core3 node6_core3 ●node1_core4 node2_core4 node3_core4 shard4 node4_core4 node5_core4 node6_core4 2013/03/27 CyberAgent, Inc. 21
- 23. 導入事例(Simplog検索) • その他 • テストケース4.2 • shard数4、node数3の場合の検索/更新 • 各shardのleaderは各nodeに分散 • 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 • shard3 node2_core4 • shard4(laeder) 2013/03/27 CyberAgent, Inc. 22
- 24. 導入事例(Simplog検索) • その他 • テストケース4.3 • shard数4、node数4の場合の検索/更新 • 2core/node • 各shardのleaderは各nodeに分散 ●node1_core1 shard1 node2_core1 ●node2_core2 shard2 node3_core2 test ●node3_core3 shard3 node4_core3 ●node4_core4 shard4 node1_core4 2013/03/27 CyberAgent, Inc.
- 25. 導入事例(Simplog検索) • その他 • テストケース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分散) • テスト結果 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 • shard数3の場合に比べて検索/更新性能が劣化 • 1nodeの場合の検索性能は特に劣化 • shard数3の場合と同様にnode数が増えるにしたがって検索性能は向上 • 更新性能はnode数が増えるにしたがって劣化 • shard数、node数が同じ場合、各node内のcore数が少ない方が検索/更新性能は良い (4.1 node3、4.2) • nodeを増やすより1nodeあたりのcore数を減らす方が検索/更新性能が良くなる場合もある (4.3、4.1 node6) 2013/03/27 CyberAgent, Inc. 24
- 26. 導入事例(Simplog検索) • その他 • テストケース5.1 • shard数6、node数3の場合の検索/更新 • 2core/node • simplog_bkコレクション同等の構成 shard1 ●node1_core1 shard2 ●node1_core2 shard3 ●node2_core3 test shard4 ●node2_core4 shard5 ●node3_core5 shard6 ●node3_core6 2013/03/27 CyberAgent, Inc. 25
- 27. 導入事例(Simplog検索) • その他 • テストケース5.2 • shard数6、node数3の場合の検索/更新 • 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 2013/03/27 CyberAgent, Inc. 26
- 28. 導入事例(Simplog検索) • その他 • テストケース5.3 • 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 • shard2 ●node3_core5 • node5 shard5 node6_core5 • shard3 • shard4 ●node3_core6 • node6 shard6 • shard5 node6_core6 • shard6 2013/03/27 CyberAgent, Inc. 27
- 29. 導入事例(Simplog検索) • その他 • テストケース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コレクションにレプリカを追 加した状態の構成） • テスト結果 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 • shard数4の場合と同様にnode数が増えるにしたがって検索性能は向上(5.1、5.3) • 更新性能はnode数が増えるにしたがって劣化 • shard数、node数が同じ場合1nodeあたりのcore数が少ない方が検索/更新性能は良い (5.1、5.2) 2013/03/27 CyberAgent, Inc. 28
- 30. 導入事例(Simplog検索) • その他 • テスト結果(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 • node数/1nodeあたりのcore数に関係なく、collection内のshard数が少ない方が検 索性能が良い • 更新性能については判別不可 2013/03/27 CyberAgent, Inc. 29
- 31. 導入事例(Simplog検索) • その他 • テスト結果(まとめ) • 1nodeあたりのcore数は少ないほど検索/更新性能が良い • 1collectionあたりのshard数は少ないほど検索性能が良い • 1node内のcore数が同じ場合、nodeが多いほど検索性能が良い • 更新性能はnode数が少ない方が良い • node数と1nodeあたりのcore数 • nodeを増やすより1nodeあたりのcore数を減らす方が検索/更新性能が良くなる場合もあ る 2013/03/27 CyberAgent, Inc. 30
- 32. まとめ • SolrCloudの利点 • Solrの設定ファイルをコレクション内で一元管理できる • 検索/更新クライアントは各コレクション内のnodeを意識しなくてよい • コレクション内のnode(レプリカ)を追加しても検索/更新クライアントの変更は不要 • SolrCloud利用時の注意点 • shardの分割機能はまだないのでコレクション作成時のデータサイズの見積もり に注意 • shardを増やす場合は合わせてnode数も検討 • コレクション情報が壊れると検索/更新できなくなる • 更新処理の必須条件 • 全shardのleader nodeのステータスがactiveであること • 検索処理の必須条件 • 各shardに最低１つのnode(core)が割り当てられていること • shardが１つでも欠落するとそのコレクションに対しては検索不可 • shardsパラメータで検索対象shardを明示的に指定した場合は可能 • パフォーマンスは素のSolrの方が良い 2013/03/27 CyberAgent, Inc. 31
- 33. ご清聴ありがとうございました 2013/03/27 CyberAgent, Inc. 32