背景

クラウドリンクスでは検索サービスとしてAlgoliaを採用していました。 Algoliaの問題点として、部分一致検索の機能はあるが、完全一致の検索機能がない点、データ量に応じた従量課金である点があります。今後、ユーザー数が増加していくことや検索機能を拡張していくには不安がある状態でした。

課題

検索サービスを選定するに当たって、下記の指標を作りました。

検索したい単語が綺麗に探し出せる 基本的に検索機能では、探したい単語(クラウドリンクスならユーザーのスキルや使用言語など)が的確にヒットする必要がある。

コストが安く済むか ここで言うコストとは、導入を行う際の技術的なコストと、料金面の話も入っています。

機能性・拡張性 カテゴリー、ソート、タイプなどの詳細な検索設定を構築することができるか。外部や内部のライブラリにより幅広いカスタマイズを行えるかどうか。

管理やモニタリングのしやすさ どのワードが一番検索されているかをモニタリングできると、今後の施策を展開する際に役立ちます。もちろん、裏側でサービスを使用していくに連れて増えていくデータの監視なども入っています。

調査

上記の観点を4つの項目に分け、Algoliaに変わる検索サービスの機能的な特徴を洗い出しました。 Algoliaでできていたことは当然移行後のサービスでもできて欲しいため、Algoliaを評価の基準としています。

	Algolia	Elastic Search	Amazon OpenSearch	Amazon CloudSearch
導入	・サービス登録から全て使用可能	・サーバー上で構築する必要がある・プラットフォームにkibanaを設定すると操作しやすい・Dockerコンテナイメージよりローカルで起動検証可能	・サーバー上で構築する必要がある・OpenSearch用のプラットフォームがある・Dockerコンテナイメージよりローカルで起動検証可能	・フルマネージド、すでにパッケージとして使用可能になっている・AWS上ですぐ試せる。・サーバレスプランならAlgoliaのようにすぐ使用可能(金額は高い)
実装	・JSONでindexを設定可能	・JSONでindexを設定可能・さまざまなライブラリが使用可能	・JSONでindexを設定可能・さまざまなライブラリが使用可能	・JSONでindexを設定可能・基本的な検索機能を使用可能
カスタマイズ	・検索機能は細かくいじれない・ファセットのカスタマイズはできる。・indexサイズに制限がある(100KB)	・詳細な検索設定を構築可能・ライブラリにより幅広いカスタマイズを行える・indexサイズ制限なし	・詳細な検索設定を構築可能・ライブラリにより幅広いカスタマイズを行える・indexサイズ制限なし	・細かめな検索設定が可能(カテゴリー、ソート、タイプなど)
管理	・プラットフォームが用意されているので、感覚的に使用することができる	・感覚的に操作可能。・全て英語ではあるが、日本語の設定もできる	・kibanaにて管理	・AWSのデザインで操作可能