Datadog / kafka

How we built a real-world evaluation platform for autonomous SRE agents at scale (새 탭에서 열림)

Datadog은 자율형 사고 조사 에이전트인 'Bits AI SRE'를 개발하면서, 특정 기능을 개선했을 때 다른 영역에서 예상치 못한 성능 저하(Regression)가 발생하는 문제를 겪었습니다. 이를 해결하기 위해 실제 운영 환경의 사고 맥락을 재현하고 에이전트의 추론 과정을 일관되게 측정할 수 있는 '재현 가능한 평가 플랫폼'을 자체 구축했습니다. 이 플랫폼은 프로덕션 환경의 복잡한 신호를 오프라인에서 재실행 가능한 환경으로 변환함으로써, 에이전트의 품질을 데이터에 기반해 지속적으로 개선할 수 있게 해줍니다. **기존 테스트 방식의 한계와 회귀 문제** * 단순한 단위 테스트나 개별 도구(Tool) 레벨의 테스트는 에이전트가 여러 도구를 체이닝(Chaining)하며 추론하는 복합적인 과정을 검증하는 데 한계가 있었습니다. * 특정 모니터에서 서비스 이름을 추출하는 등의 기능 개선이 실제로는 불필요한 노이즈를 유발하여, 오히려 에이전트의 전체적인 추론 품질을 떨어뜨리는 사례가 발생했습니다. * 실시간 운영 환경에서의 재실행(Live Replay)은 데이터의 만료, 환경의 가변성, 결과 집계의 어려움으로 인해 대규모 평가에 적합하지 않았습니다. **재현 가능한 평가를 위한 '레이블'의 구조** * 플랫폼의 핵심인 '레이블'은 근본 원인을 정의하는 '정답(Ground Truth)'과 사고 당시의 신호를 담은 '월드 스냅샷(World-snapshot)'으로 구성됩니다. * 월드 스냅샷은 원시 데이터를 그대로 저장하는 대신 에이전트가 당시 사용할 수 있었던 텔레메트리 쿼리(지표, 로그, 배포 이벤트 등) 정보를 보존하여 실제 제약 사항을 재현합니다. * Kubernetes 파드 실패부터 Kafka 지연까지, 실제 SRE가 직면하는 다양한 장애 모드와 기술 스택을 포괄하는 광범위한 레이블 세트를 구축하여 평가의 객관성을 확보했습니다. **레이블 생성 및 검증의 자동화 (Agentic Validation)** * 초기 수동 레이블링의 한계를 극복하기 위해, 사용자의 피드백과 Bits AI의 자체 조사 데이터를 결합하여 레이블을 자동 생성하는 파이프라인을 구축했습니다. * 레이블의 양이 급증함에 따라 발생하는 품질 저하 문제를 해결하기 위해, 에이전트가 직접 모호한 신호를 정리하고 관계를 도출하는 '에이전트 기반 검증' 단계를 도입했습니다. * 이 시스템을 통해 레이블 생성 속도를 10배 이상 향상시켰으며, 사람이 최종 검토하기 전 데이터의 정밀도를 높여 평가 신뢰도를 강화했습니다. **대규모 평가 오케스트레이션과 성능 추적** * 다양한 모델 버전과 설정 변경 사항이 기존의 Kafka나 Kubernetes 조사 품질에 영향을 주지 않는지 확인하기 위해 대규모 병렬 평가 시스템을 운영합니다. * 레이블 세트를 세부 카테고리별로 분할(Segmentation)하여 관리함으로써, 어떤 변경이 특정 시나리오에 어떤 영향을 주는지 정밀하게 분석할 수 있습니다. * 모든 평가 결과는 지표화되어 시간에 따른 성능 추이를 추적하고, 버전 간 비교를 용이하게 하여 새로운 기능 배포에 대한 확신을 제공합니다. 복잡한 추론을 수행하는 AI 에이전트 개발 시, 단순히 개별 도구의 정확도에 의존하기보다 실제 운영 데이터의 '쿼리 가능성'과 '맥락'을 보존하는 오프라인 평가 환경을 구축하는 것이 필수적입니다. 이는 사용자 피드백을 제품 개선의 선순환으로 연결하는 핵심 인프라가 됩니다.

Replication redefined: How we built a low-latency, multi-tenant data replication platform (새 탭에서 열림)

