indexing

Evolving our real-time timeseries storage again: Built in Rust for performance at scale (새 탭에서 열림)

데이터독(Datadog)은 급증하는 데이터 볼륨과 고카디널리티(high-cardinality) 워크로드를 처리하기 위해 Rust 기반의 6세대 실시간 시계열 데이터베이스 엔진을 새롭게 설계했습니다. 기존 시스템의 한계를 극복하기 위해 인제스션(Ingestion), 저장, 쿼리 실행 구조를 근본적으로 재구성함으로써 수집 성능은 60배, 쿼리 속도는 최대 5배까지 향상시키는 성과를 거두었습니다. 이 글은 지난 15년간 데이터독이 카산드라에서 시작해 Rust 기반의 전용 엔진에 이르기까지 거쳐온 기술적 진화 과정과 그 과정에서 얻은 교훈을 다룹니다. ### 데이터독 시계열 저장소의 아키텍처 데이터독의 메트릭 플랫폼은 데이터의 효율적인 처리를 위해 실시간 저장소와 인덱스 데이터베이스를 분리하여 운영합니다. * **RTDB (Real-time DB):** `<timeseries_id, timestamp, value>` 형태의 원시 메트릭 데이터를 저장하고 집계하며, 최신 데이터를 실시간으로 서빙합니다. * **인덱스 데이터베이스:** 메트릭 식별자와 태그 정보를 `<timeseries_id, tags>` 형태로 관리합니다. * **데이터 흐름:** 쿼리가 발생하면 상위 서비스가 RTDB와 인덱스 노드에 각각 접속하여 결과를 가져오고, RTDB 노드 내부는 인테이크(Intake), 스토리지 엔진, 스냅샷 모듈, gRPC 쿼리 실행 계층 등으로 구성되어 유기적으로 동작합니다. ### 1세대부터 3세대: 확장성과 운영 효율의 탐색 초기 데이터독은 기성 솔루션을 활용하며 실시간 쿼리 성능과 운영 편의성을 확보하는 데 집중했습니다. * **Gen 1 (Cassandra):** 뛰어난 쓰기 확장성을 제공했으나, 알람 및 분석에 필요한 복잡한 실시간 쿼리를 지원하기 어렵고 대규모 데이터셋 반환 시 효율이 떨어지는 한계가 있었습니다. * **Gen 2 (Redis):** 빠른 읽기 속도와 운영 가시성을 제공했지만, 싱글 스레드 특성상 라이브 트래픽 처리 중 스냅샷 작업이 어려웠고 데이터 직렬화/역직렬화에 따른 CPU 및 메모리 비용이 증가했습니다. * **Gen 3 (MDBM):** `mmap`을 통해 OS 페이지 캐시를 활용하는 메모리 맵 방식의 키-값 저장소를 도입했으나, 대규모 워크로드에서 성능과 정확성 이슈가 발생하며 명시적인 I/O 관리의 필요성을 체감했습니다. ### 4세대와 5세대: 커스텀 엔진과 기능 확장 성능 한계를 돌파하기 위해 범용 DB를 벗어나 전용 스토리지 엔진을 직접 구현하기 시작했습니다. * **Gen 4 (Go 기반 B+ Tree):** Go 언어로 구현된 커스텀 B+ 트리 엔진을 도입하여 '코어당 스레드(thread-per-core)' 모델의 기초를 닦았으며, 처리량과 지연 시간 면에서 큰 진전을 이루었습니다. * **Gen 5 (RocksDB 통합):** 분포 메트릭(distribution metrics)과 DDSketch 타입을 지원하기 위해 RocksDB를 병행 도입했습니다. 하지만 기존 Go 엔진과 RocksDB가 공존하는 구조는 관리가 복잡하고 효율성이 분산되는 결과를 낳았습니다. ### 6세대: Rust 기반의 통합 엔진으로의 전환 파편화된 엔진을 통합하고 성능을 극대화하기 위해 Rust를 선택하여 차세대 시스템을 구축했습니다. * **통합 및 최적화:** 스칼라 값과 스케치 데이터를 모두 처리할 수 있는 단일 엔진을 Rust로 구축하여 언어 차원의 안정성과 고성능 I/O 제어권을 확보했습니다. * **성능 성과:** 이 구조적 변화를 통해 데이터 수집 성능을 60배 높였으며, 피크 시간대 쿼리 속도를 5배 향상시켜 전례 없는 규모의 트래픽을 효율적으로 수용하게 되었습니다. **결론 및 추천** 시스템 규모가 커짐에 따라 범용 데이터베이스나 `mmap`과 같은 추상화 계층은 오히려 성능 병목이 될 수 있습니다. 데이터독의 사례처럼 워크로드의 특성에 맞춰 I/O와 메모리 레이아웃을 직접 제어할 수 있는 전용 엔진을 구축하는 것이 기술적 부채를 해결하고 폭발적인 성장을 뒷받침하는 핵심 전략이 될 수 있습니다. 특히 Rust와 같은 시스템 프로그래밍 언어는 고성능 실시간 시스템을 재설계할 때 강력한 도구가 됩니다.

