著者：溝口　泰史

9/9-12まで、ワシントンD.C.で開催されていた、Activate(旧Lucene/Solr Revolution)に参加してきましたので、レポートいたします。
イベントは、前半2日間がトレーニング、後半2日間がカンファレンスとなっており、私はカンファレンスにのみ参加しました。

ワシントンD.C.といえば米国議会やホワイトハウス、スミソニアン博物館群などの有名な観光名所が知られていますが、会場はワシントンヒルトンという観光の中心部からは少し離れたホテルでした。 周りにあまり観光客が多くなく落ち着いたホテルで、カンファレンス会場としては文句のないところでした。

Activateというカンファレンスについて簡単に説明します。すでに前年の弊社の西潟のレポートで説明されていますが、端的にいえばLucene/Solrのコミッターを多く抱えるLucidworks社主催のカンファレンスです。かつてはLucene/Solr Revolutionと呼ばれていました。
主な発表の内容としては以下のようなものがあります。

• Lucene/Solr
• 機械学習、ディープラーニング
• 自然言語処理

上記の他には、Lucidworks社のFusionという製品の導入事例が多い印象です。

私は以前のLucene/Solr Revolutionには参加したことがありませんが、YoutubeやSlideshareで確認できる当時の発表内容と比べると、技術よりの内容が少なくなっているように感じられました。(と言っても、かなり実験的な機能の発表もあったので、一概には決めつけられませんが。)

それではいくつか気になったセッションを紹介します。

SolrCloud in Public Cloud: Scaling Compute Independently from Storage

