2012年1月26日、CROOZ株式会社主催「モーショノロジー2012 #1」がアカデミーヒルズ（六本木ヒルズ内）49階タワーホールにて開催されました。

今回のテーマは「検索はシステムを救う」と題して、利用するプロダクトや技術に加えて、具体的なサービスでどのプロダクトがどのように使われているのかといった視点を多く取り入れた内容としました。

「検索」といえば、どのようなサービスでも当たり前にあるものだと思われがちですが、実際には「プロダクトを入れただけなんとかなる」範囲は狭く、提供するサービスによって複雑な開発が必要になってきます。

はじめに「モーショノロジー」について

近年、既存携帯電話からスマートフォンにデバイスが広がったことで、表現力（処理能力）が格段に上がりました。私たちのようにサービスを提供する側は、いかにしてユーザを技術で夢中にさせていくかを追求するべく、「⁠動き（motion⁠）⁠」⁠「⁠技術（Technology⁠）⁠」2つの単語を掛け合わせた造語をタイトルとしました。

CROOZ株式会社では、サービス向上について、新技術、新ガジェット、新プラットフォームなど、さまざまな課題に対して定期的に同業他社様と切磋琢磨し、業界全体の発展を寄与していきたいと考えております。

モーショノロジー（Facebookファンページ）

URL：http://www.facebook.com/motionology

発表内容

今回発表いただいた皆さんと内容は次表の通りです（敬称略⁠）⁠。検索技術や実装サービスなど、聞いた事ある！よく使っています！ というものばかりではないでしょうか？

では、実際の発表を紹介していきましょう。

groongaの索引構築の実装

有限会社未来検索ブラジルの森さんよりお話しいただきました。森さんと言えば、書籍『検索エンジンはなぜ見つけるのか』でも有名な方かと思います。

発表内容はgroongaを中心とした全文検索のお話で、検索に関する歴史からていねいに説明されました。

• 1945年：Vannevar Bush's As We May Think
• 1950年：情報検索（information retrieval）という用語が誕生
• 1971年：全文検索（full-text information retrieval）萌芽的段階

上記の段階を辿って検索の技術は発展してきましたが、現在まで「大量の文書から いかに高速に処理するか、いかに的確な情報を見つけるか」という課題に関してはあまり進展がありません。このようにいろいろと課題のある中、今回はgroongaでも採用している「転置索引」を中心とした説明がありました。

転置索引は、本の巻末索引とおおよそ同じイメージで、groongaでは「転置索引型の全文検」「⁠索引の動的構築が得意」「⁠カラムストア指向」を実現しており、今後は静的構築にも意欲を示していました。静的構築が実現されると、たとえばバッチ処理などでの利用用途などに幅が広がるとのことで、今後の対応が楽しみでもあります。

CROOZMALLでの全文検索の課題と検証

CROOZ株式会社の長谷川さんからはECサイト「CROOZMALL」の検索機能についての課題と検証についてお話しいただきました。

これまで同社は、MySQL5.1.x系に形態素解析をMeCabを利用し、ストレージエンジンはMyISAMを利用していました。しかしながら、爆発的に増え続ける商品や何パターンものソート処理など運用する上で、テーブルロックなどが発生することがあり、運用でカバーしつつも問題になりつつありました。

辞書を熟成するべくMeCabを利用した解析の方法も問題ではありましたが、それより先に今後爆発的に増えていくデータに適したシステム的な理想を整理するのが先決だという結論に至りました。

まずECサイトにおける「検索」に期待する事をきちんと定義し、その中から検索の位置づけを定義付けます。ECサイトを運用する目的は多くのユーザに買っていただくことであるため、ECサイトにおける検索システムは買っていただくための確率を上げる事が目的です。

検索対象の商品が無かったとしても「not fond」と正直レスポンスをしては行けません。そこからさらにバック系のシステムで近似検索をかけたりすると同時に、無かった商品に関しては拡充することができないか営業、マーケティングに活用する必要があります。

CROOZでは今後、EC系モールシステムと既存のBlog、コーデノートなど商品と直結できるシステムを構築し、ビックデータマイニングを実現する方法を検討しています。このあたりの詳細は、勉強会内でもお話ししたのですが、今回はテーブルロックを回避するためにgroongaストレージエンジンを検証したので、その内容を紹介します。