데이터독(Datadog)은 모놀리식 포스트그레스(Postgres) 데이터베이스의 확장성 한계와 수동 데이터 파이프라인의 복잡성을 해결하기 위해 자동화된 관리형 데이터 복제 플랫폼을 구축했습니다. 이 플랫폼은 체계적인 변경 데이터 캡처(CDC)와 비동기 복제 방식을 통해 데이터 일관성을 유지하면서도 시스템 성능을 비약적으로 향상시켰습니다. 결과적으로 엔지니어링 팀은 인프라 관리의 부담에서 벗어나 안정적이고 낮은 지연 시간으로 대규모 데이터를 다양한 서비스 간에 자유롭게 이동시킬 수 있게 되었습니다. **포스트그레스의 확장성 한계와 데이터 재건축** * 서비스 초기에는 포스트그레스의 ACID 보장과 편의성이 유용했으나, 데이터량이 증가하면서 복잡한 조인 및 집계 쿼리의 응답 시간이 수 밀리초에서 수 초 단위로 급격히 악화되었습니다. * 특정 조직의 메트릭 요약 페이지에서 수십만 개의 행을 조인할 때 P90 지연 시간이 7초에 달했으며, 인덱스 팽창(Bloat)과 VACUUM 작업 부하로 인한 I/O 병목 현상이 발생했습니다. * OLTP 부하와 검색/필터링 부하를 분리하기 위해, 복제 과정에서 데이터를 비정규화(Denormalization)하여 전용 검색 플랫폼으로 전송하는 아키텍처로 전환했습니다. * 이러한 최적화를 통해 페이지 로드 시간을 최대 97% 단축(30초 → 1초)하고, 복제 지연 시간을 500ms 수준으로 유지하는 성과를 거두었습니다. **Temporal을 활용한 복제 파이프라인 프로비저닝 자동화** * Debezium, Kafka, Elasticsearch 등 다양한 기술 스택이 결합된 복제 파이프라인을 수동으로 구축하는 과정은 운영상 큰 부담이 되었습니다. * 포스트그레스의 `wal_level` 설정, 논리적 복제 슬롯 생성, 사용자 권한 관리, Kafka 토픽 매핑 등 반복적이고 오류가 잦은 단계를 Temporal 워크플로우를 통해 모듈화했습니다. * WAL(Write-Ahead Log) 보존 문제를 해결하기 위한 하트비트 테이블 설정부터 싱크 커넥터 배포까지의 모든 과정을 오케스트레이션하여 운영 탄력성을 높였습니다. * 자동화된 플랫폼 덕분에 개발자들은 인프라 설정 대신 혁신에 집중할 수 있게 되었으며, 멀티 테넌트 환경에서도 일관된 파이프라인 관리가 가능해졌습니다. **성능과 확장성을 위한 비동기 복제 전략** * 강한 일관성을 보장하는 동기 복제 대신, 대규모 고처리량 환경에 적합한 비동기 복제 방식을 채택했습니다. * 동기 복제는 네트워크 지연이나 복제본의 응답 상태가 기본 시스템의 성능에 직접적인 영향을 주지만, 비동기 방식은 애플리케이션의 쓰기 성능을 네트워크 지연으로부터 격리합니다. * 장애 발생 시 미세한 데이터 지연이 발생할 수 있는 트레이드오프가 있으나, 이는 확장성과 가용성을 우선시하는 데이터독의 분산 환경에 더 적합한 선택이었습니다. **결론 및 권장사항** 대규모 시스템에서 데이터베이스의 성능 저하를 방지하려면 OLTP와 읽기 전용 검색 워크로드를 분리하는 것이 필수적입니다. 이때 발생하는 복잡한 데이터 이동 문제는 Temporal과 같은 워크플로우 엔진으로 자동화하여 운영 비용을 낮추고, 비동기 복제 모델을 통해 시스템의 전체적인 처리량과 가용성을 확보하는 전략이 권장됩니다.

Scaling down to speed up: How we improved efficiency of live process metrics by 100x (새 탭에서 열림)

