著者：西潟 一生

先日カナダのモントリオールで開催された Activate 2018(2017年までは Lucene/Solr Revolution)に参加したので，その内容についてご紹介したいと思います。

Activate とは Lucene/Solr やそれに関わる Machine Learning，NLP についての技術的な情報を共有するための米国 Lucidworks 社が主催するビジネスカンファレンスです。去年までは「Lucene/Solr Revolution」という名前で開催されていたのですが，今年から Activate という名前に変更され，内容も Lucene/Solr のコアな内容に限らず，そのエコシステムである Machine Learning や NLP など昨今 AI として語られる技術に関して幅広くセッションが設けられたことが特徴です。

逆に言えば Lucene/Solr について純粋に情報を手に入れたい方にとっては Lucidworks 社のビジネス色も相まって，期待する内容ではなくなっているかもしれません。と言っても，近年はこのような兆候が見られたので，予測できることではあったかと思います。

Activate では初日と 2 日目に LucidWorks 社の Solr トレーニング(有償)を受講することが可能です。Solr トレーニングと言っても，OSS としてリリースされている Solr ではなく，それをベースにカスタマイズされている LucidWorks 社特製の Fusion という製品をベースにトレーニングが進められていきます。

毎年数十名ほど参加され，内容は Solr の基礎的な内容に留め，後は Fusion 独自の機能についての解説がされるそうです。既に Solr についての基礎的な知識がある方だと少し物足りない内容かもしれません。トレーニングの内容は参加者の数にも大きく影響され，特に人数が多くなってくるとどうしてもスキル差による進行にバラつきが出てくるため，内容を初歩的なものにせざるを得ない傾向があります。そういった関係もあり Lucidworks 社のトレーニングは基礎的な内容に留めているのかもしれません。

弊社でも Solr トレーニングを行なっていますが，少人数での開催ということもあり，受講者に合わせた柔軟な進行も行っております。Solr のトレーニングをご検討されている方は是非弊社トレーニングもご検討ください。

では，Activate 2018 の中で共有できそうなセッションをご紹介します。

目次

• Query Hundreds of Fields at Scale
• Automatically Build Solr Synonyms List Using Machine Learning
• Lucene/Solr8 the next major release
• 総括

Query Hundreds of Fields at Scale

まずは Salesforce での事例をご紹介します。Salesforce は Solr ユーザーの中でも非常に大きく且つ影響力を持っている企業と言えます。毎年同カンファレンスでは，大規模環境ならではの課題を発表されており，注目を集めています。

今回のセッションは，1つのコアに大量のフィールドがある時に，どのように最適化をしたのか？というテーマでした。本事例の結論としては Salesforce 内で Lucene のコードをカスタマイズして最適化を行ったため，私達がその恩恵を今すぐに受けることは難しいですが，将来的にはマージされる可能性もあると思いますし，一部の機能については既に Lucene/Solr にコントリビュート済のようです。

Salesforce のような多くのユーザーを抱えているシステムによくある機能として，パーソナライズ機能というものがあります。これはユーザーごとの検索嗜好を考慮した検索という意味もありますが，ここではユーザーごとに検索するフィールドが異なるという意味でパーソナライズ機能という言葉が使われていたと思います。ユーザーごとに検索できるフィールドが異なると，場合によってはユーザーごとに Solr のコアが1個必要なことも検討するくらい話の規模が大きくなることもあります。

筆者は Salesforce を使用したことがないので，上記のような Salesforce の機能が Solr に影響を与えているのか分かりませんが，Salesforce では 600 万以上のコアが存在し，Solr の1ノードには一時的なものも含めると 2000 以上のコアが存在していることもあるそうです。 このような大規模なコアの構成で，且つ大量フィールドに対して検索するとなるとパフォーマンスに非常に大きな課題を抱えることは容易に想像できます。

もちろん “_text_” のようなフィールドで集約してしまって問題ないケースであれば，大量のフィールドを持つ必要はないのですが，上記で挙げたようなケースやフィールドごとに重要度の違いを設けたいなどの理由で集約できないこともよくあります。 今回のケースでは検索対象のフィールド数の想定を 150 個とした時の事例を発表されていました。150 個だと個人的には割とよくあるケースでそこまで多いケースとは言えないんじゃないかと思いました。ロンウイットのコンサルティング事例では当初は 1万 を超えるフィールドの検索を検討されているお客様もいらっしゃったくらいで，それと比べるとこのケースは優しいと言えるでしょう。

