Azure Stream Analytics의 시간 처리 이해

이 문서에서는 Azure Stream Analytics 작업에서 실제 시간 처리 문제를 해결하기 위해 디자인을 선택하는 방법에 대해 알아봅니다. 시간 처리 설계 결정은 이벤트 순서 지정 요인과 밀접하게 관련되어 있습니다.

시간에 대한 배경 개념

논의의 틀을 더 효율적으로 구성하기 위해 몇 가지 배경 개념을 정의하겠습니다.

• 이벤트 시간: 원래 이벤트가 발생한 시간입니다. 예를 들어 고속 도로에서 움직이는 자동차가 요금소 창구에 접근한 시간이 있습니다.

• 처리 시간: 이벤트가 처리 시스템에 도달하여 관찰되는 시간입니다. 예를 들어 요금소 창구 센서에서 자동차를 확인하고 컴퓨터 시스템에서 데이터를 처리하는 데 몇 분이 걸리는 경우가 있습니다.

• 워터마크: 스트리밍 프로세서에 들어오는 포인트 이벤트까지 나타내는 이벤트 시간 표식입니다. 워터마크를 사용하면 시스템에서 이벤트 수집에 대한 명확한 진행률을 표시할 수 있습니다. 스트림의 특성에 따라 들어오는 이벤트 데이터가 중지되지 않으므로 워터마크는 스트림의 특정 시점까지의 진행률을 나타냅니다.

  워터마크는 중요한 개념입니다. 워터마크를 사용하면 Stream Analytics에서 시스템이 취소할 필요가 없는 완전하고, 정확하며, 반복 가능한 결과를 생성할 수 있는 시기를 결정할 수 있습니다. 처리는 예측 가능하고 반복 가능한 방식으로 수행할 수 있습니다. 예를 들어 일부 오류 처리 조건에 대해 다시 계산해야 하는 경우 워터마크는 안전한 시작 지점과 종료 지점입니다.

이 주제에 대한 추가 리소스는 Tyler Akidau의 스트리밍 101 및 스트리밍 102 블로그 게시물을 참조하세요.

최적 시작 시간 선택

Stream Analytics는 이벤트 시간을 선택할 수 있는 두 가지 옵션(도착 시간 및 애플리케이션 시간)을 제공합니다.

도착 시간

도착 시간은 이벤트가 소스에 도달하면 입력 소스에서 할당됩니다. Event Hubs 입력의 경우 EventEnqueuedUtcTime 속성을 사용하고, IoT Hub 입력의 경우 IoTHub.EnqueuedTime 속성을 사용하고, Blob 입력의 경우 BlobProperties.LastModified 속성을 사용하여 도착 시간에 액세스할 수 있습니다.

도착 시간은 기본적으로 사용되며, temporal 논리가 필요하지 않은 데이터 보관 시나리오에 가장 적합합니다.

애플리케이션 시간(이벤트 시간이라고도 함)

애플리케이션 시간은 이벤트를 생성할 때 할당되며 이벤트 페이로드의 일부입니다. 애플리케이션 시간을 기준으로 이벤트를 처리하려면 SELECT 쿼리에서 Timestamp by 절을 사용합니다. Timestamp by가 없으면 이벤트는 도착 시간을 기준으로 처리됩니다.

원본 시스템이나 네트워크에서 지연을 고려하기 위해 temporal 논리가 사용되는 경우 페이로드에 타임스탬프를 사용하는 것이 중요합니다. 이벤트에 할당된 시간은 SYSTEM.TIMESTAMP에서 사용할 수 있습니다.

Azure Stream Analytics에서 시간이 진행되는 방법

애플리케이션 시간을 사용하는 경우 시간 진행은 들어오는 이벤트를 기반으로 합니다. 스트림 처리 시스템에서는 이벤트가 없는지 또는 이벤트가 지연되는지 여부를 알기 어렵습니다. 이러한 이유로 Azure Stream Analytics는 각 입력 파티션에 대해 다음과 같은 방식으로 추론 워터마크를 생성합니다.

