처리량을 늘리도록 Azure Stream Analytics 작업 크기 조정

이 문서에서는 Azure Stream Analytics 쿼리를 조정하여 처리량을 늘리는 방법을 설명합니다. 이러한 크기 조정 패턴을 사용하여 더 많은 대역폭, CPU 및 메모리 리소스를 사용하여 더 높은 부하를 처리합니다.

Azure Stream Analytics 컴퓨팅 용량을 SU(스트리밍 단위) 측정합니다. 각 SU V2는 단일 컴퓨팅 노드의 전체 용량을 나타냅니다. 완전히 독립적으로 병렬 처리할 수 있는 쿼리는 각 입력 파티션을 서로 독립적으로 처리할 수 있으며, 파티션 간에 공유되는 데이터가 없는 쿼리입니다.

사전 요구 사항

시작하기 전에 다음 문서를 검토합니다.

• 스트리밍 단위 이해 및 조정
• 병렬 처리 가능한 작업 만들기

완전히 병렬 처리 가능한 쿼리 크기 조정

쿼리가 입력 파티션에서 병렬 처리되는 경우 다음 단계를 수행합니다.

1. PARTITION BY 키워드를 사용하도록 쿼리를 작성합니다. 자세한 내용은 Azure Stream Analytics에서 쿼리 병렬 처리 사용을 참조하세요.

2. 쿼리에서 사용하는 출력 유형에 따라, 일부 출력은 처리 곤란 병렬이거나 완전히 병렬 처리 가능하도록 추가 구성이 필요할 수 있습니다. 예를 들어 병렬 처리를 위해 출력을 구성합니다. 모든 출력 형식이 병렬 쓰기를 지원하는 것은 아닙니다.

   출력 형식	병렬화 지원
   Azure Blob Storage, Azure Table Storage, Azure Data Lake Storage, Azure Service Bus, Azure Functions	자동
   Azure SQL Database, Azure Synapse Analytics	선택 사항입니다. 구성 필요
   Azure Event Hubs	PartitionKey을 PARTITION BY 필드(일반적으로 PartitionId)와 일치하도록 설정해야 합니다. 입력 및 출력 파티션 수를 일치하여 크로스오버를 방지합니다.
   Power BI	병렬 처리할 수 없습니다. 출력은 항상 싱크로 보내기 전에 병합됩니다.

3. 단일 컴퓨팅 노드의 전체 용량인 1개의 SU V2 를 사용하여 쿼리를 실행하여 달성 가능한 최대 처리량을 측정합니다. GROUP BY를 사용하는 경우 작업에서 처리할 수 있는 그룹(카디널리티)을 측정합니다.

4. 시스템 리소스 제한을 확인합니다. 다음 증상은 Azure Stream Analytics 작업이 리소스 제한에 도달했음을 나타냅니다.

   증상	가능한 원인	조치
   SU % 사용률 지표가 80%를 초과합니다	메모리 사용량이 높습니다. 스트리밍 단위 이해 및 조정을 참조하세요.	SU V2를 더 추가합니다.
   출력 타임스탬프가 벽 시계 시간보다 느림	쿼리 논리에 따라 출력 타임스탬프에는 벽시계 시간의 논리 오프셋이 있을 수 있습니다. 그러나 거의 동일한 속도로 진행해야 합니다. 출력 타임스탬프가 더 뒤처지는 경우 시스템이 과로하고 있음을 나타냅니다. 다운스트림 출력 싱크 제한 또는 높은 CPU 사용률의 결과일 수 있습니다. Stream Analytics는 현재 CPU 사용률 메트릭을 제공하지 않으므로 두 가지를 구분하기가 어려울 수 있습니다.	싱크 제한으로 인해 문제가 발생하는 경우 출력 파티션(및 병렬 처리를 유지하기 위해 입력 파티션)을 늘리거나 싱크 리소스(예: Azure Cosmos DB 요청 단위)를 늘립니다.
   파티션별 백로그 이벤트 메트릭은 계속 증가합니다(작업 다이어그램에 표시됨).	출력 싱크 스로틀링 또는 높은 CPU 사용률	위와 동일합니다.

5. 용량을 선형으로 추정합니다. 1 SU V2에서 처리할 수 있는 항목을 확인한 후 파티션 간에 데이터 기울이기 없이 비례적으로 SU를 추가합니다.

비할 데 없는 쿼리 크기 조정

쿼리가 자명하게 병렬화 가능한 경우가 아니라면 다음 단계를 따르세요.

