▲

Elasticsearch와 MongoDB를 Rust와 RocksDB로 교체한 방법

 (radar.com)
4P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • Radar는 하루 10억 건 이상의 API 요청을 처리하는 지리정보 인프라를 제공하며, 성능 및 확장성 문제를 해결하기 위해 기존 Elasticsearch와 MongoDB를 자체 개발한 HorizonDB로 전환함
  • HorizonDB는 Rust로 개발되었으며, RocksDB, S2, Tantivy, FST, LightGBM, FastText 등 다양한 오픈소스 도구를 결합한 고성능 지리정보 데이터베이스
  • 기존 구조에서는 Elasticsearch와 MongoDB의 확장 비용 및 복잡성이 커서 운영에 어려움이 있었음
  • HorizonDB는 단일 멀티스레드 프로세스 기반으로 동작하여 비용 절감, 성능 개선, 높은 신뢰성을 달성함
  • 전체적으로 개발 생산성과 운영 효율이 크게 향상되어, 신규 데이터나 기능의 신속한 적용이 가능해짐
  • 데이터는 Apache Spark로 전처리 후 AWS S3에 버전별 저장되며, 개발자가 로컬에서도 쉽게 실행·테스트 가능
  • 이로써 Mongo 및 Elasticsearch 클러스터를 종료하고 비용을 크게 절감하며, 기능 개발 속도와 데이터 처리 효율을 개선함

소개 및 배경

  • Radar는 전 세계 수억 대 기기에서 하루 10억 건 이상의 API 콜을 처리하는 지오로케이션 인프라 플랫폼임
    • 주요 API Geocoding, Search, Routing, Geolocation compliance 등
  • 데이터 규모와 제품이 확장됨에 따라 고성능·확장성·비용 문제 해결이 시급해짐
  • 이를 위해 Rust로 작성한 HorizonDB를 도입, 다양한 위치 서비스 기능을 하나의 고성능 바이너리에서 제공함
    • 코어당 1,000 QPS 처리
    • 포워드 지오코딩 중간 지연 50ms, 리버스 지오코딩 <1ms
    • 범용 하드웨어에서 선형 확장 가능

기존 시스템의 한계

  • 이전 구조: 전방향 지오코딩은 Elasticsearch, 역방향은 MongoDB로 처리
  • 문제점:
    • Elasticsearch는 쿼리를 모든 샤드에 분산, 주기적으로 배치 업데이트 필요
    • MongoDB는 대용량 배치 입력이 어려우며, 과도한 리소스 할당 및 안정적인 롤백 기능 부재

HorizonDB 아키텍처 목표

  • 효율성 - 일반 하드웨어에서 동작, 예측 가능한 오토스케일링, 모든 지오 엔티티의 단일 데이터 소스 역할
  • 운영성 - 데이터 자산을 하루에도 여러 번 빌드 및 처리, 변경·롤백이 용이, 운영 간소화
  • 개발 경험 - 로컬 환경에서 실행 가능, 변화 및 테스트 손쉬움

사용 기술 스택

