「AI空間設計」の家具データ
別の記事でVR空間に家具を配置する「AI空間設計」の基本的な実装方法について解説しました。その際は使用した家具は１種類のソファだけでしたが、実際の「AI空間設計」の中では、さまざまな家具ブランドから提供された家具を自分好みに選んで配置することができます！今回はその家具のデータを扱う中で発生した問題とその対応をお話しさせていただきます。
インフラ構成
「AI空間設計」のインフラ構成は下画像のようになっています。
家具のデータはユーザーがアクセスする「スペースリー」のWebアプリケーション(Ruby on Rails)の他に、家具を配置した部屋のパノラマ画像を生成するアプリケーションと、部屋に家具を自動で配置するための計算を行うアプリケーションの２つのサービスで使用されます。そのため、家具データはRailsで使用しているMySQLではなく、別サービスとして切り分ける必要がありました。家具ブランドはスペースリーのユーザーではないので、データは家具ブランドからスプレッドシートのような形式で個別に受け取り、それをスペースリーの内部でアップロードする、というフローになります（将来的には各ブランドがユーザーとしてアップロードできるようになる予定です）。
今回は上図の赤く囲まれた部分がトピックです。家具データはDocumentDBに保存し、その前段にFastAPI+motorで構築されたREST APIサーバーを置いて、各サーバーにデータを渡しています。アクセスは３つのサービスに限定し、ユーザーが「AI空間設計」を使用する際の認証はRailsアプリケーションで行います。DocumentDBはMongoDBのインターフェースに則ったデータベースで、スキーマレスのドキュメント形式でデータを扱うことができます。家具ブランドから提供されるデータがバラバラで、スキーマをガチッと決めることが開発当初は難しかったので、家具データにはRDBMSではなく、スキーマレスのDocumentDBを使用することにしました。
発生した問題
最初はとにかく「AI空間設計」をリリースする、というゴールに向かって突っ走っていて、多少の問題は横に置いていたのですが、リリースしてからいくつかの問題が顕になりました。主に、
- レイテンシーの増大
- 家具データの管理
- フリーワード検索での同義語対応
という３つの問題に直面しました。
レイテンシーの増大
「AI空間設計」をリリースして事業者様の利用が徐々に増えてきたのですが、それに伴って家具データサービスのロードバランサーのレスポンス時間が増大していることが確認されました。各処理の時間を計測したところ、motorによるDocumentDBへのクエリで300ms近くかかっており、この部分が原因とみて調査しました。実際のアプリケーションよりも非常にシンプルなクエリを実行してみても同様の遅延が発生し、試しにDocumentDBを同様の構成のMongoDB on EC2に置き換えてみたところ、そのような遅延は確認できませんでした。なかなか原因が特定できなかったのでAWSサポートに問い合わせしてみたのですが、明確な回答は得られず、ほぼ座礁状態になりました😭
家具データの管理
初期の家具データの整理・投入は3Dファイルの調整やスキーマの設計などの兼ね合いもありエンジニアが対応したのですが、それ以降のデータの管理は家具ブランドとやりとりをするビジネスサイドにお願いした方が当然効率的です。ただ、そのためには別途管理画面を作成する必要がありますが、その開発リソースをなかなか確保できず、後回し後回しになっていました😅
フリーワード検索での同義語対応
最初のリリース時は家具の種類が少なかったということもあり、最小限のフィルタ機能しか用意していなかったのですが、家具が一気に増えたタイミングがあり、同義語に対応したフリーワード検索機能の必要性が高まっていました。例えば、「椅子」を調べた場合でも、「チェア」や「スツール」を表示するようなパターンです。ただし、我々はあくまでVRや空間データをコア技術として扱っており、検索機能の開発に大きなリソースは割きたくない、というのが正直なところでした。
データ移行/検索ツール導入
上記のような複数の問題を解決するために、既存のDocumentDBを中心としたインフラ構成を変更することを検討し始めました。
検討したツール
本格的な移行検討のきっかけは検索の同義語対応ということもあり、検索性とその管理の容易さに重点を置いて、いくつかのツールを調べました。
ElasticSearch
2010年公開ということで、検索ツールの老舗というイメージがあります。OSS版とSaaS版が存在します。多機能で非常に複雑なアプリケーションの検索機能としても使えるようですが、「AI空間設計」の家具のデータは非常にシンプルなので、ここまで多機能だと逆に運用が面倒になりそうだと感じました。
Algolia
2012年公開で意外と長いサービスです（今回の調査でAlgoliaの存在を初めて知りました笑）。OSSではなく、SaaSのみ提供されています。洗練された管理画面が用意されていて、シンプルで非常に使いやすく、最終的にこのツールの導入をすることになりました。
Typesence
2015年公開の比較的新しい検索サービスです（これも知らなかったです）。"The Open Source Algolia Alternative. The Easier To Use ElasticSearch Alternative."を謳っていることもあり、シンプルで使いやすそうでした。ただ、Algoliaと比較するとまだ機能的に不足している部分があるのと、我々としてはSaaSを利用することを前提としていたこともあり、Algoliaと比較した場合の優位性はそれほど感じられなかったので、今回は見送りました。今後注視すべきツールであるな、と感じました。
MongoDB Atlas
MongoDBが提供しているクラウドデータベースサービスです。DocumentDBはMongoDBのインターフェースに則っているものの、内部ではRDSを使用していて、純粋なMongoDBとは異なるのですが、AtlasはMongoDBが提供していることもあり、当然純粋なMongoDBが使用されています。Atlasに標準装備されているAtlas Searchという機能がフリーワード検索での同義語対応をしていて、既存のコードを少し書き換えるだけで同義語への対応ができました。ただし後述しますが、今回は導入を見送りました。
なぜAlgoliaを選択したのか？
最初はMongoDB Atlasを導入するつもりで、実装も進めていました。その大きな理由としては、置き換えるのはあくまでDocumentDBで、前段の家具データのAPIサービスについては今後も使用し続ける、と考えていたからです。その前提では、DocumentDBへのクエリの実装はほとんど変える必要がなく、検索性に関しては要件を満たしており、最も導入コストが低いと思われました。レスポンス時間についても調査してみましたが、特に問題は見られませんでした。
しかし、他のメンバーの意見で気がついたのですが、そもそも前段のAPIサービスを含めて丸っと置き換えてしまう、という視点が抜けていました。このサービスはDocumentDBからデータを取得して返すだけの非常にシンプルなREST APIだったので、Algoliaのような検索ツールで十分置き換えられるものでした。Atlasでも機能の実装はできるものの、依然として管理画面を自前で用意する必要がある、という問題は解決できませんし、何よりもAPIのメンテナンスは半永久的に存在します。Algoliaに置き換えてしまうことで、コードの保守が不要になり、また非エンジニアでも簡単に扱える管理画面が最初から用意されている、というのは非常に大きなメリットでした。
データ移行
Algoliaを導入することになり、DocumentDBのデータを全てAlgoliaに移行する作業が発生しました。データベースの移行というのは初めての経験だったので、やる前はかなりビビっていたのですが、やってみるとめちゃめちゃ簡単でした笑。AlgoliaはMongoDB/DocumentDBと同様にJSONに似たドキュメント形式のデータを扱っているので、データ構造を全く変更せずに、簡単なPythonスクリプトを記述するだけで移行できました。
データ移行後、関連する各アプリケーションの実装を修正し、最終的にインフラ構成は下画像のようになりました。特に何も対応していませんが、レイテンシーも健全な状態になりました。
Algoliaを導入してみて
Algoliaでの運用が始まって感じたことは、デメリットはほとんどなく、メリットしかない、でした。もちろんデータのI/Oに関して複雑な処理が必要になってきたらAlgoliaだけでは対応できなくなると思われますが、今のところ家具のデータに関してはそのような処理は発生しない見込みなので、Algoliaで十分なはずです！開発当初は、アプリケーションを構築ためにコードを書くのが当たり前！、と考えていたような気がします。。。ノーコード・ローコードで済ますことができる機能に関しては、積極的にそのようなツールを使った方がコアの開発に集中できるんだな、と実感しました。今後もどんどん便利なツールは増えていくと思われるので、要注目ですね！！
