ElasticsearchとMongoDBをRustとRocksDBに置き換えた方法

• 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は今後の大規模拡張に対応する準備が整った。特定の機能設計プロセスは今後のブログで紹介予定