LIFULL HOME'SでのSolrの構成と運用の変遷

2021.11.30 第26回 Lucene/Solr勉強会 #SolrJP LIFULL HOME’Sでの Solrの構成と運用の変遷 株式会社LIFULL テクノロジー本部 プラットフォームグループ 磯野 圭輔 ©

1. 自己紹介・会社紹介 2. Solrの構成の変遷とバージョンアップ 目次 3. バージョンアップで気をつけたいところ 4. バージョンアップをしてきてどうだったか

自己紹介 自己紹介 磯野 圭輔 ikeisuke ソフトウェアエンジニア・エンジニアリングマネージャー at LIFULL Webサービス開発におけるインフラからサーバーサイドの構築がメインフィールド ここ数年はLIFULL HOME‘SのSolrの運用改善を担当し、情報検索や自然言語処理などについては勉強中

会社データ (2021年9月30日現在) 会社名 証券コード 代表者 沿革 株式会社LIFULL 2120（東証第一部） 代表取締役社長 井上 高志 1997年3月12日 設立 2006年10月 東証マザーズ上場 2010年3月 東証一部へ市場変更 資本金 連結従業員数 主な子会社 ( )は 議決権比率 9,716百万円 1,483名 （内、臨時雇用者数183名、海外子会社354名） LIFULL CONNECT,S.L.U. (100％） 株式会社LIFULL Marketing Partners（100％)

コーポレートメッセージ 自分らしく生きられる社会

解決すべき社会課題「住まい領域」 日本最大級の不動産・住宅情報サービス https://www.homes.co.jp/

• https://www.homes.co.jp/

本日の概要

本日の概要 本日の概要 Solrが稼働しているだけだったところから、運用を整理し、機能開発など に着手できるようになるまでに取り組んできたこと、特にバージョンアッ プ周りについてのまとめと課題について紹介させていただきます。 1. Solrの運用の変遷とバージョンアップ 2. バージョンアップで気をつけたいところ 3. バージョンアップしてきてどうだったか

Solrの構成の変遷

Solr構成の変遷 当時の構成 AWS Cloud Auto Scaling group Availability Zone 1 SPOF replication post batch solr master node replication solr repeater node solr slave node Availability Zone 2 replication solr repeater node Application Load Balancer solr slave node

Solr構成の変遷 当時の構成 AWS Cloud Auto Scaling group Availability Zone 1 SPOF replication post batch solr master node replication solr repeater node solr slave node 1-2時間に１回程度の Optimize処理 Availability Zone 2 replication solr repeater node Application Load Balancer solr slave node

Solr構成の変遷 当時の構成 AWS Cloud Auto Scaling group Availability Zone 1 Optimize後の レプリケーション SPOF replication post batch solr master node replication solr repeater node solr slave node Availability Zone 2 replication solr repeater node Application Load Balancer solr slave node

Solr構成の変遷 当時の構成 AWS Cloud Auto Scaling group Availability Zone 1 SPOF replication post batch solr master node replication solr repeater node solr slave node レプリケーション 高速化のための リピーター Availability Zone 2 replication solr repeater node Application Load Balancer solr slave node

Solr構成の変遷 当時の構成 AWS Cloud Auto Scaling group Optimize後の レプリケーション Availability Zone 1 SPOF replication post batch solr master node １時間に１回程度の Optimize処理 replication solr repeater node solr slave node レプリケーション 高速化のための リピーター Availability Zone 2 replication solr repeater node Application Load Balancer solr slave node

Solr構成の変遷 何故Solrの構成をアップデートしたか • 設定変更などほぼ全て手動でのオペレーションであり、サーバーも1系統しかなく失敗したら大惨事という状況 • 構築当初サーバーの構成管理においてバージョン管理が徹底されておらず、稼働しているサーバーが正の状態だ った • 機能拡張を対応するスキームがなく、機能追加をしたいチームのメンバーがインフラ担当と相談しながら個別に 対応していた • • 単純にフィールドを追加したいだけのためにデータの反映が終わるまで1ー2週間待つ必要がある Solr4(nightly build)が稼働しており古すぎるだけでなく、正式版との乖離がどこまであるのか把握できていなか った • master-slave構成でmasterノードがSPOFとなっており大きな問題が起きた際に復旧できない、もしくは復旧に数 日かかることが予想される¥ • 今後のサービス・データ量拡大を考慮してシャーディングも視野に入れた構成にしていきたかった

Solr構成の変遷 何故Solrの構成をアップデートしたか 何をするにしても 心理的コスト、対応コストが 大きすぎて誰も変更したくない状態を 解消する

Solr構成の変遷 何故Solrの構成をアップデートしたか LIFULL HOME’Sが掲げる 「"あなたにピッタリ"の住まい探し」を 提供していくためにも検索エンジンを もっと積極的に活用できるようにする

