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

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

まずはじめに、

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

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

となります。

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

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

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

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

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

まぁ要は、

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

ということになります。