第3回solr勉強会(アメーバにおけるsolrの利用)

第3回 Solr勉強会株式会社サイバーエージェント新規開発局安田征弘

第3回 Solr勉強会自己紹介・安田征弘（やすだまさひろ）・ 2008年からアメーバで働く・今まで関わったサービス 2008年～ 2010年 - ブログネタ 2010年～ 2010年6月 - アメーバサーチ - なう検索 - タレント検索現在の担当 - アメーバサーチの負荷改善及び機能追加 - 研究開発組織(アメーバのラボ)との連携 ※ブログ記事やクエリログを活用したバックエンドシステムの構築など 2

第3回 Solr勉強会 Agenda • アメーバにおけるLucene/Solrの利用 • 事例紹介 (なう検索) • 事例紹介 (Ameba Search) • まとめ 3

第3回 Solr勉強会アメーバにおける Lucene/Solrの利用 ■Lucene ・アメーバピグの部活検索 - Lucene 2.9.1 ・アメーバパコのパーツ検索 - Lucene 2.4.1 ・プロフィール検索(友達検索) - Lucene 2.0.0 ・アメーバプレゼントのタレント検索 - Lucene 1.4.3 ・スレッド検索(アメばた会議) - Lucene 2.3.1 ・動画検索(アメーバビジョン) - Lucene 1.9.1 ameba lucene 4

第3回 Solr勉強会 Luceneの利用アメーバピグアメーバパコ部活検索パーツ検索 5

第3回 Solr勉強会アメーバにおける Lucene/Solrの利用 ■Solr ・ブログ記事検索(Ameba Search) - Solr 1.4.0 ・なう検索 - Solr 1.4.1 ・タレント検索 - Solr 1.4.0 6

第3回 Solr勉強会 Solrの利用記事検索(Ameba Search) 7

第3回 Solr勉強会 Solrの利用記事検索(Ameba Search) 8

第3回 Solr勉強会 Solrの利用なう検索 9

第3回 Solr勉強会事例紹介（なう検索） http://now.ameba.jp/ 10

第3回 Solr勉強会事例紹介（なう検索）実績(2010年7月) ・ Solr 1.4.1 ・ドキュメント数： 3500万投稿 (2ヶ月分) ・データサイズ： 4.5GB ・検索結果への反映まで： 1～10秒・分散検索の環境パーティション： 12 shards ※記事IDの剰余によるハッシュと時間レンジで分割・負荷クエリ数： 6 ～13万 query/day ピーク帯のスループット： 3 ～ 12 qps (100 qpsまでは負荷テスト済み) 平均レスポンスタイム： 10ms 11

第3回 Solr勉強会システム構成概略図インターネットアプリケーションサーバ（PC、MB）なう(PC) 2台なう(Mobile) 4台 2 brokers LB small-shard01 2 indices / node broker small-shard02 2 slaves 分散検索 10 indices / node shard01 slave なうDB shard10 直近のデータ以外をレプリケーション直近のデータを 1 master レプリケーション 10秒間隔でレプリケーションタレントDB shard01 small-shard01 master shard10 small-shard02 12

第3回 Solr勉強会事例紹介（なう検索）サーバー環境・master (1台) OS : Linux CentOS 5.4 memory : 16GB cpu : Intel(R) Xeon(R) CPU E5540 @ 2.53GH 8core disk : 1.6TB / RAID5 SEAGATE - ST3600057SS (15000rpm, SAS) file system : ext3 ・slave (2台) OS :Linux CentOS 5.4 memory :24GB cpu : Intel(R) Xeon(R) CPU L5520 @ 2.27GHz 16Core disk : 130GB / RAID1 FUJITSU - MBD2147RC (10025rpm, SAS) file system : ext3 13

第3回 Solr勉強会事例紹介（なう検索）サーバー環境・broker (2台) OS :Linux CentOS 5.4 memory :8G cpu : Intel(R) Xeon(R) CPU X3330 @ 2.66GH 4core disk : 148GB / RAID1 WesternDigital - WD1601ABYS-18C0A0 (7200rpm, SATA) file system : ext3 14

