성능 조정에 대한 가시성 패턴 및 메트릭

이 솔루션은 Azure Databricks를 사용하는 빅 데이터 시스템의 처리 성능을 개선하기 위한 관찰 가능성 패턴 및 메트릭을 보여 줍니다.

아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

솔루션에는 다음 단계가 포함됩니다.

1. 서버는 고객이 그룹화한 큰 GZIP 파일을 Azure Data Lake Storage의 원본 폴더로 보냅니다.

2. 그런 다음 Data Lake Storage는 성공적으로 추출된 고객 파일을 Azure Event Grid로 보내 고객 파일 데이터를 여러 메시지로 바꿉니다.

3. Azure Event Grid는 메시지를 큐에 저장하는 Azure Queue Storage 서비스로 보냅니다.

4. Azure Queue Storage는 처리를 위해 Azure Databricks 데이터 분석 플랫폼으로 큐를 보냅니다.

5. Azure Databricks는 큐 데이터를 Data Lake Storage로 다시 보내는 처리된 파일로 압축을 풀고 처리합니다.

   1. 처리된 파일이 유효하면 Landing 폴더로 이동합니다.

   2. 그렇지 않으면 파일이 Bad 폴더 트리로 이동합니다. 처음에는 파일이 재시도 하위 폴더에 들어가고 Data Lake Storage는 고객 파일 처리를 다시 시도합니다(2단계). 한 쌍의 다시 시도가 여전히 유효하지 않은 처리된 파일을 반환하는 Azure Databricks로 이어지는 경우 처리된 파일은 Failure 하위 폴더로 이동합니다.

6. Azure Databricks는 이전 단계에서 데이터의 압축을 풀고 처리할 때 스토리지를 위해 애플리케이션 로그 및 메트릭도 Azure Monitor로 보냅니다.

7. Azure Log Analytics 작업 영역은 문제 해결 및 심층 진단을 위해 Azure Monitor의 애플리케이션 로그 및 메트릭에 Kusto 쿼리를 적용합니다.

구성 요소

• Azure Data Lake Storage는 빅 데이터 분석 전용 기능 모음입니다.
• Azure Event Grid를 사용하면 개발자가 이벤트 기반 아키텍처로 애플리케이션을 쉽게 빌드할 수 있습니다.
• Azure Queue Storage는 대량의 메시지를 저장하는 서비스입니다. HTTP 또는 HTTPS를 사용하여 인증된 호출을 통해 전 세계 어디에서나 메시지에 액세스할 수 있습니다. 큐를 사용하여 비동기식으로 처리할 작업의 백로그를 만들 수 있습니다.
• Azure Databricks 는 Azure 클라우드 플랫폼에 최적화된 데이터 분석 플랫폼입니다. Azure Databricks가 데이터 집약적인 애플리케이션 개발을 위해 제공하는 두 가지 환경 중 하나는 대규모 데이터 처리를 위한 Apache Spark 기반 통합 분석 엔진인 Azure Databricks 작업 영역입니다.
• Azure Monitor는 성능 메트릭 및 활동 로그와 같은 앱 원격 분석을 수집하고 분석합니다.
• Azure Log Analytics는 데이터로 로그 쿼리를 편집하고 실행하는 데 사용되는 도구입니다.

시나리오 정보

개발 팀은 관찰 가능성 패턴과 메트릭을 사용하여 병목 현상을 찾고 빅 데이터 시스템의 성능을 개선할 수 있습니다. 팀은 대규모 애플리케이션에서 대량의 메트릭 스트림에 대한 부하 테스트를 수행해야 합니다.

이 시나리오는 성능 튜닝에 대한 지침을 제공합니다. 이 시나리오는 고객당 로깅에 대한 성능 문제를 제시하므로 다음 항목을 강력하게 모니터링할 수 있는 Azure Databricks를 사용합니다.

• 사용자 지정 애플리케이션 메트릭
• 스트리밍 쿼리 이벤트
• 애플리케이션 로그 메시지

Azure Databricks는 이 모니터링 데이터를 Azure Log Analytics와 같은 다양한 로깅 서비스로 보낼 수 있습니다.

