安定したElasticsearchバージョンアップを目指して

Elasticsearch GCP 検索 パフォーマンス改善

(2024/12/10 13:35) Elastic Stack (Elasticsearch) Advent Calendar 2024のリンクを追加

初めまして。ECシステムエンジニアリング部門 EC商品基盤グループ サーチチーム 松浦です。
今回は、全文検索エンジンElasticsearch のバージョンアップの具体的な取り組みについて取り上げます。

このブログ記事の内容はElasticsearch株式会社が主催するElasticsearch Community in Osaka - connpassで発表した内容を元に作成しました。 また、Elastic Stack (Elasticsearch) - Qiita Advent Calendar 2024 - Qiita の10日目の記事です。

所属チームとシステムの概要説明

サーチチームでは、商品検索基盤を開発運用しており、主に商品の検索機能を提供しています。
例えば、monotaro.com の検索ページで、商品単位、品番単位の複数のindex を組み合わせ、ファセットや検索結果の表示といった機能を提供しています。

検索ページ以外にも、Query Auto Completion の機能もあります。

Solrを利用した旧システムからの移行を実施しており、検索ページを含め主要な検索機能は移行済みですが、そのほか新たな検索機能の検討を進めています。
検索対象の拡大や検索機能の改善を行う一方で、定常運用の一つとしてElasticsearch のバージョンアップも行っています。

以下はサーチチームで管理している商品検索基盤の簡単な構成図です。
Elasticsearch の検索用クラスタとindexing 用のクラスタ、Elasticsearch のためのデータの変換と投入、前段のElasticsearch のクエリを組み立てるSearch Core API を運用しています。

検索用のElasticsearch では平日営業時間中で、約7,000QPS のリクエストを処理しています。
また、販売中の2,372万品番 + 廃番商品 のデータを格納するindex を、複数世代保持しており、商品単位のindex のサイズは約60GB程度です。
Elasticsearch のデータ投入とindex サイズの削減の工夫については、以下をご確認ください。

tech-blog.monotaro.com

今回のバージョンアップの詳細と、これまでのバージョンアップ

今回は v8.8.2からv8.13.4へのマイナーバージョンアップを行いました。
monotaro.com や大企業向け購買管理サービスなどで商品検索基盤の利用が開始されてから、ここ3年程で5回のバージョンアップを実施しています。
社内でElasticsearch の更新バージョンの決定基準を作成して、それをもとにバージョンを決定しています。

最近はバージョンアップ方法が安定してきたため、検証手順をドキュメントやGoogle Colaboratory に整理しています。

Elasticsearch のバージョンアップに関連する、平時の取り組みと、バージョンアップ時の検証内容を、それぞれ説明いたします。

平時の取り組み

Elasticsearch のバージョンアップの下支えする平時の取り組みは以下2つです。

  • リリースノート読み会
  • Elasticsearch のBlue/Green リリース

リリースノート読み会とは

月1回、Elasticsearchの新規のバージョンがないか確認をし、翌月3-5時間をとって、リリースノートの内容を確認する会を開催しています。

リリースノート読み会の実施手順

リリースノートの全項目を確認、関係ありそうな項目 or 興味がある項目をピックアップし、Elasticsearch の関連PR やコードを元に、変更点を共有します。
そのうえで、以下観点で、関係ありなしを洗い出します。

  • 利用中の機能であり、バージョンアップ時に対応が必要な項目
  • バージョンアップするときに注意したほうが良さそうな項目
  • バージョンアップの動機になりうる新機能・機能改善
  • 現時点でバグに該当していそうなものや、バグで利用を断念したもの・断念すべきもの
  • 関係する Security Update

こちらが実際のリリースノート読み会の議事録です。

2年前からこの取り組みを行っており、リリースノート読み会を行うまで、Elasticsearch のコードを参照することとは縁遠かったのですが、実施後はチームの中でもElasticsearch のコードを参照することがより身近になるメリットなどがでています。

Elasticsearch のBlue/Green リリース

