스트리밍 단위 이해 및 조정Understand and adjust Streaming Units

SUs (스트리밍 단위)는 Stream Analytics 작업을 실행 하기 위해 할당 된 컴퓨팅 리소스를 나타냅니다.Streaming Units (SUs) represents the computing resources that are allocated to execute a Stream Analytics job. SU 수가 클수록 작업에 더 많은 CPU 및 메모리 리소스가 할당됩니다.The higher the number of SUs, the more CPU and memory resources are allocated for your job. 이러한 용량을 통해 쿼리 논리에 중점을 두고 Stream Analytics 작업을 적시에 실행하도록 하드웨어를 관리해야 할 필요성을 요약할 수 있습니다.This capacity lets you focus on the query logic and abstracts the need to manage the hardware to run your Stream Analytics job in a timely manner.

Azure Stream Analytics 작업은 대기 시간이 짧은 스트리밍 처리를 위해 모든 처리를 메모리 안에서 수행합니다.To achieve low latency stream processing, Azure Stream Analytics jobs perform all processing in memory. 메모리가 부족하면 스트리밍 작업이 실패합니다.When running out of memory, the streaming job fails. 결과적으로, 프로덕션 작업의 경우 스트리밍 작업의 리소스 사용을 모니터링하고 작업을 중단 없이 실행하기에 충분한 리소스가 할당되도록 확인해야 합니다.As a result, for a production job, it’s important to monitor a streaming job’s resource usage, and make sure there is enough resource allocated to keep the jobs running 24/7.

0%에서 100% 범위의 SU % 사용률 메트릭은 워크로드의 메모리 사용량을 설명합니다.The SU % utilization metric, which ranges from 0% to 100%, describes the memory consumption of your workload. 최소 사용되는 스트리밍 작업의 경우 이 메트릭은 보통 10~20% 범위입니다.For a streaming job with minimal footprint, this metric is usually between 10% to 20%. SU% 사용률이 높으면 (80% 이상) 또는 입력 이벤트가 백로그 (CPU 사용량을 표시 하지 않기 때문에 SU% 사용률이 낮은 경우에도)를 사용 하는 경우 워크 로드에 더 많은 계산 리소스가 필요할 수 있으며,이 경우에는 SUs의 수를 늘려야 합니다.If SU% utilization is high (above 80%), or if input events get backlogged (even with a low SU% utilization since it does not show CPU usage), your workload likely requires more compute resources, which requires you to increase the number of SUs. 가끔 급증 하는 경우를 고려 하 여 SU 메트릭을 80% 미만으로 유지 하는 것이 가장 좋습니다.It's best to keep the SU metric below 80% to account for occasional spikes. 증가 하는 워크 로드에 대응 하 고 스트리밍 단위를 늘리려면 SU 사용률 메트릭에 80%의 경고를 설정 하는 것이 좋습니다.To react to increased workloads and increase streaming units, consider setting an alert of 80% on the SU Utilization metric. 또한 워터 마크 지연 및 백로그 이벤트 메트릭을 사용 하 여 영향이 있는지 확인할 수 있습니다.Also, you can use watermark delay and backlogged events metrics to see if there is an impact.

Stream Analytics 스트리밍 단위(SU) 구성Configure Stream Analytics Streaming Units (SUs)

  1. Azure Portal에 로그인합니다.Sign in to Azure portal

  2. 리소스 목록에서 확장할 Stream Analytics 작업을 찾은 후 엽니다.In the list of resources, find the Stream Analytics job that you want to scale and then open it.

  3. 작업 페이지의 구성 제목 아래 크기 조정 을 선택합니다.In the job page, under the Configure heading, select Scale. 작업을 만들 때 기본 SUs 수는 3입니다.Default number of SUs is 3 when creating a job.

    Azure Portal Stream Analytics 작업 구성

  4. 슬라이더를 사용하여 작업에 대한 SU를 설정합니다.Use the slider to set the SUs for the job. 특정 SU 설정으로 제한되는 것을 확인합니다.Notice that you are limited to specific SU settings.

  5. 작업을 실행 하는 경우에도 작업에 할당 되는 SUs의 수를 변경할 수 있습니다.You can change the number of SUs assigned to your job even when it is running. 작업에서 분할 되지 않은 출력 을 사용 하거나 값에 따라 다른 파티션이 있는 다단계 쿼리를사용 하는 경우에는이 작업을 수행할 수 없습니다.This is not possible if your job uses a non-partitioned output or has a multi-step query with different PARTITION BY values. 작업이 실행 중일 때 SU 값 집합에서 선택 하는 것으로 제한 될 수도 있습니다.You maybe restricted to choosing from a set of SU values when the job is running.

