RoomClip 開発者ブログ

RoomClipのSolr構成について

こんにちわ、エンジニアの熊谷です。

今回は、RoomClipの検索エンジンで用いているSolrの運用・構成ついて書いてみます。

まずはじめに、

ひとえにSolr構成といっても、組織・サービス規模や要件によって構成が変わると思いますので、対象を以下のように絞りたいと思います。

「小〜中規模のサービスを運用している、少人数のインフラチームで、安定的かつ柔軟なSolr基盤を、簡単に構築したい方」

となります。

また、 「安定的かつ柔軟」についても、もう少し掘り下げておきたいと思います。非機能要件の中で、Solrの特性を考慮した上で、大きく三つに分けて考えたいと思います。

  1. 可用性: Solrインデックスのバックアップや冗長構成。また障害時の復旧方法について。この辺は、体系化されたRDBに比べ、Solr導入時はわりと戸惑うように思います。
  2. 性能・拡張性: Solrの負荷増大時のスケールアウトやスペック増強、またSolrのアップグレードのしやすさも含みます。
  3. 運用・保守性: スキーマー変更やシノニム・辞書の更新。インデックス追加・更新・削除やリインデックスのしやすさについて。実際に、Solrを導入して検索精度を上げようと思うと、試行錯誤を繰り返すことになるため、スキーマー変更やリインデックスが簡単にできる構成が望ましいかと思います。

ついでに、 「少人数のインフラチームで、〜簡単に構築」ともありますが、ここに関しても、もう少し具体的に対象エンジニアを述べると、

上司・クライアントから 「今、運営しているサービスの検索(orレコメンド orランキング)が全然いけてないから、新たにSolr導入して実装しなおしてみてよ。あ、でもSolrの専任は置けないから片手間でね。あ、あと絶対に落ちないような感じにね。」とさらりと言われたエンジニア、となります。

※注1. 勝手な妄想であり、RoomClipではそんな風には言われません。

まぁ要は、

「人的資源を節約しつつ、簡易的に可用性・冗長性を実現したい。」

ということになります。

さて、目指すべきSolr構成がぼんやりと見えてきたところで(?)、それらをどのように実現するかと考えたいと思います。

おそらく、実現方法として、SolrCloudとAWS CloudSearchが、有力候補として上がってくると思います。が、弊社では採用しませんでした。理由ついては、さらりと流します・・。

  • SolrCloud: 実際に本番で運用するには、(当たり前だけど)、SolrCloudやZooKeeperの学習コストが必要な上に、追加でZooKeeperの運用・保守も発生するため、インデックスがクラスタリングしなければならないような規模でないかぎりは、冗長構成として少々ファットで高コスト(な印象)。人と時間を費やせば、フルマネジメントに近い構成は構築できると思うが、今の要件やリソースを踏まえると、現段階では適切ではないと判断。
  • AWS CloudSearch: フルマネジメントは魅力的だけど、機能が限定的でフィールドタイプやトークナイザーなども限られ、どこまで互換があるのかもわかりづらく、新機能のキャッチアップもできない、など諸々の理由で不採用。    

では、RoomClipではどのようなSolr構成にしているか。

先に結論を述べてしまうと、非常にシンプルで、