Datadog은 프로세스 및 컨테이너 모니터링 시스템의 실시간 데이터 처리 방식을 '호스트 구독(Host Subscription)' 기반 모델로 전환하여 확장성 문제를 해결했습니다. 사용자가 현재 화면에서 보고 있는 특정 호스트(최대 50개)에 대해서만 2초 간격의 고빈도 수집을 활성화함으로써, 전체 트래픽 볼륨을 100배 줄이고 인프라 비용을 98% 절감하는 성과를 거두었습니다. 이 글은 불필요한 데이터 수집을 최소화하면서도 사용자 경험과 시스템 효율성을 동시에 개선한 기술적 여정을 다룹니다. ## 기존 실시간 데이터 수집의 한계 * **전체 활성화 방식의 비효율성:** 기존에는 테넌트 내 한 명의 사용자만 페이지를 조회해도 해당 테넌트 전체 인프라의 모든 호스트에서 2초 간격의 데이터 수집이 시작되었습니다. 이로 인해 초당 수백만 개의 프로세스 데이터가 유입되는 부하가 발생했습니다. * **수평적 확장 불가능:** 실시간 정렬 기능을 제공하기 위해 테넌트의 모든 데이터를 단일 서버의 메모리에 보관해야 했습니다. 이는 시스템을 수평적으로 확장하는 것을 불가능하게 만들었으며, 서버 사양을 높이는 수직적 확장에만 의존하게 했습니다. * **리소스 낭비:** 실제 사용자가 한 번에 확인하는 프로세스는 약 50개 내외임에도 불구하고, 보이지 않는 수만 개의 프로세스 데이터를 실시간으로 수집하고 처리하는 비효율이 존재했습니다. ## 사용자 가시성 중심의 설계 전환 * **실시간 수집 대상의 최소화:** 사용자가 보고 있는 화면에 노출된 프로세스가 실행 중인 호스트에 대해서만 실시간 모드를 활성화하도록 전략을 수정했습니다. * **데이터 용도 분리 및 정렬 로직 최적화:** 2초 간격의 실시간 데이터는 화면 갱신에만 사용하고, 10초마다 수행되는 정렬 작업에는 일반적인 10초 간격 데이터를 활용하도록 변경했습니다. * **시스템 단순화:** 실시간 뷰와 히스토리 뷰에서 동일한 정렬 로직을 사용할 수 있게 되어 시스템 복잡성이 줄어들었고, 고빈도 메트릭을 메모리에 상주시켜야 할 필요성도 사라졌습니다. ## 호스트 구독 모델 및 필터링 최적화 * **호스트 구독(Host Subscription) 도입:** 사용자가 현재 보고 있는 호스트 목록을 추적하고, 이 상태를 Kafka를 통해 인테이크(Intake) 서비스와 라이브 서버 간에 공유합니다. * **조기 필터링(Early Filtering):** 구독 정보를 바탕으로 데이터 수집 단계(Intake)에서부터 필요한 데이터만 선별하여 처리합니다. 이는 Datadog 에이전트와 백엔드 서버 모두의 부하를 줄이는 핵심 기여를 했습니다. * **성능 개선 결과:** 개념 증명(PoC) 단계에서 이미 라이브 데이터 서버의 메모리 사용량은 85%, CPU 사용량은 33% 감소했으며, 이는 시스템 전체의 안정성 향상으로 이어졌습니다. 대규모 인프라 모니터링 환경에서 모든 데이터를 실시간으로 수집하는 것은 막대한 비용과 확장성 문제를 야기합니다. 사용자의 가시성 범위 내로 수집 대상을 제한하고 데이터의 용도(갱신 vs 정렬)에 따라 수집 빈도를 이원화하는 접근 방식은 리소스 효율성을 극대화하면서도 고성능 실시간 뷰를 제공할 수 있는 실용적인 해결책이 됩니다.

How we built reliable log delivery to thousands of unpredictable endpoints (새 탭에서 열림)

Datadog은 수천 개의 외부 엔드포인트로 로그를 안정적으로 전달하기 위해 물리적인 택배 배송 서비스의 원리를 소프트웨어 아키텍처에 도입했습니다. 특히 Kafka의 엄격한 순차 처리(FIFO) 특성으로 인해 발생하는 '특정 목적지의 장애가 전체 시스템을 마비시키는 문제'를 해결하는 데 집중했습니다. 이를 통해 저지연, 고처리량, 그리고 높은 신뢰성을 보장하는 멀티테넌트 로그 전달 시스템을 구축할 수 있었습니다. ### 로그 포워딩의 역할과 내부 데이터 흐름 * Datadog 로그 포워딩은 내부에서 처리된 JSON 형식의 로그를 ElasticSearch, Splunk, 또는 커스텀 HTTP 엔드포인트와 같은 외부 목적지로 전송하는 디지털 배송 서비스입니다. * 모든 로그 데이터는 내부적으로 Kafka 토픽을 통해 이동하며, 이는 마치 물류 센터의 컨베이어 벨트처럼 작동하여 데이터의 순서를 보장합니다. * 다양한 고객과 목적지로 향하는 로그들이 Kafka 파티션 내에 혼합되어 흐르기 때문에, 이를 목적지별로 다시 그룹화하여 효율적으로 전달하는 과정이 필요합니다. ### 외부 엔드포인트 연동 시 발생하는 병목 현상 * **엔드포인트 불확실성**: 외부 수신 서버는 Datadog의 통제 밖에 있으며, 수시로 응답이 느려지거나 일시적으로 오프라인 상태가 될 수 있습니다. * **Head-of-Line Blocking**: Kafka는 파티션 내의 데이터를 순서대로 처리(Commit)해야 합니다. 만약 특정 목적지의 서버가 응답하지 않아 전송에 실패하면, 해당 파티션에 담긴 다른 모든 목적지의 로그들까지 전송이 중단되는 병목 현상이 발생합니다. * **데이터 유실과 중복의 트레이드오프**: 전송 성공 확인 없이 다음 데이터를 읽으면 유실 위험이 있고, 성공할 때까지 무한히 재시도하면 전체 시스템의 지연 시간(Latency)이 급격히 증가합니다. ### 대규모 멀티테넌시 환경의 설계 제약 * **리소스 효율성**: 수만 개의 목적지마다 별도의 Kafka 토픽을 생성하는 것은 운영 오버헤드와 리소스 낭비가 너무 커서 현실적으로 불가능합니다. * **처리량 최적화**: 매 로그마다 HTTP 요청을 보내는 대신, 택배를 모아서 한 번에 배송하듯 적절한 '배치(Batch)' 처리를 통해 네트워크 오버헤드를 줄여야 합니다. * **보호 메커니즘**: 고객의 엔드포인트가 과부하로 인해 다운되지 않도록 전송 속도를 조절(Rate Limiting)하는 기능이 필수적입니다. ### 실용적인 결론 대규모 분산 시스템에서 외부 시스템과 연동하는 기능을 설계할 때는 **"단일 장애 지점이 전체 시스템에 미치는 영향"**을 최소화하는 격리 전략이 핵심입니다. Kafka와 같은 FIFO 기반 시스템을 사용할 경우, 장애가 발생한 데이터 스트림을 별도의 재시도 경로로 분리하여 정상적인 데이터 흐름이 방해받지 않도록 아키텍처를 구성해야 합니다.