작업 성능 모니터링Monitor job performance

Azure Portal을 사용하여 작업 처리량을 추적할 수 있습니다.Using the Azure portal, you can track the throughput of a job:

Azure Stream Analytics 모니터링 작업

워크로드의 예상 처리량을 계산합니다.Calculate the expected throughput of the workload. 처리량이 예상보다 더 작은 경우 입력 파티션을 조정하고, 쿼리를 조정하고, 작업에 SU를 추가합니다.If the throughput is less than expected, tune the input partition, tune the query, and add SUs to your job.

작업에 필요한 SU 수는?How many SUs are required for a job?

특정 작업에 필요한 SU 수 선택은 입력에 대한 파티션 구성 및 작업에 정의된 쿼리에 따라 달라집니다.Choosing the number of required SUs for a particular job depends on the partition configuration for the inputs and the query that's defined within the job. 비율 크기 조정 블레이드를 사용하면 올바른 SU 수를 설정할 수 있습니다.The Scale page allows you to set the right number of SUs. 필요한 것보다 많은 SU를 할당하는 것이 좋습니다.It is a best practice to allocate more SUs than needed. Stream Analytics 처리 엔진은 메모리를 추가로 할당하는 비용으로 대기 시간과 처리량을 최적화합니다.The Stream Analytics processing engine optimizes for latency and throughput at the cost of allocating additional memory.

일반적으로 파티션 기준 을 사용하지 않는 쿼리에 대해 6 SU로 시작하는 것이 좋습니다.In general, the best practice is to start with 6 SUs for queries that don't use PARTITION BY. 그런 다음 대표적인 데이터 양을 전달하고 SU % 사용률 메트릭을 시험한 후 SU 수를 수정하는 평가판 및 오류 메서드를 사용하여 가장 적절한 부분을 판단합니다.Then determine the sweet spot by using a trial and error method in which you modify the number of SUs after you pass representative amounts of data and examine the SU% Utilization metric. Stream Analytics 작업에 사용될 수 있는 최대 스트리밍 단위 수는 작업에 대해 정의된 쿼리의 단계 수와 각 단계에 대한 파티션 수에 따라 결정됩니다.The maximum number of streaming units that can be used by a Stream Analytics job depends on the number of steps in the query defined for the job and the number of partitions in each step. 이러한 제한에 대한 자세한 내용은 여기에서 확인할 수 있습니다.You can learn more about the limits here.

올바른 SU 수 선택에 대한 자세한 내용은 처리량을 높이기 위한 Azure Stream Analytic 작업 비율 크기 조정 페이지를 참조하세요.For more information about choosing the right number of SUs, see this page: Scale Azure Stream Analytics jobs to increase throughput

참고

특정 작업에 필요한 SU 수 선택은 입력에 대한 파티션 구성 및 작업에 정의된 쿼리에 따라 달라집니다.Choosing how many SUs are required for a particular job depends on the partition configuration for the inputs and on the query defined for the job. 작업에 대해 SU의 할당량까지 선택할 수 있습니다.You can select up to your quota in SUs for a job. 기본적으로 각 Azure 구독에는 특정 지역의 모든 분석 작업에 대해 최대 500 su의 할당량이 있습니다.By default, each Azure subscription has a quota of up to 500 SUs for all the analytics jobs in a specific region. 구독의 SU를 이 할당량을 초과하여 늘리려면 Microsoft 지원에 문의하세요.To increase SUs for your subscriptions beyond this quota, contact Microsoft Support. 작업당 SU에 대한 유효한 값은 1, 3, 6이며 6 단위로 증가합니다.Valid values for SUs per job are 1, 3, 6, and up in increments of 6.

SU% 사용률이 증가하는 요인Factors that increase SU% utilization

temporal(시간 지향적인) 쿼리 요소는 Stream Analytics에서 제공하는 상태 저장 연산자의 핵심 집합입니다.Temporal (time-oriented) query elements are the core set of stateful operators provided by Stream Analytics. Stream Analytics는 서비스 업그레이드 중 메모리 소비, 복원력 검사점 및 상태 복구를 관리하여 사용자 대신 내부적으로 이러한 작업의 상태를 관리합니다.Stream Analytics manages the state of these operations internally on user’s behalf, by managing memory consumption, checkpointing for resiliency, and state recovery during service upgrades. Stream Analytics가 상태를 완벽하게 관리하더라도, 사용자가 고려해야 할 몇 가지 모범 사례 권장 사항이 있습니다.Even though Stream Analytics fully manages the states, there are a number of best practice recommendations that users should consider.

