하루 10조 개의 샘플: Databricks에서 기존 모니터링 인프라를 넘어 확장

Databricks의 모니터링 인프라는 지난 한 해 동안 규모가 3배 이상 커져, 현재 실시간으로 50억 개의 활성 시계열을 추적하고 매일 10조 개 이상의 샘플을 수집하고 있습니다. 이처럼 방대한 규모에서, 우리는 상용 솔루션이 비효율적이거나 우리의 요구 사항에 맞게 조정하기 어렵다는 것을 발견했습니다. 이 게시물에서는 대신 우리가 구축한 것을 공유합니다. 즉, 오픈 소스 모니터링 생태계의 장점을 활용하면서 우리의 고유한 요구 사항에 맞게 사용자 정의 기능을 내장한 확장 가능한 플랫폼입니다.

Databricks의 엔지니어들은 문제 발생 시 신속하게 경고하고, 스케일링 및 롤백을 자동화하며, 지능형 문제 해결을 가능하게 하는 모니터링 시스템에 의존합니다. 이러한 시스템은 잠재적인 사고 발생 시 우리가 맹목적으로 대처하지 않을 것이라고 확신할 수 있도록 높은 신뢰성을 갖춰야 합니다. 그러나 Databricks 규모에 맞는 이러한 인프라를 개발하는 것은 결코 쉬운 일이 아니었습니다.

• 확장성, 신뢰성 및 효율성 요구 사항 외에도, 우리는 3대 주요 클라우드 각각에서 약 70개의 클라우드 지역에 걸쳐 전 세계적으로 시스템을 운영합니다. 클라우드 및 개별 지역의 차이에도 불구하고 동등한 성능을 지원해야 합니다.
• 이러한 광범위함과 다양성 앞에서 대규모 인프라를 운영하는 것은 빠르게 지속 불가능해질 수 있습니다. 시스템은 가능한 한 “수동 개입 없이” 작동해야 합니다. 즉, 온콜 담당자가 각 지역 스택을 직접 관리하는 대신 자가 치유 및 자가 스케일링이 가능해야 하며, 사용자에게는 여전히 간단한 인터페이스를 제공해야 합니다.
• Databricks에서 서버리스 및 AI 워크로드의 증가와 함께, 우리 인프라 전반의 변동성이 급증하여 메트릭의 카디널리티가 빠르게 증가했습니다. 우리는 더 이상 기존 방식대로 고카디널리티 모니터링 데이터를 처리하고 저장할 수 없었지만, 엔지니어들이 의존하는 디버깅 워크플로우를 유지하는 것을 목표로 삼았습니다.

이러한 문제에 직면하여 Databricks의 기존 모니터링 스택은 신뢰성 문제에 시달렸습니다. 우리는 엔지니어들의 기대를 충족시킬 새롭고 신뢰할 수 있는 플랫폼을 개발하기 시작했습니다. 그 이후로 우리는 3가지 주요 문제를 해결했습니다.

1. 신뢰할 수 있고 효율적인 시계열 데이터베이스(TSDB) 아키텍처 구축
2. TSDB를 카디널리티로부터 보호하기 위한 메트릭 집계 도입
3. Databricks 레이크하우스를 통한 고차원 문제 해결 가능

Thanos 시계열 데이터베이스

TSDB란 무엇인가요?

TSDB는 전통적인 모니터링 시스템 아키텍처의 핵심 구성 요소입니다. 이 특수 데이터베이스는 대량의 시계열 메트릭 데이터를 수집하고 높은 QPS, 낮은 지연 시간의 실시간 읽기를 제공하도록 설계되었습니다. 특히 경고 및 대시보드 새로 고침과 같이 동일한 쿼리 세트를 반복적으로 실행하고 최신 데이터를 기반으로 매우 빠른 결과를 얻어야 하는 모니터링 쿼리 패턴에 최적입니다.

Databricks의 기존 TSDB는 훨씬 낮은 규모를 위해 구축되었으며, 최근 몇 년 동안 우리에게 주요 병목 현상이 되었습니다. 실제로 전체 모니터링 인프라의 가장 큰 신뢰성 문제는 TSDB를 확장하는 어려움이었습니다. 이는 다른 많은 회사에서는 드문 작업이지만, Databricks의 기하급수적인 성장을 고려할 때 우리는 거의 매일 수행해야 하는 일이었습니다.