第3回 Solr勉強会運用Tips ■ ストアデータの保持方法 MessagePack (ver. 0.3) で構造化したストアデータに Deflate (level 9) を適用【メリット】 - 約20% のデータサイズ削減 (I/O負荷軽減) - CPUへの負荷も少なく、高速 - schema.xml を変えずに、ストアデータ項目を追加できる (実際、リリース前日にストア項目追加の依頼を受ける。。。) 15

第3回 Solr勉強会参考 ■ MessagePack - 古橋貞之氏が開発したバイナリシリアライズライブラリ - Java の Serializable と比べて10倍以上高速【参考】・MessagePack http://msgpack.org/ ・古橋貞之の日記 http://d.hatena.ne.jp/viver/ ・アーキテクチャ http://www.slideshare.net/frsyuki/architecture-of-messagepack ・MessagePack & Deflateのデータサイズ検証 http://www.slideshare.net/moaikids/java-3560754 16

第3回 Solr勉強会運用Tips ■ 分散検索の死活監視とshardの冗長化 - Solrのコードをカスタマイズ (LBHttpSolrServerの死活監視実装 + 分散検索への対応 [自作]) ■ Tokenizer インプットテキスト ↓ SenTokenizer (cmecab-java) ↓ ASCII文字 → WhiteSpace区切りその他 → EdgeNGram (minGram=1, maxGram=5) ↓ StopFilter 17

第3回 Solr勉強会 ■ Tokenizer Example ワールドカップ準決勝Spainの勝利。 ① SenTokenizer ② EdgeNGramFilter (ASCII文字はWhiteSpace区切り[自作]) 18

第3回 Solr勉強会 ■ Tokenizer Example ② EdgeNGramFilter (ASCII文字はWhiteSpace区切り[自作]) ③ StopFilter 削除 ※誤検知の確率は1%ある (クエリログ 1000万をサンプリングして推計) 19

第3回 Solr勉強会事例紹介（Ameba Search） http://search.ameba.jp/ 20

第3回 Solr勉強会事例紹介（Ameba Search）実績(2010年7月) ・ Solr 1.4.0 ・ドキュメント数： 4億記事・データサイズ： 800GB ・検索結果への反映まで： 1～4分・分散検索の環境パーティション： 59 shards + 当日分（ハッシュ分割）×2 ※記事IDで分割 ※1shard = 1000万記事ID（11～16GB）・負荷クエリ数： 350～450万 query/day ピーク帯のスループット： 80 ～100 qps 平均レスポンスタイム： 30ms 21

第3回 Solr勉強会システム構成概略図インターネットアプリケーションサーバ（PC、MB） PC,Mobile 4台 2 brokers LB small-shard01 2 indices / node broker small-shard02 17 slaves 分散検索 2 indices / node 7 indices / node shard01 shard21 直近のデータを slave slave レプリケーション shard20 shard60 ブログDB 直近の2億記事を古い記事を 2 master レプリケーションレプリケーションレプリケーション 45 indices / node タレントDB small-shard01 shard01 shard21 master small-shard02 shard20 shardxx 22

第3回 Solr勉強会事例紹介（Ameba Search）サーバー環境・master (2台) OS : Linux CentOS 5.4 memory : 36GB cpu : Intel(R) Xeon(R) CPU E5540 @ 2.53GH 16core disk : 1.6TB / RAID5 FUJITSU MBD2300RC (10025rpm, SAS) file system : ext3 ・slave (17台) OS : Linux CentOS 5.4 memory : 48GB cpu : Intel(R) Xeon(R) CPU L5520 @ 2.27GHz 16Core disk : 270GB / RAID1 FUJITSU MBD2300RC (10025rpm, SAS) file system : ext3 23