Solr構成の変遷 どうしたか 1. デプロイのたびに新たに作るImmutable Infrastructureな構成に変更 • その際にシャーディングを見据えてSolrCloudを導入 2. できる限りの構成をコード化し自動でデプロイされる仕組みの構築 3. 継続的に最新バージョンを適用するためのバージョンアップ運用体制 の構築 4. 専任チームによる相談受付、一緒にプロジェクトを進める体制

①Immutable Infrastructure

Solr構成の変遷 現在の構成 AWS Cloud event ( put / delete ) Amazon SNS Amazon S3 data bucket uploader 物件検索システム – Immutable構成な範囲 SolrCloud Cluster Amazon SQS replication 初回ロード tlog - leader pull - replica update AWS Lambda Auto Scaling group Application Load Balancer tlog - replica zookeeper select Application Load Balancer

Immutable Infrastructure 物件検索システム – Immutable構成な範囲 リソース 説明 SQS S3の更新・削除通知を受け取る AWS Lambda SQSをイベントソースとしてS3のデータを Solrに書き込む ALB/Solr(tlogノード x2) AWS Lambdaからの書き込み処理を受け付け ALB/AutoScaling/Solr( 検索リクエストの受け付け pullノード) Zookeeper SolrCloudクラスタの管理

Immutable Infrastructure この構成により解決したこと • • SPOFだったmasterノードではなくSolrCloudのtlogノードを複数置くことで書き込み側の可用性を向上した • tlogノードを増やすごとに書き込み性能が劣化するため現在はtlogを2台で稼働中 • データの特性とこれまでの安定性、後述のデプロイを考慮して1台でいいのでは？と考えている SNS – SQSを利用したファンアウトと初回ロード処理を利用することによりクラスタを同時に複数構築すること ができるようになった • Solrのバージョンやスキーマなどの違う複数のクラスタを立て比較することが容易になった • 初回ロードに時間がかかることが課題 • ほぼ全てを作るので構築したクラスタ分のコストがかかることも課題

Immutable Infrastructure 構成変更・バージョンアップの副次的効果 • リピーターインスタンスなしでも遅延なくレプリケーションできるようになった • 当時はoptimize後にレプリケーションするように設定していたので全インデックス（数十GB） の転送に時間がかかっていた。（slaveの台数分ほぼ同時に転送） • インデックス効率の向上によりインデックスサイズは25%程度減った（と記憶している） • マージスケジューラーによるマージでの運用に変えたため差分のみ転送されることになり、一 度に行われる転送データが減った • Optimizeしない状態＆短期間でsearcherが入れ替わる状態でも同等程度の性能が出るようになった • Solr7からSolr8に上げた際にも性能改善が見られたので、都度の検証は必要だが定期的なアップ デートを視野に入れた運用体制を構築しておくことのポジティブな理由になり得る

デプロイ方法 blue-green deployment

Solrクラスタのデプロイ 毎回新規デプロイするImmutableな範囲 物件検索システム – Immutable構成な範囲 SolrCloud Cluster Amazon SQS replication 初回ロード update Auto Scaling group tlog - leader pull - replica AWS Lambda Application Load Balancer tlog - replica zookeeper 1.Solrクラスタを構築 2.データ投入用リソース（SQS/Lambdaの構築） 3.初回データロード処理により全データ投入 4.更新データ投入開始 Solrクラスタの デプロイ単位

Solrクラスタのデプロイ デプロイの手順1 – デプロイ前 AWS Cloud event ( put / delete ) Amazon SNS Amazon S3 data bucket uploader 旧クラスタ （稼働中） select Application Load Balancer

Solrクラスタのデプロイ デプロイの手順2 – デプロイ開始 AWS Cloud event ( put / delete ) Amazon SNS Amazon S3 data bucket uploader 旧クラスタ （稼働中） select Application Load Balancer 新クラスタ （構築中）

Solrクラスタのデプロイ デプロイの手順3 – リクエストの切り替え AWS Cloud event ( put / delete ) Amazon SNS Amazon S3 data bucket uploader 旧クラスタ （稼働中） select Application Load Balancer 新クラスタ （稼働中）

Solrクラスタのデプロイ デプロイの手順4 – 古いクラスタの削除 AWS Cloud event ( put / delete ) Amazon SNS Amazon S3 data bucket uploader 旧クラスタ （削除） select Application Load Balancer 新クラスタ （稼働中）

Solrクラスタのデプロイ デプロイ（blue-green deployment） 運用上現実的な時間でサーバー構築、データの投入ができるようにしたことでbluegreen deploymentを実現できた • 1回のデプロイでImmutable構成の範囲を全てデプロイする • デプロイ時は初回ロードを行うので全てのデータが反映されている状態になる • デプロイ完了後ロードバランサの向き先を旧クラスタから新クラスタに切り替える • 切り替えが完了し、正常動作を確認したら旧クラスタは全て削除する

