InfluxDB 아키텍처와 IOx 스토리지 엔진
InfluxDB v3의 근본적인 재설계
InfluxDB는 2013년 처음 출시될 때부터 시계열 전용 DB를 표방했지만, v1·v2 시절 스토리지 엔진(TSM, Time-Structured Merge Tree)은 카디널리티가 높아지면 메모리가 급격히 증가하는 구조적 한계가 있었다. 태그 조합이 수백만 가지를 넘으면 시리즈 인덱스가 수십 GB에 달해 OOM 장애가 빈번했다.
이 한계를 근본적으로 해결하기 위해 InfluxData는 2021년부터 IOx(Iron Oxide)라는 코드명으로 완전히 새로운 엔진을 개발했다. IOx는 다음 기술 스택 위에서 Rust로 작성됐다.
- Apache Arrow — 컬럼형 인메모리 데이터 포맷
- Apache DataFusion — Rust 기반 SQL 쿼리 엔진
- Apache Parquet — 컬럼형 파일 포맷(디스크 저장)
- Apache Arrow Flight — gRPC 기반 고성능 데이터 전송 프로토콜
이 네 가지를 묶어 FDAP 스택이라고 부른다. 2023년 InfluxDB 3.0이 GA로 출시되면서 IOx는 InfluxDB Cloud Dedicated와 Clustered 버전의 핵심 엔진이 됐다.
핵심 아키텍처: 컴포넌트 분리와 오브젝트 스토리지
IOx는 데이터를 로컬 디스크가 아닌 오브젝트 스토리지(S3 호환)에 Parquet 포맷으로 저장한다. 이를 통해 각 컴포넌트를 독립적으로 스케일아웃할 수 있으며, 컴포넌트 간 직접 통신 없이 Catalog와 Object Store를 매개로만 소통한다.
컴포넌트 상세 분석
Ingester: 쓰기 경로
클라이언트가 Line Protocol 형식으로 데이터를 보내면 Ingester가 받는다. 처리 흐름은 다음과 같다.
- WAL(Write-Ahead Log) 기록: 먼저 WAL에 쓴다. 프로세스가 죽어도 데이터를 잃지 않는다.
- 인메모리 버퍼: WAL에 쓴 데이터를 Apache Arrow 포맷으로 인메모리 버퍼에 유지한다. 아직 Parquet으로 플러시되지 않은 "선도 엣지(leading edge)" 데이터를 Querier가 실시간으로 읽을 수 있게 하기 위해서다.
- Parquet 플러시: 버퍼가 임계값에 도달하거나 일정 시간이 지나면 오브젝트 스토리지에 Parquet 파일로 플러시한다.
- Catalog 업데이트: 새 파일의 위치·스키마·시간 범위를 Catalog에 기록한다.
Querier: 쿼리 경로
Querier는 Apache DataFusion을 쿼리 엔진으로 사용하며 SQL과 InfluxQL 모두 지원한다.
- Catalog 조회: 쿼리의 시간 범위와 테이블 이름으로 관련 Parquet 파일 목록을 Catalog에서 가져온다.
- Ingester 데이터 포함: 플러시되지 않은 최신 데이터는 Ingester의 인메모리 버퍼에서 직접 읽는다. 이를 통해 쓰기 후 즉시 쿼리가 가능하다.
- Parquet 스캔: 오브젝트 스토리지에서 해당 Parquet 파일을 읽어 DataFusion의 실행 계획으로 처리한다.
- 결과 반환: Arrow Flight 프로토콜로 클라이언트에 반환한다.
Compactor: 파일 최적화
Ingester가 플러시하는 파일은 초기에 작고 시간 범위가 겹칠 수 있다. Compactor는 백그라운드에서 이 소형 파일들을 더 크고 겹치지 않는 파일로 병합한다.
- 쿼리 성능이 향상된다: 읽어야 할 파일 수가 줄어든다.
- Ingester와 Compactor는 서로 직접 통신하지 않는다. Catalog에서 "아직 컴팩션되지 않은 파일" 목록을 읽고, 완료 후 Catalog를 업데이트할 뿐이다.
Catalog: 메타데이터 저장소
Catalog는 PostgreSQL 호환 DB(내부적으로 CockroachDB 또는 PostgreSQL)를 사용하며, 다음 메타데이터를 저장한다.
- 데이터베이스(네임스페이스), 테이블, 컬럼 스키마
- 각 Parquet 파일의 오브젝트 스토리지 경로, 시간 범위, 파티션 키
- 컴팩션 상태, 삭제 마커
스키마 모델과 카디널리티 혁신
v1/v2의 가장 큰 문제였던 고카디널리티 한계를 IOx가 어떻게 해결했는지 살펴본다.
v1/v2의 문제: 시리즈 인덱스를 인메모리 B-Tree로 관리. 카디널리티가 수백만이 되면 수십 GB 메모리를 소비하고 OOM이 발생.
IOx의 해결책: 시리즈를 별도로 인덱싱하지 않는다. 데이터를 Parquet 컬럼형 파일로 저장하고, Parquet의 min/max statistics(컬럼별 최솟값·최댓값)를 활용해 파일 단위 프루닝(pruning)을 수행한다.
cpu{host=web-01} → shard 1, offset 0
cpu{host=web-02} → shard 1, offset 140
cpu{host=web-03} → shard 2, offset 0
⋮ (카디널리티 × 태그 조합 수 만큼)
카디널리티 100만 → 인덱스 수GB → OOM
파일 A: host=[web-01, web-50], time=[t1,t2]
파일 B: host=[web-51, web-99], time=[t1,t2]
쿼리: WHERE host='web-01' AND time>t1
→ 파일 B는 min/max 비교로 즉시 제외
카디널리티 수억이어도 메모리 증가 없음
FDAP 스택: Apache Arrow와 Parquet의 역할
Apache Arrow: 컬럼형 인메모리 포맷. Ingester의 버퍼, Querier의 중간 결과, Arrow Flight 전송 모두 Arrow 포맷을 사용한다. 직렬화·역직렬화 오버헤드를 제거한다.
Apache Parquet: 오브젝트 스토리지의 영구 파일 포맷. 컬럼형 저장으로 집계 쿼리에 최적화되고, snappy/zstd 압축과 블룸 필터, 딕셔너리 인코딩, min/max statistics가 내장되어 있다.
Apache DataFusion: SQL 파서, 논리 계획, 물리 계획, 실행기를 모두 Rust로 구현한 쿼리 엔진. InfluxQL은 내부적으로 DataFusion의 논리 계획으로 변환된다.
Arrow Flight: gRPC 위에서 Arrow 배치를 직접 스트리밍하는 프로토콜. 클라이언트가 결과를 병렬로 받을 수 있어 대형 쿼리 반환 속도가 빠르다.
데이터 모델: Line Protocol과 스키마
InfluxDB의 쓰기 형식인 Line Protocol은 다음 구조를 갖는다.
<measurement>[,<태그키>=<태그값>...] <필드키>=<필드값>[,...] [유닉스 나노초 타임스탬프]예시:
cpu,host=web-01,region=ap usage_percent=72.3,load_avg=1.52 1720742400000000000- Measurement: 테이블 이름에 해당한다 (
cpu) - Tags: 인덱스 역할, 문자열만 허용, 카디널리티 낮게 유지 (
host,region) - Fields: 실제 측정값, 숫자·문자열·불리언 허용 (
usage_percent,load_avg) - Timestamp: 나노초 유닉스 타임스탬프 (생략 시 서버 현재 시각)
v3에서는 스키마를 선언 없이 자동 생성하며, 컬럼 추가도 자동으로 처리된다. 단, 한 번 정해진 컬럼 타입은 변경할 수 없다.
파티셔닝 전략
IOx는 시간 범위 기반으로 데이터를 자동 파티셔닝한다. 기본 파티션 키는 시간 트렁케이션(일, 시간 단위)이며, 추가 태그를 파티션 키로 지정할 수 있다.
| 파티션 키 설정 | 파티션 예시 | 적합한 상황 |
|---|---|---|
%Y-%m-%d (기본) | 2026-07-12 | 일별 집계가 주 쿼리 |
%Y-%m-%dT%H | 2026-07-12T14 | 시간별 대용량 쓰기 |
region, %Y-%m-%d | ap / 2026-07-12 | 지역별 격리 쿼리 |
파티션이 작을수록 각 파티션의 파일 수가 줄어 프루닝 효율이 높아진다. 반면 파티션이 너무 세밀하면 Catalog 메타데이터가 폭발한다.
운영 고려사항
카디널리티 제한 완화 vs 쿼리 성능
IOx는 카디널리티 제한이 없지만, 카디널리티가 높은 컬럼을 WHERE 조건으로 자주 쓰면 Parquet 스캔 범위가 넓어진다. host 같은 낮은 카디널리티 컬럼은 파티션 키나 파일 통계로 빠르게 프루닝되지만, user_id처럼 수백만 가지인 컬럼은 프루닝 효율이 낮다.
오브젝트 스토리지 비용
데이터는 S3 등에 저장되므로 스토리지 비용은 낮지만, 쿼리마다 오브젝트 스토리지에서 Parquet 파일을 읽는 API 비용이 발생한다. 잦은 소형 파일 읽기를 피하기 위해 Compactor가 파일을 병합하는 것이 중요하다.
스키마 변경 제한
- 새 태그/필드 컬럼 추가: 허용 (자동)
- 기존 컬럼 타입 변경: 불허
- 태그 → 필드 또는 필드 → 태그 변경: 불허
- 측정 이름 변경: 새 테이블로 마이그레이션 필요
InfluxDB v3 제품군
InfluxDB v3는 2024년 이후 여러 배포 형태로 제공된다.
| 제품 | 특징 |
|---|---|
| InfluxDB Cloud Serverless | 완전 관리형, 멀티테넌트, 종량제 |
| InfluxDB Cloud Dedicated | 단일 테넌트 클라우드, SLA 보장 |
| InfluxDB Clustered | 자체 Kubernetes 환경에 설치 |
| InfluxDB 3 Core / Edge | 오픈소스 단일 노드, 로컬 스토리지 |
Core/Edge는 오픈소스로 공개되어 있으며, 로컬 파일시스템을 오브젝트 스토리지 대신 사용한다. 엔터프라이즈 기능(클러스터링, 복제, 세밀한 접근 제어)은 Clustered/Dedicated 버전에서만 사용할 수 있다.
References
- InfluxData 공식 문서 — InfluxDB 3 스토리지 엔진 아키텍처 (Cloud Dedicated), https://docs.influxdata.com/influxdb3/cloud-dedicated/reference/internals/storage-engine/
- InfluxData 블로그 — InfluxDB 3.0 System Architecture, https://www.influxdata.com/blog/influxdb-3-0-system-architecture/
- InfoQ — Engineering a Time Series Database Using Open Source: Rebuilding InfluxDB 3 in Apache Arrow and Rust, https://www.infoq.com/articles/timeseries-db-rust/
- Dremio — Introducing InfluxDB IOx, a Federated In-Memory Columnar Store Backed by Object Storage, https://www.dremio.com/subsurface/introducing-influxdb-iox-a-federated-in-memory-columnar-store-backed-by-object-storage/
- ODBMS.org — On InfluxData's New Storage Engine: Q&A with Andrew Lamb, https://www.odbms.org/2022/10/on-influxdata-new-storage-engine-qa-with-andrew-lamb/
- InfoQ — Inside InfluxDB 3.0: Exploring InfluxDB's Scalable and Decoupled Architecture, https://www.infoq.com/news/2023/08/influxdb-3-architecture/
- InfluxData — Understanding InfluxDB IOx and the Commitment to Open Source, https://www.influxdata.com/blog/understanding-influxdb-iox-commitment-open-source/
- Apache DataFusion 공식 문서, https://datafusion.apache.org/
- Apache Arrow Flight 공식 문서, https://arrow.apache.org/docs/format/Flight.html