• 들어오는 이벤트가 있을 때마다 워터마크는 Stream Analytics에서 지금까지 확인한 것 중 가장 큰 이벤트 시간에서 잘못된 순서 허용 시간 크기를 뺀 값입니다.

• 들어오는 이벤트가 없는 경우 워터마크는 현재 예상 도착 시간에서 지연 도착 허용 시간을 뺀 값입니다. 예상 도착 시간은 입력 이벤트가 마지막으로 표시된 시간부터 경과한 시간과 입력 이벤트 도착 시간을 더한 시간입니다.

  실제 도착 시간은 이벤트를 처리하는 Azure Stream Analytics VM이 아니라 Event Hubs와 같은 입력 이벤트 브로커에서 생성되므로 도착 시간만 예상할 수 있습니다.

디자인은 워터마크를 생성하는 것 외에도 다음 두 가지 목적을 추가로 제공합니다.

1. 시스템에서 들어오는 이벤트의 유무에 관계없이 적시에 결과를 생성합니다.

   출력 결과가 사용자에게 적시에 확인되도록 하려는 방법을 제어할 수 있습니다. Stream Analytics 작업에 대한 Azure Portal의 이벤트 순서 지정 페이지에서 잘못된 순서 이벤트 설정을 구성할 수 있습니다. 해당 설정을 구성하는 경우 이벤트 스트림에서 잘못된 순서 이벤트의 허용 시간과 적시성의 절충점을 고려합니다.

   들어오는 이벤트가 없는 경우에도 지연 도착 허용 시간은 워터마크를 계속 생성하는 데 있어 필요합니다. 이벤트 입력 스트림이 희박한 경우와 같이 들어오는 이벤트가 들어오지 않는 경우가 있을 수 있습니다. 이 문제는 입력 이벤트 브로커에서 여러 개의 파티션을 사용함으로써 악화된 것입니다.

   지연 도착 허용 시간을 사용하지 않는 스트리밍 데이터 처리 시스템에서는 입력이 희박하고 여러 파티션이 사용되는 경우 출력이 지연될 수 있습니다.

2. 시스템 동작이 반복 가능해야 합니다. 반복성은 스트리밍 데이터 처리 시스템의 중요한 속성입니다.

   워터마크는 도착 시간 및 애플리케이션 시간에서 파생됩니다. 둘 모두는 이벤트 브로커에서 유지되므로 반복할 수 있습니다. 이벤트가 없을 때 도착 시간을 예상해야 하는 경우 Azure Stream Analytics는 오류 복구를 위해 재생하는 중에 반복성에 대한 예상 도착 시간을 저널링합니다.

도착 시간을 이벤트 시간으로 사용하려는 경우 잘못된 순서 허용 시간 및 지연 도착 허용 시간을 구성할 필요가 없습니다. 도착 시간은 입력 이벤트 브로커에서 증가하도록 보장되므로 Azure Stream Analytics는 구성을 무시하기만 하면 됩니다.

지연 도착 이벤트

들어오는 각 이벤트에 대해 지연 도착 허용 시간을 정의하여 Azure Stream Analytics에서 이벤트 시간을 도착 시간과 비교합니다. 이벤트 시간이 허용 시간을 벗어나면 시스템에서 이벤트를 삭제하도록 구성하거나 허용 시간 이내로 이벤트 시간을 조정할 수 있습니다.

워터마크가 생성되면 서비스에서 잠재적으로 워터마크보다 낮은 이벤트 시간의 이벤트를 받을 수 있습니다. 이러한 이벤트를 삭제하거나 이벤트 시간을 워터마크 값으로 조정하도록 서비스를 구성할 수 있습니다.

조정의 일환으로 이벤트의 System.Timstamp가 새 값으로 설정되지만, 이벤트 시간 필드 자체는 변경되지 않습니다. 이 조정은 이벤트의 System.Timstamp가 이벤트 시간 필드의 값과 다를 수 있고 예기치 않은 결과가 발생할 수 있는 유일한 상황입니다.

