Azure Databricks의 성능 병목 상태 문제 해결

  • 아티클

참고

이 문서는 https://github.com/mspnp/spark-monitoring의 GitHub에서 호스트되는 오픈 소스 라이브러리에 따라 다릅니다.

원래 라이브러리는 Azure Databricks Runtimes 10.x(Spark 3.2.x) 이하를 지원합니다.

Databricks는 의 분기에서 https://github.com/mspnp/spark-monitoring/tree/l4jv2Azure Databricks Runtimes 11.0(Spark 3.3.x) 이상을 지원하기 위해 l4jv2 업데이트된 버전을 기여했습니다.

Databricks Runtimes에 사용되는 다른 로깅 시스템으로 인해 11.0 릴리스는 이전 버전과 호환되지 않습니다. Databricks Runtime에 올바른 빌드를 사용해야 합니다. 라이브러리 및 GitHub 리포지토리는 유지 관리 모드에 있습니다. 추가 릴리스에 대한 계획은 없으며 문제 지원은 최선의 노력일 뿐입니다. Azure Databricks 환경의 모니터링 및 로깅을 위한 라이브러리 또는 로드맵에 대한 추가 질문은 에 문의 azure-spark-monitoring-help@databricks.com하세요.

이 문서에서는 모니터링 대시보드를 사용하여 Azure Databricks의 Spark 작업에서 성능 병목 상태를 찾는 방법을 설명합니다.

Azure Databricks는 빅 데이터 분석을 신속하게 개발 및 배포할 수 있는 Apache Spark 기반 분석 서비스입니다. 프로덕션 Azure Databricks 워크로드를 운영할 때 성능 문제를 모니터링하고 해결하는 것은 매우 중요합니다. 일반적인 성능 문제를 식별하려면 원격 분석 데이터를 기반으로 모니터링 시각화를 사용하는 것이 유용합니다.

필수 구성 요소

이 문서에 표시된 Grafana 대시보드를 설정하려면 다음을 수행합니다.

배포된 Grafana 대시보드에는 시계열 시각화 집합이 포함되어 있습니다. 각 그래프는 Apache Spark 작업, 작업의 스테이지, 각 스테이지를 구성하는 태스크와 관련된 메트릭의 시계열 플롯입니다.

Azure Databricks 성능 개요

Azure Databricks는 범용 분산 컴퓨팅 시스템인 Apache Spark를 기반으로 합니다. 작업이라고 하는 애플리케이션 코드는 클러스터 관리자가 조정하는 Apache Spark 클러스터에서 실행됩니다. 일반적으로 작업은 가장 높은 수준의 계산 단위입니다. 작업은 Spark 애플리케이션에서 수행하는 전체 작업을 나타냅니다. 일반적인 작업에는 원본에서 데이터를 읽고, 데이터 변환을 적용하고, 결과를 스토리지 또는 다른 대상에 쓰는 작업이 포함됩니다.

작업은 스테이지로 분류됩니다. 작업은 스테이지를 순차적으로 진행하므로 이후 스테이지에서는 이전 스테이지가 완료될 때까지 기다려야 합니다. 스테이지에는 Spark 클러스터의 여러 노드에서 병렬로 실행할 수 있는 동일한 태스크 그룹이 포함됩니다. 태스크는 데이터의 하위 집합에서 발생하는 가장 세분화된 실행 단위입니다.

다음 섹션에서는 성능 문제 해결에 유용한 몇 가지 대시보드 시각화에 대해 설명합니다.

작업 및 스테이지 대기 시간

작업 대기 시간은 작업 실행이 시작될 때부터 완료될 때까지의 소요 시간입니다. 이상값을 시각화할 수 있도록 클러스터 및 애플리케이션 ID당 작업 실행의 백분위수로 표시됩니다. 다음 그래프는 50번째 백분위수가 일관되게 약 10초였음에도 불구하고 90번째 백분위수가 50초에 도달한 작업 기록을 보여줍니다.

작업 대기 시간을 보여 주는 그래프

클러스터 및 애플리케이션별로 작업 실행을 조사하여 대기 시간 급증을 찾습니다. 대기 시간이 긴 클러스터 및 애플리케이션이 식별되면 스테이지 대기 시간을 조사합니다.

