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

  • 아티클

이 문서에서는 Streaming Analytics 작업에 대한 처리량을 증가시키기 위해 Stream Analytics 쿼리를 조정하는 방법을 보여 줍니다. 다음 가이드를 사용하여 더 높은 부하를 처리하고 더 많은 시스템 리소스(예: 추가 대역폭, 추가 CPU 리소스, 추가 메모리)를 활용하도록 작업 크기를 조정할 수 있습니다.

필수 구성 요소로 다음 문서를 읽어보세요.

사례 1 - 쿼리가 기본적으로 여러 입력 파티션 간에 완전히 병렬 처리 가능한 경우

쿼리가 기본적으로 여러 입력 파티션 간에 완전히 병렬 처리가 가능하면 다음 단계를 따를 수 있습니다.

  • PARTITION BY 키워드를 사용하여 쉬운 병렬 처리가 되도록 쿼리를 작성합니다. 자세한 내용은 Azure Stream Analytics에서 쿼리 병렬 처리 사용을 참조 하세요.
  • 쿼리에 사용되는 출력 형식에 따라 일부 출력은 병렬 처리할 수 없거나 병렬 처리할 수 있도록 추가 구성이 필요할 수 있습니다. 예를 들어 Power BI 출력을 병렬 처리할 수 없습니다. 출력은 출력 싱크로 전송되기 전에 항상 병합됩니다. Blob, 테이블, Azure Data Lake Storage, Service Bus 및 Azure Function은 자동으로 병렬 처리됩니다. SQL 및 Azure Synapse Analytics 출력에는 병렬화 옵션이 있습니다. 이벤트 허브에는 PARTITION BY 필드(일반적으로PartitionId)와 일치하도록 PartitionKey 구성이 설정되어 있어야 합니다. Event Hubs의 경우 특히 파티션 간에 교차가 방지되도록 모든 입력과 출력의 파티션 수를 일치시켜야 합니다.
  • 단일 컴퓨팅 노드의 전체 용량인 SU(스트리밍 단위) V2 1개로 쿼리를 실행하여 달성 가능한 최대 처리량을 측정하고 GROUP BY를 사용하는 경우 작업이 처리할 수 있는 그룹 수(카드inality)를 측정합니다. 시스템 리소스 제한에 도달하는 작업의 일반적인 증상은 다음과 같습니다.
    • SU(스트림 단위) % 사용률 메트릭이 80%를 초과합니다. 메모리 사용량이 높다는 것을 나타냅니다. 이 메트릭의 증가에 기여하는 요인은 Stream Analytics 스트리밍 단위 이해 및 조정에 대해 설명 합니다.
    • 출력 타임스탬프가 벽 시계 시간보다 느립니다. 쿼리 논리에 따라 출력 타임스탬프에는 벽시계 시간의 논리 오프셋이 있을 수 있습니다. 그러나 이들은 거의 같은 속도로 진행됩니다. 출력 타임스탬프가 점점 더 느려지면 시스템이 과부하되었다는 것을 의미합니다. 이것은 다운스트림 출력 싱크 제한이나 높은 CPU 사용률의 결과일 수 있습니다. 현재는 CPU 사용률 메트릭을 제공하지 않으므로 둘 간을 구분하는 것이 어려울 수 있습니다.
      • 싱크 제한으로 인해 문제가 발생하는 경우 출력 파티션의 수를 늘리거나(작업을 완전히 병렬화할 수 있도록 입력 파티션도) 싱크의 리소스 양(예: Cosmos DB에 대한 요청 단위 수)을 늘려야 합니다.
    • 작업 다이어그램에는 각 입력에 대한 파티션별 백로그 이벤트 메트릭이 있습니다. 백로그 이벤트 메트릭이 계속 증가하는 경우에도 시스템 리소스가 제한되었다는 것을 의미할 수 있습니다(출력 싱크 제한 또는 높은 CPU 사용률이 원인).
  • 하나의 SU V2 작업에 도달할 수 있는 제한 사항을 결정했으면 특정 파티션을 "핫"으로 만드는 데이터 오차가 없다고 가정하여 SU를 더 추가할 때 작업의 처리 용량을 선형으로 추정할 수 있습니다.

참고 항목

적절한 스트리밍 단위 수를 선택합니다. Stream Analytics는 추가된 각 1 SU V2에 대한 처리 노드를 만들기 때문에 노드 수를 입력 파티션 수의 제수로 만드는 것이 가장 좋습니다. 따라서 파티션을 노드 간에 균등하게 분산할 수 있습니다. 예를 들어 SU V2 1개 작업에서 4MB/s 처리 속도에 도달할 수 있다고 측정했고 입력 파티션 수는 4개입니다. 약 8MB/s의 처리 속도에 도달하려면 SU V2 2개 또는 16MB/s에 도달하려면 SU V2 4개의 작업을 실행하면 됩니다. 그런 후 입력 속도의 함수로서, 작업에 대한 SU 수를 특정 값으로 늘려야 하는 시기를 결정할 수 있습니다.

사례 2 - 쿼리가 처리 곤란 병렬이 아닌 경우

