移行してわかった！AlgoliaとElasticsearchの違い

Penmarkの河村です。
PenmarkではFirebaseを活用してスマホアプリを開発しています。Firebaseはモバイル開発に必要な機能の殆どを提供してくれます。ただ一つ足りないのがデータベースの検索機能です。No SQLであるFirestoreはリレーショナル・データベース(以降RDBと記載)のLIKE検索のような検索機能は有りません。

Penmarkの最も重要な機能であるシラバス検索を行うためにAlgoliaを使っていましたが、2022年度のシラバスデータ投入のタイミングでElasticsearchに移行しました。このため、全く同じサービス・機能を両方の検索エンジンを用いて実装したわけですが、両方で構築することで、2つのサービスはかなり異なるということがわかりました。

今回はAlgoliaとElasticsearchの２つの検索サービスについて、何がどう違うのかを整理することで、これから検索サービスを導入しようと考えている人の参考になればと思います。

1. 背景

1章では背景として、Penmarkで何が起きたのかを簡単にご説明します。比較記事は2章になりますので、比較がすぐに見たい方は2章から読んでいただければと思います。

1.1. Algoliaの費用が…

PenmarkではFirebaseを用いてスマホアプリを開発しています。最も重要な機能として「シラバス検索」機能があります。日本の大学のシラバスデータを集めて、簡単に検索できる機能です。
この検索機能をAlgoliaを用いて提供していましたが、特に費用面が大変なことになってきました。

今年は約400大学のシラバスデータを格納しましたが、すべてを合計すると百万件以上の件数になります。Penmarkでは過去データも保持していますので、毎年数百万件単位のデータが増えていくことになります。 Algoliaはデータ件数に比例して費用も増えていきますので、その分費用も毎年跳ね上がってしまいます。来年あるいは再来年にいくらになるだろうか。という試算をしたところ、スタートアップにはかなり厳しめの金額が算出されてしまいました。

1.2. 代替案はないのか

Penmarkはスタートアップで開発メンバーも潤沢では有りません。開発コストや運用コストをできる限り抑えたい。と考えると、やはりクラウドベースのサービスから選ばないとということになります。

Firebaseのページに推奨されているのはAlgolia、Elasticsearch、Typesenseの3つですが、Google検索などで探してみても、やはりこの3つにたどり着きます。Typesenseが日本語対応が不十分だったので、Elasticsearchってどうなんだろう。もしコストが抑えられるなら…というのが移行を考えたきっかけです。

1.3. 移行しちゃえ！

という状況を踏まえ、昨年後半からElastic社にコンタクトを取り、営業の方、技術担当の方と何度か話をさせていただきました。それらを踏まえ、いけそう！と判断し、2022年度のシラバスデータ投入のタイミングからElasticsearchに移行しました。過去データももちろん移行しましたので、今年分も過去分もすべてElasticsearchで行っています。

1.4. 結果どうだったの？