스테이지 대기 시간은 이상값을 시각화할 수 있도록 백분위수로도 표시됩니다. 스테이지 대기 시간은 클러스터, 애플리케이션 및 스테이지 이름으로 구분됩니다. 그래프에서 태스크 대기 시간의 급증을 식별하여 어떤 태스크가 스테이지 완료를 지연시키는지 확인합니다.

스테이지 대기 시간을 보여 주는 그래프

클러스터 처리량 그래프는 분당 완료된 작업, 스테이지 및 태스크의 수를 보여줍니다. 이렇게 하면 작업당 상대적 스테이지 및 태스크 수 측면에서 워크로드를 이해할 수 있습니다. 여기서 분당 작업 수는 2~6개이고 스테이지 수는 분당 약 12~24개임을 알 수 있습니다.

클러스터 처리량을 보여 주는 그래프

태스크 실행 대기 시간의 합계

이 시각화는 클러스터에서 실행 중인 호스트당 태스크 실행 대기 시간의 합계를 보여줍니다. 이 그래프를 사용하여 클러스터에서 호스트 속도가 느려지거나 실행기당 태스크 할당이 잘못되었기 때문에 느리게 실행되는 태스크를 감지합니다. 다음 그래프에서 대부분의 호스트의 합계는 약 30초입니다. 그러나 호스트 중 두 개의 합계는 약 10분입니다. 호스트가 느리게 실행되거나 실행기당 태스크 수가 잘못 할당되었습니다.

호스트당 작업 실행 합계를 보여 주는 그래프

실행기당 태스크 수는 두 실행기에 불균형한 수의 태스크가 할당되어 병목 상태가 발생했음을 보여줍니다.

실행기당 작업을 보여 주는 그래프

스테이지당 태스크 메트릭

태스크 메트릭 시각화는 태스크 실행에 대한 비용 분석을 제공합니다. 이를 사용하여 serialization 및 deserialization과 같은 태스크에 소요된 상대적 시간을 확인할 수 있습니다. 이 데이터는 예를 들어 broadcast 변수를 사용하여 데이터 전달을 방지하여 최적화 기회를 보여줄 수 있습니다. 태스크 메트릭에는 태스크에 대한 셔플 데이터 크기 및 셔플 읽기 및 쓰기 시간도 표시됩니다. 이 값이 높으면 많은 데이터가 네트워크를 통해 이동한다는 의미입니다.

또 다른 태스크 메트릭은 태스크를 예약하는 데 걸리는 시간을 측정하는 스케줄러 지연입니다. 이상적으로는 이 값은 실제로 태스크를 실행하는 데 소요된 시간인 실행기 컴퓨팅 시간에 비해 낮아야 합니다.

다음 그래프는 실행기 컴퓨팅 시간(1.1초)을 초과하는 스케줄러 지연 시간(3.7초)을 보여줍니다. 즉, 실제 태스크를 수행하는 것보다 태스크가 예약될 때까지 대기하는 데 더 많은 시간이 소요된다는 의미입니다.

스테이지당 작업 메트릭을 보여 주는 그래프

이 경우 파티션이 너무 많아서 많은 오버헤드가 발생하여 문제가 발생했습니다. 파티션 수를 줄이면 스케줄러 지연 시간이 줄어듭니다. 다음 그래프는 대부분의 시간이 태스크를 실행하는 데 소요되었음을 보여줍니다.

파티션 수를 줄이면 스케줄러 지연 시간이 감소함을 보여 주는 그래프

스트리밍 처리량 및 대기 시간

스트리밍 처리량은 구조적 스트리밍과 직접 관련이 있습니다. 스트리밍 처리량과 관련된 두 가지 중요한 메트릭은 초당 입력 행과 초당 처리된 행입니다. 초당 입력 행이 초당 처리된 행을 초과하면 스트림 처리 시스템이 뒤쳐지고 있다는 의미입니다. 또한 입력 데이터가 Event Hubs 또는 Kafka에서 오는 경우 초당 입력 행은 프런트 엔드의 데이터 수집 속도를 따라야 합니다.

두 작업의 클러스터 처리량은 비슷하지만 스트리밍 메트릭이 매우 다를 수 있습니다. 다음 스크린샷은 두 가지 워크로드를 보여줍니다. 클러스터 처리량(분당 작업, 스테이지, 태스크)의 측면에서 유사합니다. 그러나 두 번째 실행은 12,000행/초 대 4,000행/초를 처리합니다.

스트리밍 처리량을 보여 주는 그래프