하위 스트림에 따른 시간 변동 처리

시간이 대부분 다양한 이벤트 전송자 간에 동기화되는 대부분의 경우에는 설명하는 추론 워터마크 생성 메커니즘이 적합합니다. 그러나 실제로, 특히 많은 IoT 시나리오에서 시스템은 이벤트 전송자의 클록을 거의 제어할 수 없습니다. 이벤트 전송자는 필드, 아마도 다른 버전의 하드웨어와 소프트웨어에 있는 모든 종류의 디바이스일 수 있습니다.

Stream Analytics에는 입력 파티션의 모든 이벤트에 글로벌 워터마크가 사용되는 대신 하위 스트림이라고 하는 다른 메커니즘이 사용되어 도움이 됩니다. TIMESTAMP BY 절과 OVER 키워드를 사용하는 작업 쿼리를 작성하여 작업에서 하위 스트림을 활용할 수 있습니다. 하위 스트림을 지정하려면 deviceid와 같은 OVER 키워드 뒤에 키 열 이름을 제공하여 시스템에서 해당 열에 따라 시간 정책을 적용하도록 합니다. 각 하위 스트림에는 자체의 독립적인 워터마크가 있습니다. 이 메커니즘은 이벤트 전송자 간의 큰 클록 스큐 또는 네트워크 지연을 처리할 때 출력을 적시에 생성할 수 있도록 하는 데 유용합니다.

하위 스트림은 Azure Stream Analytics에서 제공하는 고유한 솔루션이며, 다른 스트리밍 데이터 처리 시스템에서는 제공하지 않습니다.

하위 스트림을 사용하는 경우 Stream Analytics는 지연 도착 허용 시간을 들어오는 이벤트에 적용합니다. 지연 도착 허용 시간은 서로 다른 하위 스트림에서 서로 떨어져 있을 수 있는 최대 시간을 결정합니다. 예를 들어 디바이스 1이 타임스탬프 1에 있고 디바이스 2가 타임스탬프 2이면 최대 지연 도착 허용 시간은 타임스탬프 2 - 타임스탬프 1입니다. 확산 타임스탬프가 있는 디바이스에는 기본 설정(5초)이 너무 작을 수 있습니다. 5분으로 시작하여 해당 디바이스의 클록 스큐 패턴에 따라 조정하는 것이 좋습니다.

조기 도착 이벤트

'지연 도착 허용 시간'과 반대되는 '조기 도착 시간'이라는 또 다른 개념이 있음을 알 수 있습니다. 이 시간은 5분으로 고정되며, 지연 도착 허용 시간과 다른 용도로 사용됩니다.

Azure Stream Analytics는 전체 결과를 보장하므로 작업 시작 시간만 입력 시간이 아닌 작업의 첫 번째 출력 시간으로 지정할 수 있습니다. 작업 시작 시간은 시간의 중간에서가 아니라 전체 시간이 처리되도록 하는 데 필요합니다.

그러면 Stream Analytics는 쿼리 사양에서 시작 시간을 파생시킵니다. 그러나 입력 이벤트 브로커는 도착 시간만으로 인덱싱되므로 시스템에서 시작 이벤트 시간을 도착 시간으로 변환해야 합니다. 시스템은 입력 이벤트 브로커의 해당 지점에서 이벤트 처리를 시작할 수 있습니다. 조기 도착 시간 제한을 사용하면 변환은 간단합니다(시작 이벤트 시간 - 5분 조기 도착 시간). 또한 이 계산은 시스템에서 이벤트 시간이 도착 시간보다 5분 더 큰 것으로 표시되는 모든 이벤트를 삭제한다는 것을 의미합니다. 조기 입력 이벤트 메트릭은 이벤트가 삭제될 때 증가합니다.

