Azure Stream Analytics의 변칙 검색Anomaly detection in Azure Stream Analytics

클라우드와 Azure IoT Edge 둘 다에서 사용할 수 있는 Azure Stream Analytics는 가장 일반적으로 발생하는 두 가지 변칙(임시 및 영구적)을 모니터링하는 데 사용할 수 있는 기계 학습 기반의 기본 제공 변칙 검색 기능을 제공합니다.Available in both the cloud and Azure IoT Edge, Azure Stream Analytics offers built-in machine learning based anomaly detection capabilities that can be used to monitor the two most commonly occurring anomalies: temporary and persistent. AnomalyDetection_SpikeAndDipAnomalyDetection_ChangePoint 함수를 사용하여 Stream Analytics 작업에서 직접 변칙 검색을 수행할 수 있습니다.With the AnomalyDetection_SpikeAndDip and AnomalyDetection_ChangePoint functions, you can perform anomaly detection directly in your Stream Analytics job.

기계 학습 모델은 균일하게 샘플링된 시계열을 가정합니다.The machine learning models assume a uniformly sampled time series. 시계열이 균일하지 않으면 변칙 검색을 호출하기 전에 연속 창을 사용하여 집계 단계를 삽입할 수 있습니다.If the time series is not uniform, you may insert an aggregation step with a tumbling window prior to calling anomaly detection.

Machine learning 작업은 현재 계절성 추세 또는 여러 번의 상관 관계를 지원 하지 않습니다.The machine learning operations do not support seasonality trends or multi-variate correlations at this time.

Azure Stream Analytics에서 machine learning을 사용 하 여 변칙 검색Anomaly detection using machine learning in Azure Stream Analytics

다음 비디오는 Azure Stream Analytics에서 기계 학습 함수를 사용 하 여 실시간으로 변칙을 검색 하는 방법을 보여 줍니다.The following video demonstrates how to detect an anomaly in real time using machine learning functions in Azure Stream Analytics.

모델 동작Model behavior

일반적으로 모델 정확도는 슬라이딩 윈도우의 데이터가 많을수록 향상됩니다.Generally, the model's accuracy improves with more data in the sliding window. 지정된 슬라이딩 윈도우의 데이터는 해당 시간 프레임 동안 정상 범위의 일부로 처리됩니다.The data in the specified sliding window is treated as part of its normal range of values for that time frame. 모델은 슬라이딩 윈도우의 이벤트 기록만 고려하여 현재 이벤트가 비정상인지 확인합니다.The model only considers event history over the sliding window to check if the current event is anomalous. 슬라이딩 창이 이동 하면 모델의 학습에서 이전 값이 제거 됩니다.As the sliding window moves, old values are evicted from the model's training.

함수는 지금까지 확인한 내용을 기반으로 해서 특정 표준을 설정하여 작동합니다.The functions operate by establishing a certain normal based on what they have seen so far. 신뢰 수준 내에서 설정된 표준과 비교하여 이상값을 식별합니다.Outliers are identified by comparing against the established normal, within the confidence level. 변칙이 발생할 경우 인식할 수 있도록 정상 동작에 대한 모델 학습에 필요한 최소 이벤트 수를 기준으로 윈도우 크기를 설정해야 합니다.The window size should be based on the minimum events required to train the model for normal behavior so that when an anomaly occurs, it would be able to recognize it.

더 많은 수의 과거 이벤트를 비교 해야 하기 때문에 모델의 응답 시간이 기록 크기로 증가 합니다.The model's response time increases with history size because it needs to compare against a higher number of past events. 성능 향상을 위해 필요한 개수의 이벤트만 포함하는 것이 좋습니다.It is recommended to only include the necessary number of events for better performance.

시계열의 간격은 모델이 특정 시점에 이벤트를 수신하지 않아서 발생하는 결과일 수 있습니다.Gaps in the time series can be a result of the model not receiving events at certain points in time. 이 상황은 대체 논리를 사용 하 여 Stream Analytics에서 처리 됩니다.This situation is handled by Stream Analytics using imputation logic. 동일한 슬라이딩 윈도우의 기간뿐만 아니라 기록 크기는 이벤트가 도착하는 예상 평균 속도를 계산하는 데 사용됩니다.The history size, as well as a time duration, for the same sliding window is used to calculate the average rate at which events are expected to arrive.