복잡한 쿼리 논리를 사용하는 작업은 입력 이벤트를 지속적으로 수신하지 않더라도 높은 SU% 사용률을 나타낼 수 있습니다.Note that a job with complex query logic could have high SU% utilization even when it is not continuously receiving input events. 입력 및 출력 이벤트가 급격히 증가한 후에 이러한 현상이 발생할 수 있습니다.This can happen after a sudden spike in input and output events. 쿼리가 복잡한 경우 작업은 메모리의 상태를 계속 유지할 수 있습니다.The job might continue to maintain state in memory if the query is complex.

SU% 사용률은 잠시 동안 갑자기 0으로 떨어졌다가 정상 수준으로 돌아올 수도 있습니다.SU% utilization may suddenly drop to 0 for a short period before coming back to expected levels. 이러한 현상은 일시적인 오류 또는 시스템에서 시작한 업그레이드로 인해 발생합니다.This happens due to transient errors or system initiated upgrades. 쿼리가 완전히 병렬처리 되지 않은 경우 작업에 대 한 스트리밍 단위 수를 늘릴 경우 SU% 사용률을 줄일 수 없습니다.Increasing number of streaming units for a job might not reduce SU% Utilization if your query is not fully parallel.

일정 기간 동안의 사용률을 비교 하는 동안 이벤트 요금 메트릭을사용 합니다.While comparing utilization over a period of time, use event rate metrics. InputEvents 및 OutputEvents 메트릭은 읽고 처리 한 이벤트의 수를 표시 합니다.InputEvents and OutputEvents metrics show how many events were read and processed. Deserialization 오류와 같은 오류 이벤트의 수도 나타내는 메트릭이 있습니다.There are metrics that indicate number of error events as well, such as deserialization errors. 시간 단위 당 이벤트 수가 늘어나면 대부분의 경우 SU%가 늘어납니다.When the number of events per time unit increases, SU% increases in most cases.

temporal 요소의 상태 저장 쿼리 논리Stateful query logic in temporal elements

Azure Stream Analytics 작업의 고유한 기능 중 하나는 기간 이동 집계, 임시 조인 및 임시 분석 함수 등과 같은 상태 저장 처리를 수행하는 것입니다.One of the unique capability of Azure Stream Analytics job is to perform stateful processing, such as windowed aggregates, temporal joins, and temporal analytic functions. 이러한 연산자마다 상태 정보를 유지합니다.Each of these operators keeps state information. 이러한 쿼리 요소의 최대 시간 범위는 7일입니다.The maximum window size for these query elements is seven days.

temporal 시간 범위 개념은 몇 가지 Stream Analytics 쿼리 요소에 나타납니다.The temporal window concept appears in several Stream Analytics query elements:

  1. 기간 이동 집계: 연속, 도착 및 슬라이딩 시간 범위의 GROUP BYWindowed aggregates: GROUP BY of Tumbling, Hopping, and Sliding windows

  2. temporal 조인: DATEDIFF 함수를 사용한 JOINTemporal joins: JOIN with DATEDIFF function

  3. temporal 분석 함수: LIMIT DURATION이 있는 ISFIRST, LAST 및 LAGTemporal analytic functions: ISFIRST, LAST, and LAG with LIMIT DURATION

다음 요소는 Stream Analytics 작업에 사용되는 메모리(스트리밍 단위 메트릭의 일부)에 영향을 줍니다.The following factors influence the memory used (part of streaming units metric) by Stream Analytics jobs:

기간 이동 집계Windowed aggregates

기간 이동 집계에 소비되는 메모리(상태 크기)가 시간 범위 크기에 항상 비례하지는 않습니다.The memory consumed (state size) for a windowed aggregate is not always directly proportional to the window size. 대신 소비되는 메모리는 데이터의 카디널리티 또는 각 시간 범위의 그룹 수에 비례합니다.Instead, the memory consumed is proportional to the cardinality of the data, or the number of groups in each time window.

예를 들어 다음 쿼리에서 clusterid와 연결된 수는 쿼리의 카디널리티입니다.For example, in the following query, the number associated with clusterid is the cardinality of the query.

SELECT count(*)
FROM input 
GROUP BY  clusterid, tumblingwindow (minutes, 5)