Elasticsearch のリリースではGreen のクラスタを新規で構築し、切り替えるBlue/Green リリースを行っています。
以下ステップで行います。

  1. 既存のBlue クラスタがサービス提供している横に、検索用のGreen クラスタを構築
  2. 検索リクエストを受けるDNS の向き先をBlue クラスタから Green クラスタに切り替え
  3. ロールバック用に1日Blue クラスタを残して、問題がなければ翌日削除

「検索用のGreen クラスタを構築」では、検索用のElasticsearch をterraform で新規構築した後、index restore や暖気クエリの実施、簡単な負荷検証を行います。
「検索リクエストを受けるDNS の向き先をGreen クラスタに切り替え」では、以下図のように、Elasticsearch の前段LB を指定するDNS のIP アドレスを新規クラスタに変更することで、ユーザートラフィックを切り替えます。

ロールバック用に旧クラスタ(Blue)を念のため1日残しておき、翌日削除します。
図にはありませんが、Elasticsearch の投入用の仕組みもBlue とGreen のクラスタでそれぞれ構築しているので、翌日ロールバックになった場合も、データの復旧は必要ありません。

バージョンアップ検証

バージョンアップ検証としては以下を実施しています。

  • 現行バージョンとの差分の把握
  • クラスタ構築時の確認
  • Elasticsearch レスポンス前後比較
  • 速度検証
  • そのほか
    • 各検証時のサーバーログの確認(Google Colaboratory)
    • deprecation log の確認
    • 開発環境での経過観察

現行バージョンとの差分の把握

現行バージョンとリリース予定の新バージョンとの間で、Elasticsearchの機能の差分を確認します。
Elasticsearch の Upgrade to Elastic 8.13.4 | Elastic Installation and Upgrade Guide [8.13] を現行バージョンからリリース予定の新バージョンまですべて確認し、商品検索基盤で利用している機能に変更がないかを確認します。
また、リリースノート読み会で「関係あり」としていた項目についても、Elasticsearch の設定変更などが必要ないかを確認します。
事前にリリースノートのチェックを実施しているので、Elasticsearch のバージョンアップに伴う、Elasticsearch やデータ変換・投入の改修の有無を事前にある程度把握できていました。

クラスタ構築時の確認

自前のプラグインのビルド等をしたうえで、Elasticsearch のクラスタを構築後、新、旧バージョンのクラスタ間での差分確認を実施しています。
Elasticsearch Support Diagnostics で出力される、nodes.json, cluster_settings_defaults.json, cluster_state.json などの各種API実行結果ファイルと、
Elasticsearch のサービスなどの稼働状況、index template をElasticsearch のAPI 経由で確認した結果を元にしています。
これらの比較はGoogle Colaboratory を利用しており、バージョンアップ途中に変更が入った場合も簡単に再度確認できるようになっています。
以下はcluster_settings_defaults.json に関する設定差分の出力サンプルであり、reference (現行バージョン)にはない設定がtarget (新バージョン)には追加されていることが分かります。

Elasticsearch の設定差分を確認した後、それぞれの設定について、Elasticsearch のリファレンス、コードや関連PR などから、設定の詳細を把握し、それぞれの変更が問題ないかを調査します。
以下は調査結果の表の一部ですが、 search.query_phase_parallel_collection_enabled と、search.worker_thread_enabled については差分が検出されたためドキュメントなどを調べて、Elasticsearch のクエリの速度に影響する可能性があるパラメータであると確認しています。

Elasticsearch レスポンス前後比較

Elasticsearch に同一クエリを流した場合のレスポンス結果やスコアを、比較します。
平時も利用している、Elasticsearch の検索結果のExplain データを取得するツールを利用し、取得したデータを、Colaboratory で差分確認しています。
今回のバージョンアップではレスポンスの差分はありませんでした。

速度検証

同一クエリをある程度本番相当のリクエストの割合と流量で実施した場合のレイテンシの変化を確認します。