「Solr DIH(Data Import Handler」+ AWS AutoScaling + GitHub 」

となります。

以下、要点だけかいつまみたいと思います。

1. Solr DIH(Data Import Hander)

SolrにはRDSと連携できるDIHという機能が備わっているので、データの永続性の責務は、Solrではなく、MySQLに任せてしまいました。バックアップやリカバリのことも考えると、Solrにデータの永続性を担保させるのは厳しいなという判断でした。

DIHには、RDSのテーブルの内容を丸ごとインポートする「フルインポート」と、差分だけインポートする「デルタインポート」があるので、インスタンス生成時にフルインポートして、その後の追加・更新・削除分は、デルタインポートで対応するといったことができます。

また、デルタインポートとソフトコミットを組み合わせることで、RDSのテーブルデータとほぼリアルタイム(完全には無理)に近い形で同期することもできます。

Screen Shot 2017-06-27 at 9.54.47.png

2. GitHub連携

Solrの検索精度向上のために試行錯誤する過程で、スキーマーファイルや辞書・シノニムファイル、またDIH設定ファイルなどを度々変更することになるため、よくあるWebアプリケーションのデプロイ構成を参考にしつつ、自動化しています。

注意点として、Solrの場合は、変更箇所によっては、インデックスを作り直す必要があるため、リインデックスする仕組みも組み込んでおくと後々楽です。

実際は、Solrにはリインデックスするための機能はないため、新しくコアを作成して古いコアと入れ替えるという方法をとっています。コアの入れ替えには、SolrのCoreAdminにあるSWAP機能を使うことで、リクエストを止める事なく、ダウンタイム0での入れ替えが可能です。

Screen Shot 2017-06-27 at 9.54.47.png

3 AWS ALB

現在、RoomClipではSolrコアが写真検索用、アイテム検索用など4種類あり、それぞれ負荷に偏りがあるのですが、ALB配下に置いておくことで、簡単に分散することもできます。

Screen Shot 2017-06-27 at 9.55.35.png

4. Redash & Redshift (番外編)

本題とは外れますが、 ログの格納にはRedshift、可視化にはRedashを使っています。

Screen Shot 2017-06-27 at 9.56.16.png

ということで、 ざっくりですが、RoomClipのSolr構成の紹介でした。

すでにAWSを利用している方であれば、比較的簡単に構築できるかと思います。

特に、Solr+EC2だけの単体構成で運用している場合では、なにかと余計な作業が発生しがちだと思いますので、先に基盤を構築しておいて、クエリやスキーマーの調整に集中できる環境を整えておく事で、結果的に、サービス改善が迅速に進むのではと思います。

次回は、Solrのクエリまわりについて書けたらなと思います。

それではごきげんよう。


この記事を書いた人:rkumagai

熊です。RoomClipのインフラ〜サーバーサイドを担当しています。


あるエンジニアと勉強会、そして DroidKaigi

鷲田と言います。業務では RoomClip の Android 版の開発をするほか、時々 iOS 版を開発したりバックエンド側の開発に関する支援を行なっていたりします。

先日、DroidKaigi 2017 というエンジニア向けのカンファレンスがあり、そこでスタッフをやってきました。今年は公式サイトのメンテや司会をしたりしました。

ちなみに、DroidKaigi と前日準備と合わせて三日間業務扱いでした。 \(^o^)/ 重要なことなので言っておきたかった。

過去に参加した勉強会を振り返ってみる

本当は DroidKaigi の感想などを書こうかと思っていたのですが、すでにスタッフを含め色々な人によって良い記事が書かれています。なので今回の DroidKaigi の話は他の方に譲り、この記事ではエンジニアとしての今の自分に大きく影響を与えた勉強会について振り返ろうかと思います。

JavaOne Tokyo 2005

エンジニア向けの勉強会に初めて参加したのは、JavaOne Tokyo 2005 というサン・マイクロシステムズ主催のカンファレンスでした。その時は大学でバイトをしていて、その繋がりで JavaOne Tokyo に行きたい人の募集があったので参加しました。

実は当時は Cocoa 大好き Objective-C 大好きな Mac ユーザーで、Java というとネガティブなイメージを持っていました。それなのになぜ行ったかというと、「タダ飯が食べられる」「そもそも当時勉強会イベントがほとんどなかった」という事情がありました。

そんな軽い理由で参加したのですが、思いの外面白かったです。

当時印象的だったのは Sun のエンジニアによる Beans Binding という技術の発表でした。今の Android でいうと DataBinding のような、要するに「View と Model を綺麗に分離するためのオブザーバー機能」なのですが、これが Cocoa Binding という Cocoa の機能に近く、当時この種の機能に熱狂していた僕は同等の機能を見て「Java 思ったより頑張ってるな!」と思いました1

その他、レセプションでタダで夕飯を食べられたり本社の方と話ができたり iPod Shuffle が抽選で当たったりと…。色々と楽しくて、結果として Java に対する抵抗感が金による買収により消えていました。

JavaOne Tokyo 2005a JavaOne Tokyo 2005b
当時の JavaOne Tokyo の画像を探してきました。ちょっと画質が悪い

WWDC 2006, 2007

学生の頃は WWDC にも行きました。

WWDC 2006 WWDC 2006
昔の画像を探してきました。

WWDC は参加費が 10 万円程度かかる上にサンフランシスコまで行かないといけないのですが、学生向けに Scholarship というのがあり無料で参加する事ができました(旅費は有料)。当時は iOS アプリの開発ができるようになる前で、Apple の開発環境に興味がある開発者は今と比べると少ししかいませんでした。そういった事情で倍率も低かったためか、2 年連続で参加できました。

WWDC にも非常に刺激を受けました。参加した時は「WWDC なんて基調講演で新しい事がほとんど語られてしまっているんじゃないか」と思っていたのですが全くそんな事はなくて、技術的に新しい事や面白い事はむしろセッションの中で発表されていました。

また Apple のエンジニアと直接話せたり実際に開発をしているエンジニアと話ができたりと、学生の身分にとっては勉強になる時間でした。同じく学生で WWDC に参加した ninjinkun と知り合ったりもしました。

あと、他の参加者とカニを食べたりステーキを食べたりしてとても楽しかったです。

WWDC 2006 WWDC 2006
WWDC では毎年アーティストを呼んでライブをやっています。カニはWWDCでは提供されません。

読書会

WWDC に行った何年か後に社会人になったのですが、社会人なりたての頃は日本にはスポンサーが付くような大きなイベントは少なく、個人で開催する小規模な勉強会が多かったように思います。もう少し深く話ができる勉強会に参加したいと思い、カンファレンスよりも読書会に参加していました。

参加した読書会はProgramming with Quartz や Growing Object-Oriented Software Guided by Tests (実戦テスト駆動開発)といった比較的難しい本を題材にしていたものが多かった中、読書のモチベーションを維持する助けになったように思います(とはいえ終盤は脱落してました)。

また読書会は一人で読むのに比べ、エンジニアの先輩方による本の内容に対する考えや温度感といった事がわかるのが大きかったように思います。

そのあと社内やプライベートで読書会を開催もしたりしました(認識を合わせて議論したりするのがまた面白いと思うのですが、この話はまたの機会に…)。

DroidKaigi 2015 に参加

社会人になってからはずっと Web エンジニアをやっていたのですが、色々あって 2015 年あたりから Android や iOS のネイティブアプリの開発を始める事になりました。

そんな中、WWDC で知り合った ninjinkun が DroidKaigi で発表するというので、見に行く目的もあって DroidKaigi 2015 に参加しました。

当時は自分の周りにアプリエンジニアがとても少なく、Android の事はとりあえずコードを書くために必要な事しか知らないような状態だったのですが、Android のSDKにある色々な機能や流行りのライブラリなど、色々と新しい知識が得られました。

そして何よりも、「Android エンジニアコミュニティは思ったよりずっと活発だな!」という事がわかりました。若干浦島太郎感…。

ちなみに DroidKaigi はランチやアフターパーティーの料理がいつも豪華です(と思います)。

DroidKaigi 2016、2017 にスタッフとして参加

DroidKaigi 2016 の寿司 DroidKaigi 2017 の弁当
DroidKaigi の写真を探したのですが、食べ物の写真しかありませんでした。なお DroidKaigi 2017 に関しては後日公式から写真が公開されると思います。

DroidKaigi が終わってからしばらく後に、ninjinkun が次の DroidKaigi のスタッフ募集のツイートをしていて、それに応募しました。この頃は現状に退屈さを感じていて、もうちょっと変わった事をしたいと思っていました(ちなみにこの時期に前の会社から Tunnel に転職していたりします)。

イベント運営はもちろんやった事がなかったですし、Android アプリの開発はしていたものの Android コミュニティや他のエンジニアがどういった人達なのかもあまりよく知りませんでした。

運営を通じて Android 界隈のいろんなエンジニアと知り合いになれましたし(ちなみに DroidKaigi のスタッフに関しては全般的に優秀な人ばかりだなあというのが一番の印象です)、代表の日高さんはじめ色んな活動をやっている人がいて刺激を受けました。

来年は発表とかしたいですね。

勉強会が良かった事

これだけだと単なる思い出話なので、勉強会に参加してよかった事を振り返ってみたいと思います。勉強会に参加すると以下のような良い事があったと思います。

刺激を受け、選択肢が広がる

DroidKaigi を「知見の激流」という表現をしていた方がいましたが、これは本当にそうだと思います。勉強会には様々な人の知見が熱量とともに集まります。これは DroidKaigi や WWDC のような大きなイベントはもちろん、もっと小規模な勉強会でも本当に刺激を受けますし、それによって選択肢が広がったりもすると思います。

人との繋がり

WWDC で出会った ninjinkun 経由で DroidKaigi のスタッフになったように、縁で色々と選択肢が広がったりしました。実は Tunnel に入社したのは勉強会がきっかけだったりします。

勉強になる

他の人の知見によって本やインターネットとは違った質の理解が得られると思います。特に経験の浅い頃や慣れないプラットフォームを勉強する場合、チュートリアルやリファレンス的な情報だけでは得られない実践的な情報や、情報の集め方などのとっかかりのための知識を得られる事が多いです。

タダ飯

まとめ

JavaOne Tokyo 2005 で「これからは参加の時代」という話がありました。 その時から 10 年以上経っていますが、IT 業界では当時よりもずっとコミュニティが多様化し、参加が身近になり、また参加する事のメリットも増えてきていると思います。コミュニティには参加が難しいものも簡単なものもありますが、エンジニアは手頃な所から勇気を出して参加をしていくと、数年後はきっとより面白い事になっているんじゃないかと思います。


  1. 残念ながら現在はメンテナンスされていないようです。 ↩︎


この記事を書いた人:鷲田

Tunnel株式会社のアプリケーションエンジニア。よくうどんを食べている。