ただ，150 個であったとしても検索文字列の数と Lucene のセグメントの数を考慮すれば生成されるタームクエリの数は単純計算で数千から数万のオーダーになります。

• クエリのパース時の計算量：O(fields)
• クエリの実行時の計算量：O(segments×disMaxQuery×fields)

Lucene ではこのようなケースには最適化されておらず，アンチパターンの1つになるかと思います。加えてこの実行には大きなメモリも消費されることが予想されます。

Salesforce では非常に短い間隔でアップデートが走るらしく，30秒単位で登録バッチが走り，レプリケーションは60秒単位だそうです。このような状況ではコミットが大量に発行される関係でセグメントが大量になります。セグメントが大量であるということは上記の計算量が多くなるということになります。従って，Salesforce ではデフォルトのセグメントのマージポリシーは使用せず，可能な限り積極的にマージするようにポリシーを変更したそうです。

発表のケースでは，セグメント数は 3 以下になるように，そして新しいセグメントが 3MB を超えるようだったらマージするというポリシーだそうです。これは小さなマージであればその時のコストは小さいという発想に基づきます。この影響でインデクシング時間は 15% ほど悪化したしたとのことですが，検索時のパフォーマンスを考慮するとさほど大きな問題ではないのかもしれません。

上記のセグメントの管理だけでは検索を十分に高速化することはできず，Salesforce ではインデックスの走査方法についても手を加えています。 本件では，Lucene50PostingsFormat をラップし，フィールドのサフィックスをメモリ上に持つことで高速化を試みたそうですが，詳細については難しくて理解ができませんでした。。。 この独自実装によりスコアリングにも手を加えています。スコアリングについては，SOLR-11595 にも反映されています。 結果，新しい PostingsFormat，QParserPlugin，MergePolicy，MergeScheduler を実装したことになり，結果として通常よりも検索速度が 2 倍になったとのことでした。

Automatically Build Solr Synonyms List Using Machine Learning

次は，Lucidworks 社の Chao Han さんが発表された，シノニム辞書を自動構築するセッションをご紹介します。結論から述べますと，Lucidworks の Fusion を使えば自動構築ができるよという営業色の強いセッションではありましたが，手法そのものは検索エンジンの特性を活かしたものであり，なるほどと思っていただけると思います。

Solr でシノニムと言った時に具体的に指すのは以下の4つが考えられます。

• Synonym: 同義語。言い換え。首相と内閣総理大臣のようなケース。
• Acronym: 省略語。playstation と ps のようなケース。
• Misspelling: accesary, accesaire はタイポで，正しくは accessary のようなケース。
• Misplaced blank spaces: 間違った空白。Elasticsearch と Elastic Search，正しくは Elasticsearch のようなケース。

Solr では後者2つのように，間違った文字列を訂正する目的としてもシノニム辞書を利用することがあります。 本セッションでは，このような4つのケースをカバーできるシノニム辞書の構築を自動的に行う試みを紹介されていました。

まず，シノニムの構築方法としてよくあるケースを紹介しています。1つ目は WordNet など，既に構築されているシソーラス辞書などを利用することです。 構築コストがかからない方法としては非常に有効ですが，一般的な用語でしかシノニムを構築することができず，対象ドメインに特化したシノニムを構築することができません。 また，Misspelling などの問題には一切対処することはできません。

次によくあるケースとしては word2vec のようなソフトウェアから出力される意味が近いとされる語をシノニムとして用いるケースです。 これは対象ドメインに適応した結果を得ることができるという点では上記のシソーラス辞書よりも有効ですが，word2vec の特性上，[red,blue] や [unlocked,phone] など確かに意味の距離としては近いが，シノニムとしては適切ではない結果も多く出力されます。

これらのことから，シノニムを自動で構築するのは非常に難しいと考えられますが，検索エンジンの特性を活かせば上記の方法よりももっと効率的に且つ精度良くシノニムを構築できる方法があります。それが「似た検索結果のクエリ」を使ったシノニム構築です。

