こんにちは。データマネジメントグループでデータサイエンティストをしている馬場と申します。最近はデータ品質をどう測っていくのかを考え実装したり、その前はレコメンデーションシステムを扱ったりしていたのですが、検索基盤周りが一段落したので何したのかを書き留めようと思い筆を取りました。
今回は何がしたくて検索基盤を作ったかと構成の話を書いていこうと思います。
検索基盤をこれから作られる方で、簡単/ サービスの乗り換え/ リアルタイムでのデータ更新などが気になった方は是非読んでみてください！
何をしたいか
なぜ検索したいのか？をいくつか書いていきたいと思います。
estieではestie proというサービスを提供しています。
estie proではオフィスビルの貸主さんや仲介会社さんが
- 建物情報
- 募集情報
- テナント情報
などのデータを分析することができ、それには必要なデータを検索する機能が不可欠です。
例えばそこから競合物件にどれだけ空室があってどんな賃料をつけていてどんなテナントが入居しているか、などを知ることで賃料の設定の参考にしたりマーケティング戦略を立てたりします。
その検索体験をより良いものにするには様々な課題がありそれを解決するために検索基盤を導入しようというのが今回の取り組みの骨子です。
では具体的にどういったことを解決したいのかを見ていきましょう。（未実装なものだけでなく現在のestie proでも対応済みの課題もあって、それを改善する、高速化するといった類のものを含んでいることをご留意ください。）
- ビルは表記揺れが激しい。
- 名前が変わることがある。（例えば持ち主が変わった場合など）
- 通称とか略称とかいっぱい。（例：丸の内ビルディング→丸ビル）
- アルファベット表記とカタカナ表記がある。（例えばestieが入っているビルもFORT TOWERだったりフォートタワーだったり表記が揺れています）
これは例えばシノニム（同義語）辞書というものに登録しておけば吸収できます。（OpenSearch/Elasticsearchにある機能です。）
これがあるとビルの正式名称を知らなくても検索に引っかかる可能性がますし、入力の手間も減るはずです。
- 検索ログをとって
- よく検索されるビルを検索結果上位に表示したい。
- 検索ログを分析してユーザー行動の理解を深化したい。
検索した時に探している物件が上の方にあると下の方まで見なくてもすぐ見つかって時間短縮できる/見逃す可能性が減るなどで嬉しい。オフィスは地域毎にベンチマークになる有名ビルというものがあることが多々あるので、そういうものは多くの人によく検索されます。上にあると便利ですよね。他にも自分の頭だけで考えていては思いつかないキーワードが提案させる、みたいなことも出てきてより分析が捗ることもありそうです。
検索ログについては今回構成部分の説明から割愛しましたが、ここだけで知見が貯まれば別途書きたいと思っています。（これは商業用不動産だからどう、とかはないと思いますが）
- 検索は文言だけではなく地理的なものも扱える。
例えばgeo_point（緯度経度を使う）を使えば基準となる地点から半径◯◯m以内にある競合ビル、ベンチマークしたいビルなどを取れたりします。（実際には物理距離よりもアクセスに依存するのでそのまま使うのではなく組み合わせるなどの工夫が必要となりますが）
基盤の構成
基盤を作るにあたり、いくつかの条件を満たすよう技術選定をしました。
- 簡単に（比較的短時間で）作れること。
- （簡単に作ることを前提に）必要があったときに他のサービスに乗り換えやすいこと。
- （ほぼ）リアルタイム性を持ってデータ更新ができること。
- データの処理フローが落ちた時にリカバリ策が充実していること。
RDSに検索したいデータが入っているのでまずはこれをそのまま検索エンジンに入れたい。あとで細かいブラッシュアップや随時置き換えは考えるがとりあえずサクッと入れるためにAWSで閉じた形で実装したいということで以下のようなものを使うことにしました。
- OpenSearch （検索エンジン）
- AWS Database Migration Service （データ移行ツール）
- Amazon Elastic Container Service （APIサーバーの置き場所）
OpenSearch
OpenSearch とは? - オープンソース検索エンジンの説明 - AWS
元々はAmazon Elasticsearchと呼ばれていたもの。
Elastic Cloudを使うことも考えたんですが、AWSで一旦作ってしまおうということでこちらを選択しました。
Elasticsearch 7.10.2から分岐しているので、記事を探したりする場合はOpenSearchだけでなくElasticsearchも併せて検索した方が思ってたのと近い内容が見つかることが結構ありました。
もしElastic Cloudに乗り換えるとしてもまだ分岐してからそこまで時間が経っていないので、今のところ（少なくともクエリや機能の）学習コストがあまり高くないので上で挙げた
- 他のサービスに乗り換えやすい
を満たしやすいかと思います。
AWS Database Migration Service（以降DMS）
DMSとはざっくりというとあるデータストアから別のデータストアにデータを移行させるサービスで、
今回はRDS（MySQL）からOpenSearchへデータを移行させよう、という用途で使っています。
詳しくはAWSのドキュメント。
AWS Database Migration Service とは - AWS Database Migration Service
この構成に決める前はKinesis Data Stream + Lambda + EventBridgeで定期的にデータを同期する、という方法も考えました。（実際Kinesis Data Streamでデータを送るまでは作ってみて比較しています。）
この辺りは他にEmbulkを使う、というのもやり方としてはありそうです。（実際以前いた会社で検索基盤を作ったときはEmbulkを使いました。）
他にもSecret Managerを使ってセキュリティを〜など細かいことはやっていますが大枠はこんな感じです。
DMSを選んでいるのは
- リアルタイム性を持ってデータ更新ができること。
をあまり工夫せずとも実現できそう、というのが1番です。（それがないなら割とKinesis Data Streamがアリかも、という所感です。他にもっといい方法があるかもしれないですが２つを比較した場合。）
加えてこのセクションで書いたようにいくつかの方法があるので、
- 必要があったときに他のサービスに乗り換えやすいこと。
も満たせているかと思っています。
Amazon Elastic Container Service（以降ECS）
Opensearchにアクセスしてクエリを書けば結果は得られるんですが、それだと利用者（といってもユーザーさんというよりは社内のアプリ開発者）が細かいクエリの書き方を学ぶ必要もあるし、それを書いてしまうとコードが汚くなるのでAPIを用意しています。今回はECSにFastAPIを乗せてそこでリクエストに対応した内容をOpensearchに問い合わせてそれをきれいにして返す、ということをやりました。
以下のような構成をとっています。
簡易な構成図
ちなみに私は最初に一度コンソールからポチポチやって作ったんですが、それをTerraform管理できるようにしてもらったり、ネットワークも設定してもらったりとSREに協力してもらいました。
大枠はざっと以上のような感じなのですが、いくつか考えておかないといけない事項があります。
DMSでデータをOpenSearchに送ると、
- 継続的なレプリケーション（移行元のデータソースの継続的な変更をキャプチャすることができるタスクAWS DMS を使用した継続的なレプリケーションのタスクの作成 - AWS Database Migration Service ）を選ぶことでMySQLで差分が出たらすぐに反映させることができる。
というメリットがある一方
- 継続的なレプリケーションはMySQL8.0に対応していない。MySQL 互換データベースの AWS DMS のソースとしての使用 - AWS Database Migration Service
- データの加工が簡単なものしかできない。（データの型を変えるなどはできる）
- 複数のカラムを計算して投入とかはできない。
といったことへの対応が必要です。まだ未対応ですが対応策は考えていて、
継続的なレプリケーション
EventBridge+Lambdaで定期実行をかける（総入れ替えになる場合はOpenSearchのindexを複数用意し切り替えることで対応）
(AWSがMySQL8.0以降に対応してくれると一番いいのですが、それを待ってたら間に合わそうな場合の対策です）データの加工が簡単なものしかできない
Kinesis Data Streamを使用し、加工内容をLambdaなどでコントロール
必要があればやりたいものの、複数のデータ移行方法が併存すると管理が汚くなるので現状は上に書いた構成で維持しています。
今後やりたいこと
今estieでは分析基盤としてSnowflakeの導入を進めています。ですのでRDSから直接ではなく、Snowflakeをかませる形でデータの流れを整理できたらいいな、と思っています。
以上検索基盤について書いてきたのですが、いかがだったでしょうか。
何かしらのお役に立てたなら嬉しいです。
同僚を募集しているので、
- 自分ならもっと上手く構築する/ここを改善したい
- 検索を使ってサービスを作りたい
- 不動産データ自体に興味がある
などといった方がいらっしゃればご応募お待ちしています！
