LIFULL HOME'SでのSolrの構成と運用の変遷
•Als PPTX, PDF herunterladen•
1 gefällt mir•751 views
2021/11/30 第26回 Lucene/Solr勉強会 LIFULL HOME’SでのSolrの構成と運用の変遷 テクノロジー本部事業基盤ユニットプラットフォームグループ 磯野 圭輔
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie LIFULL HOME'SでのSolrの構成と運用の変遷
Ähnlich wie LIFULL HOME'SでのSolrの構成と運用の変遷 (20)
Mehr von LIFULL Co., Ltd.
Mehr von LIFULL Co., Ltd. (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (12)
LIFULL HOME'SでのSolrの構成と運用の変遷
- 1. 第26回 Lucene/Solr勉強会 #SolrJP LIFULL HOME’Sでの Solrの構成と運用の変遷 株式会社LIFULL テクノロジー本部 プラットフォームグループ 磯野 圭輔 2021.11.30 ©
- 2. 目次 1. 自己紹介・会社紹介 2. Solrの構成の変遷とバージョンアップ 3. バージョンアップで気をつけたいところ 4. バージョンアップをしてきてどうだったか
- 3. 磯野 圭輔 ソフトウェアエンジニア・エンジニアリングマネージャー at LIFULL Webサービス開発におけるインフラからサーバーサイドの構築がメインフィールド ここ数年はLIFULL HOME‘SのSolrの運用改善を担当し、情報検索や自然言語処理などについては勉強中 自己紹介 自己紹介 ikeisuke
- 4. 会社名 株式会社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日現在)
- 7. 本日の概要
- 8. 本日の概要 Solrが稼働しているだけだったところから、運用を整理し、機能開発など に着手できるようになるまでに取り組んできたこと、特にバージョンアッ プ周りについてのまとめと課題について紹介させていただきます。 1. Solrの運用の変遷とバージョンアップ 2. バージョンアップで気をつけたいところ 3. バージョンアップしてきてどうだったか 本日の概要
- 9. Solrの構成の変遷
- 10. 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
- 11. 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処理
- 12. 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後の レプリケーション
- 13. 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
- 14. 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処理
- 15. Solr構成の変遷 • 設定変更などほぼ全て手動でのオペレーションであり、サーバーも1系統しかなく失敗したら大惨事という状況 • 構築当初サーバーの構成管理においてバージョン管理が徹底されておらず、稼働しているサーバーが正の状態だ った • 機能拡張を対応するスキームがなく、機能追加をしたいチームのメンバーがインフラ担当と相談しながら個別に 対応していた • 単純にフィールドを追加したいだけのためにデータの反映が終わるまで1ー2週間待つ必要がある • Solr4(nightly build)が稼働しており古すぎるだけでなく、正式版との乖離がどこまであるのか把握できていなか った • master-slave構成でmasterノードがSPOFとなっており大きな問題が起きた際に復旧できない、もしくは復旧に数 日かかることが予想される¥ • 今後のサービス・データ量拡大を考慮してシャーディングも視野に入れた構成にしていきたかった 何故Solrの構成をアップデートしたか
- 18. Solr構成の変遷 1. デプロイのたびに新たに作るImmutable Infrastructureな構成に変更 • その際にシャーディングを見据えてSolrCloudを導入 2. できる限りの構成をコード化し自動でデプロイされる仕組みの構築 3. 継続的に最新バージョンを適用するためのバージョンアップ運用体制 の構築 4. 専任チームによる相談受付、一緒にプロジェクトを進める体制 どうしたか
- 20. 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
- 21. Immutable Infrastructure 物件検索システム – Immutable構成な範囲 リソース 説明 SQS S3の更新・削除通知を受け取る AWS Lambda SQSをイベントソースとしてS3のデータを Solrに書き込む ALB/Solr(tlogノード x2) AWS Lambdaからの書き込み処理を受け付け ALB/AutoScaling/Solr( pullノード) 検索リクエストの受け付け Zookeeper SolrCloudクラスタの管理
- 22. Immutable Infrastructure • SPOFだったmasterノードではなくSolrCloudのtlogノードを複数置くことで書き込み側の可用性を向上した • tlogノードを増やすごとに書き込み性能が劣化するため現在はtlogを2台で稼働中 • データの特性とこれまでの安定性、後述のデプロイを考慮して1台でいいのでは？と考えている • SNS – SQSを利用したファンアウトと初回ロード処理を利用することによりクラスタを同時に複数構築すること ができるようになった • Solrのバージョンやスキーマなどの違う複数のクラスタを立て比較することが容易になった • 初回ロードに時間がかかることが課題 • ほぼ全てを作るので構築したクラスタ分のコストがかかることも課題 この構成により解決したこと
- 23. Immutable Infrastructure • リピーターインスタンスなしでも遅延なくレプリケーションできるようになった • 当時はoptimize後にレプリケーションするように設定していたので全インデックス（数十GB） の転送に時間がかかっていた。（slaveの台数分ほぼ同時に転送） • インデックス効率の向上によりインデックスサイズは25%程度減った（と記憶している） • マージスケジューラーによるマージでの運用に変えたため差分のみ転送されることになり、一 度に行われる転送データが減った • Optimizeしない状態＆短期間でsearcherが入れ替わる状態でも同等程度の性能が出るようになった • Solr7からSolr8に上げた際にも性能改善が見られたので、都度の検証は必要だが定期的なアップ デートを視野に入れた運用体制を構築しておくことのポジティブな理由になり得る 構成変更・バージョンアップの副次的効果
- 25. 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.更新データ投入開始 初回ロード
- 26. Solrクラスタのデプロイ デプロイの手順1 – デプロイ前 AWS Cloud Amazon S3 data bucket select Application Load Balancer uploader Amazon SNS event ( put / delete ) 旧クラスタ （稼働中）
- 27. Solrクラスタのデプロイ デプロイの手順2 – デプロイ開始 AWS Cloud Amazon S3 data bucket select Application Load Balancer uploader Amazon SNS event ( put / delete ) 旧クラスタ （稼働中） 新クラスタ （構築中）
- 28. Solrクラスタのデプロイ デプロイの手順3 – リクエストの切り替え AWS Cloud Amazon S3 data bucket select Application Load Balancer uploader Amazon SNS event ( put / delete ) 旧クラスタ （稼働中） 新クラスタ （稼働中）
- 29. Solrクラスタのデプロイ デプロイの手順4 – 古いクラスタの削除 AWS Cloud Amazon S3 data bucket select Application Load Balancer uploader Amazon SNS event ( put / delete ) 新クラスタ （稼働中） 旧クラスタ （削除）
- 30. Solrクラスタのデプロイ 運用上現実的な時間でサーバー構築、データの投入ができるようにしたことでblue- green deploymentを実現できた • 1回のデプロイでImmutable構成の範囲を全てデプロイする • デプロイ時は初回ロードを行うので全てのデータが反映されている状態になる • デプロイ完了後ロードバランサの向き先を旧クラスタから新クラスタに切り替える • 切り替えが完了し、正常動作を確認したら旧クラスタは全て削除する デプロイ（blue-green deployment）
- 32. Solrクラスタのデプロイ • 稼働系を危険に晒すようなことなく安全に新しい設定を適用可能になった • 切り替え後に問題があった場合でも問題があった際にロードバランサの向き先を変え るだけで切り戻しが完了できるため、さらにリスクは少ない • インフラ構成から設定に至るまでバージョン管理されていることで特定バージョンへ の切り戻しや微調整しての再デプロイが容易 • 古いクラスタ削除後に戻したい場合であっても、元の設定で再度デプロイして切り替 えるだけのため、デプロイの手順をそのまま利用できる この構成により解決したこと
- 33. 継続的なバージョンアップ運用
- 34. 継続的なバージョンアップ運用 Solr 4(nightly build)を長期間運用し続けた結果、大きな技術的負債として抱えてしま った反省を生かし、継続的に新しいバージョンを適用していくための運用体制を構築し た。 大きく分けて3つの対応をしている。 1. 平日のLucene/Solrの更新情報の確認 2. マイナーバージョンリリースごとの動作確認 3. 動作確認後のデプロイ判断とデプロイ 継続的なバージョンアップのために
- 36. 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
- 38. 継続的なバージョンアップ運用 パフォーマンスの確認以外にも以下の観点で新旧クラスタを比較している • SolrのログとCloudWatchを利用した書き込み性能の比較 • 実際のクエリログをパターン毎に抽出して同一のレスポンスが返却され るかの確認 • 登録されているレコード数、レコード内容の同一性確認 • Zookeeper停止時の検索機能の継続稼働確認 マイナーバージョンアップ毎の動作確認
- 40. サービスで活用してもらうために
- 43. バージョンアップで気をつけたいとこと 新しい healthcheck endpoint（Solr8）の取り扱いについて 8にバージョンアップした際にローカルCoreがアクティブなことをチェックしたい要件があり、あまり細 かく考えずエンドポイントを切り替えてしまった 本番環境を数時間停止させた大障害 PingRequestHandler HealthCheckHandler 対応バー ジョン 全て 8以降 (SolrCloud) 用途 ロードバランサのヘルスチェック用 特定ノードが正常かどうかを確認する （＝特定ノードが正常に起動しているかどうかの 確認用途） 動作 対象のcollectionが利用可能になったら • 指定のcollectionで検索できること • リクエスト転送されるのでレプリケーション終 わっていなくてもHealthになる • [OPTION] healthcheckFileがあること ノードが正常かどうか • Coreがアクティブなこと • Zookeeperと接続されていること • live_nodesに登録されていること • [OPTION] ローカルCoreがアクティブなこと
- 44. バージョンアップで気をつけたいとこと 本番環境を数時間停止させた大障害 時系列 アラート 内容 障害半年以上 前 - 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の復旧が完了し旧クラスタも正常動作確認
- 45. バージョンアップで気をつけたいとこと Zookeeperの管理が雑だったことに尽きる 1. 全台停止した原因はディスクフルだったため、監視とストレージの分割 を追加 2. Zookeeperを全台停止してもヘルスチェックは成功し、検索はし続けら れることを確認するテストを追加 • SolrCloud導入の際は確認していたがヘルスチェックの変更時に確認が漏れていた 3. リリース時のサーバーのログにエラーが記載されていないことのテスト の厳密化 本番環境を数時間停止させた大障害の原因と対応
- 47. バージョンアップで気をつけたいとこと 古いものも含めると • lucene-gosenからkuromojoへの変更 • Result groupingからCollapsing query parserへの変更による並びの変化 • ビルド済みの古い自作プラグインがそのままでは動かない • シャーディングは深いページングと相性が悪い などメジャーバージョン更新・SolrCloud化によるアプリケーション側への影響は大きく、導入にはアプリケーショ ンの大幅な仕様変更が必要になってくるものも多い。 現在はバージョンアップ運用で説明した、非推奨・廃止機能を継続的に確認することで、先手を打って 対応しこの問題を最小限に抑えていきたいと考えている。 その他の問題
- 49. バージョンアップしてきてどうだったか 手順や仕組みのない中でバージョンアップをときどきするというのはその都度、手間も時間もかかり、何 よりも作業に対する心理的なハードルが高すぎる。 • デプロイや管理の運用を改善しすぐに同一の環境を構築できるようにすること • バージョンアップを見越して日々情報をキャッチアップすること • テストをコード化しできるかぎり小さい工数で検証できるようにすること こういった積み重ねもあって、今では実際のサービスで稼働しているSolrをアップデートし続けられる下 地が整ってきていると感じている。 単体作業としてのバージョンアップは辛い
- 50. バージョンアップしてきてどうだったか バージョンアップのテストのためにコード化、自動化をしてきたことで • 既存クラスタの負荷試験 • サーバー設定、スキーマ変更時の負荷・動作試験 • サーバースペック変更時の負荷試験 など、想定していなかった範囲の改善にもつながっている。 通常の運用にもポジティブに働く
- 51. まとめ
- 53. バージョンアップしてきてどうだったか まとめ • 稼働しているものと同等の環境をいつでも構築できる • 変更時に既存と同等の利用方法で機能・パフォーマンスなど に影響ないことを確認できる • 次のバージョンの導入を見据えて運用している