주요 컨텐츠로 이동

워크플로우와 DLT 파이프라인에서 스트리밍 관찰 가능성 소개

간단하고 적극적인 백로그 관리를 통한 스트리밍 지표 모니터링 및 알림

Introducing Streaming Observability in Workflows and DLT Pipelines

Published: February 14, 2025

공지사항1분 이내 소요

Summary

  • 실시간 스트리밍 인사이트: Databricks 워크플로우와 Delta Live Tables (DLT)의 새로운 관찰 가능성은 Kafka, Kinesis, Delta 등에 대한 백로그 메트릭과 알림을 통해 모니터링을 간소화합니다.
  • 최적화된 파이프라인 성능: 시각적인 지표와 알림이 지연을 줄이고, 리소스를 관리하며, 데이터 신선도를 향상시킵니다.
  • 간소화된 스케일링: 신뢰할 수 있고, 고처리량 성능을 위해 스트리밍 파이프라인을 쉽게 추적하고, 조정하고, 최적화합니다.

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

Databricks는 WorkflowsDelta Live Tables (DLT) 파이프라인 내에서 향상된 스트리밍 관찰 기능을 소개하게 되어 기쁩니다. 이 기능은 데이터 엔지니어링 팀에게 실시간 데이터 처리를 최적화하는 강력한 도구를 제공합니다. 사용자 인터페이스는 직관성을 위해 설계되었으며, 사용자가 Kafka, Kinesis, Delta, Autoloader와 같은 주요 스트리밍 소스에서 처리된 바이트, 수집된 레코드, 처리된 파일 등의 핵심 지표를 모니터링할 수 있게 해줍니다.

적극적인, 작업 수준의 알림 구현을 통해 백로그 관리에서 모호성이 제거되어, 보다 효율적인 컴퓨팅 리소스 활용을 촉진하고 데이터 신선도 유지가 보장됩니다. 이러한 혁신은 조직이 신뢰할 수 있는 고성능 스트리밍 파이프라인을 통해 실시간 분석을 확장하게 함으로써, 의사결정 과정을 향상시키고 우수한 결과를 촉진합니다.

스트리밍 모니터링 및 알림에서 흔히 발생하는 문제들

증가하는 백로그는 일회성 수정부터 데이터 볼륨 증가를 처리하기 위한 재구성 또는 최적화 필요성에 이르기까지 다양한 문제를 나타낼 수 있습니다. 아래는 엔지니어링 팀이 스트리밍 파이프라인의 처리량과 신뢰성을 유지하기 위해 집중하는 몇 가지 중요한 영역입니다.

  1. 용량 계획
    이것은 고성능을 유지하고 시스템 안정성을 유지하기 위해 수직적으로 확장할지 (기존 리소스에 더 많은 파워를 추가) 또는 수평적으로 확장할지 (노드를 더 추가) 결정하는 것을 포함합니다.
  2. 운영 인사이트
    이에는 버스티 입력 패턴, 지속적인 고 처리량 기간 또는 하위 시스템의 둔화를 모니터링하는 것이 포함됩니다. 이상치 또는 급증의 조기 감지는 원활한 운영을 유지하기 위한 적극적인 대응을 가능하게 합니다.
  3. 데이터 신선도 보장
    실시간 애플리케이션, 예를 들어 머신 러닝 모델이나 스트림에 내장된 비즈니스 로직에서는 가장 최신의 데이터에 접근하는 것이 매우 중요합니다. 오래된 데이터는 부정확한 결정을 초래할 수 있으므로 스트리밍 워크플로우에서 데이터 신선도를 우선시하는 것이 중요합니다.
  4. 오류 감지 및 문제 해결
    이는 문제를 플래그하고 실행 가능한 인사이트를 제공하며 엔지니어가 빠르게 수정 조치를 취할 수 있도록 강력한 모니터링 및 알림 시스템이 필요합니다.

스트림의 백로그를 이해하는 데는 여러 단계가 필요했습니다. Delta Live Tables에서는 파이프라인 이벤트 로그 를 계속 파싱하여 관련 정보를 추출하는 것이 포함되었습니다. 구조화된 스트리밍의 경우, 엔지니어들은 종종 Spark의 StreamingQueryListener 에 의존하여 백로그 지표를 캡처하고 이를 제3자 도구로 밀어내는데, 이는 추가 개발 및 유지 관리 오버헤드를 도입했습니다. 알림 메커니즘을 설정하는 것은 더 복잡하게 만들었으며, 더 많은 사용자 정의 코드와 구성이 필요했습니다.

지표가 전달된 후에도 백로그를 지우는 데 필요한 시간에 대한 기대 관리에는 여전히 도전이 있습니다. 데이터가 따라잡을 때까지 정확한 예측을 제공하는 것은 처리량, 리소스 가용성, 스트리밍 작업 부하의 동적 특성과 같은 변수를 포함하므로 정확한 예측을 하는 것이 어렵습니다.

Workflows와 Delta Live Tables는 이제 백로그 지표를 표시합니다.

스트리밍 관찰 가능성의 출시로 데이터 엔지니어는 이제 워크플로우 및 DLT UI의 시각적 지표를 통해 백로그를 쉽게 감지하고 관리할 수 있습니다. 스트리밍 백로그 메트릭은 워크플로우 UI의 Databricks 노트북 코드와 나란히 위치해 있습니다.

Workflow UI의 오른쪽 창에 표시되는 스트리밍 지표 그래프는 백로그를 강조합니다. 이 그래프는 시간에 따른 미처리 데이터의 양을 플롯합니다. 데이터 처리 속도가 데이터 입력 속도보다 느려지면, 백로그가 쌓이기 시작하며, 이는 그래프에서 명확하게 시각화됩니다.