이 시나리오는 고객별로 그룹화되고 GZIP 보관 파일에 저장된 대규모 데이터 세트의 수집을 간략하게 설명합니다. 자세한 로그는 실시간 Apache Spark 사용자 인터페이스 외부의 Azure Databricks에서 사용할 수 없으므로 팀은 각 고객에 대한 모든 데이터를 저장한 다음 벤치마킹하고 비교할 방법이 필요합니다. 대규모 데이터 시나리오에서는 가장 빠른 처리 시간을 위해 최적의 조합 실행기 풀과 VM(가상 머신) 크기를 찾는 것이 중요합니다. 이 비즈니스 시나리오의 경우 전체 애플리케이션은 수집 속도 및 쿼리 요구 사항에 의존하므로 시스템 처리량이 증가하는 작업량과 함께 예기치 않게 저하되지 않습니다. 시나리오는 시스템이 고객과 설정한 SLA(서비스 수준 약정)를 충족함을 보장해야 합니다.

잠재적인 사용 사례

이 솔루션의 이점을 얻을 수 있는 시나리오는 다음과 같습니다.

• 시스템 상태 모니터링:
• 성능 유지.
• 일상적인 시스템 사용을 모니터링합니다.
• 해결되지 않은 경우 향후 문제를 일으킬 수 있는 추세를 파악합니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

이 아키텍처를 고려할 때 다음 사항을 염두에 두세요.

• Azure Databricks는 대규모 작업에 필요한 컴퓨팅 리소스를 자동으로 할당하여 다른 솔루션에서 발생하는 문제를 방지할 수 있습니다. 예를 들어 Apache Spark의 Databricks 최적화 자동 크기 조정을 사용하는 경우 과도한 프로비저닝으로 인해 리소스 사용이 최적화되지 않을 수 있습니다. 또는 작업에 필요한 실행기의 수를 모를 수도 있습니다.

• Azure Queue Storage의 큐 메시지 크기는 최대 64KB일 수 있습니다. 큐에는 스토리지 계정의 총 용량 제한까지 수백만 개의 큐 메시지가 포함될 수 있습니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

Azure 가격 계산기를 사용하여 이 솔루션 구현 비용을 예상합니다.

시나리오 배포

프로세스의 모든 로그 및 정보를 가져오려면 Azure Log Analytics 및 Azure Databricks 모니터링 라이브러리를 설정합니다. 모니터링 라이브러리는 작업에서 Azure Monitor로 Apache Spark 수준 이벤트 및 Spark 구조적 스트리밍 메트릭을 스트리밍합니다. 이러한 이벤트 및 메트릭에 대한 애플리케이션 코드를 변경할 필요가 없습니다.

빅 데이터 시스템에 대한 성능 튜닝을 설정하는 단계는 다음과 같습니다.