第3回 Solr勉強会事例紹介（Ameba Search）サーバー環境・broker (2台) OS :Linux CentOS 5.4 memory :12G cpu : Intel(R) Xeon(R) CPU E5540 @ 2.53GH 8core disk : 130GB / RAID1 FUJITSU MBD2147RC (10025rpm, SAS) file system : ext3 24

第3回 Solr勉強会インデックスデータサイズ(1shardあたり) File Size[GB] Field Infos (*.fnm) 0.0 Stored Fields Data (*.fdt) 7.2 Field Index (*.fdx) 0.1 Positions (*.prx) 4.0 Frequencies (*.frq) 4.2 Terms Infos (*.tis) 0.2 Term Info Index (*.tii) 0.0 Normalization Factors (*.nrm) 0.1 25

第3回 Solr勉強会 MessagePack & Deflateを適用した場合 File Size[GB] Field Infos (*.fnm) 0.0 Stored Fields Data (*.fdt) 4.5 Field Index (*.fdx) 0.1 従来比 Positions (*.prx) 4.3 38%削減 Frequencies (*.frq) 3.0 Terms Infos (*.tis) 0.1 Term Info Index (*.tii) 0.0 Normalization Factors (*.nrm) 0.0 ※現在、リプレイス中 26

第3回 Solr勉強会運用Tips ■Masterサーバ ⅰ) Masterサーバでは、インデックス生成用のSolr (Batch) とレプリケーション用のSolr の2つのプロセスが稼働 → レプリケーション用のSolrは、lockType=none ※Batch用のSolrでは各warm-up処理が発生しないように設定。当初、QuerySenderListenerを登録していたら、 1 commit処理に20～30分かかった。。。 27

第3回 Solr勉強会運用Tips ■Masterサーバ ⅱ) レプリケーションを始めるトリガーはMasterサーバから行う。レプリケーションの実行フロー 1. インデックスのoptimize処理 2. インデックスバージョンのリフレッシュ(coreのリロード) MasterURL + /admin/cores?action=RELOAD&core=コア名 3. レプリケーションのキック SlaveURL + /コア名/admin/replication/index.jsp?replicate=now 28

第3回 Solr勉強会運用Tips ■Masterサーバ ⅲ) CompoundFileファイルの書き込み時に監視不能になる(I/O負荷の過多) snmpdがNo Response 29

第3回 Solr勉強会 ■ 解決策 1. CompoundFileWriter にsleep処理を入れてみる監視不能 I/O負荷を抑えた cfs書き出し cfs書き出し ※改善したが、まだ監視不能になる。。。。。 30

第3回 Solr勉強会 ■ 解決策 SEAGATE ST3500620SS (7200rpm, SAS) 2. スケールアップ - RAID5(300GB×8) から RAID5+0 (500GB×16) へ (RX200 [FUJITSU] → DX60 [FUJITSU] へ) 監視不能 loadが半分 cfs書き出し cfs書き出し現在、リプレイス中。 31

第3回 Solr勉強会 ■ 解決策 2. スケールアップ - RAID5(300GB×8) から RAID5+0 (500GB×16) へ (RX200 [FUJITSU] → DX60 [FUJITSU] へ) 2倍以上の書き込み速度 cfs書き出し cfs書き出し現在、リプレイス中。 32

第3回 Solr勉強会 ■Masterサーバ運用Tips ⅳ) 主なパラメータ useCompoundFile=true ← falseの方が主流らしいです ramBufferSizeMB=256 mergeFactor=20 maxFieldLength=80000 maxMergeDocs=2147483647 writeLockTimeout=1000 commitLockTimeout=10000 luceneAutoCommit=false lockType=native termIndexInterval=256 unlockOnStartup=true reopenReaders=true deletionPolicy.keepOptimizedOnly=true deletionPolicy.maxCommitsToKeep=1 deletionPolicy.maxOptimizedCommitsToKeep=1 deletionPolicy.maxCommitAge=1DAY 33