그래서 우리는 오픈 소스 CNCF Thanos 프로젝트의 포크인 Pantheon이라는 코드명의 새로운 TSDB를 개발했습니다. 우리는 세 클라우드 제공업체의 모든 지역에 걸쳐 160개 이상의 Thanos 인스턴스로 성공적으로 확장했으며, 총 약 50억 개의 인메모리 활성 시계열과 매일 10조 개 이상의 샘플을 수집하고 있습니다. 가장 큰 인스턴스는 약 3억 개의 인메모리 시계열을 호스팅하고 초당 거의 1,000개의 PromQL 쿼리를 지원합니다. 또한 소규모 3노드 배포 및 그 사이의 모든 것을 실행합니다. 배포의 광범위함, 규모 및 다양성으로 인해 우리는 종종 Thanos의 엣지 케이스와 성능 최적화를 발견하고 이를 오픈 소스 커뮤니티에 다시 기여합니다.

Pantheon으로 마이그레이션함으로써 연간 클라우드 비용을 수백만 달러 절감하고, 모니터링 인프라 다운타임을 약 5배 줄였으며, 많은 수동 작업을 없앨 수 있었습니다. Pantheon 아키텍처는 아래에 나와 있으며, 다음 섹션에서는 이러한 성과를 가능하게 한 몇 가지 주요 설계 결정을 설명합니다.

스토리지 아키텍처

Thanos의 핵심 요소는 계층형 스토리지 아키텍처입니다. 가장 최신 시계열은 인메모리에 유지되고, 지난 24시간 동안의 시계열은 디스크에 유지되며, 모든 오래된 데이터는 객체 스토리지에 보관됩니다. 이는 일반적으로 최신 데이터에 의존하는 경고 및 기타 실시간 쿼리가 엄격한 성능 요구 사항을 충족할 수 있음을 의미합니다. 동시에 객체 스토리지를 활용하면 시스템이 컴퓨팅과 스토리지를 본질적으로 분리할 수 있습니다. 즉, 클러스터는 모든 과거 데이터를 데이터베이스 노드에 걸쳐 재조정할 필요 없이 확장할 수 있습니다.

이 아키텍처는 우리의 주요 병목 현상(확장)을 해결하고 Pantheon의 비용 절감을 위한 토대를 마련했습니다. 우리는 몇 가지 다른 최적화를 적용했습니다.

• 메모리 보존: 우리는 서로 다른 메모리 보존 정책을 가진 두 개의 Receive 그룹을 배포합니다. 하나는 영구 서비스의 장기 시계열에 최적화되어 두 시간 분량의 샘플을 메모리에 유지하고, 다른 하나는 Databricks의 임시 워크로드에서 발생하는 단기 시계열에 최적화되어 30분 분량만 메모리에 유지합니다. 이러한 분할은 Databricks에서 서버리스 워크로드에 대해 관찰된 수명을 반영하며, 정확성을 유지하면서 메모리 사용량과 클라우드 비용을 크게 줄입니다.
• Receive 그룹 구조: 각 그룹은 단일 대규모 해시 링 대신 세 개의 복제본에 해당하는 세 개의 격리된 Kubernetes StatefulSet으로 의도적으로 구현됩니다. 이 설계는 쿼럼 쓰기와 함께 3방향 복제를 유지하면서 더 강력한 운영 및 데이터 격리를 제공합니다. 이 설정은 릴리스 또는 노드 로테이션 중에 쿼럼을 위반하거나 쓰기 가용성에 영향을 주지 않고 전체 StatefulSet을 병렬로 롤링하거나 재시작할 수 있게 하여 일상적인 작업을 실질적으로 단순화합니다.
• 멀티테넌시: Pantheon은 Thanos 멀티테넌시를 사용하여 Receive 그룹 전반에 걸쳐 분리된 테넌트 세트를 호스팅합니다. 라우터 계층에서는 규칙 기반 테넌트 속성을 적용하여 메트릭 이름과 선택된 레이블을 검사하여 각 데이터 샘플의 테넌트를 추론합니다. 이를 통해 동일한 쓰기 배치 내의 샘플이 업스트림 클라이언트 변경 없이 다른 테넌트(따라서 다른 Receive 그룹)로 라우팅될 수 있습니다.
• 최소 한 번 업로드: 정확성을 유지하면서 비용을 더욱 최적화하기 위해 세 개의 StatefulSet 중 두 개만 블록을 객체 스토리지에 업로드합니다. 이는 복제 및 쿼럼 시맨틱스를 통해 데이터 내구성 및 일관성 보장을 유지하면서 중복 업로드 트래픽과 클라우드 스토리지 비용을 줄입니다.