rpm -ivh http://packages.groonga.org/centos/groonga-repository-1.0.0-0.noarch.rpm
yum update
yum -y install MySQL-client
yum -y install MySQL-devel
yum -y install MySQL-embedded
yum -y install MySQL-server
yum -y install MySQL-shared
yum -y install MySQL-test
yum install -y groonga groonga-tokenizer-mecab groonga-devel
yum -y install mysql-groonga
mysql -u root
mysql> INSTALL PLUGIN groonga SONAME 'ha_groonga.so';
mysql> CREATE FUNCTION last_insert_grn_id RETURNS INTEGER soname 'ha_groonga.so';
mysql> SHOW ENGINES;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine             | Support | Comment                                                        | Transactions | XA   | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| InnoDB             | DEFAULT | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| CSV                | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MyISAM             | YES     | MyISAM storage engine                                          | NO           | NO   | NO         |
| BLACKHOLE          | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| MRG_MYISAM         | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| MEMORY             | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| groonga            | YES     | CJK-ready fulltext search, column store                        | NO           | NO   | NO         |
| PERFORMANCE_SCHEMA | YES     | Performance Schema                                             | NO           | NO   | NO         |
| FEDERATED          | NO      | Federated MySQL storage engine                                 | NULL         | NULL | NULL       |
| ARCHIVE            | YES     | Archive storage engine                                         | NO           | NO   | NO         |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
10 rows in set (0.00 sec)

全体的にinsertに関する処理は圧倒的にgroongaの方が高速であることがわかりました。また、selectに関してはMyISAMに軍配が上がるものの、明示的にロックせずに参照していること、実際のクエリを完全に一致させることが難しく、取り急ぎ行ってみたといった感じの検証であるため、今後、参照側もチューニングなどを重ねるに連れてgroongaストレージエンジンを採用する可能性（使いどころの検討）が高まってくるかと思います。

当日利用したスライドは以下で公開されています。ぜひご覧ください。

20120126-mnlgy-1-11336943

URL：http://www.slideshare.net/sususlideshare/20120126-mnlgy-1-11336943

全文検索のちょっとちがった使い方（仮）

グリー株式会社でログ分析システムに従事している一井さんよりお話しいただきました。

グリーでの数値指標管理では、基本となるデータ総数が「1億キー×最大7年」と現時点でも膨大な上に、現在でも時間と共に増えるアプリIDと組み合わせる必要があり、よくある「あのキーってなんだっけ？」や「PV? pageview?」「⁠そもそもこの数値って事前集計されてるんだっけ？」といった問題が頻繁に起こり、人間が管理するには限界があると感じていたそうです。

今ではHadoopやMongoDBなどの選択肢もある中、あえてそれらを利用せず、「⁠MySQLでKVS」という構成で行っています。どうしてこの構成で行けると思っているかというと、やはり担当者が膨大なデータに埋まることなく、主たる目的を理解しているためです。

スライドにも記載されていた通り、

• やりたいことはただのKVS
  • ただしkeyの種類がものすごく多い
  • keyは人間が扱うので、記憶はあやふや
• 種類が多いぶん、それなりに構造は持っている／パターンも決まってはいる

と問題、要件を整理します。そして全文検索でkeyを探すのです。

• 構造があるkeyでも、単にserializeして書いておけばよい
• keystringに対して全文検索
• 必要なkeyがわかれば、あとはいつものKVS

こうすると、MySQLに慣れていれば運用的にもメリットがあり、当面はこの構成で問題ないとのことでした。

ただし、このパターンはユーザなどの第三者が検索ワードを入力する事などは想定しておらず、自分言語に近い形でkeyを作成する事が前提となります。しかし全文検索をこのように利用することで自社の抱える問題が解決し、増え続けるデータに担当者がつぶれてしまったり、新しいプロダクトやソリューションに手を出す必要が無い可能性もあるという点では、面白いアプローチかと思います。

他にもいろいろとお話しいただいたのですが、詳細は以下で公開されています。ぜひご覧ください。

Ichii gree-crooz-20120126

URL：http://www.slideshare.net/ichii386/ichii-greecrooz20120126

rroongaによる検索サービスの実装

株式会社クリアコードの須藤さんより、Rubyとgroongaを一緒に使った検索サービスの作り方について説明がありました。

rroongaはgroongaのRubyライブラリで、プロセス内（アプリケーション内）にDBを持つのが特徴で、groongaをライブラリとして使う場合、以下のようなメリットがあります。

• 通信コストがないため、小さいコストで細かくデータを読み書きできる
• 低レベルのAPIから高レベルのAPIまで使えるため柔軟に演算を組み合わせた検索ができる

この中で「柔軟に演算を組み合わせた例」として、「⁠多段ドリルダウン」を実現する説明、用途などを紹介しました。このような機能は、たとえユーザが意識しなくても、システム的には絞り込み条件が途中で変更される場合、キーやそれまでの結果を効率よく引き継ぐことができ、継続検索を可能にします。

また今回のお話では「デメリットはスケールアウトする標準的な仕組みがないことです。そのため、レプリケーションの仕組みを自分で作り込む必要があります」と、デメリットにも言及されました。

開発事例として、テレビ番組横断検索＆共有サービス「テレコ!」の紹介がありました。ここでは、たとえば番組説明から出演者を抽出する場合のような、メタデータ抽出にはドリルダウンが有効であること。またコンテンツベースの候補の精度がいいなど、メリットを効果的に適用する事ができます。

その他、groonga本体が持ってる機能。ローマ字、かな。補完、補正、提案、学習などのサジェスト機能なども利用することができるので、要件次第では非常に相性が良いとのお話を頂きました。