여기 에서 사용 가능한 변칙 생성기를 사용 하 여 다른 변칙 패턴의 데이터로 Iot Hub를 공급할 수 있습니다.An anomaly generator available here can be used to feed an Iot Hub with data with different anomaly patterns. 이러한 변칙 검색 기능을 사용 하 여이 Iot Hub에서 읽고 변칙을 검색할 수 있습니다.An ASA job can be set up with these anomaly detection functions to read from this Iot Hub and detect anomalies.

급증 및 급감Spike and dip

시계열 이벤트 스트림의 일시적인 변칙을 급증 및 급감이라고 합니다.Temporary anomalies in a time series event stream are known as spikes and dips. 급증 및 급감은 기계 학습 기반 연산자인 AnomalyDetection_SpikeAndDip을 사용하여 모니터할 수 있습니다.Spikes and dips can be monitored using the Machine Learning based operator, AnomalyDetection_SpikeAndDip.

급증 및 급감 변칙의 예

동일한 슬라이딩 윈도우에서 두 번째 급증이 첫 번째 급증보다 작을 경우 더 작은 급증에 대해 계산된 점수가 지정된 신뢰 수준 내에서 첫 번째 급증의 점수와 비교하여 유의미하지 않을 수 있습니다.In the same sliding window, if a second spike is smaller than the first one, the computed score for the smaller spike is probably not significant enough compared to the score for the first spike within the confidence level specified. 모델의 신뢰도를 줄여 이러한 변칙을 검색할 수 있습니다.You can try decreasing the model's confidence level to detect such anomalies. 그러나 너무 많은 경고를 받기 시작하면 더 높은 신뢰 구간을 사용할 수 있습니다.However, if you start to get too many alerts, you can use a higher confidence interval.

다음 예제 쿼리는 2분 슬라이딩 윈도우에서 초당 1개 이벤트의 균일한 입력 속도와 120개 이벤트의 기록을 가정합니다.The following example query assumes a uniform input rate of one event per second in a 2-minute sliding window with a history of 120 events. 최종 SELECT 문은 신뢰 수준 95%로 점수 및 변칙 상태를 추출하고 출력합니다.The final SELECT statement extracts and outputs the score and anomaly status with a confidence level of 95%.

WITH AnomalyDetectionStep AS
(
    SELECT
        EVENTENQUEUEDUTCTIME AS time,
        CAST(temperature AS float) AS temp,
        AnomalyDetection_SpikeAndDip(CAST(temperature AS float), 95, 120, 'spikesanddips')
            OVER(LIMIT DURATION(second, 120)) AS SpikeAndDipScores
    FROM input
)
SELECT
    time,
    temp,
    CAST(GetRecordPropertyValue(SpikeAndDipScores, 'Score') AS float) AS
    SpikeAndDipScore,
    CAST(GetRecordPropertyValue(SpikeAndDipScores, 'IsAnomaly') AS bigint) AS
    IsSpikeAndDipAnomaly
INTO output
FROM AnomalyDetectionStep

변경 지점Change point

시계열 이벤트 스트림의 영구적 변칙은 수준 변경 및 추세와 같은 이벤트 스트림의 값 분산 변경입니다.Persistent anomalies in a time series event stream are changes in the distribution of values in the event stream, like level changes and trends. Stream Analytics에서 이러한 변칙은 Machine Learning 기반의 AnomalyDetection_ChangePoint 연산자를 사용하여 검색됩니다.In Stream Analytics, such anomalies are detected using the Machine Learning based AnomalyDetection_ChangePoint operator.

영구적 변경은 급증 및 급감보다 훨씬 오래 지속되며 치명적인 이벤트를 나타낼 수 있습니다.Persistent changes last much longer than spikes and dips and could indicate catastrophic event(s). 일반적으로 영구적 변경은 표시되지 않지만 AnomalyDetection_ChangePoint 연산자를 사용하여 검색할 수 있습니다.Persistent changes are not usually visible to the naked eye, but can be detected with the AnomalyDetection_ChangePoint operator.

다음 이미지는 수준 변경의 예입니다.The following image is an example of a level change:

수준 변경 변칙의 예