이 개념은 출력을 시작하는 위치에 관계없이 처리가 반복 가능하도록 하는 데 사용됩니다. 이러한 메커니즘이 있어야 다른 많은 스트리밍 시스템에서 요구하는 대로 반복성을 보장할 수 있습니다.

이벤트 순서 지정 허용 시간으로 인한 부작용

Stream Analytics 작업에는 몇 가지 이벤트 순서 지정 옵션이 있습니다. Azure Portal에서는 잘못된 순서 이벤트 설정(잘못된 순서 허용 시간)과 지연 도착 이벤트 설정(지연 도착 허용 시간)의 두 가지 옵션을 구성할 수 있습니다. 조기 도착 허용 시간은 고정되어 조정할 수 없습니다. 이러한 시간 정책은 Stream Analytics에서 강력한 보장을 제공하기 위해 사용됩니다. 그러나 이러한 설정으로 인해 다음과 같이 예기치 않은 영향을 주는 경우가 있습니다.

1. 실수로 이벤트를 너무 일찍 보냅니다.

   일반적으로 조기 이벤트는 출력되지 않아야 합니다. 전송자의 클록이 너무 빨리 실행되면 조기 이벤트를 출력으로 보낼 수 있습니다. 조기 도착 이벤트는 모두 삭제되므로 출력에 표시되지 않습니다.

2. 오래된 이벤트를 Azure Stream Analytics에서 처리할 Event Hubs로 보냅니다.

   오래된 이벤트는 처음에는 해롭지 않은 것으로 보일 수 있지만, 지연 도착 허용 시간이 적용되므로 삭제될 수 있습니다. 이벤트가 너무 오래되면 이벤트 수집 중에 System.Timstamp 값이 변경됩니다. 이 동작으로 인해 현재 Azure Stream Analytics는 기록 이벤트 처리 시나리오 대신 실시간에 가까운 이벤트 처리 시나리오에 더 적합합니다. 경우에 따라 지연 도착 이벤트 시간을 가능한 최댓값(20일)으로 설정하여 이 문제를 해결할 수 있습니다.

3. 출력이 지연되는 것 같습니다.

   첫 번째 워터마크는 계산된 시간, 즉 시스템에서 지금까지 관찰한 최대 이벤트 시간에서 잘못된 순서 허용 시간 크기를 뺀 시간에 생성됩니다. 기본적으로 잘못된 순서 허용 시간은 0(00분 00초)으로 구성됩니다. 0이 아닌 더 높은 시간 값으로 설정하면 계산된 첫 번째 워터마크 시간으로 인해 스트리밍 작업의 첫 번째 출력이 해당 시간 값(또는 그 이상)만큼 지연됩니다.

4. 입력이 희박합니다.

   지정된 파티션에 입력이 없는 경우 워터마크 시간은 도착 시간에서 도착 허용 시간을 뺀 값으로 계산됩니다. 결과적으로 입력 이벤트가 간헐적으로 드문 경우 출력이 해당 시간만큼 지연될 수 있습니다. 기본 지연 도착 이벤트 값은 5초입니다. 예를 들어 입력 이벤트를 한 번에 하나씩 보내면 약간의 지연이 발생할 수 있습니다. 지연 도착 이벤트 시간을 큰 값으로 설정하면 지연이 더 심해질 수 있습니다.

5. System.Timstamp 값이 이벤트 시간 필드의 시간과 다릅니다.

   앞에서 설명한 대로 시스템에서는 이벤트 시간을 잘못된 순서 허용 시간 또는 지연 도착 허용 시간으로 조정합니다. 이벤트의 System.Timstamp 값이 조정되지만 이벤트 시간 필드는 조정되지 않습니다. 이는 타임스탬프가 조정한 이벤트를 식별하는 데 사용할 수 있습니다. 시스템이 허용 오차 중 하나로 인해 타임스탬프를 변경한 경우 일반적으로 동일합니다.

관찰할 메트릭

다양한 이벤트 순서 지정 허용 시간의 효과는 Azure Stream Analytics 작업 메트릭을 통해 관찰할 수 있습니다. 관련된 메트릭은 다음과 같습니다.