Salesforceの発表で、Solrの生みの親であるYonik Seeleyが発表していたセッションです。
まだパッチ(https://issues.apache.org/jira/browse/SOLR-13101)がマージされていませんが、新たなSolrCloudノードの種類の話で、個人的には今回のカンファレンスの中で最も面白かったです。

Salesforceは世界最大のSolrユーザーの一つで、Activate 2018でも社内の事例を発表しています。今回もSalesforceのような大規模な使い方ならではの機能の発表になっていました。

まず前提として、SolrCloudのノードの種類について説明します。
現在、SolrCloudは以下の3つのノードの種類が用意されています。

• NRT
• TLOG
• PULL

実際にSolrCloudを組む場合、リアルタイム性とデータのレプリケーションにかかる負荷とのバランスからこれらを組み合わせてSolrCloudを構築します。推奨構成は2017年のLucene/Solr Revolutionの西潟のレポートに記載があり、これはSolr 8.xでも変わっていません。

これらのタイプからなるSolrCloudでは、インデクシング・検索・レプリケーション・負荷分散などの大規模な検索サービスに必要とされる機能が全てSolrCloud(ZooKeeper + Solr)だけで必要な全ての機能を賄うことができるようになっている反面、データのレプリケーションを行う際にLeaderノード(Master-Slave構成のMasterのような役割)の負荷が大きくなるため、動作が遅くなったり、レプリケーション途中でLeaderノードが動作を停止し、登録されたデータが最新のものになっているか、確認しなければならないなどの問題点もありました。

この発表では、AmazonやGoogleのクラウドサービスやオンプレミスのBLOBストレージの利用を前提としたノードの種類を追加することで、レプリケーションにかかるマスターノードの負荷軽減とインデックスファイルの冗長性を向上させることができるため、結果としてSolrCloudのサービスレベルを上げることができるというものでした。

仕組み自体はとても簡単で、Leaderノードにデータがインデクシングされたら、それをBLOBストレージに登録してZooKeeperに登録されているインデックスの世代を更新し、それを元に他のレプリカノードがBLOBストレージから最新のインデックスをコピーするというものとなっています。

この機能は非常に画期的で、前述の通りSolrCloudの柔軟性を大きく向上させることが期待できます。
最も利益を得るのは、Salesforceのように大規模なSolrCloudを運用していて、負荷に応じてSolrCloudのノードの増減を行っているようなケースでしょう。
稼働している各ノードへの負荷が上昇して、ノードを増やして負荷分散する場合を考えます。現在は上述の通り、検索リクエストが増えて新たにノードを立ち上げた場合、Leaderノードの持っているインデックスファイルをダウンロードするために、一気に多くのノードを立ち上げることが難しいです。また、夜間などで検索リクエストが落ち込む場合にはノードを落としてSolrCloudの処理量を減らしますが、現状では上記のように一気にノードを増やすことができないため、ある程度余剰のノードを準備しておく必要があります。
インデックスファイルをBLOBストレージからダウンロードするようになれば、上記のようなノードの増加に関する制約が緩まるので、SolrCloudの処理キャパシティを柔軟に変化させやすくなり、サービスレベルを保ちながらコストを削減することが可能となります。

ここ数年弊社の案件でもSolrをクラウドサービス上で動作させることが多くなってきました。そういったものを踏まえてクラウドサービス特有の機能に依存した設計を行うというのが、今後のSolrの方針なのかもしれません。

このセッションと、Lucidworks社のFusionの最新版がKubernetes上でのみ動くということを現地でお会いしたLucidworks社の日向寺様より聞いて、今後のSolrの開発方針がどのようになるのか、面白みを感じました。

(R)Evolving Relevance Tuning with Genetic Algorithms

Genetic Algorithms(GA、遺伝的アルゴリズム)を利用することで、パラメータを最適化して検索エンジンの検索結果を改善するというお話。

検索結果のチューニングは、(真面目にやろうとすると)ユーザーの興味や登録されるドキュメントが時間とともに移ろいゆくため、永遠に続けていかなくてはならないもので、大変な手間がかかります。弊社の製品でも、少しでもその手間を減らすような機能を取り込んでいたりしますが、なかなか全自動化はできかねています。
チューニングの手法としては、弊社も力を入れているLearning To Rank(LTR)という機械学習などを取り入れた手法が最近では流行っており、SolrにもBloomberg社がLTRの機能をコントリビュートしていたりします。SolrのLTRでは、検索結果の上位N(設定可能)件に対して計算コストが大きく複雑なスコアリング計算を行うことで、ランキングを改善します。
しかしながら、本当に欲しい結果が上位N件に含まれていなければ意味がなく、ただの計算リソースの無駄遣いとなってしまいます。

このセッションがターゲットとするパラメータ最適化とは、LTRのチューニングを含まず(もちろんLTRにもパラメータチューニングの概念はあります。)、LTRが対象とする上位N件を適切に取得するためのパラメータチューニングをさしていました。

利用した評価フレームワークはこちら(https://github.com/mitre/quaerite)とのことで、2019年10月の時点でまだかなり頻繁に更新されていて、後述するように色々な改善がなされているのが伺えます。

パラメータチューニングの説明を簡単にします。
パラメータチューニングでは、機械学習の最適パラメータ同定に用いられるハイパーパラメータ探索と呼ばれる手法がよく利用されています。 これはいくつかの手法がありますが、簡単に言ってしまえば変化させるパラメータを一つ設定して、そのパラメータを変える前後で結果が良くなったか否かを確認し、最も結果が良くなったら他のパラメータを変更して、ということを繰り返しながら最適なパラメータ群(モデル)を同定するというものです。しかしながらSolrでは様々なパラメータ(フィールドのブースト倍率、tie、mm、関数クエリ、アナライザ、etc..)が存在することから、非常に計算量が多くなりがちになる上、オーバーフィッティングと呼ばれる未知データに対するモデルの弱さが生じがちになります。

本セッションで紹介されたGAは、Generation(世代)を設定してその世代ごとにそれぞれのパラメータに対して、値を変えない(mutate)、パラメータ間の値の入れ替え(crossover)、ランダムな変更(random)を繰り返して、最も効果的なモデルを本番環境に採用することで、未知データに対しても強いモデルを導き出すというものです。

ランダムな値の変更や値の入れ替えなどのトリッキーな動作があることから、(真面目に)少しずつ目標のパラメータに近づいていくハイパーパラメータ探索とは異なり、オーバーフィッティングのリスクを小さくできるという背景でしたが、評価の検証に交差検証(Cross validation)を使わなければオーバーフィッティングが発生しうるということで、まだ手順が確立していないという手探り感も覚えました。

結果としては、あまりハイパーパラメータ探索との比較は明確には示されていませんでしたが、オーバーフィッティングに対してわずかだが効果があり、検証を継続していくとのことで、今後の発達が楽しみな分野ではあります。

総括

イベント自体の感想として、前年のActivateに参加した弊社の西潟のレポートにもありますが、Lucene/Solrのコアなセッションは少なく、Lucidworks社の製品の導入事例などが多いという感じは否めません。また、テーマも先述のとおり検索、AI/機械学習、自然言語処理、Lucidworks社のFusionの導入事例と複数存在するため、参加するセッションを選ぶのが難しく感じました。

また、今回は例年には(必ず？)あった、次期Lucene/Solrのメジャーリリースの新機能の紹介も無く、個別技術よりはサービスやソフトウェアのインテグレーションによるソリューションの紹介の面を強め、よりユーザーメリットを追求する方向になっているのかもしれません。
また、日本からの参加者はかなり少なかった一方で、中国や韓国などの参加者は多いように感じました。Lucidworks社がすでに公式に進出している地域からの出席者が多めというのはあるかもしれませんが、少し寂しいものを覚えます。

Solrの新機能の紹介はありませんでしたが、Salesforceのセッションであったり、参加者と話したりする中から、今後のSolrではクラウドのインフラを前提とする仕組みが多く作られていきそうな感触を覚えました。

最後に、カンファレンスの少し前にワシントンD.C.に到着していたため、少しだけ観光してきました。
今年はアポロ11号の月面着陸から50周年という事で、スミソニアンの航空宇宙博物館に行きました。(肝心のアポロ11号を推している画像は撮り忘れてしまいましたが。。。) 一方で、大規模リノベーション中ということもあり、一部の展示が見れなかったことは残念でした。