How we scaled fast, reliable configuration distribution to thousands of workload containers (새 탭에서 열림)

데이터독(Datadog)은 초당 수백만 개의 로그를 처리하는 대규모 분산 환경에서 사용자가 설정한 로그 파싱 규칙 등 '컨텍스트 데이터'를 수천 개의 컨테이너에 실시간으로 전파해야 하는 과제에 직면해 있습니다. 단순히 데이터베이스를 조회하거나 짧은 주기의 캐시를 사용하는 방식은 대규모 트래픽 환경에서 DB 부하와 지연 시간 문제를 야기하며, 이를 해결하기 위해 데이터독은 안정성과 확장성을 모두 고려한 독자적인 설정 전파 시스템을 구축했습니다. ### 실시간 설정 전파의 기술적 도전 과제 * **컨텍스트 데이터의 중요성**: 로그 파싱 규칙, 민감 데이터 스캐너 설정, 저장 쿼터 등 사용자별(per-tenant) 설정 데이터는 데이터독 서비스가 고객 데이터를 처리하는 방식의 핵심을 이룹니다. * **낮은 지연 시간 요구**: 사용자가 UI에서 설정을 변경하면 '라이브 테일(Live Tail)'과 같은 실시간 서비스에 즉각 반영되어야 하며, 이는 수천 개의 워크로드 컨테이너가 변경 사항을 거의 동시에 인지해야 함을 의미합니다. * **고도의 신뢰성**: 컨텍스트 데이터는 데이터 처리에 필수적이므로, 이 데이터를 공급하는 시스템은 어떤 장애 상황에서도 견고하게 동작해야 하는 '록 솔리드(rock solid)'한 수준의 안정성이 요구됩니다. ### 단순 접근 방식의 한계 * **온디맨드 조회의 불가능**: 로그가 들어올 때마다 DB에서 설정을 읽어오는 방식은 초당 수십만 건의 읽기 요청을 발생시켜 DB가 감당할 수 없는 수준의 부하를 줍니다. * **로컬 캐싱의 트레이드오프**: 각 컨테이너에 데이터를 캐싱하고 일정 시간마다 갱신하는 방식은 DB 부하를 줄일 수 있지만, 캐시 만료 시간만큼 설정 반영이 늦어져 사용자 경험을 저해합니다. 캐시 기간을 늘릴수록 지연은 심해지고, 줄일수록 DB 부하는 급증하는 딜레마가 발생합니다. ### V1 아키텍처: Kafka 기반 캐시 무효화 * **작동 원리**: 사용자가 설정을 변경하면 DB에 저장된 후 Kafka를 통해 무효화 알림(invalidation message)이 브로드캐스트됩니다. 이를 수신한 모든 워크로드 컨테이너는 해당 테넌트의 데이터만 DB에서 다시 읽어와 캐시를 갱신합니다. * **장점**: 수년간 잘 작동했으며, 평상시 DB 읽기 횟수를 최소화하면서도 설정 변경 시에만 신속하게 업데이트를 수행할 수 있었습니다. * **확장성 한계**: 데이터독의 규모가 커짐에 따라 한 번의 설정 변경이 수천 개의 컨테이너에서 동시에 DB 조회를 일으키는 '천둥 벌거숭이(thundering herd)' 문제를 야기했습니다. 이는 중앙 DB에 막대한 부하를 주며, DB 장애 시 설정 전파가 완전히 중단되는 취약점을 드러냈습니다. 사용자 설정 변경이 실시간으로 반영되어야 하는 대규모 분산 시스템에서는 중앙 집중식 데이터베이스에 직접 의존하는 구조를 탈피해야 합니다. 워크로드 컨테이너가 DB에 직접 접근하여 데이터를 가져오는 대신, 변경 사항을 안정적으로 밀어넣어 주거나 중간에 완충 역할을 하는 계층을 두어 DB 부하를 격리하고 시스템 전체의 복원력을 높이는 설계가 권장됩니다.