1. Azure Portal에서 Azure Databricks 작업 영역을 만듭니다. 나중에 사용할 수 있는 Azure 구독 ID(GUID(Globally Unique Identifier), 리소스 그룹 이름, Databricks 작업 영역 이름 및 작업 영역 포털 URL을 복사하고 저장합니다.

2. 웹 브라우저에서 Databricks 작업 영역 URL로 이동하여 Databricks 개인용 액세스 토큰을 생성합니다. 나중에 사용할 수 있도록 표시되는 토큰 문자열(dapi 및 32자 16진수 값으로 시작)을 복사하여 저장합니다.

3. mspnp/spark-monitoring GitHub 리포지토리를 로컬 컴퓨터에 복제합니다. 이 리포지토리에는 다음 구성 요소에 대한 소스 코드가 있습니다.

   • Azure Log Analytics 작업 영역을 만들기 위한 ARM 템플릿(Azure Resource Manager 템플릿) - Spark 메트릭 수집을 위해 미리 빌드된 쿼리도 설치합니다.
   • Azure Databricks 모니터링 라이브러리
   • Azure Databricks에서 Azure Monitor로 애플리케이션 메트릭 및 애플리케이션 로그를 보내기 위한 샘플 애플리케이션

4. ARM 템플릿을 배포하기 위해 Azure CLI 명령을 사용하여 미리 빌드된 Spark 메트릭 쿼리로 Azure Log Analytics 작업 영역을 만듭니다. 명령 출력에서 새 Log Analytics 작업 영역에 대해 생성된 이름을 복사하고 저장합니다(spark-monitoring-<randomized-string> 형식).

5. Azure Portal에서 나중에 사용할 수 있도록 Log Analytics 작업 영역 ID 및 키를 복사하고 저장합니다.

6. JDK(Java Development Kit) 및 Apache Maven을 기본적으로 지원하는 IDE(통합 개발 환경)인 IntelliJ IDEA Community 버전을 설치합니다. Scala 플러그 인을 추가합니다.

7. IntelliJ IDEA를 사용하여 Azure Databricks 모니터링 라이브러리를 빌드합니다. 실제 빌드 단계를 수행하려면 보기>도구 창>Maven을 선택하여 Maven 도구 창을 표시한 다음 Maven Goal 실행>mvn package를 선택합니다.

8. Python 패키지 설치 도구를 사용하여 Azure Databricks CLI를 설치하고 이전에 복사한 Databricks 개인용 액세스 토큰으로 인증을 설정합니다.

9. 이전에 복사한 Databricks 및 Log Analytics 값으로 Databricks 초기화 스크립트를 수정한 다음 Azure Databricks CLI를 통해 초기화 스크립트 및 Azure Databricks 모니터링 라이브러리를 Databricks 작업 영역에 복사하여 Azure Databricks 작업 영역을 구성합니다.

10. Databricks 작업 영역 포털에서 Azure Databricks 클러스터를 만들고 구성합니다.

11. IntelliJ IDEA에서 Maven을 사용하여 샘플 애플리케이션을 빌드합니다. 그런 다음 Databricks 작업 영역 포털에서 샘플 애플리케이션을 실행하여 Azure Monitor에 대한 샘플 로그 및 메트릭을 생성합니다.

12. 샘플 작업이 Azure Databricks에서 실행되는 동안 Azure Portal로 이동하여 Log Analytics 인터페이스에서 이벤트 유형(애플리케이션 로그 및 메트릭)을 보고 쿼리합니다.

    1. Spark 수신기 이벤트(SparkListenerEvent_CL), Spark 로깅 이벤트(SparkLoggingEvent_CL), Spark 메트릭(SparkMetric_CL)에 대한 테이블 스키마를 보려면 테이블>사용자 지정 로그를 선택합니다.
    2. 쿼리 탐색기>저장된 쿼리>Spark 메트릭을 선택하여 Log Analytics 작업 영역을 만들 때 추가된 쿼리를 보고 실행합니다.

    다음 섹션에서 미리 빌드된 사용자 지정 쿼리를 보고 실행하는 방법에 대해 자세히 알아봅니다.

Azure Log Analytics에서 로그 및 메트릭 쿼리

미리 빌드된 쿼리에 액세스

Spark 지표를 쿼리하기 위해 미리 빌드된 쿼리 이름은 아래에 나열되어 있습니다.

사용자 지정 쿼리 작성

KQL(Kusto 쿼리 언어)로 고유한 쿼리를 작성할 수도 있습니다. 편집 가능한 상단 중간 창을 선택하고 필요에 맞게 쿼리를 사용자 지정하기만 하면 됩니다.

다음 두 쿼리는 Spark 로깅 이벤트에서 데이터를 가져옵니다.

SparkLoggingEvent_CL | where logger_name_s contains "com.microsoft.pnp"

SparkLoggingEvent_CL
| where TimeGenerated > ago(7d)
| project TimeGenerated, clusterName_s, logger_name_s
| summarize Count=count() by clusterName_s, logger_name_s, bin(TimeGenerated, 1h)

그리고 이 두 가지 예는 Spark 메트릭 로그에 대한 쿼리입니다.

SparkMetric_CL
| where name_s contains "executor.cpuTime"
| extend sname = split(name_s, ".")
| extend executor=strcat(sname[0], ".", sname[1])
| project TimeGenerated, cpuTime=count_d / 100000

SparkMetric_CL
| where name_s contains "driver.jvm.total."
| where executorId_s == "driver"
| extend memUsed_GB = value_d / 1000000000
| project TimeGenerated, name_s, memUsed_GB
| summarize max(memUsed_GB) by tostring(name_s), bin(TimeGenerated, 1m)

쿼리 용어

다음 표에서는 애플리케이션 로그 및 메트릭 쿼리를 구성할 때 사용되는 몇 가지 용어를 설명합니다.

다음 섹션에는 시스템 처리량, Spark 작업 실행 상태 및 시스템 리소스 사용량을 모니터링하기 위해 이 시나리오에서 사용되는 일반적인 메트릭이 포함되어 있습니다.

시스템 처리량

Spark 작업 실행 상태

시스템 리소스 사용량

Azure Databricks가 전체 일괄 처리 작업을 단위로 처리하므로 GZIP 보관 파일에 결합된 고객 입력을 특정 Azure Databricks 출력 파일과 연결하는 방법을 결정합니다. 여기에서 추적에 세분성을 적용합니다. 또한 사용자 지정 메트릭을 사용하여 하나의 출력 파일을 원본 입력 파일로 추적합니다.

각 메트릭에 대한 자세한 정의는 이 웹 사이트에서 대시보드의 시각화를 참조하거나 Apache Spark 설명서의 메트릭 섹션을 참조하세요.

성능 튜닝 옵션 평가

기준선 정의

사용자와 사용자의 개발 팀은 애플리케이션의 향후 상태를 비교할 수 있도록 기준선을 설정해야 합니다.

애플리케이션의 성능을 정량적으로 측정합니다. 이 시나리오에서 주요 메트릭은 대부분의 데이터 미리 처리 및 수집에서 일반적으로 나타나는 작업 대기 시간입니다. 아래 차트와 같이 데이터 처리 시간을 가속화하고 대기 시간 측정에 집중합니다.

작업의 실행 대기 시간을 측정합니다. 전체 작업 성능에 대한 대략적인 관점과 시작부터 완료까지의 작업 실행 기간(마이크로 배치 시간)입니다. 위의 차트에서 19:30 표시에서 작업을 처리하는 데 소요되는 시간은 약 40초입니다.

이 40초를 자세히 살펴보면 단계에 대한 아래 데이터를 볼 수 있습니다.

19시 30분에 두 단계가 있습니다. 10초의 주황색 단계와 30초의 녹색 단계입니다. 급증은 단계의 지연을 나타내므로 단계 급증 여부를 모니터링합니다.

특정 단계가 느리게 실행되고 있는지 조사합니다. 분할 시나리오에는 일반적으로 파일을 읽는 단계와 파일을 무작위로 재생하고, 분할하고, 쓰기 위한 다른 단계의 두 가지 단계가 있습니다. 쓰기 단계에서 대부분의 단계 대기 시간이 긴 경우 분할 중에 병목 현상이 발생할 수 있습니다.

작업의 단계가 순차적으로 실행될 때 작업을 관찰하고 이전 단계는 이후 단계를 차단합니다. 단계 내에서 한 작업이 다른 작업보다 느린 무작위 재생 파티션을 실행하면 클러스터의 모든 작업은 단계가 완료될 때까지 느린 작업이 완료될 때까지 기다려야 합니다. 그런 다음 작업은 데이터 기울이기 및 가능한 병목 현상을 모니터링하는 방법입니다. 위의 차트를 보면 모든 작업이 고르게 분포되어 있는 것을 볼 수 있습니다.

이제 처리 시간을 모니터링합니다. 스트리밍 시나리오가 있으므로 스트리밍 처리량을 살펴봅니다.

위의 스트리밍 처리량/일괄 처리 대기 시간 차트에서 주황색 선은 입력 속도(초당 입력 행 수)를 나타냅니다. 파란색 선은 처리 속도(초당 처리된 행 수)를 나타냅니다. 어떤 지점에서는 처리 속도가 입력 속도를 따라가지 못합니다. 잠재적인 문제는 입력 파일이 큐에 쌓여 있다는 것입니다.

처리 속도가 그래프의 입력 속도와 일치하지 않기 때문에 처리 속도를 개선하여 입력 속도를 완전히 커버하도록 합니다. 한 가지 가능한 이유는 병목 현상으로 이어지는 각 파티션 키의 고객 데이터 불균형일 수 있습니다. 다음 단계 및 잠재적 솔루션을 위해 Azure Databricks의 확장성을 활용합니다.

파티션 조사

먼저 Azure Databricks에 필요한 정확한 크기 조정 실행기 수를 추가로 식별합니다. 실행 중인 실행기에서 전용 CPU가 있는 각 파티션을 할당하는 경험 법칙을 적용합니다. 예를 들어 200개의 파티션 키가 있는 경우 CPU 수에 실행기 수를 곱한 값은 200이어야 합니다. (예를 들어, 25개의 실행기와 결합된 8개의 CPU가 적합합니다.) 200개의 파티션 키를 사용하면 각 실행기는 하나의 작업만 수행할 수 있으므로 병목 현상이 발생할 가능성이 줄어듭니다.

이 시나리오에는 일부 느린 파티션이 있으므로 작업 기간의 높은 편차를 조사합니다. 작업 기간에 급증이 있는지 확인합니다. 하나의 작업이 하나의 파티션을 처리합니다. 작업에 더 많은 시간이 필요한 경우 파티션이 너무 커서 병목 현상이 발생할 수 있습니다.

오류 추적

고객별 데이터 오류를 파악할 수 있도록 오류 추적용 대시보드를 추가합니다. 데이터 전처리 과정에서 파일이 손상되고 파일 내의 레코드가 데이터 스키마와 일치하지 않는 경우가 있습니다. 다음 대시보드는 많은 잘못된 파일과 잘못된 레코드를 포착합니다.

이 대시보드에는 디버깅을 위한 오류 수, 오류 메시지 및 작업 ID가 표시됩니다. 메시지에서 오류를 다시 오류 파일로 쉽게 추적할 수 있습니다. 읽는 동안 오류가 있는 파일이 여러 개 있습니다. 상위 타임라인을 검토하고 그래프의 특정 지점(16:20 및 16:40)에서 조사합니다.

기타 병목 현상

더 많은 예와 지침은 Azure Databricks의 성능 병목 현상 해결을 참조하세요.

성능 튜닝 평가 요약

이 시나리오에서 이러한 메트릭은 다음 관찰을 식별했습니다.

• 스테이지 대기 시간 차트에서 쓰기 스테이지는 처리 시간의 대부분을 차지합니다.
• 작업 대기 시간 차트에서 작업 대기 시간은 안정적입니다.
• 스트리밍 처리량 차트에서 일부 지점에서 출력 속도가 입력 속도보다 낮습니다.
• 작업 기간 테이블에는 고객 데이터의 불균형으로 인한 작업 편차가 있습니다.
• 분할 단계에서 최적화된 성능을 가져오려면 스케일링 실행기의 수가 파티션의 수와 일치해야 합니다.
• 잘못된 파일, 잘못된 레코드 등의 추적 오류가 있습니다.

이러한 문제를 진단하기 위해 다음 메트릭을 사용했습니다.

• 작업 대기 시간
• 단계 대기 시간
• 작업 대기 시간
• 스트리밍 처리량
• 단계당 작업 기간(최대, 평균, 최소)
• 오류 추적(개수, 메시지, 작업 ID)

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• David McGhee | 수석 프로그램 관리자

비공용 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

• Log Analytics 자습서를 읽어보세요.
• Azure Log Analytics 작업 영역에서 Azure Databrick 모니터링
• Spark 메트릭을 사용한 Azure Log Analytics 배포
• 가시성 패턴

관련 참고 자료

• Azure Databricks 애플리케이션 로그를 Azure Monitor에 보내기
• 대시보드를 사용하여 Azure Databricks 메트릭 시각화
• 클라우드 애플리케이션 모니터링을 위한 모범 사례
• 패턴 다시 시도