Pantheon 제어 평면

우리의 글로벌 규모에서는 수동 작업, 최선형 Kubernetes 자동화 또는 일반적인 Thanos 동작만으로는 불충분합니다. 모든 릴리스, 스케일 이벤트 또는 호스트 장애는 쿼럼 및 데이터 가용성을 유지하면서 안전하고, 자동으로, 최소한의 사람 개입으로 처리되어야 합니다. 이를 달성하기 위해 Pantheon은 Thanos 구성 요소의 수명 주기 및 용량 결정을 조율하는 전용 제어 평면을 도입합니다. 이는 세 가지 주요 컨트롤러로 구성됩니다.

• 롤아웃 오퍼레이터: 세 개의 격리된 Receive StatefulSet에 걸쳐 릴리스 및 스케일링을 조율하여 읽기 및 쓰기 모두에 대한 쿼럼을 보장합니다. 병렬 StatefulSet 업데이트를 통해 더 빠른 릴리스를 가능하게 하며, 언제든지 최대 하나의 복제본만 사용할 수 없도록 보장합니다.
• 해시링 컨트롤러: 라우터에 어떤 Receive 엔드포인트가 보이는지 관리합니다. 건강하고 완전히 준비된 파드만 해시링에 추가되며, 스케일 다운 또는 유지 보수 중에 제거가 준비됩니다. 이는 트래픽 관리를 파드 수명 주기에서 분리하고 동적 클러스터 변경 중에 우발적인 쿼럼 위반 또는 부분 라우팅을 방지합니다.
• 자동 스케일링 및 자가 치유 컨트롤러: 일반적인 Kubernetes 신호 대신 Pantheon 특정 수집 및 리소스 압력을 기반으로 클러스터를 확장합니다. 내장된 힐러 시스템은 잘못된 호스트, 과부하된 파드 또는 손상된 WAL과 같은 일반적인 장애 모드를 지속적으로 감지하고 수정하여 운영자 개입 없이 시스템이 자체 복구할 수 있도록 합니다. 우리의 규모에서는 이러한 자동화가 매주 수십 번 작동합니다.

카디널리티 및 집계

카디널리티란 무엇이며 왜 중요한가요?

메트릭 소유자는 특정 차원에서 문제를 디버그하고 인시던트를 더 빠르게 완화하기 위해 노드 ID 또는 Pod ID와 같은 레이블을 추가하는 경우가 많습니다. 그러나 이는 고전적인 관측 가능성 문제인 카디널리티 관리로 이어집니다. 메트릭의 카디널리티는 해당 레이블의 고유한 조합 수입니다. 모니터링하는 Pod 수가 10배 증가하면 Pod ID 레이블이 있는 모든 메트릭의 카디널리티도 증가합니다. 카디널리티는 TSDB의 주요 스케일링 요소이며, 기존 메트릭의 카디널리티 증가는 Pantheon의 비용과 스케일링 압력을 증가시킵니다.

빠른 인프라 성장은 Databricks가 누리는 도전 과제입니다. 고객 기반과 제품 사용량이 크게 증가하는 동시에, 많은 고객이 최근 당사의 서버리스 컴퓨팅 아키텍처를 채택했으며, 당사의 서버리스 컴퓨팅 플랫폼은 매일 수천만 개의 VM을 시작합니다. 더 많은 워크로드가 서버리스로 전환됨에 따라, 우리가 모니터링하는 인프라는 이탈률이 높아지고 이러한 식별자 레이블의 수명은 계속해서 짧아지고 있습니다.