その他、当日の発表内容につきましては、同社のブログでご紹介いただいております。

モーショノロジー2012 #1: rroongaによる検索サービスの実装

URL：http://www.clear-code.com/blog/2012/1/26.html

ぐるなびサービスにおける、groongaの位置情報検索関連について。

株式会社ぐるなびの塩畑さんには、groongaを利用した位置情報を利用したレストラン検索についてお話しいただきました。「⁠ぐるなび」といえば、レストラン、居酒屋などの検索でおなじみではないでしょうか？ 今回は、これらの店舗について、どうやって位置を特定しているのかといった実装についてのお話です。

groongaを利用したきっかけは、それまで利用していたパッケージの提供が終了となったことです。新たなパッケージ選定を検討した結果、groongaに決定し、2010年に移行を完了したそうです。位置検索の一般的な方法は、飲食店などの店舗を緯度経度検索し、結果を地図で表示するもので、地図に関しては日本測地系と世界測地系があるとのこと。groongaの場合は両方ともサポートされているそうです。

実際の検索方法としては、ある場所を基準点として、そこから矩形と円形による範囲検索を提供。また、基準点（座標）から、各データ（店舗など）までの距離を、方形近似、球面近似、楕円体（ヒュベニ）で算出し、結果に反映しているそうです。

距離算出に関しては、そこまでサポートする必要があるのかなどと質問もありましたが、「⁠誤差に関しては地域によって差が生じる（実際に最大数メートル誤差が生じる所もある⁠）⁠」ことと、「⁠たとえば隣の店舗を指してしまったらしたら契約店舗に迷惑がかかる」などを考慮したとのことで、この点に関しては、絶対的なプロ意識を持って対応している点が伺えました。

また、店舗名や補足説明などに関しては、MeCabを利用した全文検索を採用しているとのことでした。

当日のレポートはこちらでも公開されています。また、スライドは以下で公開されていますのでぜひご覧ください。

groongaの位置情報検索について（PDF）

Solrを使ったレシピ検索のプロトタイピング

クックパッド株式会社からは、レシピ検索担当の兼山さんより、実際にクックパッドで利用されているSolrを使ったレシピ検索のプロトタイピングについてお話し頂きました。

クックパッドでは、開発サイクルとして、まず細かいプロトタイプを作成し、本番環境へデプロイし、ユーザの反応を見て展開を検討します。このためにRailsのchankoライブラリを開発。複数の環境をデプロイする仕組みを構築し、数十バージョンの本番を平行で展開したり、ABテストなどにも活用するなどの恩恵を受ける事ができるようになりました。

一見、本番環境でプロトタイプというと、エンドユーザを使ってデバッグしているイメージを受けるかもしれませんが、この場合はどれも真剣勝負の本番環境で、インターフェースやデータ抽出方法などの最適など、ユーザの反応が必要な部分を中心にプロトタイプ展開しているイメージでした。

検索システムに関しては、MySQL（Tritonn⁠）⁠→Solrに全面移行したそうです。Apache＋Javaの環境があれば手軽にSolrを利用する事が可能とはいえ、MySQLからの移行は大規模なソースコードの修正を必要とし、その点では苦労されたとのことでした。

従来利用していたTritonnで抱えていた問題は以下になります。（⁠スライドより）

• パフォーマンス悪い
• フィールド追加が辛い
• レプリがステートメントベース（本番でテーブル定義を変えにくい）

Solrへの移行メリットは以下の点です。

• パフォーマンス良い
• フィールド追加が簡単
• レプリ→ファイルベース（本番でテーブル定義を変えやすい）

このように移行前の問題点をほぼ改善したので、プロトタイピングがしやすい環境を構築する目的を達成できたとのことでした。

その他、HTTPを利用するため並列化のメリットなどがある反面、JavaベースのためGC実行時にロックがかかる場合があるなど、いくつか問題点もあるとのことでしたが、varnishなどを前段に置きキャッシュさせるなど、より安全に運用するべく施策を検証しているとのことでした。

その他にもいろいろとお話しいただきました。当日のスライドは以下に提供いただいています。

Solrを使ったレシピ検索のプロトタイピング

URL：http://d.hatena.ne.jp/code46/20120127/p1

まとめと次回予告

今回、非常に有名なサイトで実際に利用されている検索が、どのようなコンセプトで何を使って実装されているか、実際に開発に携わる方々にお話しいただくことができ、非常に有意義な時間だったかと思います。また、ふだんプロダクト別に開催される事が多い印象のあった検索系の勉強会ですが、開発者、ユーザ、プロダクト関係なく一同にお話しいただく機会を開催する事ができて、本当に良かったと思っています。

次回は、『⁠「⁠ネイティブアプリケーション」vs「Webアプリケーション⁠」⁠』と題しまして、開発手法、技術、デザインなどさまざまな観点からお話できる会を予定しておりますので、ぜひとも参加いただければと思います。