디스코드가 수조 개의 (새 탭에서 열림)

디스코드(Discord)는 수십억 개의 메시지를 효율적으로 검색하기 위해 엘라스틱서치(Elasticsearch)를 기반으로 한 고성능 검색 인프라를 구축했습니다. 초기 설계는 길드(서버)나 DM 단위로 데이터를 샤딩하여 쿼리 속도를 높이고 운영 관리를 용이하게 하는 데 집중했으며, 리소스를 절약하기 위해 지연 인덱싱(Lazy Indexing) 방식을 채택했습니다. 하지만 서비스가 급격히 성장함에 따라 초기 설계의 효율성보다는 대규모 확장성 측면에서 구조적인 한계가 나타나기 시작했습니다. **엘라스틱서치 기반의 샤딩 및 저장 구조** - 데이터의 논리적 네임스페이스인 인덱스를 두 개의 엘라스틱서치 클러스터에 분산 배치하여 관리했습니다. - 모든 메시지는 길드(Guild) 또는 DM ID를 기준으로 샤딩되어, 특정 그룹의 메시지가 동일한 인덱스에 저장되도록 설계했습니다. - 이러한 샤딩 전략은 관련 데이터를 한데 모아 쿼리 실행 속도를 최적화하고, 클러스터 규모를 제어 가능한 수준으로 유지하는 데 기여했습니다. **메시지 큐와 대량 인덱싱 처리** - 모든 사용자가 검색 기능을 사용하는 것이 아니라는 점에 착안하여, 메시지를 즉시 처리하지 않고 필요할 때 인덱싱하는 '지연 인덱싱' 방식을 도입했습니다. - 메시지 큐를 구축하여 워커(Worker)들이 메시지 덩어리(Chunks)를 가져와 처리할 수 있도록 시스템을 구성했습니다. - 엘라스틱서치의 벌크 인덱싱(Bulk-indexing) 기능을 활용하여 대량의 메시지를 한 번에 처리함으로써 인덱싱 효율을 극대화했습니다. 초기 설계 단계에서 데이터 응집도와 리소스 효율성을 고려한 샤딩 및 인덱싱 전략은 시스템의 성능과 비용 효율성을 잡는 데 효과적입니다. 그러나 서비스의 성장에 따라 기존 아키텍처에서 발생하는 병목 현상을 미리 예측하고, 성능 저하가 시작되는 시점에 맞추어 인프라 고도화를 준비하는 과정이 필수적입니다.

대규모 시계열 인덱싱 (새 탭에서 열림)