Workflows UI에서 백로그 지표에 대한 알림 설정

Databricks는 시작, 지속 시간, 실패, 성공에 대한 알림을 포함하는 기존 기능과 함께 백로그 메트릭을 통합함으로써 알림 기능을 강화하고 있습니다. 사용자는 워크플로우 UI 내에서 스트리밍 메트릭에 대한 임계값을 설정하여, 이러한 한계가 초과될 때마다 알림이 트리거되도록 할 수 있습니다. 알림은 이메일, 슬랙, 마이크로소프트 팀, 웹훅, 또는 PagerDuty를 통해 알림을 보낼 수 있도록 설정할 수 있습니다. DLT 파이프라인에 알림을 구현하는 가장 좋은 방법은 Databricks 워크플로우를 사용하여 조정하는 것입니다.

위의 알림은 이메일을 통해 전달되었으며, Workflows UI로 직접 클릭할 수 있게 해줍니다.

DLT에서 실시간 백로그 메트릭을 통한 스트리밍 파이프라인 성능 향상

Delta Live Tables에서 스트리밍 파이프라인을 관리하고 최적화하는 것은 큰 도전이며, 특히 Kafka와 같은 고처리량 데이터 소스를 다루는 팀에게는 더욱 그렇습니다. 데이터 볼륨이 확장됨에 따라 백로그가 증가하고, 이로 인해 성능이 저하됩니다. 서버리스 DLT에서는 스트림 파이프라이닝과 수직 자동 확장과 같은 기능이 시스템 성능을 효과적으로 유지하는 데 도움이 되지만, 비서버리스에서는 이러한 기능이 사용할 수 없습니다.

주요 문제 중 하나는 백로그 메트릭에 대한 실시간 가시성이 부족하여, 팀이 빠르게 문제를 식별하고 파이프라인을 최적화하기 위한 정보를 제공하는 능력을 저해합니다. 현재 DLT 파이프라인은 이벤트 로그 지표에 의존하며, 이는 백로그를 효과적으로 추적하기 위해 사용자 정의 대시보드 또는 모니터링 솔루션을 필요로 합니다.

그러나 새로운 스트리밍 관찰 기능을 통해 데이터 엔지니어는 DLT UI를 통해 백로그를 신속하게 식별하고 관리할 수 있어 모니터링 및 최적화의 효율성이 향상됩니다.

여기서는 카프카로부터 데이터를 수집하고 스트리밍 델타 테이블에 쓰는 델타 라이브 테이블 파이프라인을 살펴보겠습니다. 아래 코드는 DLT에서의 테이블 정의를 나타냅니다.

kafka_stream_bronze 는 파이프라인에서 생성된 스트리밍 델타 테이블로, 지속적인 데이터 처리를 위해 설계되었습니다. maxOffsetsPerTrigger 설정은 DLT 파이프라인 내에서 트리거 간격당 처리할 수 있는 Kafka 오프셋의 최대 수를 1000으로 제한하여 제어합니다. 이 값은 현재 데이터 크기에 기반한 필요한 처리 속도를 분석하여 결정되었습니다. 파이프라인은 초기 설정의 일부로 Kafka에서 과거 데이터를 처리하고 있습니다.

처음에는 Kafka 스트림이 초당 1000개 미만의 레코드를 생성하였고, 백로그 지표는 꾸준히 감소하였습니다(이미지1 참조). Kafka에서 들어오는 데이터의 양이 증가하기 시작하면, 시스템은 부하가 증가하고 있음을 나타내는 징후를 보이기 시작합니다(이미지 2와 3 참조), 이는 처리가 증가하는 데이터 볼륨을 따라잡는 데 어려움을 겪고 있음을 나타냅니다. 초기 설정은 처리에 지연을 초래하여 인스턴스와 설정 설정을 재평가하게 됩니다.

초기 설정이 maxOffsetsPerTrigger 를 1000으로 제한하는 것이 증가하는 부하를 효과적으로 처리하는 데 부족하다는 것이 분명해졌습니다. 이를 해결하기 위해, 아래와 같이 트리거당 최대 10,000개의 오프셋을 허용하도록 설정이 조정되었습니다.

이는 파이프라인이 각 트리거에서 더 큰 데이터 배치를 처리하도록 도와, 처리량을 크게 향상시켰습니다. 이 조정을 한 후에는 백로그 지표가 일관되게 감소하는 것을 보았습니다(이미지 4 참조), 이는 시스템이 들어오는 데이터 스트림을 성공적으로 따라잡고 있음을 나타냅니다. 백로그의 감소는 전체 시스템 성능을 향상시켰습니다.

이 경험은 스트림 백로그 메트릭을 시각화하는 것의 중요성을 강조하며, 이를 통해 구성에 대한 적극적인 조정을 가능하게 하고 파이프라인이 변화하는 데이터 요구 사항을 효과적으로 관리할 수 있도록 합니다. 백로그의 실시간 추적은 복잡한 이벤트 로그 쿼리나 스파크 UI 탐색 없이 Kafka 스트리밍 파이프라인을 최적화하는 데 도움이 되었으며, 지연을 줄이고 데이터 처리량을 향상시켰습니다.

병목 현상이 당신을 놀라게 하지 않도록 하세요. 백로그, 신선도, 처리량을 모니터링하기 위해 새로운 관찰 가능성 기능을 활용하세요. 오늘 시도해보고 스트레스 없는 데이터 파이프라인 관리를 경험해보세요.

게시물을 놓치지 마세요

관심 있는 카테고리를 구독하고 최신 게시물을 받은편지함으로 받아보세요