この方法では「検索結果が似ているならば，そのクエリはシノニムの候補である」という仮定に基づきます。 例えば，「ps4 cooler」と「ps4 intercooler」の検索結果がほぼ同じなら，「cooler」と「intercooler」はシノニムであるとみなすものです。この方法では Misspelling の語も同様に取得することができますし，検索結果を利用しなくとも，クエリが似ているというだけで解決することもできそうです。この「cooler」と「intercooler」がシノニムとするかどうかの判断基準として対象コーパスに一定以上の頻度で出現しているなどの情報を利用しているとのことでした。

最終的には取得できたシノニムのペアを2つに分類します。例えば [earbud,earphone] というシノニムのペアは「純粋なシノニムのペア」とします。次に [game,playstation] というシノニムのペアは「上位下位関係のペア」とします。これは「game console, playstation console」から console を落とし，[game,playstation] を得る過程で作られたモデルによってタグ付けされるらしいのですが，詳細については分かりませんでした。

Solr の場合は「上位下位関係のペア」をシノニム辞書として利用するにはかなり検討が必要です。これは「playstation」の検索で「game」が出現しているドキュメントをヒットさせることは非常にノイズが多くなってしまう懸念があるためです。通常は完全な言い換えである「純粋なシノニムのペア」を利用します。

上記の手法により取得されたシノニムのペアを word2vec で取得したペアを使って評価をされていました。

Method	Precision	Recall	F-measure
本手法	83%	81%	82%
word2vec	31%	28%	29%

この結果だけを見ると，word2vec に圧倒的な差をつけて適切なシノニムペアを取得できていることが分かります。 このようなシノニムの自動取得は Fusion を使えば簡単にできるそうです。日本語でもどの程度までできるのか興味がある内容でした。

Lucene/Solr8 the next major release

最後に Lucidworks の Steve Rowe さんから Lucene/Solr8 についての情報共有があったので，ご紹介します。実際のセッションでは Lucene/Solr8 についてというより，Lucene/Solr8 に至るまでの Lucene/Solr7 の歴史についてほとんどの時間が割かれたように思えます。

まずは Lucene/Solr6.X,7.X のマイナーリリースの間隔について言及がありました。6.X では平均して 10 週に 1 度，7.X では 11 週に 1 度マイナーリリースがあったようです。リリースのグラフを見てみると，分散は 7.X の方が大きく，6.X では安定した間隔でリリースされていたようです。

次に 7.X での主なアップデートの内容についてアナウンスがありましたが，非常に量が多いのでここでは割愛します。

次に 8.X でのアップデート内容についてそれぞれ紹介します。

Autoscaling

• Suggestion API：ポリシー違反がなくともリバランス可
• Suggestion API:add-replica 対応
• index size trigger に maxOps limit 追加
• Autocaling policy framework デフォルト

Autoscaling は Solr7 から導入された SolrCloud 用の機能です。SolrCloud クラスターの各ノードの負荷を均等にし，安定稼働させるための機能です。

その中に，Suggestions API という API があります。この API を使用すると，設定したポリシーに反しているクラスターがあった時に，ポリシーに沿ったクラスターにするためのサジェストがされる機能です。例えば，「このコレクションのこのシャードがポリシーに反しているので，こちらのクラスターに移動させましょう」と言った出力を得ることができます。

Solr8 ではこの Suggestions API がポリシー違反がなくともリバランスするためのサジェストができるようになったり，レプリカがダウンした時の add-replica するようなサジェストが追加されるようになるそうです。 また，index size trigger に maxOps limit が追加されたり，レプリカを配置する設定が Autoscaling policy framework を経由することがデフォルトになるそうです。

※ trigger とは発動条件のようなもので， index size trigger はインデックスサイズが指定した値になった時に発動させる条件のことです。maxOps は既に Search Rate Trigger にはありましたが，これを index size trigger にも持ってきたようです。

Index upgrades

• Solr8 からは N-2 もしくはそれよりも古いインデックスはオープン不可

古いバージョンのインデックスのサポートについても案内がありました。これまでの Solr は IndexUpgrader というツールを使って 1 個前のバージョンのインデックスが使用可能でした。

