RocksDB
A library that provides an embeddable, persistent key-value store for fast storage.
Elasticsearch와 MongoDB를 Rust와 RocksDB로 교체한 방법
소개 및 배경
- Radar는 전 세계 수억 대 기기에서 하루 10억 건 이상의 API 콜을 처리하는 지오로케이션 인프라 플랫폼임
- 주요 API Geocoding, Search, Routing, Geolocation compliance 등
- 코어당 1,000 QPS 처리
- 포워드 지오코딩 중간 지연 50ms, 리버스 지오코딩 <1ms
- 범용 하드웨어에서 선형 확장 가능
기존 시스템의 한계
- 이전 구조: 전방향 지오코딩은 Elasticsearch, 역방향은 MongoDB로 처리
- 문제점:
- Elasticsearch는 쿼리를 모든 샤드에 분산, 주기적으로 배치 업데이트 필요
- MongoDB는 대용량 배치 입력이 어려우며, 과도한 리소스 할당 및 안정적인 롤백 기능 부재
HorizonDB 아키텍처 목표
- 효율성 - 일반 하드웨어에서 동작, 예측 가능한 오토스케일링, 모든 지오 엔티티의 단일 데이터 소스 역할
- 운영성 - 데이터 자산을 하루에도 여러 번 빌드 및 처리, 변경·롤백이 용이, 운영 간소화
- 개발 경험 - 로컬 환경에서 실행 가능, 변화 및 테스트 손쉬움
사용 기술 스택
RocksDB, S2, Tantivy, FSTs, LightGBM, FastText 등 여러 오픈소스를 활용하며, 데이터는 Apache Spark로 전처리 후 Rust에서 S3에 버전 관리 파일로 저장
- Rust
- 모질라에서 개발한 시스템 프로그래밍 언어
- 컴파일 및 메모리 안전성 보장, 가비지 컬렉션 없이 예측 가능한 대용량 인덱스 메모리 관리 가능
- Null 처리, 패턴 매칭 등 고수준 추상화 지원해 복잡한 검색 랭킹 로직을 표현 쉽게 함
- 멀티스레드 단일 프로세스로 SSD에서 수백 GB의 데이터 처리에 최적화
- 고성능 LSM 트리 기반 인프로세스 저장소
- 마이크로초 단위 응답, 대용량 데이터에도 안정적인 속도
- Google의 공간 인덱싱 라이브러리로 지구를 사분면으로 분할해 점-다각형 조회를 고속화함
- Radar는 C++ S2 라이브러리의 Rust 바인딩을 자체 개발, 곧 오픈소스 공개 예정
- 효율적 문자열 압축·접두어 검색 데이터 구조
- 쿼리의 80%가 규칙적인 “행복 경로(happy-path)”임을 반영, 메모리 수 MB로 수백만 경로 캐시 가능
- Lucene과 유사한 인프로세스 역색인 라이브러리
- 기존 Elasticsearch 같은 외부 서비스 대신 도입 이유:
- 검색 품질 - 동적 키워드 확장 등 고급 검색 처리에 UML 통신 지연 없이 대응
- 운영 단순화 - 단일 프로세스 내 처리, 대용량 인덱스도 메모리 맵핑으로 손쉬운 확장 가능
- 자체 코퍼스와 로그로 학습된 FastText 모델을 이용해 단어의 벡터 표현 생성, ML 응용에 활용
- 오타 및 미등록어에 강인하며, 인접 벡터의 의미 유사성을 활용해 검색 의미 이해 가능
- 질의 의도 분류, 질의 내 속성 태깅 등 다수의 LightGBM 모델 활용
- 예: “New York” 등 지역 질의는 주소 검색 생략, “841 Broadway” 같은 경우 POI/지역 탐색 건너뛰기
- 수억 건 데이터 포인트를 1시간 이내 고속 처리, 조인/집계 성능 향상을 위해 작업 지속 개선
- 최종 데이터는 S3에 저장되어, Amazon Athena나 DuckDB 등으로 SQL 기반 결과 탐색 가능
HorizonDB 도입 결과
- 서비스가 대폭 빨라지고 운영이 단순화, 신뢰성 개선
- 개발팀이 새로운 기능과 데이터 소스를 하루 만에 적용 및 평가 가능
- Mongo, Elasticsearch 등 대규모 클러스터 및 여러 마이크로서비스 종료로 월 수만 달러 절감
- Radar는 향후 대규모 확장에 대응할 준비를 마침. 특정 기능 설계 과정에 대해서는 향후 블로그에서 소개 예정