이전 쿼리에서 높은 카디널리티로 인 한 문제를 완화 하기 위해로 분할 된 이벤트 허브에 이벤트를 전송 하 clusterid 고 아래 예제와 같이 시스템에서 partition by 를 사용 하 여 별도로 각 입력 파티션을 처리 하도록 허용 하 여 쿼리를 확장할 수 있습니다.In order to mitigate any issues caused by high cardinality in the previous query, you can send events to Event Hub partitioned by clusterid, and scale out the query by allowing the system to process each input partition separately using PARTITION BY as shown in the example below:

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

쿼리가 분할되면 여러 노드에 걸쳐 분산됩니다.Once the query is partitioned out, it is spread out over multiple nodes. 결과적으로, 각 노드로 들어오는 clusterid 값의 수가 감소하여 GROUP BY 연산자 카디널리티가 줄어듭니다.As a result, the number of clusterid values coming into each node is reduced thereby reducing the cardinality of the group by operator.

이벤트 허브 파티션은 단계를 줄이지 않아도 되도록 그룹 키로 분할되어야 합니다.Event Hub partitions should be partitioned by the grouping key to avoid the need for a reduce step. 자세한 내용은 Event Hubs 개요를 참조하세요.For more information, see Event Hubs overview.

temporal 조인Temporal joins

Temporal 조인의 사용 된 메모리 (상태 크기)는 조인의 임시 공간에 있는 이벤트 수에 비례 합니다. 즉, 이벤트 입력 률에는 흔들기 방 크기를 곱합니다.The memory consumed (state size) of a temporal join is proportional to the number of events in the temporal wiggle room of the join, which is event input rate multiplied by the wiggle room size. 즉, 조인에 의해 소비되는 메모리는 DateDiff 시간 범위에 평균 이벤트 속도를 곱한 값에 비례합니다.In other words, the memory consumed by joins is proportional to the DateDiff time range multiplied by average event rate.

조인에서 일치하지 않는 이벤트 수는 쿼리에 대한 메모리 사용률에 영향을 줍니다.The number of unmatched events in the join affect the memory utilization for the query. 다음 쿼리는 클릭을 유도하는 광고 노출을 찾는 것입니다.The following query is looking to find the ad impressions that generate clicks:

SELECT clicks.id
FROM clicks 
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.

이 예제에서 광고는 많은 데 사용자가 거의 클릭하지 않는 경우 모든 이벤트를 timewindow에 있도록 해야 합니다.In this example, it is possible that lots of ads are shown and few people click on it and it is required to keep all the events in the time window. 사용된 메모리는 창 크기와 이벤트 속도에 비례합니다.Memory consumed is proportional to the window size and event rate.

이를 수정 하려면 조인 키 (이 경우 ID)로 분할 된 이벤트 허브에 이벤트를 보내고 다음과 같이 시스템에서 PARTITION by 를 사용 하 여 별도로 각 입력 파티션을 처리 하도록 허용 하 여 쿼리를 확장 합니다.To remediate this, send events to Event Hub partitioned by the join keys (ID in this case), and scale out the query by allowing the system to process each input partition separately using PARTITION BY as shown:

SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId 
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10 

쿼리가 분할되면 여러 노드에 걸쳐 분산됩니다.Once the query is partitioned out, it is spread out over multiple nodes. 결과적으로, 각 노드로 들어오는 이벤트 수가 감소하여 조인 창에 유지되는 상태 크기가 줄어듭니다.As a result the number of events coming into each node is reduced thereby reducing the size of the state kept in the join window.

temporal 분석 함수Temporal analytic functions

temporal 분석 함수의 소비 메모리(상태 크기)는 이벤트 속도와 기간의 곱에 비례합니다.The memory consumed (state size) of a temporal analytic function is proportional to the event rate multiply by the duration. 분석 함수가 소비하는 메모리는 시간 범위의 크기에 비례하지 않고 각 시간 범위의 파티션 수에 비례합니다.The memory consumed by analytic functions is not proportional to the window size, but rather partition count in each time window.

조치는 임시 조인과 유사합니다.The remediation is similar to temporal join. PARTITION BY 를 사용하여 쿼리를 확장할 수 있습니다.You can scale out the query using PARTITION BY.

잘못된 버퍼Out of order buffer