Elasticsearch の設定を変更しなかった場合、レイテンシが90%ile以後で悪化していることが分かります。
また、検証時にElasticserach data node のCPU使用率もv8.8.2が最大40%程度に対して、v8.13.4は50%まで上がっており、負荷にも違いがありました。

この差分の原因を調査するため、Elasticsearch Benchmarks を参照しました。
クエリの分類ごとに、バージョンごとのレイテンシの変化をグラフで確認することができます。

MonotaROでは検索の主要部分では nested query を利用しています。
Elasticsearch のindex の持ち方とクエリに興味がある方は、以下をご確認ください。 tech-blog.monotaro.com

nested query のレイテンシを見たところ、v8.12.0 から、遅いpercentile で速度が悪化していることが確認できました。
結果、query phase の並列化 の導入が、ベンチマークとしても nested query に影響を与えていることが分かり、
クラスタ構築時の確認で挙げていた、search.query_phase_parallel_collection_enabled と、search.worker_thread_enabled が影響している可能性が高いことが確認できました。

その後、search.query_phase_parallel_collection_enabled とsearch.worker_threads_enabled の設定を変更して速度検証しました。
結果、Elasticsearch のクエリの種類により、速度改善/悪化がみられましたが、悪化幅の小さかった、worker_threads_enabled だけFalse にすることを決定しました。

そのほか

そのほか、各検証時のElasticsearch の各種ログの確認を、追加検証時に再実行が容易で検証結果の記録が残しやすいので、Google Colaboratory で行っています。
MonotaROではElasticsearch のログをBigQuery に保存しており、特に、Elasticsearch Server log については、問題ないと判断したログを正規表現でgitに管理し、ログをフィルタしながら、既知ではないログだけを各検証で確認しています。

これまで挙げた検証で問題ないことを確認したのち、開発環境での経過観察を1週間行った上で、本番環境のElasticsearch バージョンアップを行っています。

バージョンアップ時のElasticsearch の切り替え手順

バージョンアップ時も平時の取り組みで挙げた、通常のBlue Green リリースと同一手順で行っており、一般的なRolling Upgrades は実施していません。
平時のリリースとの差異としては、ロールバック用のBlue クラスタを1日長く残していた程度でした。
このメリットは、通常と同じ手順であるためミスなく実施可能なことです。

バージョンアップの効果

今回はマイナーバージョンの更新でしたが、速度改善と、商品検索基盤で起きていた問題の解消が効果としてありました。

速度改善

速度改善については、Aggregation のみのクエリで明確に速度改善が見られました。

特に、キーワードやidなどの絞り込みがないクエリのAggregation は大きな速度改善効果が見られました。

file system disk read size の増加する問題の解消

今回のバージョンアップ前から、Elasticsearch のデータノードでfile system disk read size が増加する問題が発生していました。
これは、file system disk read sizeがリクエスト量に対応して増加していき、あるタイミングでレイテンシが悪化する、という問題でした。
利用されていないindex がpage cache に乗っていることは分かっていましたが、それ以上は原因不明でした。
徐々に発生頻度が増加し、最終的には2、3日に一度発生し、手動で利用されていないindex を削除する運用を実施していました。

この問題に関連するissue は見つけられませんでしたが、速度検証の実施中からバージョンごとにfile system disk read size の利用傾向が異なることが確認できており、本番リリース後に解消しました。

まとめ

以上が、MonotaROで行っている、安定してElasticsearch のバージョンアップ検証を行うための取り組みでした。
次回バージョンアップスケジュールも決まっており、これまでにまとめた手順を利用して今回とは別の担当者が、バージョンアップ検証を実施する予定です。

なお、同内容を発表したElasticsearch Community in Osakaですが、MonotaROの本社オフィス内で実施しました。
社外イベントの実施は、本社がJPタワー大阪に移転してから、初の試みでした。
35名に参加いただき、各LT発表と、その後の懇親会も含めて大変学びが多いものでした。

この記事を通じてMonotaROに興味を持っていただいた方は、カジュアル面談もやっていますのでぜひご連絡ください。 採用募集もご覧ください。