Datadog은 5년 사이 데이터 규모가 30배 이상 급증함에 따라, 기존의 시계열 인덱싱 시스템에서 발생하는 성능 병목과 유지보수 문제를 해결하기 위해 아키텍처를 재설계했습니다. 수조 건의 이벤트를 효율적으로 처리하기 위해 인덱스 서비스를 시계열 데이터 저장소와 분리하였으며, 쿼리 로그를 분석해 인덱스를 자동으로 생성하는 전략을 취했습니다. 이 글은 RocksDB와 SQLite를 기반으로 한 초기 인덱싱 서비스의 구조와 대규모 시계열 데이터를 관리하기 위한 Datadog의 기술적 접근 방식을 다룹니다. ### 메트릭 플랫폼의 계층별 구조 * **수집(Intake) 계층:** 데이터 포인트는 메트릭 이름, 태그(env, host, service 등), 타임스탬프, 수치 값으로 구성됩니다. 수집된 데이터는 메시지 브로커인 Kafka로 전달되어 분석, 인덱싱, 아카이빙 등 다양한 용도로 독립적으로 소비됩니다. * **저장(Storage) 계층:** 데이터 저장소는 두 개의 서비스로 나뉩니다. '시계열 데이터베이스'는 `<시계열_ID, 타임스탬프, 값>` 튜플을 저장하고, '시계열 인덱스' 서비스는 RocksDB를 기반으로 `<시계열_ID, 태그>`를 매핑하여 쿼리 시 필터링과 그룹화를 담당합니다. * **쿼리(Query) 계층:** 분산 쿼리 계층은 인덱스 노드에서 검색된 식별자를 바탕으로 시계열 데이터베이스에서 실제 값을 가져와 병합하며, 필터와 집계 함수(avg 등)를 적용해 최종 결과를 도출합니다. ### 쿼리 로그 분석을 통한 자동 인덱싱 전략 * **풀 스캔 방지:** 특정 메트릭의 전체 데이터를 조회하는 비효율적인 스캔을 피하고자, 태그 기반의 인덱스를 생성하여 쿼리 실행 속도를 최적화했습니다. * **동적 인덱스 생성:** 시스템은 백그라운드 프로세스를 통해 실시간 쿼리 로그를 분석합니다. 쿼리 횟수, 실행 시간, 입력 대비 출력 식별자 비율을 따져 리소스 소모가 큰 '고선택성' 쿼리에 대해 자동으로 인덱스를 생성합니다. * **구체화된 뷰(Materialized Views):** 자주 사용되는 복잡한 쿼리를 미리 계산된 인덱스 형태로 저장함으로써, 반복되는 쿼리 요청을 단순한 키-값 조회로 변환해 CPU와 메모리 리소스를 획기적으로 절감합니다. ### 임베디드 데이터베이스를 활용한 시스템 설계 * **SQLite 기반의 메타데이터 관리:** 인덱스 정의와 쿼리 로그 등 읽기 중심의 데이터는 Go 애플리케이션 내에 임베디드된 SQLite에 저장됩니다. SQL의 유연성 덕분에 CLI를 통한 디버깅과 테이블 관리가 용이합니다. * **RocksDB를 통한 고성능 쓰기 처리:** 매일 발생하는 수조 건의 인덱싱 데이터는 고성능 키-값 저장소인 RocksDB가 처리합니다. 별도의 서버 프로세스 없이 애플리케이션에 직접 통합되어 성능 극대화를 꾀했습니다. * **인덱스 수명 주기 관리:** 일정 기간 쿼리가 발생하지 않아 쓸모없어진 인덱스는 시스템이 자동으로 삭제하여 저장 공간을 효율적으로 관리합니다. 대규모 분산 환경에서 모든 데이터에 대해 미리 인덱스를 생성하는 것은 불가능에 가깝습니다. Datadog의 사례처럼 실제 사용자의 쿼리 패턴을 모니터링하고, 리소스 집약적인 쿼리에 대해 인덱스를 동적으로 생성하는 '쿼리 기반 최적화' 방식은 폭발적인 데이터 성장세 속에서 시스템 가용성을 유지하는 매우 실용적인 전략입니다.