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

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

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

会社名
株式会社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％)
会社データ (2021年9月30日現在)

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

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

本日の概要

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

Solrの構成の変遷

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

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

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

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

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

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

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

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

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

①Immutable Infrastructure

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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