料金ベースで言うとかなりのコストダウンに成功しました。
シラバス検索が多用される繁忙期(3月〜4月、9月〜10月）とそれ以外の閑散期とで大きく費用が異なりますが、閑散期だとマシンスペックをかなり落とせるので、1/10ぐらいの大きなコストダウンになっています。
もちろん費用は利用方法に大きく依存するので、他の方が同等レベルのコストダウンできるかというとわかりませんが、少なくともペンマークでは大幅なコストダウンになりました。

1.5. 両者の違いは？

ただ両方触ってみて、それぞれかなり特徴の異なるサービスだなというのを実感しました。Elasticsearchは構築する際に勉強しないといけないことが多く、あらためてAlgoliaの簡単さを痛感した。というのも事実です。両方の特徴を簡単にまとめると下記となります。

• Algolia
  検索エンジンに関する知識がほとんどなくても構築・運用可能。ただし、料金がかなり高い。

• Elasticsearch
  マネージドサービスのメリットをしっかり享受しながら、きめ細やな運用を行うことが可能。ただし、それを行うには相応の知識・勉強が必要。

次の章ではこのように感じた理由を整理したいと思います。

2. 移行してわかった！AlgoliaとElasticsearchの違い

1章で述べたとおり、両者は下記のような特徴があると感じました。

• Algolia
  検索エンジンに関する知識がほとんどなくても構築・運用可能。ただし、料金がかなり高い。

• Elasticsearch
  マネージドサービスのメリットをしっかり享受しながら、きめ細やな運用を行うことが可能。ただし、それを行うには相応の知識・勉強が必要。

2章ではこの様に感じた理由を、費用見積もり、環境構築、運用、機能の４つの観点で説明したいと思います。

2.1. 費用見積もり方法の比較

机上計算で費用が 見積もれるAlgolia。試してみないと費用が見積もれないElasticsearch。
サービス選定するにあたり、選定条件の大きな比重を占めるのが費用です。大抵の場合、導入前に概算費用の見積もりを行うと思います。その際の違いについて整理します。
まず両者の費用体系を簡単に整理します。

• Algolia
  Algoliaはレコード件数とリクエスト数の大きい方に比例して料金がかかります。ペンマークの場合、リクエスト数についてはかなり余裕があったので、事実上件数比例となっていましたが、両方の値が計算できれば見積もりも可能となります。詳しくはAlgoliaのホームページをご確認ください。

• Elasticsearch
  Elastic(ElasticCloud)はサービスを利用する際に、システム構成を決める形となります。サーバのスペックと、冗長構成をどうするかを選定でき、サーバのスペックを上げると費用があがる。冗長性を上げると費用が上がる。というような形です。サーバのスペック選定はAWSのEC2のスペックをどれにするかな。みたいな感じで、タイプとグレードがあるので適切なものを選べばよいです。 Elasticさんが提供している計算ページはこちらありますので気になる方は見てください。このページで提示される選択肢を全部決めたら費用が決まります。 ちなみに、サーバのグレードはサービス開始後もボタン一つで変更可能ですので、運用開始後にグレードを変更して費用を調整することも可能です。

両者は性能に対する考え方が大きく異なっており、料金体系もその差が現れています。
Algoliaはリクエスト数が増え、必要な処理性能が増えた場合は勝手に拡張して受け止めてくれます。リクエスト増に対するシステム的な対応(スケールアップ)はAlgolia側がすべて行い、あとからリクエストが増えた分を費用で請求される形となります。
一方でElasticsearchは、処理に必要なスペックの機器を選定することはユーザ側の責任になります。処理をこなすために十分なグレードを選定しておかなければいけません。ボタンひとつでスケールアップできるものの、ボタンを押すかどうかはユーザの責任です。
Elasticsearchを採用する際に問題なのは、どのスペックを選定したらどれぐらいの処理をこなせるのかは、作ってみないとわからないことです。なので、Elasticsearchでシステム導入前に費用見積もりを行うことは難しいです。 一方でAlgoliaはレコード数とリクエスト数という机上計算で予測が可能な値で費用が決まるので、概算見積もりは簡単に行なえます。
実際のところ、構築して検証したらElasticsearchの方が安いケースが圧倒的に多いのではないかと思うのですが、構築せずとも計算できるAlgoliaの方が見積もりは立てやすいです。

2.2. 構築難易度の比較

なんにもしなくて良いAlgolia、検索エンジンやインフラに関する知識が求められるElasticsearch。
ここでは、サービス提供するまでに必要な環境構築の難易度を比較します。
RDBで例えるなら、サーバ構築、データベース構築、テーブル作成、データ投入、検索リクエストを送るまでの範囲について比較します。

• Algolia
  Algoliaの場合は、サーバ構築、データベース構築、スキーマ作成はほぼ不要です。 サービスを契約したらIndex(＝テーブル)の名前を決めてあげるだけで、データ投入可能です。試しにやってみたい。というレベルであれば、Algoliaの画面からJsonファイルをアップロードするだけでデータ投入できます。検索するには、Webのコンソール画面で検索対象のフィールドを選択するだけで検索できます。環境構築という意味では何もする必要はなく、いきなりデータ投入して検索できます。
  Algoliaは検索用のAPIも比較的簡単です。Algoliaは検索対象となるフィールドや、ソート順などはWebのコンソール画面にて設定しており固定のため、検索時はキーワードと絞り込み条件を指定するぐらいで検索リクエストを構築できます。

• Elasticsearch
  Elasticsearchはやること一杯あります。 見積もりのところでも書きましたが、Elasticsearchは機器構成の選定はユーザが行う必要があります。これを選定して構築ボタンをポチッと押すと、RDBでいうところのサーバ構築、データベース構築までが完了します。
  次にMapping定義が必要です。これはRDBでいうところのテーブル作成にあたる作業です。Mapping定義は、Indexがどういうフィールドで構成されており、形態素解析で検索したい場合は、形態素解析用のフィールドを定義し、N-Gramで検索したい場合はN-Gram 用のフィールドを定義します。形態素解析とN-Gramを行うにはElasticsearchにプラグインを入れる必要があるので、その設定も行う必要があります。このあたりの設定方法については、Elastic社公式のドキュメントがありますので、気になる方はこちらを見てみてください。Mapping定義を行った上でその定義の通りのデータを投入すれば、検索が可能になります。
  Elasticsearchは検索対象となるフィールドや、ソート順、検索方法など、検索リクエストを送る際に動的に指定することが可能です。逆に言うとそれらを適切に組み立ててリクエストする必要があるので、リクエストパラメータは結構複雑なものを組み立てる必要があります。

さて、これを読んでいる皆さんは、特にElasticsearchの説明部分について理解できましたでしょうか。「形態素解析」「N-Gram」という言葉が出てきましたが、これはいずれも、日本語の全文検索の技術を語る上では常識といえる言葉なのですが、ご存知でしたか？
Elastic社が提供している「Elasticsearchで日本語の全文検索の機能を実装する」というドキュメントをみても、まず形態素解析とN-Gramの説明から始まっています。Elasticsearchで検索システムを構築するには、最低でもこれらの言葉の意味がわかるぐらいの知識は必要です。一方でAlgoliaの場合は、このあたりは完全に隠蔽されており、全文検索に関する知識が全く無くてもシステム構築可能です。
私が両方のサービスを触ってみて感じた一番の差はここでした。Algoliaは全文検索に関する知識が全く無くてもサービス構築可能ですが、Elasticsearchは、全文検索に関する知識がないと構築できません。

2.3. 運用面の比較

Elasticsearchはリソース管理を自分たちで行う必要がありますが、これを適切に行うことで非常に高いコストパフォーマンスが得られます。

両者の運用に関する違いを整理します。

• Algolia
  サーバの台数やスペックなどハードウェア的な要素は完全に隠蔽されており、リソース管理は何もしなくて良い。リクエスト数がドカンと増えたとしても何もする必要は有りません。Algolia側で勝手にスケールアップしてくれます。

• Elasticsearch
  障害対応などは不要ですが、サーバ構成、スペックはこちらで選定したもので運用されますので、Elasticsearch側で勝手に増減はしてくれません。リクエスト数がドカンと増えたときは、手動でグレードを変更するなど対応が必要です。

いずれもマネージドのサービスですので、障害対応という意味ではほぼなにもする必要はありません。
ただ、リソース管理(ディスク・CPU）については差があります。Elasticsearchは自分たちで選定しますので、性能が足りない状況なら、グレードを上げる作業を行う必要があります。
ただ、これらを自分たちで行うことがメリットであると思います。
Penmarkのシラバス検索は、履修登録を行う4月や10月はかなりの検索が行われます。一方でそれ以外の月はかなり検索頻度が落ちます。
このため、4月や10月はそれ相応のグレードの機器を用意しますが、5月になったらグレードを下げることで、コストも下げられます。
あくまでPenmarkの場合ですが、これを行うことで相当なコストダウンができたことは事実です。Algoliaは性能について何も考えなくて良いことがメリットですが、そのために必要以上のリソースを確保し、その分料金も高くなってしまってる。というような印象を受けます。
Elasticsearchで適切にスペックをコントロールする方が、適切な費用で運用可能です。

2.4. 機能面の比較

機能については両方とも必要十分だが、AlgoliaはIndexの考え方が特殊で落とし穴有り。
Penmarkでは時間割の検索に用いていますが、ここで必要な検索機能というのは高度な全文検索機能というよりはSQLで言うところのLIKE検索相当のものです。その前提で両者を比較すると、いずれも必要十分な機能はあります。
ただし、AlgoliaはIndexの考え方が若干特殊なので、これが問題になるかもしれません。AlgoliaではIndexを作成すると、検索対象とするフィールドや、ソートキーはIndexの属性として定義します。Webのコンソール画面で定義できるのですが、一つのIndexに対して一つの検索対象、一つのソートキーしか設定できません。
Algoliaで、「日付順と価格順で並び替えたい」というような複数のソートキーを使い分けたいという場合は、Indexをまるっと複製した「レプリカ」を作ります。レプリカはソートキーや検索対象フィールドなどをオリジナルのIndexとは別のものを指定できるので、属性の異なるレプリカを作成した上で、それを指定するという対応が必要となります。ElasticsearchやRDBのSQLのように、検索時に動的に指定する形ではないので注意が必要です。
レプリカ機能を使うことで、実現可能ではあるのですが、費用面で落とし穴があるので注意が必要です。料金が安いStandardプランを利用している場合は、レプリカを作るとそのレプリカの件数も費用の対象となります。つまり、レプリカを作ると料金も倍。ということになります。Premiumプランだと基本料金が上がるものの、レプリカを作ってもその件数は費用の対象とならないので、Premiumプランにアップグレードしたほうが安いかもしれません。機能としては実現できるものの、費用に大きく跳ねる可能性があるので、注意が必要です。
Penmarkでも昨年(移行前)に「シラバス検索を行う際に、履修者の数、レビューの数など、ソートキーを変更できるようにしたい」という要望が上がったのですが、その時にこの内容が発覚しました。試算の結果、Premiumプランに変更するのが一番安いとわかりましたが、Elasticsearchに移行することを決めていたタイミングだったので、プラン変更せずにElasticsearch導入後まで対応を見送ることにしました。
Algoliaでは複数のソートキーを使い分けたいというレベルの要望でも、できなくはないものの制約が発生してしまいます。

3.まとめ

いかがでしょうか。マネージドの検索エンジンとして代表的な２つのサービスですが、両方を触ってみることで、こんなにも違うのかと感じました。
コストや機能面を考えたときに圧倒的にElasticsearchをおすすめしますが、構築難易度が高いことも事実です。Penmarkもそうでしたが、サービス立ち上げ時など実装しなければならない機能がとにかく多いですので、たとえ料金が高くともAlgoliaでサクッと作った方が全体として得策ということもあるかもしれません。
それらを検討する際にこのノートが判断材料になれば幸いです。

エンジニア積極採用中です！

急成長するプロダクトを一緒に開発して頂けるエンジニアを積極採用中です。このノートで記載した検索エンジンの構築・開発・運用に携わりたい方はサーバーサイドエンジニアの枠で募集しています。
Penmarkのサーバーサイドエンジニアは、検索エンジンだけではなく、

• 大学のシラバスサイトをクローリングして、Elasticsearch・Firestoreに格納するシステム

• Penmarkの膨大なユーザのログを分析し、ユーザの行動を見える化する分析基盤

など、Penmarkのサービスを支える様々なシステムを構築しています。全体概要はこちらのページにまとめていますので見ていただけると嬉しいです。
新しい技術へのチャレンジもウェルカムな環境です。Elasticsearchへの移行も「やっちゃえ！」という感じで移行しましたが、新しい技術にチャレンジしてみたい人は是非一緒にチャレンジしましょう！

採用にこだわらず、技術やプロダクトの情報交換など、ゆるっと雑談するのもウェルカムです。Meetyにて話してみましょう。

ペンマーク採用情報はこちら
サーバーサイドエンジニアの採用情報はこちら

アプリのダウンロードはこちらから

• アプリHP：https://penmark.jp

• AppStore(iOS)：https://bit.ly/3NrsKNN

• GooglePlay(Android)：https://bit.ly/3LrDQSq