다음 이미지는 추세 변경의 예입니다.The following image is an example of a trend change:

추세 변경 변칙의 예

다음 예제 쿼리는 20분 슬라이딩 윈도우에서 초당 1개 이벤트의 균일한 입력 속도와 1200개 이벤트의 기록 크기를 가정합니다.The following example query assumes a uniform input rate of one event per second in a 20-minute sliding window with a history size of 1200 events. 최종 SELECT 문은 신뢰 수준 80%로 점수 및 변칙 상태를 추출하고 출력합니다.The final SELECT statement extracts and outputs the score and anomaly status with a confidence level of 80%.

WITH AnomalyDetectionStep AS
(
    SELECT
        EVENTENQUEUEDUTCTIME AS time,
        CAST(temperature AS float) AS temp,
        AnomalyDetection_ChangePoint(CAST(temperature AS float), 80, 1200) 
        OVER(LIMIT DURATION(minute, 20)) AS ChangePointScores
    FROM input
)
SELECT
    time,
    temp,
    CAST(GetRecordPropertyValue(ChangePointScores, 'Score') AS float) AS
    ChangePointScore,
    CAST(GetRecordPropertyValue(ChangePointScores, 'IsAnomaly') AS bigint) AS
    IsChangePointAnomaly
INTO output
FROM AnomalyDetectionStep

성능 특징Performance characteristics

이러한 모델의 성능은 기록 크기, 기간, 이벤트 로드 및 함수 수준 분할 사용 여부에 따라 달라 집니다.The performance of these models depends on the history size, window duration, event load, and whether function level partitioning is used. 이 섹션에서는 이러한 구성에 대해 설명 하 고 초당 1K, 5K 및 10K 이벤트 수집 속도를 유지 하는 방법에 대 한 샘플을 제공 합니다.This section discusses these configurations and provides samples for how to sustain ingestion rates of 1K, 5K and 10K events per second.

  • 기록 크기 -이러한 모델은 기록 크기로 선형으로 수행 됩니다.History size - These models perform linearly with history size. 기록 크기가 길수록 모델이 새 이벤트 점수를 매기는 데 걸리는 시간이 길어집니다.The longer the history size, the longer the models take to score a new event. 이는 모델이 새 이벤트를 기록 버퍼의 각 이전 이벤트와 비교 하기 때문입니다.This is because the models compare the new event with each of the past events in the history buffer.
  • 기간 - 창 지속 시간은 기록 크기에 지정 된 수 만큼 이벤트를 수신 하는 데 걸리는 시간을 반영 해야 합니다.Window duration - The Window duration should reflect how long it takes to receive as many events as specified by the history size. 창에 이벤트가 없으면 Azure Stream Analytics에서 누락 된 값을 돌립니다 수 있습니다.Without that many events in the window, Azure Stream Analytics would impute missing values. 따라서 CPU 소비는 기록 크기의 함수입니다.Hence, CPU consumption is a function of the history size.
  • 이벤트 로드 - 이벤트 로드가 많을 수록 CPU 소비에 영향을 주는 모델에 의해 수행 되는 작업이 더 많이 발생 합니다.Event load - The greater the event load, the more work that is performed by the models, which impacts CPU consumption. 작업은 더 많은 입력 파티션을 사용 하는 비즈니스 논리에 적합 하다 고 가정 하 고 처리가 적합 병렬로 만들어 확장할 수 있습니다.The job can be scaled out by making it embarrassingly parallel, assuming it makes sense for business logic to use more input partitions.
  • 함수 수준 분할 - 함수 수준 분할PARTITION BY 변칙 검색 함수 호출 내에서를 사용 하 여 수행 됩니다.Function level partitioning - Function level partitioning is done by using PARTITION BY within the anomaly detection function call. 이러한 유형의 분할은 여러 모델에 대 한 상태를 동시에 유지 해야 하므로 오버 헤드를 추가 합니다.This type of partitioning adds an overhead, as state needs to be maintained for multiple models at the same time. 함수 수준 분할은 장치 수준 분할과 같은 시나리오에서 사용 됩니다.Function level partitioning is used in scenarios like device level partitioning.

관계Relationship

기록 크기, 기간 및 총 이벤트 로드는 다음과 같은 방식으로 관련 됩니다.The history size, window duration, and total event load are related in the following way:

windowDuration (밀리초) = 1000 * historySize/(초당 총 입력 이벤트 수/입력 파티션 수)windowDuration (in ms) = 1000 * historySize / (Total Input Events Per Sec / Input Partition Count)

DeviceId로 함수를 분할 하는 경우 변칙 검색 함수 호출에 "PARTITION BY deviceId"를 추가 합니다.When partitioning the function by deviceId, add "PARTITION BY deviceId" to the anomaly detection function call.

결과Observations

다음 표에는 분할 되지 않은 경우에 단일 노드 (6 SU)의 처리량 관찰이 포함 되어 있습니다.The following table includes the throughput observations for a single node (6 SU) for the non-partitioned case:

기록 크기 (이벤트)History size (events) 기간 (밀리초)Window duration (ms) 초당 총 입력 이벤트 수Total input events per sec
6060 5555 2,2002,200
600600 728728 16501,650
6,0006,000 1091010,910 1,1001,100

다음 표에는 분할 된 사례에 대 한 단일 노드 (6 SU)의 처리량 관찰이 포함 되어 있습니다.The following table includes the throughput observations for a single node (6 SU) for the partitioned case:

기록 크기 (이벤트)History size (events) 기간 (밀리초)Window duration (ms) 초당 총 입력 이벤트 수Total input events per sec 디바이스 수Device count
6060 10911,091 1,1001,100 1010
600600 1091010,910 1,1001,100 1010
6,0006,000 218182218,182 <550<550 1010
6060 2181921,819 550550 100100
600600 218182218,182 550550 100100
6,0006,000 21818192,181,819 <550<550 100100

위에서 분할 되지 않은 구성을 실행 하는 샘플 코드는 Azure 샘플의 스트리밍 규모 리포지토리에 있습니다.Sample code to run the non-partitioned configurations above is located in the Streaming At Scale repo of Azure Samples. 이 코드는 이벤트 허브를 입력 및 출력으로 사용 하는 함수 수준 분할 없이 stream analytics 작업을 만듭니다.The code creates a stream analytics job with no function level partitioning, which uses Event Hub as input and output. 입력 부하는 테스트 클라이언트를 사용 하 여 생성 됩니다.The input load is generated using test clients. 각 입력 이벤트는 1KB json 문서입니다.Each input event is a 1KB json document. 이벤트는 JSON 데이터를 전송 하는 IoT 장치를 시뮬레이션 합니다 (최대 1K 장치).Events simulate an IoT device sending JSON data (for up to 1K devices). 기록 크기, 기간 및 총 이벤트 로드는 2 개의 입력 파티션에 따라 달라 집니다.The history size, window duration, and total event load are varied over 2 input partitions.

참고

좀 더 정확한 예측을 위해 시나리오에 맞게 샘플을 사용자 지정합니다.For a more accurate estimate, customize the samples to fit your scenario.

병목 상태 식별Identifying bottlenecks

Azure Stream Analytics 작업의 메트릭 창을 사용하여 파이프라인의 병목 상태를 파악할 수 있습니다.Use the Metrics pane in your Azure Stream Analytics job to identify bottlenecks in your pipeline. 또한 입출력 이벤트 를 검토하여 처리량을 확인하고 “워터마크 지연” 또는 백로그된 이벤트 를 검토하여 입력 속도에 맞게 작업이 처리되고 있는지 확인할 수 있습니다.Review Input/Output Events for throughput and "Watermark Delay" or Backlogged Events to see if the job is keeping up with the input rate. 이벤트 허브 메트릭의 경우 제한된 요청 을 검색하고 그에 따라 임계값 단위를 조정합니다.For Event Hub metrics, look for Throttled Requests and adjust the Threshold Units accordingly. Cosmos DB 메트릭의 경우 처리량에서 파티션 키 범위당 최대 사용된 RU/초 를 검토하여 파티션 키 범위가 균등하게 사용되도록 합니다.For Cosmos DB metrics, review Max consumed RU/s per partition key range under Throughput to ensure your partition key ranges are uniformly consumed. Azure SQL DB의 경우 로그 IOCPU 를 모니터링합니다.For Azure SQL DB, monitor Log IO and CPU.

다음 단계Next steps