第3回 Solr勉強会運用Tips ■Slaveサーバ ⅰ) サーバの空きメモリ > 1shardのデータサイズ Memory Usageをみて Slaveへ配備するインデックス量を調整まだ置ける 34

第3回 Solr勉強会運用Tips ■Slaveサーバ ⅱ) JVMへのメモリ割り当ては最低限で良い ex) memory 48GBのshardへの設定 -server -Xmx9000m -Xms9000m -Xss256k -Xmn7000m -XX:MaxNewSize=7000m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:SurvivorRatio=2 -XX:MaxTenuringThreshold=80 -XX:TargetSurvivorRatio=80 -XX:+UseBiasedLocking -XX:+DoEscapeAnalysis -XX:-UseGCOverheadLimit -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled ⅲ) useColdSearcher=false に設定 - trueにすると負荷に耐えられない 35

第3回 Solr勉強会運用Tips ■Slaveサーバ ⅳ) レプリケーション時のI/O負荷を減らすため、転送速度を絞る転送速度 60Mbps → 30Mbps にした → SnapPullerにsleepをいれて調整 ⅴ) Document Cacheを生成するため、solrconfig.xmlに最も頻出するワードを登録し、十分なautowarmingを行う LukeRequestHandlerから取得 ⅵ) ファイルシステムのマウントにnoatimeオプションをいれる writebackオプションも試したが、あまり効果がなかった ⅶ) レプリケーション終了時にシステムコールを行う ”dd if=新しいインデックスデータのファイルパス of=/dev/null” → インデックスファイルをキャッシュさせる(QuerySenderListenerの後に実行) 36

第3回 Solr勉強会 ■Slaveサーバ運用Tips ⅷ) 主なパラメータ queryResultCache.class=solr.LRUCache queryResultCache.size=16384 queryResultCache.initialSize=16384 queryResultCache.autowarmCount=16384 queryResultCache.cleanupThread=true documentCache.class=solr.LRUCache documentCache.size=16384 documentCache.initialSize=16384 documentCache.autowarmCount=16384 documentCache.cleanupThread=true useFilterForSortedQuery=true queryResultWindowSize=40 queryResultMaxDocsCached=400 enableLazyFieldLoading=false useColdSearcher=false maxWarmingSearchers=1 37

第3回 Solr勉強会今後 ■今後の計画・ストアデータとインデックスの分離 → Lucene/Solrには、Indexのみを保持させる。・検索ランキング(スコアリング)、検索オプションの拡充 → アメーバのソーシャル基盤を活かし、探している記事がヒットする仕組みを。・転置インデックスデータの圧縮 → Lucene trunkにあるFlex API を利用・・・ 38

第3回 Solr勉強会おわりに ■まとめ・ストアデータの保持方法にMessagePack & Deflateを適用。効率的且つ仕様変更に強いため、アメーバサーチにも導入予定。・マスターサーバには、I/O性能の良いサーバを選定すべき。・ Solrはメモリ依存のシステム → サーバーのメモリ量に合わせたインデックス配備が重要・ Solrを使えば、短期間で大規模な検索システムを構築可能 39

第3回 Solr勉強会ご静聴、ありがとうございました 40

http://d.hatena.ne.jp	837
https://twitter.com	39
https://si0.twimg.com	32
http://twitter.com	13
http://a0.twimg.com	13
https://twimg0-a.akamaihd.net	3
http://www.slideshare.net	3
http://webcache.googleusercontent.com	2
http://triple-c.sakura.ne.jp	2
https://confluence.livesense.jp	2
http://www.freerss.net	1
http://b.hatena.ne.jp	1

第3回solr勉強会(アメーバにおけるsolrの利用)

by Masahiro Yasuda

Accessibility

Categories

Upload Details

Usage Rights

12 Embeds 948

Statistics

第3回solr勉強会(アメーバにおけるsolrの利用) Presentation Transcript