이벤트 순서 지정 구성 창에서 잘못된 버퍼 크기를 구성할 수 있습니다.User can configure the out of order buffer size in the Event Ordering configuration pane. 이 버퍼는 창의 기간에 대한 입력을 유지하고 순서를 재지정하는 데 사용됩니다.The buffer is used to hold inputs for the duration of the window, and reorder them. 버퍼 크기는 이벤트 입력 비율과 잘못된 창 크기의 곱에 비례합니다.The size of the buffer is proportional to the event input rate multiply by the out of order window size. 기본 창 크기는 0입니다.The default window size is 0.

순서가 잘못된 버퍼의 오버플로를 수정하려면 PARTITION BY 를 사용하여 쿼리를 확장합니다.To remediate overflow of the out of order buffer, scale out query using PARTITION BY. 쿼리가 분할되면 여러 노드에 걸쳐 분산됩니다.Once the query is partitioned out, it is spread out over multiple nodes. 결과적으로, 각 노드로 들어오는 이벤트 수가 감소하여 각각의 순서 재지정 버퍼의 이벤트 수가 줄어듭니다.As a result, the number of events coming into each node is reduced thereby reducing the number of events in each reorder buffer.

입력 분할 개수Input partition count

작업 입력의 각 입력 파티션에는 버퍼가 있습니다.Each input partition of a job input has a buffer. 입력 파티션 수가 클수록 이 작업이 더 많은 리소스를 소비합니다.The larger number of input partitions, the more resource the job consumes. 각 스트리밍 단위에 대해 Azure Stream Analytics는 대략 1 MB/s의 입력을 처리할 수 있습니다.For each streaming unit, Azure Stream Analytics can process roughly 1 MB/s of input. 따라서 Stream Analytics 스트리밍 단위 수를 Event Hubs의 파티션 수와 일치 시켜서 최적화할 수 있습니다.Therefore, you can optimize by matching the number of Stream Analytics streaming units with the number of partitions in your Event Hub.

일반적으로 하나의 스트리밍 유닛으로 구성된 작업은 두 개의 파티션이 있는 Event Hub(Event Hub의 경우 최소)로 충분합니다.Typically, a job configured with one streaming unit is sufficient for an Event Hub with two partitions (which is the minimum for Event Hub). Event Hub에 더 많은 파티션이 있으면 Stream Analytics 작업이 더 많은 리소스를 소비하지만 Event Hub에서 제공한 추가적인 처리량을 반드시 사용하는 것은 아닙니다.If the Event Hub has more partitions, your Stream Analytics job consumes more resources, but not necessarily uses the extra throughput provided by Event Hub.

스트리밍 단위가 6인 작업의 경우 Event Hub에서 4 또는 8개 파티션이 필요할 수 있습니다.For a job with 6 streaming units, you may need 4 or 8 partitions from the Event Hub. 그러나 불필요한 파티션을 너무 많이 사용하면 과도한 리소스 사용이 발생하므로 피해야 합니다.However, avoid too many unnecessary partitions since that causes excessive resource usage. 스트리밍 단위가 1인 Stream Analytics 작업에서 16개 이상의 파티션이 있는 Event Hub가 그러한 예입니다.For example, an Event Hub with 16 partitions or larger in a Stream Analytics job that has 1 streaming unit.

참조 데이터Reference data

ASA의 참조 데이터는 빠른 조회를 위해 메모리에 로드됩니다.Reference data in ASA are loaded into memory for fast lookup. 현재 구현에서는 동일한 참조 데이터를 여러 번 조인하더라도 참조 데이터와의 각 조인 작업이 메모리에 참조 데이터의 사본을 유지합니다.With the current implementation, each join operation with reference data keeps a copy of the reference data in memory, even if you join with the same reference data multiple times. PARTITION BY 를 통한 쿼리의 경우 각 파티션은 참조 데이터의 사본을 유지하므로 파티션이 완전히 분리됩니다.For queries with PARTITION BY, each partition has a copy of the reference data, so the partitions are fully decoupled. 참조 데이터를 여러 파티션과 여러 차례 조인할 경우 승수 효과에 따라 메모리 사용이 갑자기 급증할 수 있습니다.With the multiplier effect, memory usage can quickly get very high if you join with reference data multiple times with multiple partitions.

UDF 함수 사용Use of UDF functions

UDF 함수를 추가하면 Azure Stream Analytics가 JavaScript 런타임을 메모리에 로드합니다.When you add a UDF function, Azure Stream Analytics loads the JavaScript runtime into memory. 이것이 SU%에 영향을 주게 됩니다.This will affect the SU%.

다음 단계Next steps