ElasticsearchとMongoDBをRustとRocksDBに置き換えた方法
(radar.com)- Radarは1日あたり10億件以上のAPIリクエストを処理する地理情報インフラを提供し、性能と拡張性の問題を解決するために既存のElasticsearchとMongoDBを独自開発のHorizonDBに切り替えた
- HorizonDBはRustで開発され、RocksDB、S2、Tantivy、FST、LightGBM、FastTextなどの様々なオープンソースツールを統合した高性能地理情報データベース
- 既存構成ではElasticsearchとMongoDBの拡張コストと複雑さが大きく、運用が困難だった
- HorizonDBは単一マルチスレッドプロセスベースで動作し、コスト削減、性能改善、高い信頼性を実現した
- 全体として開発生産性と運用効率が大幅に向上し、新しいデータや機能の迅速な適用が可能になった
- データはApache Sparkで前処理した後、AWS S3にバージョン管理された状態で保存され、開発者はローカル環境でも容易に実行・テストできる
- これにより、MongoおよびElasticsearchクラスタを廃止し、コストを大幅に削減するとともに、機能開発速度とデータ処理効率を改善した
紹介と背景
- Radarは、世界中の数億台のデバイスから1日あたり10億件以上のAPIコールを処理するジオロケーションインフラプラットフォームである
- 主要APIはGeocoding, Search, Routing, Geolocation complianceなど
- データ規模と製品が拡大するにつれて、高性能・拡張性・コストの課題を解決する必要が生じた
- そのため、Rustで作成されたHorizonDBを導入し、複数の位置情報サービス機能を1つの高性能バイナリで提供する
- コアあたり1,000 QPSの処理
- フォワードジオコーディング中間遅延50ms、リバースジオコーディング<1ms
- 汎用ハードウェアで線形スケール可能
既存システムの限界
- 以前の構成: フォワードジオコーディングはElasticsearch、リバースはMongoDBで処理
- 問題点:
- Elasticsearchはクエリを全シャードへ分散し、定期的にバッチ更新が必要
- MongoDBは大量のバッチ取り込みが難しく、過剰なリソース割り当てと安定したロールバック機能の欠如
HorizonDBアーキテクチャの目標
- 効率性 - 汎用ハードウェア上で動作、予測可能なオートスケーリング、すべての地理エンティティの単一データソース
- 運用性 - データ資産を1日複数回ビルド・処理、変更・ロールバックが容易で、運用簡素化
- 開発体験 - ローカル環境で実行可能、変更とテストが容易
使用技術スタック
RocksDB、S2、Tantivy、FSTs、LightGBM、FastTextなど複数のOSSを活用し、データはApache Sparkで前処理後、RustでS3にバージョン管理ファイルとして保存する
-
Rust
- Mozillaが開発したシステムプログラミング言語
- コンパイルおよびメモリ安全性を保証し、ガーベジコレクションなしで予測可能な大規模インデックスメモリ管理が可能
- Null処理、パターンマッチングなどの高レベル抽象化をサポートし、複雑な検索ランキングロジックを容易に表現
- 単一のマルチスレッドプロセスとしてSSD上で数百GBのデータ処理に最適化
-
RocksDB
- 高性能LSMツリー型インプロセスストレージ
- マイクロ秒単位の応答、巨大データでも安定した速度
-
S2
- Googleの空間インデックスライブラリとして、地球を四分割し点とポリゴンの問い合わせを高速化
- RadarはC++のS2ライブラリ用Rustバインディングを独自開発し、まもなくOSS公開予定
-
FSTs (Finite State Transducers)
- 効率的な文字列圧縮・プレフィックス検索データ構造
- クエリの80%が定型的な「ハッピーパス(happy-path)」であることを反映し、数MBのメモリで数百万の経路をキャッシュ可能
-
Tantivy
- Lucene類似のインプロセス逆インデックスライブラリ
- 従来のElasticsearchなどの外部サービスを使わずに導入した理由:
- 検索品質 - 動的キーワード拡張など高度な検索処理に対し、UML通信遅延なしで対応
- 運用簡素化 - 単一プロセス内で処理し、大規模インデックスでもメモリマッピングで容易に拡張可能
-
FastText
- 独自コーパスとログで学習したFastTextモデルを利用して単語のベクトル表現を生成し、ML用途に活用
- タイポや未登録語に堅牢で、近接ベクトルの意味的類似性を活用した検索意味理解を可能にする
-
LightGBM
- クエリ意図分類、クエリ内属性タグ付けなど多数のLightGBMモデルを活用
- 例えば“New York”のような地域クエリは住所検索を省略し、“841 Broadway”の場合はPOI/地域探索をスキップ
-
Apache Spark
- 数億件のデータポイントを1時間以内に高速処理し、ジョイン/集計性能向上のためジョブを継続的に改善
- 最終データはS3に保存され、Amazon AthenaやDuckDBなどでSQLベースの結果探索が可能
HorizonDB導入結果
- サービスは大幅に高速化し運用が簡素化され、信頼性が改善された
- 開発チームは新機能とデータソースを1日で適用・評価可能
- Mongo、Elasticsearchなどの大規模クラスターと複数のマイクロサービスを終了して、月に数万ドルを節約
- Radarは今後の大規模拡張に対応する準備が整った。特定の機能設計プロセスは今後のブログで紹介予定
1件のコメント
Hacker News の意見
詳細が不足していて、オープンソース化の計画もないようで残念です。もし ES（ElasticSearch）の代替案を探してこの投稿を開いたのであれば、typesense.org と duckdb.org（特に Spatial プラグイン含む）をおすすめしたいです。どちらのサービスも空間データの性能が高く、DuckDB は変更が少ないデータなら実運用で使うにもとても良さそうです。クラスター／シャーディング構成でも完全にオープンソースです。投稿者個人の使用体験に基づく推薦で、特に関連はありません。
この 2 つのプロジェクトは本当に優れています。私たちのチームも DuckDB をデータレイクの検査と簡単なデータ加工に積極的に使っており、今後もシステムのさまざまな部分を詳しく説明するブログ記事を追加する予定です。1 つの投稿に情報を詰めすぎると読みにくいので、内容を分散して載せることにしました。
こうしたオープンソース・プロジェクトがあることには常に感謝していますが、私のプロジェクトに統合するのは容易ではないように思います。以前、duckdb と spatial、SQLite 拡張を静的リンクでビルドしようとしたところ、SQLite のシンボルが異なるバージョンだったためにビルドが失敗し、難儀することが分かりました。
DuckDB はシャーディングやクラスター化が全くないんですか？サーバーが別にない（HTTP Server Extension を除く）
Typesense は本当に性能が良く、開発体験も本当に満足できます。
何をオープンソース化すべきか分からない、Rust のコードなのでしょうか？DB として宣言しているようですが、実際はスタック全体を説明した印象です。
就職ページで第一のメリットとして「オフィス勤務文化」を強調するのが可笑しいと感じます。通勤がどうしてメリットなのか、本当に不思議です。
通勤対リモートは、単純な移動時間だけでなく、勤務環境、ワークライフバランスなどの複数の要素があります。実際、通勤時間が 30 分以内で、歩いたり自転車で移動できるときはとても楽しかった経験があります。運動にもなり、頭の整理にもなり、家と仕事の切り替えにもなります。2020 年に完全リモートしていたときは、同じ空間で働き休むことが徐々に難しくなり、毎日退勤後に1時間ずつ散歩して精神的にかなり回復できました。とはいえ、公共交通や高速道路で 1 時間以上かけて通勤したことがある場合はつらかったです。
オフィス文化が本当にメリットになるには、賢い人たちと学ぶ機会、友人作り、無料の食事・ドリンク、DDR マシンなどが必要だと思います。最後のオフィス体験ではこうしたメリットは全くなく、在宅勤務を拡大したような暗い雰囲気でした。
いくらかの人はオフィス出社が好きかもしれません。人によって異なります。
私はリモートより通勤を好みます。つまり「通勤がメリット」と考える人は確かにいます。
このシステムが OSM（OpenStreetMap）データ向けのオープンソース ElasticSearch／OpenSearch エンジン Photon に役立つか気になります。ほとんどの OSM アプリの検索体験はあまりよくなく、誤字にも弱いですが、Photon はこの問題に小さな革新をもたらしています。Photon の GitHub リンク
メタ的な意見ですが、再び独自データストアやクエリエンジン設計、ブログ記事が増える動きが見られるのはうれしいです。2010 年代にもこのブームがあり、最近は AI 側への集中傾向がありました。
そのようなブームは AI のせいではなく、ほとんどが役に立たないと判明したからだと考えます。既存のシステムを調整・拡張すれば性能を十分に満たせるため、過度に専門化した独自スタックは結局必要ありませんでした。社内専用のストレージ／クエリシステムを製品として販売する計画がないのに作ることは、最終的にリソースのある会社の NIH（Not Invented Here）シンドロームです。
NoSQL／代替データベースが一時的に流行したように広がりましたが、最終的にほとんどの企業には Postgres 1 つで十分だとわかり、沈静化しました。
まださらに革新すべきことが残っているか分かりません。実験的なデータストアより、信頼性があり検証済みの製品を求めます。
記事タイトルに「Rust」という言語そのものが含まれているのはおかしいと感じます。読者なら、Rust が何を置き換えるのか（ElasticSearch か MongoDB か）迷うかもしれないと思います。
この記事は情報が非常に不足しています。たとえばデータシャーディング方式、インデックス作成とサービス間のタイムラグ、障害ノードの扱い、分散システムでのレイテンシなど、多くの重要な内容が欠けています。
検索分野にいる立場として、最近どれだけの企業が「ElasticSearch の代替」を目標としているかに興味を持って見ています。
投稿者です！運用面から「分散システム」を「モノリシックシステム」に移行する動機づけを受け、最近のハードウェアでも十分可能だと考えて RocksDB、Tantivy のような埋め込み型ストレージシステムを選びました。メモリマッピングのおかげで、世界中をカバーする状況も満たすことができ、クラウドなら RAM 増設も自由です。データのバックフィルと更新は ES／Mongo のように現在の状態を別途意識する必要がなく、同一バイナリで新ノードから全量をリインデックス後、S3 へ送信するという簡単な方法で処理しています。
ElasticSearch クラスターを運用管理するのにかかる手間と時間が、実運用データベースよりはるかに大きく感じられることが多いです。このため、さまざまな状況で ES 全機能を提供するのではなく、少数機能だけを使って、よりシンプルで壊れにくい代替を用いたいという思いが強くなります。
いくつかの会社が自社にフィットするソリューションを組み合わせる事例を見ているのは面白いです。特に最初から独自ソリューションを開発するより、商用オープンソースツールを活用して開始した点を肯定的に見ます。ちなみに Tantivy で知った Quickwit が目に入ってきました。Lucene ベースの ES に近い印象です。Quickwit の GitHub リンク
Rocks は Level のフォークで、Level はデータ破損などのバグでよく知られています。両システムとも本番で広く使われましたが、私が Level を使っていたときは運用チームがサービス継続のためエラー処理でかなり苦労していました。こうした会社ブログは、先進技術スタックの欠点や重大な問題を決して正直に話さないようです。「大手企業」のテックトークも最終的には自社ストーリーマーケティングです。
RocksDB は LevelDB からすでに長い間分岐しており、産業界・学術界で大規模な改善が行われています。もはや LevelDB のような玩具データベースではないと考えます。見つけられていない欠点があるかもしれませんが、RocksDB でバグ発生の可能性は低いと思います。
私の経験も異なります。過去 4 年間、数千台のサーバー（1 台あたり数テラバイト）のデータで RocksDB を運用しましたが、RocksDB 自体でエラーが発生したことはありません。
Elasticsearch というキーワードでクリックしましたが、radar.com を知らなかったのは不思議でした。必要としていた適切な価格帯のオートコンプリート機能が見えたため、関心を持ちました