Achieving relentless Kafka reliability at scale with the Streaming Platform (새 탭에서 열림)

데이터독(Datadog)은 매일 수백 조 건의 이벤트를 처리하기 위해 수천 개의 토픽과 수백 개의 아파치 카프카(Apache Kafka) 클러스터를 운영하고 있습니다. 기존의 정적인 카프카 설정으로는 대규모 환경에서 발생하는 하드웨어 장애나 트래픽 변동에 유연하게 대응하기 어렵기 때문에, 데이터독은 카프카 인프라를 추상화한 '스트리밍 플랫폼(Streaming Platform)'이라는 제어 계층을 구축했습니다. 이를 통해 애플리케이션의 재설정이나 배포 없이도 실시간으로 트래픽을 리디렉션하고 클러스터를 관리함으로써 시스템의 복원력과 확장성을 극대화했습니다. ### 스트림(Streams)을 통한 파이프라인 복원력 강화 - **논리적 추상화**: 물리적인 카프카 토픽 대신 '스트림'이라는 추상화된 단위를 사용합니다. 스트림은 여러 클러스터와 가용 영역(AZ)에 걸쳐 존재할 수 있으며, 생산자와 소비자는 실제 카프카 토폴로지를 알 필요 없이 안정적인 식별자를 통해 데이터에 접근합니다. - **인프라 디커플링**: 애플리케이션이 특정 카프카 리소스에 종속되지 않기 때문에, 인프라 구성을 실시간으로 변경하거나 트래픽을 새로운 토픽/클러스터로 원활하게 재라우팅할 수 있습니다. ### 실시간 트래픽 페일오버 및 리밸런싱 - **무중단 전환**: 특정 클러스터에 문제가 발생하면 제어 계층이 즉시 새로운 토픽을 생성하고 트래픽을 리디렉션합니다. 생산자는 즉시 새 토픽으로 데이터를 보내고, 소비자는 기존 토픽의 잔량을 처리한 후 새 토픽으로 넘어가는 방식을 통해 데이터 유실 없이 전환이 이루어집니다. - **유연한 운영**: 장애 대응뿐만 아니라 클러스터 폐기, 파티션 수 조정, 부하 분산 등의 작업을 애플리케이션 수정 없이 수 초 내에 수행할 수 있습니다. ### 대규모 환경에 최적화된 Assigner와 소비자 모델 - **자체 코디네이터 개발**: 카프카의 기본 그룹 코디네이터는 세션 타임아웃에 의존하여 반응이 느리다는 단점이 있습니다. 이를 대체하기 위해 개발된 'Assigner'는 클러스터 상태와 CPU 부하 등의 메트릭을 실시간으로 모니터링하여 수 초 내에 워크로드를 재분배합니다. - **병렬 처리 극대화**: 엄격한 순서 보장보다는 '최소 한 번(at-least-once)' 전달 모델을 채택하고 소비 단계에서의 순서 제약을 완화했습니다. 이를 통해 대규모 병렬 처리를 구현하고, 순서 보장이 필요한 경우 이벤트 저장소 하단에서 처리하도록 설계했습니다. ### Head-of-line Blocking 문제 해결 및 고급 커밋 로그 - **스트림 레인(Stream Lanes)**: 서비스 품질(QoS)에 따라 트래픽을 독립적인 '레인'으로 분리합니다. 우선순위가 높은 실시간 데이터가 일시적인 트래픽 급증이나 낮은 우선순위 데이터로 인해 지연되는 것을 방지합니다. - **Dead-letter Queue(DLQ)**: 특정 이벤트(Poison Pill)가 처리를 방해할 경우 이를 별도의 DLQ로 격리하여 파티션 전체가 멈추는 현상을 방지합니다. - **메타데이터 기반 커밋**: 카프카의 단일 포인터 오프셋 커밋 방식에서 벗어나, 커밋 메타데이터 공간을 활용해 파티션 내 여러 오프셋 범위를 동시에 추적합니다. 이를 통해 소비자가 이전 데이터를 재처리하는 동안에도 최신 트래픽을 동시에 처리할 수 있는 유연성을 확보했습니다. 카프카를 대규모로 운영할 때는 인프라를 고정된 자산이 아닌 '교체 가능한 소모품'으로 취급하는 제어 계층이 필수적입니다. 데이터독의 사례처럼 물리적 인프라와 논리적 데이터 흐름을 분리하는 추상화 계층을 구축함으로써, 운영 복잡성을 낮추고 대규모 장애 상황에서도 시스템의 연속성을 보장할 수 있습니다.