例えば Solr7 を使用しているのであれば，Solr6 のインデックスは IndexUpgrader を使えば利用可能でした。Solr5 以前を使っている場合は，Solr6 に付属している IndexUpgrader を使って一旦 Solr6 対応させた後に Solr6 の IndexUpgrader を使って，Solr7 に対応させる必要がありました。

このポリシーが Solr8 から変更になり，Solr7 からのアップグレードのみ可能になったようです。今までは順々にアップグレードする手間はありましたが，2個前のインデックスまで使用可能でしたが，これが1個前に変更になるということです。したがって，Solr6 から Solr8 にする場合は再インデクシングが必要ということになります。

HTTP/2

• HTTP/2 対応でいろいろ高速化
• インデクシング時のスループット 54% 向上

HTTP/2 は HTTP 通信の新しい規格で，一度のコネクションで同時に複数のリクエスト/レスポンスをやりとりでき，大量の通信がされる場合においてはスループットの向上が見込まれます。 Solr8 では HTTP/2 に対応することで，インデクシングのスループットが 54% 向上したそうです。（33M 文書，1 シャード，2 レプリカの SolrCloud 環境にて）

その代わり，Leader の CPU time が 39% 増加，Replica は 76% 低下したそうです。

Lucene/Solr minimum JDK

• 2019 年 1 月にオラクルが Oracle JDK8 の無償サポートを終了
• Oracle JDK9,10 は既に EOL を迎え，サポートも終了（JDK10 は 2018 年 9 月 にサポート終了）
• Solr8 では JDK11 が最低限必要なバージョンになりそう
• JDK9 以上では Solr の Hadoop 周りの機能で問題あり
• Oracle JDK9 以上だと Jenkins 上でのテストの失敗率が Oralce JDK8 に比べて高い

近年 Java の開発環境のライフサイクルやサポートポリシーが開発元のオラクルによって大きく変わったことで，Lucene/Solr がサポートする JDK のバージョンのライフサイクルも変わりそうです。少なくとも，Solr8 がサポートする JDK は JDK11 以上になりそうです。

Luke: UI framework & licensing

Luke は Lucene のインデックスを参照するための GUI ツールです。Lucene のインデックスを参照するツールなので，Elasticsearch のインデックスも参照可です。 Lucene/Solr8 からはこの Luke が標準で組み込まれることになりそうです。

New Lucene features

• 転置インデックスから検索するアルゴリズムを Block-Max WAND にすることで一部クエリが高速化
• PageRank を実現できるような情報をフィールドに格納できるように
• Soft deletes が実装

Lucene/Solr8 の新機能は上記のようなことが挙げられます。検索アルゴリズムが変わったことで，クエリが高速化されるのが大きいでしょうか。これは特に dismax で顕著だそうです。WAND は OR 検索において高速化されるので，これの影響かもしれません。

Soft deletes は Soft Commit と同様，ディスクに対して手をつけないので，例えばドキュメントの変遷を見るようなことが可能になります。揮発性なので使いどころは難しいかもしれませんが。

総括

カンファレンス全体としては，Lucene/Solr のコアな機能に対するセッションが少なく感じ，エンジニア向けではなくなってきた感触は否めませんでしたが，逆に新規参入者の風のようなものはこれまでよりも大きく感じられました。カンファレンス参加者の 85% が初参加というのも頷けます。個人的には Solr のパフォーマンスを上げるようなスキーマ設定や，プラグインの紹介，アンチパターン紹介のセッションが増えてくれると嬉しいです。

本カンファレンスには大きな世界地図のボードがあり，参加者は自分の国に押しピンを刺せるようになっていました。これを見ると，本カンファレンスには世界各国から参加者がいることが分かります。

と言っても，欧米諸国がほとんどで，アジアはほとんどいないことが分かります。（日本人は4名）

カンファレンス最終日は，毎年恒例，日本人の方とモントリオールの夜を楽しみました。モントリオールの街は非常にオシャレで，本当に欧州に来たような気にさせてくれます。現在はエア・カナダが直行便を出しているのですが，それまでは便が悪かったことから，お金と時間に余裕のあるセレブの方々だけが行くような街だったとのことです。東京オリンピックが終わるまでは成田-モントリオール間でエア・カナダが直行便を出しているので，楽に行けます。旅行好きな方はこの機会に是非，北米のパリを堪能してはいかがでしょうか。