検索エンジンチームの加藤宏脩です。 今回は、LIFULLの検索エンジンであるSolrのバージョンアップについて紹介します。
Solrを含むミドルウェアの最新バージョンへのアップデートには多くの工夫と努力が必要です。 この記事では、私たちがLIFULL HOME`Sを支える物件検索エンジンのバージョンアップにどのように取り組んでいるのか、またv9.2.1へのバージョンアップ対応の詳細ついて紹介します
課題: Solrバージョンアップ移行時の課題
Solrのアップデートは単純な作業ではありません。 特に、古いバージョンからの大きなジャンプでは、多くの非互換性や変更点が存在します。以下は、私たちが移行時に遭遇した主要な課題です。
非互換性の問題: 既存の機能や設定が新バージョンで動作しない可能性。
テスト環境の構築: 新バージョンの動作確認に必要なテスト環境のセットアップ。
既存のカスタム機能の移行: LIFULL独自のカスタム機能を新バージョンに適応させる。
パフォーマンスの違い: 新旧バージョンの間でのパフォーマンス差。
新機能の取り込み: どの新機能を採用し、どう利用するかの判断。
影響が不明: 自社で利用している機能が把握できず、影響があるのかが分からない。
継続的にバージョンアップするために普段行っていること
LIFULLでのSolr運用は日々の変更調査から始まります。
日々の変更調査
SolrやLuceneの変更内容を追跡し仕様変更や非推奨・廃止機能の調査します。
LIFULLの利用環境への影響を調査します。
調査結果をスプレッドシートにまとめます。
バージョンアップをブロックする可能性があれば、はやめにコミットします。
バージョン毎の調査
新バージョンのリリース毎に変更内容を確認し、動作確認を行います。 LIFULLの検証手順で動作確認をします。 テスト結果や修正項目、留意点をまとめます。
バージョンの選定
変更が多くなると作業量が増えるため、こまめにバージョンアップをします メジャーバージョンアップ等変更が多い場合は、 その一つ前のバージョンに上げるなどして、一つあたりのバージョンアップの作業量を減らすようにします。
バージョンアッププロジェクトで行うことについて
バージョンアップは以下のような手順で進められます。
バージョンアッププロジェクトの開始
日々の調査やバージョンの調査結果をもとに、対応内容を確認。 調査計画、デプロイ計画、テスト計画を作成。 システム変更タスクの消化: 新バージョンに対応するための変更タスクを実施。
検証
LIFULLでは、物件検索エンジンの比較、検証用にテストを用意しています。
これがあることにより、
頻繁に物件データの更新がある環境で、データをそろえた２つの環境を用意したり
任意の量のクエリを抽出して性能や結果を比較するような手間のかかるタスクが簡単に行えるようになっています。
性能テスト
実際に本番環境で投げられているクエリを用意して、 新旧バージョンのクラスタにクエリを投げて、そのレスポンス速度を比較します。
回帰テスト
実際に本番環境で投げられているクエリをサンプリングして、 新旧バージョンのクラスタにクエリを投げて、レスポンスの差分を比較します。
データの差分確認テスト
新旧バージョンのクラスタに同じデータを投入して、 全件の出力を比較します。
混沌テスト（カオスエンジニアリング的な観点から行われるテストを略して混沌テストと呼んでいます）
SolrのLeaderがfailoverして切り替わるのを確認します。
Zookeeperを落としてクラスタにクエリを投げて、そのレスポンスを確認します。
SolrのインスタンスにOOMを起こさせて、意図した挙動をするのかを確認します
OOMは、自社で作ったOOMを起こさせるプラグインを導入してテストしています。
ディスクの使用量テスト
Zookeeper、Solrのインスタンスのディスク使用量が新旧で大きく違っていないかを確認します。 Solrの台数を増減させてリクエストを受け付け続けられるかを確認します。
ログ出力テスト
サーバー内のログにエラーやワーニングがないかを確認します。 cloudwatch logsに送信できているかを確認します。
デプロイ
問題がなければ、本番環境にデプロイ。
バージョンアップの運用をしたメリット
バージョンアップを始めるときのハードルが低くなる
バージョンアップが始まった段階で、変更内容やプロジェクトの手順など必要なタスクが分かります。
バージョンアップのPJのテンプレート化をしているので、PJの進め方も分かります。
共通のテスト手順が決まっているので、テストの手順を考える必要がなくなります。(変更内容を見て別途テストの設計はします)
知識が増える
変更調査を毎日やっているため、 メンバーが徐々にSolrの仕様変更に詳しくなります。
気になることをSlackでつぶやくと、誰かが知っているということが何度かありました。
リリースの安心感
検証は、過去の障害事例を元にしたテストも含んでおり
そのテストがパスしている状態でのリリースには安心感があります。
Solr v9.2.1へのバージョンアップについて
v9.2.1を選んだ理由。
当時最新のSolrバージョンであったことと、v9.x以降ベクトルが利用できるようになるため
v9.2.1へのバージョンアップを行いました。
v8.x系の最新バージョンへの変更も考えましたが、
v9.2.1の検証もできており問題ないと判断したため、v9.2.1へのバージョンアップを行うことにしました。
Solrの変更について
調査や検証をする中で、いくつか問題や気を付けることがあったため
その点についての紹介をさせていただきます。
※具体的な変更については、Solrの公式の変更点を参照してください。 https://solr.apache.org/guide/solr/latest/upgrade-notes/major-changes-in-solr-9.html
- experimentalなAPIの機能廃止
- zookeeperがlog4jを廃止して、logbackを使うようになりました
- logの出力先が変わるため、awslogsなどログの収集元を変更する必要があります。
- FastLRUCache廃止に伴いCaffeineCacheへ変更
- SolrのbooleanClausesの設定を参照する箇所の変更
- 節の長さが設定値を超えるようになり、バージョンアップ前まで成功してたクエリが失敗するようになるということが起きます
- LegacyBM25SimilarityFactoryの廃止に伴いBM25SimilarityFactoryへの変更
- フリーワード検索による類似スコアでのブースト計算が変わりソートのための重みが下がります
- 類似度によるスコアの開きが少なくなるので、fqなど他の条件でのスコア計算の影響を受けやすくなります
バージョンアップの効果
高速化
レスポンス速度が向上。 LIFULLの環境では、p99が大幅に改善しました。
CPU使用率の低下
CPU使用率が低下して、さばけるクエリ数が増えたので インスタンス数を3~40%ほど減らせました。 Solr v9というより、Javaのバージョンアップによる影響が大きかったのもあるかもしれません。
新機能の活用
新バージョンに含まれるベクトルを使った検証ができるようになりました。
まとめ
今回は、LIFULLが行っているSolrを継続的にバージョンアップする仕組みと、Solr v9.2.1へのバージョンアップについて紹介しました。 少ない工数かつ、比較的安全にバージョンアップできるようになりました。 また、最新のSolrにバージョンアップしたことで、新機能の活用やパフォーマンスの向上やコストカットなどのメリットも得られました。
ミドルウェアのバージョンアップは疎かにしがちですが、 LIFULLでは上記のような運用を行うことで、物件検索エンジンのSolrを最新バージョンに追随しています。
最後に、 このような効率化をしたいまたは得意なエンジニアの方々、 LIFULL では一緒に働く仲間を募集しています。この記事を読んで LIFULL に興味ができた方は求人情報も御覧ください。