메트릭	설명
잘못된 순서 이벤트	잘못된 순서로 받은 이벤트(삭제되었거나 조정된 타임스탬프가 제공되었음)의 수를 나타냅니다. 이 메트릭은 Azure Portal에 있는 작업의 이벤트 순서 지정 페이지의 잘못된 순서 이벤트 설정 구성에 따라 직접적인 영향을 받습니다.
지연 입력 이벤트	원본에서 늦게 도착하는 이벤트의 수를 나타냅니다. 이 메트릭에는 삭제되었거나 타임스탬프가 조정된 이벤트가 포함됩니다. 이 메트릭은 Azure Portal에 있는 작업의 이벤트 순서 지정 페이지의 지역 도착 이벤트 설정 구성에 따라 직접적인 영향을 받습니다.
조기 입력 이벤트	삭제되었거나 5분을 초과하여 일찍 도착한 경우 해당 타임 스탬프가 조정된 원본에서 일찍 도착한 이벤트의 수를 나타냅니다.
워터마크 지연	스트리밍 데이터 처리 작업의 지연을 나타냅니다. 자세한 내용은 다음 섹션을 참조하세요.

워터마크 지연 세부 정보

워터마크 지연 메트릭은 처리 노드의 벽 시계 시간에서 지금까지 확인한 것 중 가장 큰 워터마크를 뺀 값으로 계산됩니다. 자세한 내용은 워터마크 지연 블로그 게시물을 참조하세요.

다음과 같이 일반적인 작업에서 이 메트릭 값이 0보다 큰 몇 가지 이유가 있을 수 있습니다.

1. 스트리밍 파이프라인 고유의 처리 지연입니다. 일반적으로 이 지연은 명목적입니다.

2. 워터마크가 허용 시간의 크기만큼 줄어들므로 잘못된 순서 허용 시간에 지연이 도입되었습니다.

3. 워터마크가 허용 시간의 크기만큼 줄어들므로 지역 도착 시간에 지연이 도입되었습니다.

4. 메트릭을 생성하는 처리 노드의 클록 스큐입니다.

스트리밍 파이프라인의 속도가 느려질 수 있는 다른 많은 리소스 제약 조건이 있습니다. 워터마크 지연 메트릭이 높아질 수 있는 이유는 다음과 같습니다.

1. Stream Analytics에서 입력 이벤트의 볼륨을 처리할 수 있을 만큼 충분한 처리 리소스가 없습니다. 리소스를 강화하려면 스트리밍 단위 이해 및 조정을 참조하세요.

2. 입력 이벤트 브로커 내의 처리량이 부족하여 해당 처리량이 제한됩니다. 가능한 해결 방법은 Azure Event Hubs 처리량 단위 자동 확장을 참조 하세요.

3. 출력 싱크가 충분한 용량으로 프로비저닝되지 않으므로 제한됩니다. 가능한 해결 방법은 사용되는 출력 서비스의 버전에 따라 크게 달라집니다.

출력 이벤트 빈도

Azure Stream Analytics는 워터마크 진행률을 출력 이벤트가 생성되는 유일한 트리거로 사용합니다. 워터마크는 입력 데이터에서 파생되므로 오류 복구 중과 사용자가 시작한 재처리 중에도 반복할 수 있습니다. 기간 이동 집계를 사용하는 경우 서비스는 시간의 끝에서 출력만 생성합니다. 경우에 따라 사용자는 시간 범위에서 생성된 부분 집계를 보려고 할 수 있습니다. 부분 집계는 현재 Azure Stream Analytics에서 지원되지 않습니다.

