ファンド検索の最適化

f:id:monex_engineer:20190910111405j:plain


こんにちは。マネックス・ラボの戸谷です。

今回はマネックス証券の投資信託の検索システムを最適化したお話をしたいと思います。

fund.monex.co.jp

今までのシステム構成

今までのシステム構成

これまでのファンド検索は上記のように、すべて EC2 で構成・実装されていました。

( 認証・認可、バックエンド構成、Akamai などは省略しています)

ユーザーが検索を行うと、フロントの EC2 内にある Tomcat が検索条件を解析し、MongoDB に対して検索リクエストを行い、結果をユーザーに返却する流れになります。

EC2 のデメリット

以下の点で EC2 はハードウェアの保守は不要なものの、ほとんどレンタルサーバーと変わらず、業務要件の実装と、インフラを切り離しきれていません。

  • OSの保守が必要
  • ミドルウェアの保守が必要
  • 上記の知識・対応ができる人員確保

リリースサイクルを早くし、エンドユーザーに早く価値を提供し、効率的に運用するためには、このデメリットは決して小さくないと思います。

そのため、できるかぎりフルマネージドなサーバーレスアーキテクチャにしたいと考えました。

現在のアーキテクチャ

現在のアーキテクチャ

現在のアーキテクチャは上記画像の中央になります。

理想としては一番右の形なのですが、現実的にまずは中央のように、検索していた MongoDB が動いている EC2 を 3台、無くし、新たに検索エンジンとして AWS の Elasticsearch というマネージドサービスを導入しました。

最終的には一番右のように、S3 から静的コンテンツや JavaScript を取得し、クライアント側で API や、検索エンジンから必要なデータを取得できる形にできればと考えています。

Elasticsearch は AWS コンソールからポチポチしていけば簡単に準備できるので、EC2 + MongoDB のようにインフラのリソースは不要です。

キーワード検索の改善

これまでは MongoDB という検索エンジンではないミドルウェアを利用してキーワード検索を実現していました。

そのため、なかなか思ったようにキーワードに合致した結果が得られないということもありました。

仕組みとしては、マネックス証券が持つファンド情報を形態素解析で分解し、類義語を組み合わせ、MongoDB にインデックスとして保存しておき、ユーザーから検索のリクエストが来たら、その検索ワードを形態素解析で分解し、MongoDB に保存していたインデックスと突き合わせる、といったことを自前で実装していました。

Elasticsearch は検索エンジンであるため、上記のことを自前で実装する必要がなく、単純にファンドの情報を保存しておくだけで済みます。

また、形態素解析や類義語だけでなく、重み付けや、N-Gram を使ったハイブリッド検索、全角・半角を揃える、平仮名とカタカナを揃える等、スマートに検索を行ってくれる上に、細かいカスタマイズにも対応しています。

この結果、現在は今まで特定のキーワードではヒットしなかった銘柄もヒットするように改善されています。

最後に

是非、この機会に投資信託の検索機能をご利用ください♪

fund.monex.co.jp

戸谷 洋紀マネックス・ラボ マネージャー