이로 인해 카디널리티가 급증하여 Pantheon의 확장성과 비용 절감 효과를 잠식했습니다. 따라서 우리는 어떤 메트릭 데이터를 저장할지에 대해 훨씬 더 현명해져야 했습니다. 이것이 바로 “집계”가 등장한 지점입니다. 즉, 수집 중에 서버리스 시스템에서 비용이 많이 드는 레이블을 제거하면서도 서비스 소유자에게 집계된 전체 플릿 보기를 제공하는 것입니다. 메트릭에 대한 자동화된 집계 전략을 통해 카디널리티 증가 "곡선을 꺾어", 모니터링 인프라가 Databricks의 나머지 부분보다 빠르게 확장될 필요가 없도록 했습니다.

집계 아키텍처

대규모로 안정적인 집계 인프라를 구축하는 것은 상태를 유지해야 하므로 어렵습니다. 수백만 개의 입력 카운터를 관리하는 집계기는 재설정을 올바르게 처리할 수 있어야 합니다. 즉, 입력 시계열이 사라지더라도 집계된 출력 값은 감소하지 않고 단조롭게 계속 증가해야 합니다. 집계기 전체에 걸쳐 메트릭이 분할된 경우, Pod 재시작 및 로드 불균형과 같은 시나리오도 처리해야 합니다.

이러한 문제는 종종 Kafka와 같은 메시징 시스템을 사용하여 파티션 할당 및 이전 데이터를 유지함으로써 해결됩니다. 이는 당사의 규모에서는 비용이 많이 들고 실시간 사용 사례에 영향을 미치는 수집 지연을 추가합니다. 대안적인 접근 방식은 집계기에 인메모리 상태를 저장하고 할당을 준수하기 위해 집계기 간에 메트릭을 재라우팅하는 것입니다. 그러나 이는 집계기가 재배포될 때 데이터 손실로 이어집니다. 초기 버전의 집계 인프라에서는 이러한 동작으로 인해 집계된 메트릭이 사용자에게 거의 이해할 수 없게 되었습니다.

이를 원활하게 작동시키기 위해, 우리는 대신 Telegraf와 Databricks의 “자동 샤더” 서비스인 Dicer를 사용하여 자체 집계 시스템을 개발했습니다. 이 아키텍처는 집계기 간에 메트릭을 재라우팅하는 대신 지능형 스티키 라우팅을 사용하여 재배포 실패 모드를 해결했습니다. Telegraf에 추가한 다른 최적화와 함께, 우리는 가장 큰 리전에서 파이프라인을 1GB/s 이상으로, 그리고 수천 개의 집계 규칙으로 확장할 수 있었습니다.

이 새로운 집계 파이프라인은 장기적인 카디널리티 증가와 예상치 못한 메트릭 급증으로부터 TSDB를 효과적으로 보호하는 방패가 되었습니다. 예를 들어, 최근 Databricks 인프라 사고로 인해 여러 리전에서 메트릭 로드가 2~5배 급증했습니다. Telegraf는 이 로드의 대부분을 흡수했고, Pantheon은 20%만 급증하여 회사 전체의 엔지니어들이 아무런 영향 없이 디버깅 및 경고 쿼리를 실행할 수 있었습니다.

레이크하우스의 고카디널리티 데이터

집계의 문제점

당사의 집계 인프라는 Pantheon을 기하급수적인 카디널리티 증가로부터 보호할 수 있게 해주지만, 여기에는 비용이 따릅니다. 즉, 엔지니어가 인시던트 중에 필요로 하는 정확한 차원을 제거합니다. 다음과 같은 글로벌 플릿을 고려해 보십시오.

• 지난 2시간 동안 수백만 개의 활성 노드
• 노드당 여러 테넌트
• 단기 워크로드
• 빠른 자동 스케일링

집계된 메트릭은 다음을 알려줍니다.

• 리전 수준 CPU 사용량이 높아졌습니다.
• 서비스 수준 지연 시간이 급증하고 있습니다.