RocksDB, S2, Tantivy, FSTs, LightGBM, FastText 등 여러 오픈소스를 활용하며, 데이터는 Apache Spark로 전처리 후 Rust에서 S3에 버전 관리 파일로 저장

  • Rust

    • 모질라에서 개발한 시스템 프로그래밍 언어
    • 컴파일 및 메모리 안전성 보장, 가비지 컬렉션 없이 예측 가능한 대용량 인덱스 메모리 관리 가능
    • Null 처리, 패턴 매칭 등 고수준 추상화 지원해 복잡한 검색 랭킹 로직을 표현 쉽게 함
    • 멀티스레드 단일 프로세스로 SSD에서 수백 GB의 데이터 처리에 최적화

  • RocksDB

    • 고성능 LSM 트리 기반 인프로세스 저장소
    • 마이크로초 단위 응답, 대용량 데이터에도 안정적인 속도

  • S2

    • Google의 공간 인덱싱 라이브러리로 지구를 사분면으로 분할해 점-다각형 조회를 고속화함
    • Radar는 C++ S2 라이브러리의 Rust 바인딩을 자체 개발, 곧 오픈소스 공개 예정

  • 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 도입 결과

  • 서비스가 대폭 빨라지고 운영이 단순화, 신뢰성 개선
  • 개발팀이 새로운 기능과 데이터 소스를 하루 만에 적용 및 평가 가능
  • Mongo, Elasticsearch 등 대규모 클러스터 및 여러 마이크로서비스 종료로 월 수만 달러 절감
  • Radar는 향후 대규모 확장에 대응할 준비를 마침. 특정 기능 설계 과정에 대해서는 향후 블로그에서 소개 예정
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 자세한 내용이 부족하고 오픈소스 계획도 없는 것 같음에 아쉬움을 느낌, 혹시 ES(ElasticSearch) 대체 방안을 찾다 이 글을 클릭했다면 typesense.org와 duckdb.org(특히 spatial 플러그인 포함)를 추천하고 싶음, 두 서비스 모두 공간 데이터 성능이 우수하고, DuckDB는 변경이 적은 데이터에 대해 실서비스에 쓰기에도 아주 좋아 보임, 클러스터/샤딩 구성에서도 완전한 오픈소스임, 별 연관은 없고 순수한 사용 경험 기반의 추천임

    • 이 두 프로젝트 정말 훌륭함, 우리 팀도 DuckDB를 데이터레이크 검사와 간단한 데이터 가공에 적극적으로 사용 중임, 앞으로 시스템의 다양한 부분을 자세히 설명하는 블로그 글을 추가할 계획임, 한 포스트에 너무 많은 내용을 담으면 읽기 어렵다고 우려해서 내용 분산을 결정함

    • 이런 오픈소스 프로젝트가 있다는 점에 늘 감사함, 하지만 내 프로젝트에 통합하는 건 쉽지 않게 느껴짐, 예전엔 duckdb와 spatial, SQLite 확장들을 정적으로 링크해서 빌드하려다가, 서로 다른 버전의 SQLite 심볼 때문에 빌드가 실패해서 벅차다는 것을 깨달음

    • DuckDB는 샤딩이나 클러스터링이 전혀 없지 않음? 서버도 따로 없고(HTTP Server Extension 말고는)

    • Typesense는 성능이 진짜 훌륭하고, 개발 경험도 정말 만족스러움

    • 뭘 오픈소스화할지는 잘 모르겠음, 러스트 코드일까? DB라고 선언하고 있지만 사실 전체 스택을 설명한 느낌임

  • 구직 페이지에서 첫 번째 혜택으로 '오피스 근무 문화'를 강조하는 게 웃기다고 느껴짐, 통근이 어떻게 혜택인지 진심 궁금해짐

    • 통근 vs. 재택은 단순히 이동 시간뿐 아니라 근무 환경, 일과 삶의 균형 등 여러 요소가 있음, 실제로 통근 시간이 30분 이내이고 걷기나 자전거로 이동할 수 있을 때는 매우 즐거웠던 경험임, 운동도 되고 생각 정리도 되고, 집과 일의 전환도 되어줌, 2020년에 풀재택을 할 때는 같은 공간에서 일하고 쉬는 게 점점 힘들어져서, 매일 퇴근 후 한 시간씩 산책하면서 정신적으로 많이 회복했음, 다만 대중교통이나 고속도로로 한 시간 이상 출퇴근했던 적은 힘들었음

    • 오피스 문화가 정말 장점이 있으려면 똑똑한 사람들과 배울 기회, 친구 만들기, 무료 음식/음료, DDR 머신 같은 게 있어야 한다고 생각함, 마지막 오피스 경험에서는 이런 장점이 전혀 없고, 집에서 일하는 것을 대형화한 느낌의 우울한 분위기였음

    • 어떤 사람들은 오피스 출근을 좋아할 수 있음, 사람마다 다름

    • 나는 재택보다 통근을 선호함, 즉, '통근이 혜택'이라고 생각하는 사람 분명 있음

  • 이 시스템이 OSM(OpenStreetMap) 데이터를 위한 오픈소스 ElasticSearch/OpenSearch 엔진 Photon에 도움이 될지 궁금함, 대부분의 OSM 앱에서 검색 경험이 별로고, 오타에도 약한데 Photon은 이 문제에 작은 혁신을 가져옴, Photon 깃허브 링크

    • 이 경우 RocksDB보다 LMDB로 구축된 시스템이 더 잘 맞는다고 생각함, 참고로 OSM Express는 이미 LMDB를 사용하고 있음, OSM Express 위키 링크

  • 메타한 의견이지만, 다시 자체 데이터 저장소나 쿼리 엔진 설계, 블로그 글이 활발해지는 모습이 반가움, 2010년대에 이런 붐이 있었고 최근엔 AI 쪽에 집중 추세였음

    • 그런 붐이 AI 때문이 아니라, 대부분 쓸모가 없다는 게 판명나서였다고 생각함, 기존 시스템을 조정하거나 확장으로 충분히 성능을 맞출 수 있으니 지나치게 특화된 자체 스택은 결국 필요하지 않았음, 제품으로 팔 계획이 없는 사내 전용 스토리지/쿼리 시스템은 결국 리소스 여유 있는 회사의 NIH(Not Invented Here) 신드롬임

    • NoSQL/대체 데이터베이스가 한때 유행처럼 번지다가, 결국 대부분의 기업에 Postgres 하나만으로 충분하다는 게 알려지면서 사그라짐

    • 아직 더 혁신할 것이 남아 있는지 모르겠음, 실험적인 데이터 저장소보다 믿을 수 있고 검증된 제품을 원함

  • 기사 제목에 "Rust"라는 언어 자체가 포함된 게 이상하다고 느낌, 독자라면 Rust가 뭘 대체하는지—ElasticSearch 인지 MongoDB 인지—헷갈릴 수 있다고 생각함

  • 이 아티클은 너무 세부 정보가 부족함, 예를 들어 데이터 샤딩 방식, 인덱싱과 서비스 간 시간차, 장애 노드 처리, 분산 시스템에서의 지연 시간 등 여러 핵심적인 내용이 빠져 있음

  • 검색 분야에 있는 입장에서, 최근 들어 얼마나 많은 회사들이 "ElasticSearch 대체"를 목표로 하는지 흥미롭게 지켜보고 있음

    • 글 작성자임! 운영 관점에서 "분산 시스템" 문제를 "모놀리식 시스템"으로 전환하는 데 동기부여를 받아, 최근 하드웨어로도 충분히 가능하다는 생각에 RocksDB, Tantivy 같은 임베디드 스토리지 시스템을 택함, 메모리 매핑 덕분에 전 세계를 커버하는 상황도 충족할 수 있었고, 클라우드라 RAM 증설도 자유로움, 데이터 백필과 업데이트는 ES/Mongo와 현재 상태를 따로 신경 쓸 필요 없이, 같은 바이너리로 새 노드에서 전체를 리인덱싱 후 S3로 전송하는 방식으로 간단히 처리함

    • ElasticSearch 클러스터를 운영하고 관리하는 데 드는 노력과 시간이 실제 운영 데이터베이스보다 훨씬 크게 느껴질 때가 많았음, 이런 점 때문에 여러 상황에선 ES 전체 기능이 아닌 소수 기능만 제공하면서 더 단순하고, 망가질 일 적은 대안을 쓰고 싶다는 생각이 강함

  • 여러 회사가 자신에게 꼭 맞는 솔루션을 조합하는 사례를 보는 게 흥미로움, 특히 처음부터 자체 솔루션을 개발하기보다 상용 오픈소스 툴을 활용해 시작한 점을 긍정적으로 봄, 참고로 Tantivy에서 알게 된 Quickwit이 눈에 들어옴, Lucene 기반의 ES와 비슷한 느낌임, Quickwit 깃허브 링크

    • tantivy임 :)

  • Rocks는 Level의 포크이고, Level은 데이터 손상 등 버그로 잘 알려져 있음, 두 시스템 모두 프로덕션에서 많이 쓰였지만, 내가 Level을 썼을 때는 운영팀이 서비스 유지를 위해 에러 처리에 엄청난 고생을 했음, 이런 회사 블로그 포스트는 신기술 스택의 단점이나 심각한 이슈를 절대 솔직히 얘기하지 않음, '빅네임 기업'의 테크 토크도 결국 자기 회사 스토리 광고임

    • RocksDB는 이미 오래전에 LevelDB와 갈라서, 산업계와 학계에서 대규모 개선이 이루어진 상태임, 이제는 LevelDB와 달리 토이 데이터베이스가 아니라고 생각함, 혹시 발견하지 않은 단점이 있을 수 있지만, RocksDB에서 올 문제 가능성은 희박하다고 봄

    • 내 경험도 다름, 지난 4년간 RocksDB를 수천 대의 서버(서버당 수 테라바이트 데이터)에서 돌렸지만 RocksDB 자체에서 오류가 발생한 적 없음

  • Elasticsearch라는 키워드 때문에 클릭했는데, radar.com을 몰랐던 게 신기했음, 내가 필요로 하는 적당한 가격대의 오토컴플릿 기능이 보여서 관심이 감

답변달기