新規開発局コアテクGで、現在はサービスの管理ツールなどの開発を担当しているGakuです。
現在は担当していないのですが、以前に担当しており、全面的に作り直したアメーバサーチについて書かせていただこうかと思います(一番大変だったんですが、一番楽しい開発でした)。
■以前のアメーバサーチ
- Lucene使用(RMI機能を使ってました)
- 検索対象:6000万件ほど(直近3ヶ月~6ヶ月)
- スケールアップがしにくいつくり
- Luceneのバージョンアップもむずかしい(バージョンアップ後はRMIは非推奨化予定でした。使えないなと)
- 「アクセス過多のため・・・・・」と検索できない事が頻発
- QPS(一秒辺りの検索数) 50ぐらい(4セット合計で)
急激にアメブロの記事数が増えていた為、明らかにキャパオーバに陥ってしまっていました。
それで・・・・・・・・・
ユーザの方々からおおいにお怒りの声が多数届いてました。。。。
・自分が書いた記事が検索結果に出てこないんですけど(-_-##
・検索できないんでけど(-_-#########
----------------------------------------------------------------------------------------
,. < ̄ ̄ ̄ ̄ ̄ > 、
/ ヽ _
〈彡 Y彡三ミ;, も、もうしわけございません…
{\ \|_ \>ー 、 ト三三ニ:}
人{ >、,___.>、/三 ヾ\ |わ三彡;!
/./ トミ;,_ Y/ \>ノー~=- "
V / /!  ̄ ̄ ゝ | / _
し/'┴──----─''| ン}\-ヾ彡
ヾ、___ノー'''`
----------------------------------------------------------------------------------------
弊社社長もおおいに怒る(表面上は穏やかに)
「ぜんぜん検索できないんですけど(^^##########」(特にモバイル)
----------------------------------------------------------------------------------------
,. < ̄ ̄ ̄ ̄ ̄ > 、
/ ヽ _
〈彡 Y彡三ミ;, も、もうしわけございません…
{\ \|_ \>ー 、 ト三三ニ:}
人{ >、,___.>、/三 ヾ\ |わ三彡;!
/./ トミ;,_ Y/ \>ノー~=- "
V / /!  ̄ ̄ ゝ | / _
し/'┴──----─''| ン}\-ヾ彡
ヾ、___ノー'''`
----------------------------------------------------------------------------------------
そんな時に、
第一回Apache Solr勉強会が開催!
※Apache Solrとは・・・
※OSSの全文検索のエンジンとして有名なApache Luceneをベースに、
※機能拡張を行ったJavaのWebサーバアプリケーション。
※LuceneのHTTPラッパー+拡張機能(キャッシュ機構や設定が簡単、管理画面あり)ということになります。
との事で、わらにもすがる気持ちで参加しました。
■Apache Solrの導入の経緯
・分散検索がある
→スケールできる!
・構築が簡単そう!(実際にお気軽です!)
- スキーマ定義がxml
- Tomcatで起動ですぐ導入
- データの登録がとっても簡単(XMLをPost など)
・いろいろな検索に対応!(ファセット検索とかいろいろ)
・Master/Slave構成がとれる!
その時点(2010年6月)で、既に記事数は4億を超え、毎日膨大な数の記事がアップされていたので
・高い拡張性
が一番の決め手でした。
■開発期間
Solr1.4が2009年11月リリース!
Solr1.4のnightlyで
技術検証(一ヵ月半)
2009年10月頃
(実はタレント検索はSolr1.4nightlyでリリース済みだったり)
2009年12月~ 開発
2010年2月 一部リリース
2010年3月 記事データ登録完了
■システム構成
システム構成は下記の図のようになります。
1段目)Wap 4台
いわゆる・・・・なんでしょ^^;皆様の目に入る検索ページや結果を表示するサーバ群です
2段目)トップレベル(まとめ用)Solr 2台
Brokerとも言われます。実際にインデックスをもっている3段目のサーバ群にクエリをコールして、その結果をまとめて、WAPに返します。なので、「まとめ用Solr」ともいってます。当日用のIndexも保持しています
3段目)セカンドレベルSolr いっぱい
常時検索対象のインデックスをもつサーバ (1台辺り2Shard保持)
と
アメーバID指定時のみに検索対象になるインデックスを持つサーバ(1台辺り6Shard保持)
※1Shardあたり1000万記事のインデックスを保持しています
※「Shard」とは、インデックスみたいなものです。
があります。
※アメーバID指定時は、過去すべての記事を対象にしないとねってことでこうしました。
データ更新については、
更新用Masterサーバにて作成→最適化後、レプリケーション
・随時更新(4分ごと)
直近24時間分をすぐ検索対象へ反映 (新規・更新記事(差分))
・日次更新(古い記事)
一日一回(差分) - 削除記事、アメンバー記事削除、退会者削除も
■パフォーマンス(2010年6月末時点)
・クエリー
1日350万~450万(2010年6月末) モバイル:300万 PC:100万
・QPS(一秒辺りの検索数)
85~100(ピーク帯の10分間) →まだまださばける感じ
・平均レスポンスタイム 30ms
<!--[if !ppt]--><!--[endif]-->
・常時検索
2億記事(shard: 20)
・アメーバID指定検索
4億記事(shard:58)
大体一日に70万記事ほど投稿されてる
■苦労した事
対象となる記事が膨大(開発時点で3億記事)だったので、これが思った以上に大変でした。
1)レプリケーションがめっちゃ大変
Master/Slave構成をとっていましたが、
Master→Slaveへ最適化後のINDEXを転送するのが思った以上に大変でした。
ファイル転送もきつかったですが、各ShardのINDEXの最適化もI/Oがすごくかかり大変でした
→SSDにするとかI/Oのいいのを使うに限りますね
2)分散検索をしていますが、ひとつのセカンドレベルSolrが落ちると全体が検索できなくなる
各Shardに死活監視をいれて、一定時間反応がなければ、分散検索対象からはずすとかいろいろ工夫
3)Tomcatの設定で大変
メモリをたっぷり乗せたのですが、こちらをうまく使ってくれずに大変苦労しました。
TimeAllowという設定もあるのですが、負荷が高い時には役に立ちませんでした
4)なによりも・・・記事のインデックスを作るのが大変
なにしろ3億件もあるので、それをインデックス化するだけでとっても大変
かるく1ヶ月はかかりました(一緒にやっていたY田君がほとんどやってくれていました)
■Apache Solrのいいところ
最近は検索エンジンというとどんどん寡占がすすんでいます。
SolrのいいところはOSSであるところですね。
検索結果をどうだすか?
検索結果にどのようなものをだすといいか?
というのは、サービスの特性によって変わってくると思います。(ブログ検索とかニュース検索とか人検索とか)
そこを独自に変えることができるのがいいなっておもいます。
次のバージョンでは、Cluster的なものをつくったりするそうで、すごく愉しみです^^