다른 스트리밍 솔루션에서는 외부 상황에 따라 다양한 트리거 지점에서 출력 이벤트를 구체화할 수 있습니다. 일부 솔루션에서는 지정된 시간 범위 쌍에 대한 출력 이벤트가 여러 번 생성될 수 있습니다. 입력 값이 구체화됨에 따라 집계 결과는 더욱 정확하게 됩니다. 이벤트는 처음에는 추측되고 시간이 지남에 따라 수정될 수 있습니다. 예를 들어 특정 디바이스가 네트워크에서 오프라인 상태인 경우 시스템에서 예상 값을 사용할 수 있습니다. 나중에 동일한 디바이스가 네트워크에서 온라인 상태가 됩니다. 그러면 실제 이벤트 데이터가 입력 스트림에 포함될 수 있습니다. 출력에서는 해당 시간 범위를 처리하여 더 정확한 출력을 생성합니다.

워터마크의 예

다음 이미지에서는 다양한 상황에서 워터마크가 진행되는 방식을 보여 줍니다.

다음 표에는 아래 차트에 있는 예제 데이터가 나와 있습니다. 이벤트 시간과 도착 시간은 경우에 따라 일치하거나 다를 수 있습니다.

이벤트 시간	도착 시간	DeviceId
12:07	12:07	device1
12:08	12:08	device2
12:17	12:11	device1
12:08	12:13	device3
12:19	12:16	device1
12:12	12:17	device3
12:17	12:18	device2
12:20	12:19	device2
12:16	12:21	device3
12:23	12:22	device2
12:22	12:24	device2
12:21	12:27	device3

다음 그림에 사용된 허용 시간은 다음과 같습니다.

• 조기 도착 시간이 5분입니다.
• 지연 도착 시간이 5분입니다.
• 순서 재지정 시간이 2분입니다.

1. 이러한 이벤트를 통해 진행되는 워터마크의 예:

   

   앞의 그래픽에 표시된 주목할 만한 프로세스:

   1. 첫 번째 이벤트(device1)와 두 번째 이벤트(device2)는 시간을 정렬했고 조정 없이 처리됩니다. 각 이벤트에서 워터마크가 진행됩니다.

   2. 세 번째 이벤트(device1)가 처리되면 도착 시간(12:11)이 이벤트 시간(12:17)보다 앞섭니다. 이 이벤트는 6분 일찍 도착했으므로 5분 조기 도착 허용 시간으로 인해 삭제됩니다.

      이러한 조기 이벤트에서는 워터마크가 진행되지 않습니다.

   3. 네 번째 이벤트(device3)와 다섯 번째 이벤트(device1)는 시간을 정렬했고 조정 없이 처리됩니다. 각 이벤트에서 워터마크가 진행됩니다.

   4. 여섯 번째 이벤트(device3)가 처리되면 도착시간(12:17)과 이벤트 시간(12:12)이 워터마크 수준보다 낮습니다. 이벤트 시간이 워터마크 수준(12:17)으로 조정됩니다.

   5. 12번째 이벤트(device3)가 처리되면 도착 시간(12:27)이 이벤트 시간(12:21)보다 6분 정도 앞섭니다. 지연 도착 정책이 적용됩니다. 이벤트 시간이 워터마크(12:21)보다 높은 12:22로 조정되어 조정이 더 이상 적용되지 않습니다.

2. 조기 도착 정책 없이 진행되는 워터마크의 두 번째 예:

   

   이 예에서는 조기 도착 정책이 적용되지 않습니다. 일찍 도착하는 비정상 이벤트는 워터마크를 크게 높입니다. 이 시나리오에서는 세 번째 이벤트(시간이 12:11인 deviceId1)가 삭제되지 않고 워터마크가 12:15로 높아집니다. 결과적으로 네 번째 이벤트 시간이 7분 앞으로(12:08에서 12:15로) 조정됩니다.

3. 마지막 그림에서는 하위 스트림이 사용됩니다(DeviceId를 통해). 여러 개의 워터마크가 스트림별로 하나씩 추적됩니다. 결과적으로 시간이 조정되는 이벤트가 줄어듭니다.

   

다음 단계

• Azure Stream Analytics 이벤트 순서 고려 사항

• Azure Stream Analytics 작업 메트릭