Timeseries indexing at scale (새 탭에서 열림)

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의 사례처럼 실제 사용자의 쿼리 패턴을 모니터링하고, 리소스 집약적인 쿼리에 대해 인덱스를 동적으로 생성하는 '쿼리 기반 최적화' 방식은 폭발적인 데이터 성장세 속에서 시스템 가용성을 유지하는 매우 실용적인 전략입니다.

Husky: Exactly-once ingestion and multi-tenancy at scale (새 탭에서 열림)

Datadog의 3세대 이벤트 저장소인 Husky는 대규모 멀티테넌트 환경에서 데이터 중복 없는 '정확히 한 번(Exactly-once)'의 인입을 보장하기 위해 데이터 지역성(Locality) 기반의 라우팅 아키텍처를 도입했습니다. 스캔과 집계에 최적화된 Husky의 특성상 고성능 포인트 조회가 어렵다는 점을 극복하기 위해, 결정론적 샤딩을 통해 중복 제거의 범위를 샤드 단위로 한정하여 시스템 복잡도를 낮췄습니다. 이를 통해 테넌트별 데이터 격리 비용을 최소화하고, 가변적인 트래픽 상황에서도 효율적으로 스토리지와 컴퓨팅 자원을 확장할 수 있는 기반을 마련했습니다. ## 샤드 라우터를 통한 데이터 지역성 확보 * **결정론적 매핑**: 업스트림 서비스인 'Shard Router'를 사용하여 이벤트의 ID와 타임스탬프를 기반으로 특정 샤드(파티션 그룹)에 이벤트를 할당합니다. * **샤드 할당 전략**: 각 테넌트에게 고정된 리스트의 샤드를 할당하고, 해당 리스트 내에서 이벤트 ID를 해싱하여 샤드를 선택함으로써 무작위 라우팅을 방지합니다. * **테넌트 격리**: 개별 워커 노드가 노출되는 테넌트와 인덱스의 수를 최소화하여, 시스템 전체의 복잡도를 관리 가능한 수준으로 유지합니다. ## 데이터 지역성 도입의 기술적 이점 * **중복 제거(Deduplication) 효율화**: 동일한 ID를 가진 이벤트는 항상 같은 샤드로 라우팅되므로, 전체 시스템이 아닌 샤드 내부에서만 중복 여부를 확인하면 됩니다. 이벤트 ID 세트가 메모리에 수용 가능한 크기로 유지되어 처리 속도가 비약적으로 향상됩니다. * **스토리지 비용 절감**: Husky는 테넌트별로 데이터를 전용 테이블에 격리하며 파일 단위로 저장합니다. 지역성을 통해 워커당 처리하는 테넌트 수를 제한하면 생성되는 파일 수가 줄어들어, 클라우드 스토리지 비용과 후속 컴팩션(Compaction) 작업의 부하를 동시에 낮출 수 있습니다. * **성능 최적화**: 워커 노드가 처리해야 할 논리적 네임스페이스의 카디널리티(Cardinality)가 낮아짐에 따라 쓰기 성능이 개선되고 리소스 효율성이 높아집니다. ## 동적 환경에서의 라우팅 도전 과제 * **할당 변경 관리**: 특정 테넌트의 트래픽이 갑자기 수십 배 증가하거나 전체 샤드 수가 변경될 때, 기존의 결정론적 규칙을 유지하면서도 유연하게 샤드 배정을 변경해야 합니다. * **분산 노드 간 합의**: 모든 샤드 라우터 노드가 동일한 라우팅 규칙을 공유해야 중복 데이터 유입을 방지할 수 있으며, 이를 위해 노드 간의 일관성 있는 결정 메커니즘이 필수적입니다. * **부하 분산(Load Balancing)**: 모든 샤드에 인입 트래픽이 균등하게 배분되도록 설계하여 특정 워커 노드에 부하가 집중되는 '핫스팟' 현상을 방지해야 합니다. 대규모 분산 시스템에서 데이터 일관성을 유지하며 비용을 최적화하려면, 무상태(Stateless) 라우팅보다는 데이터의 특성에 맞춘 지역성 설계를 우선 고려해야 합니다. 특히 테넌트 수가 많은 SaaS 환경에서는 워커가 처리하는 테넌트의 카디널리티를 물리적으로 제한하는 것이 스토리지 관리 비용을 결정짓는 핵심 요소가 됩니다.