스트리밍 처리량은 처리되는 데이터 레코드 수를 측정하기 때문에 클러스터 처리량보다 더 나은 비즈니스 메트릭인 경우가 많습니다.

실행기당 리소스 소비량

이러한 메트릭은 각 실행기가 수행하는 작업을 이해하는 데 도움이 됩니다.

백분율 메트릭은 실행기가 다양한 항목에 소비하는 시간을 측정하며, 소비한 시간 대비 전체 실행기 컴퓨팅 시간의 비율로 표시됩니다. 메트릭은 다음과 같습니다.

  • % Serialize 시간
  • % Deserialize 시간
  • % CPU 실행기 시간
  • % JVM 시간

이러한 시각화는 이러한 각 메트릭이 전체 실행기 처리에 얼마나 기여하는지 보여줍니다.

이러한 각 메트릭이 전체 실행기 처리에 얼마나 기여하는지 보여 주는 시각화

셔플 메트릭은 실행기 간의 데이터 셔플링과 관련된 메트릭입니다.

  • 셔플 I/O
  • 셔플 메모리
  • 파일 시스템 사용량
  • 디스크 사용량

일반적인 성능 병목 상태

Spark의 두 가지 일반적인 성능 병목 상태는 태스크 스트래글러(task stragglers) 및 최적이 아닌 셔플 파티션 수(non-optimal shuffle partition count)입니다.

태스크 스트래글러(straggler)

작업의 스테이지는 순차적으로 실행되며 이전 스테이지는 이후 스테이지를 차단합니다. 한 태스크가 다른 태스크보다 셔플 파티션을 더 느리게 실행하는 경우 클러스터의 모든 태스크는 느린 태스크가 따라잡을 때까지 기다려야 하며 그 후에 스테이지가 끝날 수 있습니다. 이 문제는 다음과 같은 이유로 발생할 수 있습니다.

  1. 호스트 또는 호스트 그룹이 느리게 실행되고 있습니다. 증상: 태스크, 스테이지 또는 작업 대기 시간이 높고 클러스터 처리량이 낮습니다. 호스트당 태스크 대기 시간의 합계는 균등하게 분산되지 않습니다. 하지만 리소스 소비량은 실행기 간에 균등하게 분산됩니다.

  2. 태스크에 실행하는 데 비용이 많이 드는 집계(데이터 기울이기)가 있습니다. 증상: 높은 태스크 대기 시간, 높은 스테이지 대기 시간, 높은 작업 대기 시간 또는 낮은 클러스터 처리량이지만 호스트당 대기 시간 합계는 균등하게 분산됩니다. 리소스 소비량은 실행기 간에 균등하게 분산됩니다.

  3. 파티션 크기가 같지 않으면 파티션이 클수록 태스크 실행이 불균형해질 수 있습니다(파티션 기울이기). 증상: 실행기 리소스 소비량이 클러스터에서 실행되는 다른 실행기에 비해 높습니다. 해당 실행기에서 실행되는 모든 태스크는 느리게 실행되고 파이프라인에서 스테이지 실행을 보류합니다. 이러한 스테이지를 스테이지 장벽(stage barriers)이라고 합니다.

최적이 아닌 셔플 파티션 수

구조적 스트리밍 쿼리 중에 실행기에 태스크를 할당하는 것은 클러스터에 대한 리소스 집약적인 작업입니다. 셔플 데이터가 최적의 크기가 아닌 경우 태스크의 지연 시간은 처리량과 대기 시간에 부정적인 영향을 미칩니다. 파티션이 너무 적으면 클러스터의 코어 사용이 부족하여 처리 비효율성이 발생할 수 있습니다. 반대로 파티션이 너무 많으면 적은 수의 태스크에 대해 상당한 관리 오버헤드가 발생합니다.

리소스 소비량 메트릭을 사용하여 클러스터에서 실행기의 파티션 기울이기 및 잘못된 할당 문제를 해결합니다. 파티션이 기울어지면 실행기 리소스는 클러스터에서 실행되는 다른 실행기와 비교하여 상승됩니다.

예를 들어, 다음 그래프에서는 처음 두 실행기에서 셔플링에 사용된 메모리가 다른 실행기보다 90배 더 큰 것을 볼 수 있습니다.

처음 두 실행기에서 셔플링에 사용된 메모리가 다른 실행기보다 90배 더 큰 것을 보여 주는 그래프

다음 단계