Databricks 모니터링 지표 정리, 비용 초과와 장애 미리 잡는 법

Databricks 구조부터 이해하기

Databricks는 workspace라는 협업 환경을 중심으로 돌아가는데, 크게 control plane과 compute plane으로 나뉩니다. control plane은 웹 애플리케이션, API, 오케스트레이션 백엔드 서비스, 그리고 데이터 거버넌스 솔루션인 Unity Catalog를 포함하고 있어서 data lineage와 쿼리 히스토리, 비용 기록 같은 운영 telemetry를 보여줍니다. compute plane은 실제 데이터 처리가 일어나는 곳인데, classic compute는 고객 클라우드 계정에서 돌아가 호스트 레벨 메트릭 수집과 모니터링 에이전트 설치가 가능하고, serverless compute는 Databricks가 관리해서 호스트 접근이 없는 대신 시스템 테이블로 쿼리 레벨 telemetry를 확인해야 합니다.

워크로드별로 봐야 할 핵심 지표

Job과 파이프라인은 system.lakeflow.job_run_timeline.result_state로 실패, 타임아웃, 스킵, 블록 상태를 알림 조건으로 걸고, period_start_time과 period_end_time으로 job 소요시간을 과거 기준선과 비교해 회귀를 잡아야 합니다. Spark 실행 성능 쪽은 (spark.executor.peak_mem.major_gc_time + minor_gc_time)을 spark.stage.executor_run_time 대비 비율로 보고 작업 시간 대비 GC 시간이 임계치(예: 10%)를 넘으면 알림을 걸고, spark.stage.disk_bytes_spilled로 셔플 데이터가 메모리에 못 들어가 디스크로 스필되는지 확인합니다. SQL warehouse는 system.query.history.waiting_at_capacity_duration_ms로 큐 대기시간을, total_duration_ms로 쿼리 지연을, read_bytes로 쿼리 효율을 추적합니다. 스트리밍은 spark.structured_streaming.input_rate와 processing_rate의 격차가 여러 트리거 구간에 걸쳐 지속되면 backpressure 신호로 보고, latency 지표가 트리거 간격을 넘으면 데이터 증가나 스키마 변경, 소스 측 쓰로틀링을 의심합니다.

실무 적용 포인트

이 지표들을 알림 체계로 옮길 때 체크할 점을 정리해봤어요.

• classic compute인지 serverless compute인지에 따라 모니터링 방식이 다르다는 점부터 확인하세요(classic은 에이전트 설치와 호스트 메트릭, serverless는 시스템 테이블 기반)
• job 실패는 downstream으로 전파되니 result_state 기반 알림을 가장 먼저 세팅하는 게 우선순위가 높습니다
• GC 시간과 디스크 스필 지표는 executor 리사이징이나 데이터 리파티셔닝 같은 구체적 조치로 이어지는 신호라서 단순 경고에 그치지 않고 대응 플레이북을 같이 준비해두면 좋아요
• SQL warehouse의 큐 대기시간 상승은 serverless autoscaling이 수요를 못 따라간다는 뜻이라 웨어하우스 사이즈 조정 타이밍을 판단하는 근거가 됩니다

이번 글은 시리즈 첫 편이고, 다음 편에서는 Databricks 자체 모니터링 리소스를 다룰 예정이라고 합니다.

자주 묻는 질문

Databricks란 무엇인가요

Databricks는 analytics, AI, 데이터 인텔리전스를 위한 플랫폼으로 lakehouse라는 구조를 선도한 솔루션이에요. 데이터 레이크의 유연한 저장과 웨어하우스의 ACID 트랜잭션, 강한 거버넌스를 결합해서 구조화, 반구조화, 비정형 데이터를 모두 다룰 수 있습니다.

Databricks의 compute plane과 control plane 차이는 뭔가요

control plane은 웹 애플리케이션, API, 오케스트레이션, Unity Catalog 거버넌스를 포함해서 데이터 lineage와 운영 telemetry를 보여주는 영역이에요. compute plane은 실제 데이터 읽기와 쓰기가 일어나는 영역으로, classic compute와 serverless compute 두 가지 옵션으로 나뉩니다.

Databricks에서 비용 초과를 막으려면 어떤 지표를 봐야 하나요

이번 가이드에서는 job 실패와 지연(result_state, duration), Spark 실행 성능(GC 시간, 디스크 스필), SQL warehouse 쿼리 대기시간과 읽기 바이트, 스트리밍 입력률 대비 처리율 격차 같은 지표를 구체적으로 제시하고 있어요. 다음 편에서 비용 이상 탐지를 더 자세히 다룰 예정입니다.

classic compute와 serverless compute 모니터링은 어떻게 다른가요

classic compute는 고객 클라우드 계정에서 돌아가기 때문에 호스트 레벨 메트릭 수집과 모니터링 에이전트 설치, 실행 로그 직접 수집이 가능합니다. serverless compute는 Databricks가 관리해서 호스트 접근이 없고, 대신 system.query.history 같은 시스템 테이블로 쿼리 레벨 telemetry와 warehouse 이벤트를 확인해야 해요.