Introducing Husky, Datadog's third-generation event store (새 탭에서 열림)

데이터독(Datadog)은 폭발적인 데이터 증가와 다양한 제품군의 요구사항을 충족하기 위해 새로운 이벤트 저장 시스템인 '허스키(Husky)'를 구축했습니다. 기존 시스템은 대규모 멀티테넌트 환경에서 발생하는 성능 간섭과 고비용 구조, 데이터 삭제의 어려움이라는 한계에 봉착했으며, 이를 해결하기 위해 저장소와 클러스터링을 분리하고 효율성을 극대화한 새로운 아키텍처가 필요했습니다. 결과적으로 허스키는 로그, RUM, 보안 데이터 등 다양한 고카디널리티(High-cardinality) 이벤트를 경제적이고 안정적으로 처리할 수 있는 기반이 되었습니다. ### 메트릭과 로그의 기술적 차이 * **메트릭의 효율성:** 메트릭 시스템은 데이터를 `<timeseries_id, timestamp, float64>` 형태의 튜플로 사전 집계하여 저장합니다. '델타-오브-델타(delta-of-delta)' 인코딩을 통해 16바이트 데이터를 2바이트 미만으로 압축할 수 있어 매우 효율적이지만, 태그 카디널리티에 제한이 있습니다. * **로그의 복잡성:** 로그는 이벤트당 킬로바이트(KB) 단위의 크기를 가지며, UUID나 스택 트래적(stack traces)과 같은 고카디널리티 데이터를 포함해야 합니다. 로그 시스템은 모든 문맥(context)을 보존하면서 쿼리 시점에 임의의 차원으로 집계할 수 있는 능력이 필수적입니다. ### 초기 아키텍처의 한계와 클러스터링 개선 * **초기 버전의 문제:** 멀티테넌트 클러스터 내에서 단일 노드의 장애나 특정 테넌트의 과부하가 전체 클러스터의 가용성을 떨어뜨리는 '노이즈 네이버(Noisy Neighbor)' 문제가 빈번했습니다. * **저장소와 클러스터링 분리:** 두 번째 버전에서는 저장 엔진과 클러스터링 로직을 분리했습니다. '샤드 라우터(Shard Router)'가 카프카(Kafka)를 통해 데이터를 샤드 단위로 정리하고, 각 노드는 독립적인 유닛으로 동작하게 하여 장애 전파를 차단했습니다. * **커스텀 쿼리 엔진:** 여러 샤드에 분산된 데이터를 쿼리하고 부분 집계 결과를 병합하는 전용 엔진을 도입하여 신뢰성을 높였습니다. ### 플랫폼 급성장과 새로운 요구사항의 등장 * **제품군의 확장:** 로그뿐만 아니라 네트워크 성능 모니터링(NPM), 실제 사용자 모니터링(RUM), 프로파일러 등 다양한 제품이 출시되면서 저장해야 할 이벤트의 양과 종류가 급증했습니다. * **장기 보관 비용 문제:** 가끔 쿼리하지만 장기간 보관이 필요한 데이터를 기존 아키텍처에서 운영하는 것은 비용 효율성이 낮았습니다. * **데이터 관리 편의성:** GDPR 대응을 위한 특정 데이터의 정밀한 삭제 기능과 테넌트 간의 완전한 자원 격리에 대한 요구가 강해졌습니다. ### 허스키(Husky)의 설계 방향 * **범용 이벤트 저장소:** 로그와 유사한 구조를 가진 모든 유형의 데이터를 수용할 수 있는 유연한 스키마 구조를 지향합니다. * **비용 효율적인 확장:** 스토리지 계층화를 통해 자주 사용되지 않는 데이터는 저렴한 저장소에 보관하면서도 즉시 쿼리가 가능한 구조를 구축했습니다. * **격리 및 제어권 강화:** 특정 테넌트의 트래픽 급증이 다른 테넌트의 쿼리 성능에 영향을 주지 않도록 정교한 할당량(Quota) 관리와 격리 메커니즘을 포함했습니다. 시스템을 설계할 때 단순히 현재의 성능 개선에만 집중하는 것이 아니라, 향후 데이터의 기하급수적인 증가와 다양한 제품 요구사항(비용, 삭제, 격리)을 수용할 수 있는 아키텍처 유연성을 확보하는 것이 중요합니다. 특히 대규모 멀티테넌트 환경에서는 '폭포수 장애'를 방지하기 위해 각 구성 요소를 최대한 독립적으로 격리하는 설계가 필수적입니다.

