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のインフラ〜サーバーサイドを担当しています。