Solrクラスタのデプロイ この構成の課題 • 新規に全て構築しデータ投入するため、運用上現実的な時間とはいえ通常のアプリケ ーションに比べて構築に多少の時間がかかる • 複数の構成が立ち上がるため、一時的ではあるが構成の維持コストがかかる

Solrクラスタのデプロイ この構成により解決したこと • 稼働系を危険に晒すようなことなく安全に新しい設定を適用可能になった • 切り替え後に問題があった場合でも問題があった際にロードバランサの向き先を変え るだけで切り戻しが完了できるため、さらにリスクは少ない • インフラ構成から設定に至るまでバージョン管理されていることで特定バージョンへ の切り戻しや微調整しての再デプロイが容易 • 古いクラスタ削除後に戻したい場合であっても、元の設定で再度デプロイして切り替 えるだけのため、デプロイの手順をそのまま利用できる

継続的なバージョンアップ運用

継続的なバージョンアップ運用 継続的なバージョンアップのために Solr 4(nightly build)を長期間運用し続けた結果、大きな技術的負債として抱えてしま った反省を生かし、継続的に新しいバージョンを適用していくための運用体制を構築し た。 大きく分けて3つの対応をしている。 1. 平日のLucene/Solrの更新情報の確認 2. マイナーバージョンリリースごとの動作確認 3. 動作確認後のデプロイ判断とデプロイ

継続的なバージョンアップ運用 平日のLucene/Solrの更新情報の確認 毎朝9時に検知したLucene/Solrの差分チェックを行 なっている。 仕様変更と非推奨になった機能を主な監視対象とし ている。 現在5人チームなので曜日毎に担当を決めて、 GitHub ActionsでGitHub issueとして自動登録して いる。

Solrクラスタのデプロイ マイナーバージョンアップ毎の動作確認 AWS Cloud event ( put / delete ) Amazon SNS Amazon S3 data bucket uploader Amazon CloudWatch Amazon S3 result bucket Amazon Athena 確認済み バージョン クラスタ Logs production solr.log Application Load Balancer 最新バージョン クラスタ Vegeta on AWS Fargate

継続的なバージョンアップ運用 マイナーバージョンアップ毎の動作確認 Fargate上にデプロイしたvegetaを利用して2つのクラスタにほぼ同時に指定のスループットで前日の本 番のクエリを投げてパフォーマンスのテストを行う。リクエストの結果CloudWatchに記録されたレスポ ンスなどのメトリクスと、vegetaがS3に出力した結果ファイルを参照したAmazon Athenaを利用して問 題ないかを判断している。

継続的なバージョンアップ運用 マイナーバージョンアップ毎の動作確認 パフォーマンスの確認以外にも以下の観点で新旧クラスタを比較している • SolrのログとCloudWatchを利用した書き込み性能の比較 • 実際のクエリログをパターン毎に抽出して同一のレスポンスが返却され るかの確認 • 登録されているレコード数、レコード内容の同一性確認 • Zookeeper停止時の検索機能の継続稼働確認

継続的なバージョンアップ運用 動作確認後のデプロイ判断 検証結果は右の図のようにまとめており、検証済み のバージョンは必要に応じてリリースできるように している。 （リリース前に同様の内容で再テストを行う） 次のリリースは8.11.x（8.11.0がまだ未検証）もし くは9.1以降で検討中

サービスで活用してもらうために

サービスで活用してもらうために 活用できている状態にするために SolrはRDBやKVSのようなよく使われるデータストアとは構成が違うため、各自でがん ばってもっと活用しようという話をしてもうまくいかない。 サイト側で検索エンジンが必要な案件に対して検索エンジンチームの担当をアサインし て一緒に実現に向けて進めるようにしている。 1. 案件ごとにヒアリングしてどのように実現するのか、分担はどのようにするのかを 個別に決定している 2. 新しい処理の負荷検証というような軽い話であれば、デプロイの仕組みを使うこと で必要に応じて専用の環境を提供して検証してもらっている

バージョンアップで 気をつけたいところ