하지만 다음은 알려주지 않습니다.

• 어떤 테넌트가 스왑 압력을 유발하는지
• 어떤 노드가 충돌했는지
• 어떤 샤드가 격리되었는지
• 어떤 워크로드가 노이즈를 유발하는지

Databricks 엔지니어들은 이러한 고카디널리티 레이블에 의존하는 워크플로 문제 해결을 위한 솔루션이 여전히 필요했습니다. 이러한 “건초 더미에서 바늘 찾기” 시나리오에는 Pantheon이 처리할 수 없는 방대한 양의 원시 데이터를 효율적으로 저장하고 처리하는 것이 필요했습니다. 이러한 사용 사례를 지원하기 위해, 우리는 카디널리티 증가에 의해 제한되지 않는 다른 스토리지 아키텍처를 모색했습니다.

레이크하우스의 등장!

우리의 핵심 통찰력: Databricks 레이크하우스가 완벽하게 들어맞습니다! 이는 스토리지(저렴한 객체 스토리지 + Delta Lake)를 컴퓨팅(스트리밍 + 쿼리 클러스터)과 분리하며, 두 가지 차원 모두에서 대규모로 확장 가능합니다.

Databricks의 최고의 기능을 활용하여, 우리는 Hydra라는 원시 문제 해결 데이터를 위한 새로운 플랫폼을 개발했으며, 이를 통해 대규모 고카디널리티 디버깅을 실용화했습니다. Hydra는 전 세계 수백만 개의 노드에서 200억 개의 비집계 활성 시계열을 수집하며, 5분 엔드투엔드 데이터 신선도를 달성하고 Thanos보다 50배 저렴한 데이터 스토리지를 제공합니다.

이러한 성공은 Hydra의 레이크하우스 네이티브 설계 덕분입니다.

• 우리는 Databricks에서 Apache Spark™ Structured Streaming을 사용하여 메트릭 데이터가 도착하는 대로 증분적으로 처리하고 Delta Lake에 쓰는 연속 수집 작업을 실행합니다. Structured Streaming을 사용하면 배치 작업을 작성하는 것과 동일한 방식으로 스트리밍 계산을 표현할 수 있지만, 안정적인 수집을 위해 연속적이고 증분적인 처리와 정확히 한 번(exactly-once) 의미론을 제공합니다.
• 수백만 개의 객체 스토리지 파일을 효율적으로 검색하고 수집하기 위해, 우리는 수동 목록 작성이나 상태 관리 없이 새 파일을 추적하고 증분적으로 처리하는 고처리량 Structured Streaming 소스인 Databricks Auto Loader를 활용합니다. Auto Loader는 검색된 파일에 대한 메타데이터를 자동으로 유지하고 거의 실시간에 가까운 도착 패턴을 처리하도록 확장됩니다.
• 또한 우리는 지역별로 수집을 분할하여 여러 지리적 위치에 독립적인 스트리밍 작업을 배포합니다. 이를 통해 각 파이프라인은 독립적으로 자동 확장되고, 지역 간 지연 시간을 최소화하며, 실패 시 영향 범위를 줄입니다. 이러한 설계 선택은 함께 작동하여 수십억 개의 시계열 볼륨에서도 원시 메트릭 데이터가 방출된 후 몇 분 이내에 쿼리 가능하도록 하며, 대시보드 시스템의 성능을 유지합니다.

인터페이스 통합

Hydra를 구축하는 것은 단순히 인프라 과제가 아니라 인터페이스 설계 과제였습니다. 처음부터 우리는 스토리지 계층이나 수집 파이프라인보다는 엔지니어를 위한 핵심 사용자 여정(CUJ)을 중심으로 Hydra를 설계했습니다. 우리의 목표는 간단했습니다. 엔지니어들이 이미 사용하고 있는 동일한 인터페이스를 사용하여 고카디널리티 메트릭을 다룰 수 있도록 하는 것이었습니다.

Grafana를 통한 쿼리

대부분의 엔지니어는 Grafana에서 디버깅 워크플로를 시작합니다. 그들은 PromQL을 작성하고, 기존 대시보드를 사용하며, 레이블을 자세히 살펴보고, 인시던트 중에 빠르게 전환할 수 있기를 기대합니다.