Introducing Kafka-Kit: Tools for scaling Kafka (새 탭에서 열림)

데이터독(Datadog)은 매일 수조 개의 데이터 포인트를 처리하기 위해 대규모 카프카(Kafka) 클러스터를 운영하며, 이 과정에서 발생하는 대규모 데이터 이동과 스케일링 문제를 해결하기 위해 **'Kafka-Kit'**을 개발하여 공개했습니다. 이 툴킷은 기존 카프카 표준 도구들의 제약을 넘어 파티션 재배치, 장애 브로커 교체, 저장 용량 기반의 리밸런싱 등을 자동화하고 최적화합니다. 결과적으로 데이터독은 복잡한 카프카 운영 업무를 보다 안정적이고 예측 가능한 방식으로 관리할 수 있게 되었습니다. ### Kafka-Kit의 구성과 목적 * **핵심 도구:** `topicmappr`와 `autothrottle`이라는 두 가지 주요 도구로 구성됩니다. * **주요 기능:** 브로커와 파티션 간의 매핑 관리, 장애 브로커 발생 시 자동 교체, 저장 용량 기반의 파티션 리밸런싱, 복제 속도 자동 제한(Throttling) 기능을 제공합니다. * **개발 배경:** 시스템이 커짐에 따라 데이터 이동 빈도와 크기가 기하급수적으로 늘어나는데, 카프카 기본 도구만으로는 고도의 운영 유연성을 확보하기 어렵다는 점을 해결하기 위해 구축되었습니다. ### 효율적인 데이터 배치를 위한 topicmappr * **결정론적 출력:** 동일한 입력에 대해 항상 동일한 파티션 맵을 생성하여 운영의 예측 가능성을 높입니다. * **최소 이동 브로커 교체:** 브로커 교체 시 전체 맵을 새로 짜는 대신, 문제가 생긴 브로커의 빈자리만 채우는 방식으로 데이터 이동을 최소화합니다. 기본적으로 ISR(In-Sync Replicas) 상태가 정상인 파티션은 건드리지 않습니다. * **랙(Rack) 및 저장 공간 인지:** 카프카의 `broker.rack` 태그와 주키퍼(ZooKeeper) 메타데이터를 활용하여 물리적 위치와 저장 용량(Bin-packing)을 고려한 안전한 배치를 수행합니다. * **복제 계수(RF) 조정:** 운영 중인 토픽의 복제 계수를 실시간으로 쉽고 빠르게 변경할 수 있습니다. * **실행 요약 제공:** 파티션 맵을 실제로 적용하기 전, 브로커 분포 변화와 예상 결과를 요약하여 사용자에게 미리 보여줍니다. ### 파티션 배치 전략: Count 전략 * **리더십 최적화:** 브로커 간의 리더 파티션 분포를 극대화하고, 각 브로커가 보유하는 파티션 수를 균등하게 유지합니다. * **균등한 데이터 흐름:** 모든 파티션에서 일정한 데이터 흐름이 예상될 때 유용하며, 메트릭 데이터 없이도 빠르게 맵을 생성할 수 있습니다. * **브로커 관계 다양화:** 단순히 파티션 수만 맞추는 것이 아니라, 특정 브로커들끼리만 복제본을 공유하는 '클러스터링' 현상을 방지하기 위해 브로커 간의 복제 관계를 최대한 분산시킵니다. ### 기술적 구현 및 운영 이점 * `topicmappr`는 Go 언어로 작성되어 실행 파일 형태로 어디서든 쉽게 구동할 수 있으며, 주키퍼 클러스터와 통신하여 실시간 메타데이터를 확인합니다. * 지정된 모든 브로커의 활성 상태를 검증하고, 파티션 맵을 생성하기에 충분한 브로커가 있는지 사전에 체크하여 운영 실수를 방지합니다. * 표준 `kafka-reassign-partitions.sh`와 호환되는 입력 파일을 생성하므로 기존 워크플로우에 쉽게 통합할 수 있습니다. 대규모 카프카 환경에서 데이터 불균형이나 브로커 장애 대응으로 고민하고 있다면, 단순한 파티션 분산을 넘어 저장 용량과 물리적 인프라 구조를 모두 고려하는 Kafka-Kit 도입을 검토해 볼 가치가 있습니다.