バージョンアップで気をつけたいとこと 本番環境を数時間停止させた大障害 新しい healthcheck endpoint（Solr8）の取り扱いについて PingRequestHandler HealthCheckHandler 対応バー ジョン 全て 8以降 (SolrCloud) 用途 ロードバランサのヘルスチェック用 特定ノードが正常かどうかを確認する （＝特定ノードが正常に起動しているかどうかの 確認用途） 動作 対象のcollectionが利用可能になったら • 指定のcollectionで検索できること ノードが正常かどうか • Coreがアクティブなこと • Zookeeperと接続されていること • live_nodesに登録されていること • [OPTION] ローカルCoreがアクティブなこと • リクエスト転送されるのでレプリケーション終 わっていなくてもHealthになる • [OPTION] healthcheckFileがあること 8にバージョンアップした際にローカルCoreがアクティブなことをチェックしたい要件があり、あまり細 かく考えずエンドポイントを切り替えてしまった

バージョンアップで気をつけたいとこと 本番環境を数時間停止させた大障害 時系列 アラート 内容 障害半年以上 前 - Solr 8.6.xへのアップデート ALBのヘルスチェックエンドポイントの差し替え（全停止の根本原因） 障害２週間程 度前 - Solr 8.8.xへのアップデート Zookeeperのディスクフル要因の変更リリース（全停止の起因埋め込み） 00:00:00 - ディスクフルによるZookeeperの停止 00:00:00 書き込みエラー検知 書き込み処理停止 00:01:00 検索用インスタンス 台数減少検知 ヘルスチェックエラーによる検索用インスタンスの停止 00:10:00 検索用インスタンス 全台起動不可 ヘルスチェックエラーによって全ての検索用インスタンスが停止 Zookeeperが動作しておらず、Solrが起動できずサービス完全停止 03:00:00 - 新規クラスタ構築完了しサービス正常化完了 04:00:00 - Zookeeperの復旧が完了し旧クラスタも正常動作確認

バージョンアップで気をつけたいとこと 本番環境を数時間停止させた大障害の原因と対応 Zookeeperの管理が雑だったことに尽きる 1. 全台停止した原因はディスクフルだったため、監視とストレージの分割 を追加 2. Zookeeperを全台停止してもヘルスチェックは成功し、検索はし続けら れることを確認するテストを追加 • SolrCloud導入の際は確認していたがヘルスチェックの変更時に確認が漏れていた 3. リリース時のサーバーのログにエラーが記載されていないことのテスト の厳密化

バージョンアップで気をつけたいとこと バージョンアップでつらかった仕様変更 ネガティブブーストの廃止（Solr7→Solr8) Lucene８においてマイナスの重み付けができなくなる変更があった。 特定の条件下において優先度の調整に利用していた。 詳しく弊社ブログを参照ください https://www.lifull.blog/entry/2021/03/28/090000

• https://www.lifull.blog/entry/2021/03/28/090000

バージョンアップで気をつけたいとこと その他の問題 古いものも含めると • lucene-gosenからkuromojoへの変更 • Result groupingからCollapsing query parserへの変更による並びの変化 • ビルド済みの古い自作プラグインがそのままでは動かない • シャーディングは深いページングと相性が悪い などメジャーバージョン更新・SolrCloud化によるアプリケーション側への影響は大きく、導入にはアプリケーショ ンの大幅な仕様変更が必要になってくるものも多い。 現在はバージョンアップ運用で説明した、非推奨・廃止機能を継続的に確認することで、先手を打って 対応しこの問題を最小限に抑えていきたいと考えている。

バージョンアップしてきて どうだったか

バージョンアップしてきてどうだったか 単体作業としてのバージョンアップは辛い 手順や仕組みのない中でバージョンアップをときどきするというのはその都度、手間も時間もかかり、何 よりも作業に対する心理的なハードルが高すぎる。 • デプロイや管理の運用を改善しすぐに同一の環境を構築できるようにすること • バージョンアップを見越して日々情報をキャッチアップすること • テストをコード化しできるかぎり小さい工数で検証できるようにすること こういった積み重ねもあって、今では実際のサービスで稼働しているSolrをアップデートし続けられる下 地が整ってきていると感じている。

バージョンアップしてきてどうだったか 通常の運用にもポジティブに働く バージョンアップのテストのためにコード化、自動化をしてきたことで • 既存クラスタの負荷試験 • サーバー設定、スキーマ変更時の負荷・動作試験 • サーバースペック変更時の負荷試験 など、想定していなかった範囲の改善にもつながっている。

まとめ

バージョンアップしてきてどうだったか まとめ 何をするにしても 心理的コスト、対応コストが 大きすぎて誰も変更したくない状態

バージョンアップしてきてどうだったか まとめ • 稼働しているものと同等の環境をいつでも構築できる • 変更時に既存と同等の利用方法で機能・パフォーマンスなど に影響ないことを確認できる • 次のバージョンの導入を見据えて運用している

バージョンアップしてきてどうだったか まとめ 追加・変更したい機能に集中して 安心して開発できる状態に 近づいている

バージョンアップしてきてどうだったか まとめ また、これらの改善により できるようになった機能開発・改善を コントリビュートできるように していきたい