이 워크플로를 유지하기 위해 Hydra는 Databricks에 저장된 데이터에 대해 PromQL 쿼리를 실행할 수 있도록 Grafana와 직접 통합됩니다. 우리는 PromQL 표현식을 레이크하우스의 Delta 테이블에서 실행되는 SQL 쿼리로 변환하는 PromQL-to-SQL 변환 계층을 구축했습니다. 이 접근 방식을 통해 엔지니어는 익숙한 PromQL 구문과 대시보드를 수정 없이 계속 사용할 수 있습니다. 동시에, 기본 쿼리는 인메모리 TSDB가 아닌 대규모 Delta 테이블에 대해 실행됩니다.

Databricks에서 직접 SQL 액세스

Grafana는 실시간 디버깅에 이상적이지만, 일부 조사는 더 심층적인 분석을 필요로 합니다. 엔지니어는 메트릭을 배포 메타데이터와 조인하고, 메트릭을 로그와 상호 연관시키고, 광범위한 시간 범위 스캔을 실행하고, 이상 감지를 수행하거나, 고급 분석을 위해 데이터 세트를 내보내야 할 수도 있습니다.

Hydra는 Databricks 내에서 기본 Delta 테이블을 직접 노출합니다. 엔지니어는 Databricks SQL 또는 노트북을 사용하여 이 테이블을 쿼리할 수 있으며, 이는 기존 모니터링 워크플로우를 넘어선 유연한 분석을 가능하게 합니다.

데이터가 Lakehouse에 있기 때문에 다른 엔터프라이즈 데이터셋과 조인할 수 있으며 동일한 보안 및 액세스 제어 하에 관리됩니다. 이는 관측성 데이터를 고립된 모니터링 사일로가 아닌 일류 분석 자산으로 전환시킵니다.

통합 메트릭 의미론

Hydra의 핵심 설계 원칙은 엔지니어가 데이터 수집 아키텍처를 이해할 필요가 없다는 것입니다. 메트릭이 TSDB 기반의 집계 경로를 통해 액세스되든, Lakehouse 기반의 원시 메트릭 경로를 통해 액세스되든 인터페이스는 일관되게 유지됩니다.

메트릭 이름, 레이블 의미론 및 메타데이터 차원은 모든 환경에서 통합됩니다. 서비스 팀은 표준화된 인터페이스를 사용하여 메트릭을 한 번만 내보냅니다. 플랫폼은 집계, 원시 데이터 보존, 수집, 저장 및 쿼리 라우팅을 처리합니다. 이 통합 모델은 인지 부하를 줄이고 팀이 서로 다른 관측성 백엔드에 대해 별도의 구성을 관리할 필요를 없앱니다.

앞으로 Hydra의 성능을 개선하여 Pantheon과 유사한 데이터 최신성을 달성하고 두 경험이 더욱 수렴되도록 노력할 것입니다.

핵심 내용

Databricks 모니터링 인프라를 확장하기 위해 안정성, 효율성, 운영성 및 개발자 여정을 최적화해야 했습니다. 우리에게 “확장”은 단순히 배포 규모를 늘리는 것 이상을 의미합니다. 이는 다음을 의미했습니다.

• 이러한 전역적이고 끊임없이 변화하는 시스템에 대해 “수동 개입 없는” 운영을 달성하기 위해 기본 아키텍처에 복원력과 자동화를 내재화하는 것
• 경고, 문제 해결, 데이터 소스 전반의 분석에 이르는 다양한 모니터링 사용 사례에 필요한 시스템의 종류를 첫 번째 원칙부터 다시 생각하는 것
• Databricks의 나머지 인프라가 우리와 함께 변화함에 따라 아키텍처를 발전시키는 것

이것은 우리에게 끝없는 여정이 될 것이며, Databricks에서 인프라 엔지니어링이 왜 그렇게 역동적인 분야인지 보여줍니다. 어려운 엔지니어링 문제 해결을 좋아하고 이 여정에 함께하고 싶다면 databricks.com/careers를 확인해 보세요!

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)