쿼리가 병렬 처리되지 않는 경우 다음 단계를 수행할 수 있습니다.

  • 먼저 분할 복잡성이 방지되도록 PARTITION BY 없이 쿼리를 시작하고 사례 1과 같이 SU V2 1개로 쿼리를 실행하여 최대 부하를 측정합니다.
  • 처리량 측면에서 예상 부하를 달성하면 완료된 것입니다. 또는 2/3 SU V2 및 1/3 SU V2에서 소수 노드로 실행되는 동일한 작업을 측정하여 시나리오에 적합한 최소 스트리밍 단위 수를 확인할 수 있습니다.
  • 원하는 처리량을 달성할 수 없는 경우 여러 단계가 아직 없는 경우 쿼리를 여러 단계로 분할하고 쿼리의 각 단계에 대해 최대 하나의 SU V2를 할당합니다. 예를 들어 세 단계가 있는 경우 "크기 조정" 옵션에 3개의 SU V2를 할당합니다.
  • 이러한 작업을 실행하기 위해 Stream Analytics는 전용 SU V2 리소스를 사용하여 각 단계를 자체 노드에 배치합니다.
  • 부하 목표에 도달하지 못한 경우 입력에 가까운 단계부터 시작해서 PARTITION BY를 사용할 수 있습니다. 자연스럽게 분할할 수 없는 GROUP BY 연산자의 경우 로컬/전역 집계 패턴을 사용하여 분할된 GROUP BY와 분할되지 않은 GROUP BY를 수행할 수 있습니다. 예를 들어 3분마다 각 유료 부스를 통과하는 차량 수를 계산하려는 경우 데이터의 양이 하나의 SU V2에서 처리할 수 있는 양을 초과합니다.

쿼리:

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

쿼리에서는 파티션당 유료 부스당 자동차를 계산한 다음 모든 파티션의 수를 함께 추가합니다.

분할된 후 단계의 각 파티션에 대해 하나의 SU V2를 할당하여 각 파티션을 자체 처리 노드에 배치할 수 있습니다.

참고 항목

쿼리를 분할할 수 없는 경우 다단계 쿼리에 SU를 더 추가한다고 해서 항상 처리량이 개선될 수 있는 것은 아닙니다. 성능을 얻는 한 가지 방법은 5단계에 설명된 대로 로컬/전역 집계 패턴을 사용하여 초기 단계에서 볼륨을 줄이는 것입니다.

사례 3 - 한 작업에서 많은 양의 독립 쿼리를 실행하는 경우

단일 작업에서 여러 테넌트의 데이터를 처리하는 것이 더 비용 효율적인 특정 ISV 사용 사례의 경우 각 테넌트에 대해 별도의 입력 및 출력을 사용하여 단일 작업에서 상당히 많은(예: 20) 독립 쿼리를 실행하게 됩니다. 여기서는 이러한 각 하위 쿼리 부하가 비교적 작다고 가정합니다.

이 경우 다음 단계를 수행할 수 있습니다.

  • 이 경우에는 쿼리에서 PARTITION BY를 사용하지 마세요.
  • Event Hubs를 사용하는 경우 입력 파티션 수를 가능한 가장 낮은 값인 2로 줄입니다.
  • 하나의 SU V2를 사용하여 쿼리를 실행합니다. 각 하위 쿼리에 예상된 부하가 있으면, 작업이 시스템 리소스 제한에 도달할 때까지 이러한 하위 쿼리를 최대한 많이 추가합니다. 증상이 발생하면 사례 1 을 참조하세요.
  • 측정된 하위 쿼리 제한에 도달하면 새 작업에 하위 쿼리를 추가하기 시작합니다. 독립적인 쿼리 수에 대한 함수로서, 실행할 작업의 수는 비교적 선형이며 부하 기울이기가 없다고 가정합니다. 그런 다음 서비스하려는 테넌트 수의 함수로 실행해야 하는 SU V2 작업의 수를 예측할 수 있습니다.
  • 이러한 쿼리와 함께 참조 데이터 조인을 사용할 경우 동일한 참조 데이터와 조인하기 전에 입력을 함께 통합합니다. 그런 다음, 필요한 경우 이벤트를 분할합니다. 그렇지 않은 경우, 각 참조 데이터 조인은 참조 데이터의 복사본을 메모리에 유지하여 메모리 사용량이 불필요하게 증가할 수 있습니다.

참고 항목

각 작업에 몇 개의 테넌트를 배치해야 할까요? 이 쿼리 패턴에는 종종 많은 수의 하위 쿼리가 있으며 매우 크고 복잡한 토폴로지가 생성됩니다. 작업의 컨트롤러는 이러한 대량의 토폴로지를 처리하지 못할 수 있습니다. 원칙적으로 SU V2 1/3개 작업의 경우 테넌트 40개, SU V2 2/3개 및 1개 작업의 경우 테넌트 60개 미만으로 유지하는 것이 좋습니다. 컨트롤러 용량을 초과하는 경우에는 작업이 제대로 시작되지 않습니다.

도움말 보기

추가 지원이 필요한 경우 Azure Stream Analytics용 Microsoft Q&A 질문 페이지를 참조하세요.

다음 단계