MNTSQの検索周りの構成の変遷

MNTSQ(モンテスキュー)株式会社で検索エンジニアをやっている溝口です。
MNTSQはMNTSQ CLM(ちょっと前までMNTSQ for Enterprise)という数十万件を超えるような契約書を管理するプロダクトを提供しており、以下のような検索機能を提供しています。

https://speakerdeck.com/mntsq/mntsq-careersdeck?slide=12 （公開時点）

今年の4月で入社してから2年が経ち、入社してからやってきたことの振り返りも兼ねて今回は検索処理周辺のコンポーネントの変遷をまとめてみました。

最初期(2020/08-2021/07)
Index sizeの増加に伴う変更(2021/08-2022/04)
インデクシングの高速化と複雑なクエリへの対応(現在)
(今後)マルチテナントへ
まとめ
この記事を書いた人

最初期(2020/08-2021/07)

検索エンジンとインデクシング処理をコンテナとして独立させ、間にELBを挟んでリクエストを分散していました。オンプレミスの環境では、インデクシング処理はコンテナとして独立させたものの、サーバ台数の都合からシングルノードで運用していました。 (MNTSQではAWS上だけでなく顧客の要件に応じてオンプレミスでもサービスを提供しているため、双方でよしなに動くようにインフラを設計する必要があります。)

¹, ²

Index sizeの増加に伴う変更(2021/08-2022/04)

契約の検索のみから、契約の管理へとプロダクトラインが広がるとともに検索エンジンが提供する機能と扱うデータ量も増加していきました。
また、契約書は契約書間で似たような条項が存在したり(MNTSQは条単位での検索も可能です)、微妙に言い回しの違う締結前のドラフトなど、場合によりますが検索結果としてはグルーピングして表示してほしいものなどがあります。そういった機能を検索処理側で行っているため、徐々に検索パフォーマンスが落ちていくという問題に直面しました。

特にAWS環境において従来の構成ではディスクI/Oによる検索速度の劣化が目立ってきたため、SREと相談してECS上での稼働をやめて自由度の高いEC2上に移動させ、ディスクをEBSからInstance storeに変更して速度劣化を解消しました。
ほぼ同時期にEC2のインスタンスをARMアーキテクチャに変更し、コストを維持したままCPUコア数を増やし、性能を最大80%程度向上させることに成功しました。

また、上記に加えてお客様が増えるにつれて当初の想定以上のデータをお持ちのお客様からの受注も頂いており、今後もデータ量の増加が予測できたことから、柔軟にシャード分割数を変更できるようにしました。

インデクシングの高速化と複雑なクエリへの対応(現在)

検索エンジンの役割が増えていくにつれて、変更された内容が登録 & 反映されるまでのリードタイムの影響が大きくなってきました。そのため、ソフトウェアエンジニアの沼井の力を借りてインデクシング処理をRuby on Railsに移管し、最大40%程度のリードタイムの短縮を実施しました。

また、当初は制約こそ非常に強いものの、それなりの結果を出せるようなクエリの仕組みを提供していましたが、より自由なクエリを提供する必要に迫られました。そのため、クエリパーサーを実装してクエリの自由度を上げるとともに、その状態でもより良い検索結果が提供できるようにアルゴリズムエンジニアの知見を検索処理に応用できるように、検索処理をRuby on RailsからPythonベースのFastAPIに移行しています。

³, ⁴, ⁵

(今後)マルチテナントへ

現在、MNTSQでは契約案件の管理プロダクトを開発中であり、そこでも検索エンジンを利用する機能を提供する予定です。
また、多くのお客様から受注をいただく中で、運用コストが非常に大きくなってきており、そこを減らすことが将来的に課題になると考えています。そのため、マルチテナントをデフォルトの構成とし、インフラのスケールメリットの追求と運用コストの低減を実現したいと思っています。

まとめ

MNTSQのこれまでの検索周りのインフラ構成を振り返りました。
紹介したのは大きめの変更をしたときのものですが、もっと細かい変化を含めるともっと活発に変化し続けています。

MNTSQの検索処理ではプロダクトの成長/プロダクトラインの増加、導入先の増加とともに進歩し続けています。その中で今回触れたような構成変更には当然SREやソフトウェアエンジニアとの協働が必要になってきます。また、当然ながら検索に利用するメタデータの抽出はアルゴリズムエンジニアが担当している場合が多いため、自然言語処理分野ではアルゴリズムエンジニアと協働することもあります。

上記のように検索処理はインフラ・ソフトウェア・アルゴリズム(自然言語処理)にまんべんなく携われるという魅力があるとおもいます。
検索処理以外でも、もしご興味を持っていただけたなら、右上の「採用ページへ」からご応募いただければ幸いです。