1. 복잡성을 방지하기 위해 PARTITION BY 없이 시작합니다. 1개 SU V2로 쿼리를 실행하여 최대 처리량을 측정합니다. 이전 섹션에서 설명한 것과 동일한 리소스 제한 증상을 확인합니다 (SU 사용률 80%, 출력 타임스탬프 지연, 백로그 증가).

2. 대상 처리량을 달성하면 완료된 것입니다. 필요에 따라 2/3 SU V2 및 1/3 SU V2로 테스트하여 시나리오에 대한 최소 SU V2 수를 찾습니다.

3. 원하는 처리량을 달성할 수 없는 경우 쿼리를 여러 단계로 분할합니다. 각 단계에 대해 최대 1개의 SU V2를 할당합니다. 예를 들어 3단계 쿼리에는 3개의 SU V2가 필요합니다. Azure Stream Analytics 각 단계를 자체 전용 노드에 배치합니다.

4. 처리량 대상에 아직 도달하지 않은 경우 PARTITION BY 를 입력에 가까운 단계에 추가합니다. 자연스럽게 분할할 수 없는 GROUP BY 작업의 경우 로컬/전역 집계 패턴을 사용합니다. 먼저 분할된 GROUP BY 를 수행한 다음 분할되지 않은 GROUP BY를 수행합니다. 예를 들어 볼륨이 1 SU V2에서 처리할 수 있는 용량을 초과할 때 3분마다 각 유료 부스를 통과하는 자동차의 수를 계산하려면 다음을 수행합니다.

   WITH Step1 AS (
   SELECT COUNT(*) AS Count, TollBoothId, PartitionId
   FROM Input1 Partition By PartitionId
   GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
   )
   SELECT SUM(Count) AS Count, TollBoothId
   FROM Step1
   GROUP BY TumblingWindow(minute, 3), TollBoothId
   

   이 쿼리는 1단계의 파티션당 유료 부스당 자동차 수를 계산한 다음, 최종 단계에서 분할된 수를 집계합니다.

   쿼리를 분할한 후 각 파티션이 자체 처리 노드에서 실행되도록 각 단계의 각 파티션에 대해 1개의 SU V2를 할당합니다.

   비고

   쿼리를 분할할 수 없는 경우 다단계 쿼리에 SU V2를 더 추가해도 처리량이 향상되지 않을 수 있습니다. 성능을 얻으려면 4단계에 표시된 로컬/전역 집계 패턴을 사용하여 초기 단계에서 볼륨을 줄입니다.

단일 작업에서 여러 독립 쿼리 크기 조정

단일 Azure Stream Analytics 작업(테넌트당 별도의 입력 및 출력 포함)에서 여러 테넌트의 데이터를 처리하는 다중 테넌트 ISV(Independent Software Vendor) 시나리오의 경우 각 하위 쿼리의 로드는 일반적으로 작습니다. 아래 단계를 수행하세요.

1. 쿼리에서 PARTITION BY 를 사용하지 마세요.

2. Azure Event Hubs 사용하는 경우 입력 파티션 수를 최소값 2로 줄입니다.

3. SU V2 1개로 쿼리를 실행합니다. 작업이 리소스 제한에 도달할 때까지 하위 쿼리를 추가합니다. 증상은 완전히 병렬 처리 가능한 쿼리의 경우와 동일합니다. 80개 이상의 SU 사용률%, 출력 타임스탬프 지연 시간 또는 백로그 증가.

4. 하위 쿼리 제한에 도달한 후 새 하위 쿼리를 별도의 작업에 추가합니다. 작업 수는 독립적인 쿼리 수로 선형적으로 확장됩니다(부하 기울이기 없음 가정). 서비스하려는 테넌트 수의 함수로 얼마나 많은 SU V2 작업을 실행해야 하는지 계산할 수 있습니다.

5. 참조 데이터 조인의 경우 참조 데이터와 조인하기 전에 모든 입력을 통합한 다음, 나중에 이벤트를 분할합니다. 그렇지 않으면 각 참조 데이터 조인이 메모리에 참조 데이터의 별도 복사본을 유지하므로 불필요한 메모리 사용이 발생할 수 있습니다.

도움받기

추가 지원을 받으려면 Azure Stream Analytics에 대한 Microsoft Q&A 질문 페이지를 참조하세요.

관련 콘텐츠

• Azure Stream Analytics 소개
• Azure Stream Analytics 사용 시작
• Azure Stream Analytics 쿼리 언어 참조
• Azure Stream Analytics 관리 REST API 참조