# AWS Glue 스트리밍 작업 모니터링 정보
스트리밍 작업을 모니터링하는 것은 ETL 파이프라인 구축의 중요한 부분입니다. Spark UI 외에도 Amazon CloudWatch를 사용하여 지표를 모니터링할 수도 있습니다. 다음은 AWS Glue 프레임워크에서 내보내는 스트리밍 지표 목록입니다. 모든 AWS Glue 지표의 전체 목록은 [Amazon CloudWatch 지표를 사용한 AWS Glue 모니터링](https://docs.aws.amazon.com/glue/latest/dg/monitoring-awsglue-with-cloudwatch-metrics.html)을 참조하세요.
AWS Glue는 구조화된 스트리밍 프레임워크를 사용하여 입력 이벤트를 처리합니다. 코드에서 Spark API를 직접 사용하거나 이러한 지표를 게시하는 `GlueContext`에서 제공하는 `ForEachBatch`를 활용할 수 있습니다. 이러한 지표를 이해하려면 먼저 `windowSize`를 파악해야 합니다.
**windowSize**: `windowSize`는 사용자가 제공하는 마이크로 배치 간격입니다. 기간을 60초로 지정하면 AWS Glue 스트리밍 작업이 60초 또는 그 이상(이전 배치가 완료되지 않은 경우) 대기한 후 스트리밍 소스에서 배치의 데이터를 읽고 `ForEachBatch`에 제공된 변환을 적용합니다. 이를 트리거 간격이라고도 합니다.
상태 및 성능 특성을 이해하기 위해 지표를 더 자세히 검토해 보겠습니다.
**참고**
지표는 30초마다 내보내집니다. `windowSize`가 30초 미만인 경우 보고된 지표는 집계입니다. 예를 들어, `windowSize`가 10초이고 마이크로 배치당 20개의 레코드를 꾸준히 처리하고 있다고 가정해 보겠습니다. 이 시나리오에서 numRecords에 대해 내보낸 지표 값은 60입니다.
사용 가능한 데이터가 없으면 지표가 내보내지지 않습니다. 또한 소비자 지연 지표의 경우 해당 지표를 가져오는 기능을 활성화해야 합니다.
# AWS Glue 스트리밍 지표 시각화
시각적 지표 도표화
1. Amazon CloudWatch 콘솔에서 **지표**로 이동한 다음 **찾아보기** 탭을 선택합니다. 그런 다음 '사용자 지정 네임스페이스'에서 **Glue**를 선택합니다.
![\[스크린샷은 AWS Glue 스트리밍 작업을 모니터링할 때 Amazon CloudWatch 콘솔에서 지표에 액세스하는 것을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/streaming-monitoring-1.png)
1. **작업 지표**를 선택하여 모든 작업에 대한 지표를 표시합니다.
1. JobName=glue-feb-monitoring과 JobRunId=ALL을 기준으로 지표를 필터링합니다. 아래 그림에 표시된 대로 '\$1' 기호를 클릭하여 검색 필터에 지표를 추가할 수 있습니다.
1. 관심 있는 지표의 확인란을 선택합니다. 아래 그림에서는 `numberAllExecutors`와 `numberMaxNeededExecutors`를 선택했습니다.
![\[스크린샷은 스트리밍 작업을 모니터링할 때 지표에 평균을 적용하는 것을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/streaming-monitoring-2.png)
1. 이러한 지표를 선택한 후에는 **그래프로 표시된 지표** 탭으로 이동하여 통계를 적용할 수 있습니다.
1. 지표가 1분마다 내보내지기 때문에 `batchProcessingTimeInMs`와 `maxConsumerLagInMs`에 대해 1분 동안의 '평균'을 적용할 수 있습니다. `numRecords`에 대해 1분마다 '합계'를 적용할 수 있습니다.
1. **옵션** 탭을 사용하여 그래프에 가로 `windowSize` 주석을 추가할 수 있습니다.
![\[스크린샷은 스트리밍 작업을 모니터링할 때 그래프에 windowSize 주석을 추가하는 것을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/streaming-monitoring-3.png)
1. 지표를 선택했으면 대시보드를 생성하고 지표를 추가합니다. 다음은 샘플 대시보드입니다.
![\[스크린샷은 스트리밍 작업을 모니터링하기 위한 샘플 대시보드를 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/streaming-monitoring-4.png)
# AWS Glue 스트리밍 지표 사용
이 섹션에서는 각 지표와 이러한 지표가 서로 어떻게 상호 연관되는지 설명합니다.
## 레코드 수(지표: streaming.numRecords)
이 지표는 처리 중인 레코드 수를 나타냅니다.
![\[스크린샷은 스트리밍 작업에서 레코드 수를 모니터링하는 것을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/streaming-monitoring-5numrecords.png)
이 스트리밍 지표는 기간 중 처리하고 있는 레코드 수에 대한 가시성을 제공합니다. 이는 처리 중인 레코드 수와 함께 입력 트래픽의 동작을 이해하는 데도 도움이 됩니다.
+ 표시기 \$11은 버스트가 없는 안정적인 트래픽의 예제를 보여줍니다. 일반적으로 이는 일정 간격으로 데이터를 수집하여 스트리밍 소스로 전송하는 IoT 센서와 같은 애플리케이션입니다.
+ 표시기 \$12는 안정된 부하에서 트래픽이 갑자기 급증하는 예제를 보여줍니다. 이는 블랙 프라이데이와 같은 마케팅 이벤트가 있고 클릭 수가 급증할 때 클릭스트림 애플리케이션에서 발생할 수 있습니다.
+ 표시기 \$13은 예측할 수 없는 트래픽의 예제를 보여줍니다. 트래픽을 예측할 수 없으면 문제가 있는 것입니다. 이는 입력 데이터의 특성일 뿐입니다. IoT 센서 예제로 돌아가서 수백 개의 센서가 스트리밍 소스로 날씨 변화 이벤트를 전송하고 있다고 가정해 보겠습니다. 날씨 변화를 예측할 수 없으므로 데이터도 예측할 수 없습니다. 트래픽 패턴을 파악하는 것이 실행기 크기 조정의 핵심입니다. 입력이 급증하는 경우 자동 크기 조정 사용을 고려할 수 있습니다(나중에 자세히 설명).
![\[스크린샷은 스트리밍 작업에서 레코드 수와 Kinesis PutRecords 지표를 사용하여 모니터링하는 것을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/streaming-monitoring-6putrecords.png)
이 지표를 Kinesis PutRecords 지표와 결합하여 수집하고 있는 이벤트 수와 읽고 있는 레코드 수가 거의 동일한지 확인할 수 있습니다. 이는 지연을 이해하려고 할 때 특히 유용합니다. 수집 속도가 증가함에 따라 AWS Glue에서 읽는 `numRecords`도 증가합니다.
## 배치 처리 시간(지표: streaming.batchProcessingTimeInMs)
배치 처리 시간 지표는 클러스터가 과소 프로비저닝되었는지 과잉 프로비저닝되었는지 확인하는 데 도움이 됩니다.
![\[스크린샷은 스트리밍 작업에서 배치 처리 시간을 모니터링하는 것을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/streaming-monitoring-7batchprocess.png)
이 지표는 레코드의 각 마이크로 배치를 처리하는 데 걸린 시간(밀리초)을 나타냅니다. 여기서 주요 목표는 이 시간을 모니터링하여 `windowSize` 간격보다 작은지 확인하는 것입니다. 다음 기간 간격에서 복구되는 한 `batchProcessingTimeInMs`가 일시적으로 초과되어도 괜찮습니다. 표시기 \$11은 작업을 처리하는 데 걸리는 시간이 다소 안정적임을 보여줍니다. 그러나 입력 레코드 수가 늘어나면 표시기 \$12와 같이 작업을 처리하는 데 걸리는 시간이 늘어납니다. `numRecords`가 증가하지 않지만 처리 시간이 증가하는 경우 실행기의 작업 처리를 더 자세히 살펴봐야 합니다. `batchProcessingTimeInMs`가 10분 이상 120%를 넘지 않도록 임곗값과 경보를 설정하는 것이 좋습니다. 경보 설정에 대한 자세한 내용은 [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요.
## 소비자 지연(지표: streaming.maxConsumerLagInMs)
소비자 지연 지표는 이벤트 처리에 지연이 있는지 파악하는 데 도움이 됩니다. 지연이 너무 길면 올바른 windowSize가 있더라도 비즈니스가 의존하는 처리 SLA를 놓칠 수 있습니다. `emitConsumerLagMetrics` 연결 옵션을 사용하여 이 지표를 명시적으로 활성화해야 합니다. 자세한 내용은 [KinesisStreamingSourceOptions](https://docs.aws.amazon.com/glue/latest/webapi/API_KinesisStreamingSourceOptions.html)를 참조하세요.
![\[스크린샷은 스트리밍 작업에서 지연을 모니터링하는 것을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/streaming-monitoring-8lag.png)
## 파생된 지표
더 심층적인 인사이트를 얻으려면 Amazon CloudWatch에서 스트리밍 작업에 대해 더 자세히 이해하기 위해 파생된 지표를 생성할 수 있습니다.
![\[스크린샷은 스트리밍 작업에서 파생된 지표를 모니터링하는 것을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/streaming-monitoring-9derived.png)
파생된 지표로 그래프를 작성하여 더 많은 DPU를 사용해야 하는지 결정할 수 있습니다. 자동 크기 조정은 이를 자동으로 수행하는 데 도움이 되지만 파생된 지표를 사용하여 자동 크기 조정이 효과적으로 작동하는지 확인할 수 있습니다.
+ **InputRecordsPerSecond**는 입력 레코드를 가져오는 속도를 나타냅니다. 입력 레코드 수(glue.driver.streaming.numRecords)/WindowSize로 파생됩니다.
+ **ProcessingRecordsPerSecond**는 레코드가 처리되는 속도를 나타냅니다. 입력 레코드 수(glue.driver.streaming.numRecords)/batchProcessingTimeInMs로 파생됩니다.
입력 속도가 처리 속도보다 높으면 작업을 처리하기 위해 용량을 더 추가하거나 병렬 처리를 늘려야 할 수 있습니다.
## 자동 크기 조정 지표
입력 트래픽이 급증하는 경우 자동 크기 조정 활성화를 고려하고 최대 워커 수를 지정해야 합니다. 이를 통해 `numberAllExecutors`와 `numberMaxNeededExecutors`의 두 가지 추가 지표를 얻을 수 있습니다.
+ **numberAllExecutors**는 능동적으로 실행 중인 작업 실행기 수입니다.
+ **numberMaxNeededExecutors**는 현재 로드를 충족하는 데 필요한 최대 작업 (능동 실행 및 보류) 실행기 수입니다.
이 두 지표는 자동 크기 조정이 제대로 작동하는지 파악하는 데 도움이 됩니다.
![\[스크린샷은 스트리밍 작업에서 자동 크기 조정을 모니터링하는 것을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/glue/latest/dg/images/streaming-monitoring-10autoscaling.png)
AWS Glue는 몇 가지 마이크로 배치를 통해 `batchProcessingTimeInMs` 지표를 모니터링하고 두 가지 중 하나를 수행합니다. `batchProcessingTimeInMs`가 `windowSize`에 더 가까울 경우 실행기를 스케일 아웃하고, `batchProcessingTimeInMs`가 `windowSize`보다 비교적 낮을 경우 실행기를 스케일 인합니다. 또한 실행기의 단계적 크기 조정을 위한 알고리즘을 사용합니다.
+ 표시기 \$11은 로드 처리에 필요한 최대 실행기를 따라잡기 위해 활성 실행기가 어떻게 스케일 업되었는지 보여줍니다.
+ 표시기 \$12는 `batchProcessingTimeInMs`가 낮았기 때문에 활성 실행기가 어떻게 스케일 인되었는지 보여줍니다.
이러한 지표를 사용하여 현재 실행기 수준의 병렬 처리를 모니터링하고 이에 따라 자동 크기 조정 구성의 최대 워커 수를 조정할 수 있습니다.
## 최고의 성능을 얻는 방법
Spark는 Amazon Kinesis 스트림에서 읽기 위해 샤드당 하나의 작업을 생성하려고 합니다. 각 샤드의 데이터가 파티션이 됩니다. 그런 다음 각 워커의 코어 수에 따라 이러한 작업을 실행기/워커 전체에 분배합니다(워커당 코어 수는 선택하는 워커 유형(`G.025X`, `G.1X` 등)에 따라 다름). 그러나 작업이 분배되는 방식은 비결정적입니다. 모든 작업은 해당 코어에서 병렬로 실행됩니다. 샤드가 사용 가능한 실행기 코어 수보다 많으면 작업이 대기열에 추가됩니다.
위의 지표와 샤드 수를 조합해서 사용하여 버스트를 위한 여유 공간이 있는 안정적인 로드를 위해 실행기를 프로비저닝할 수 있습니다. 대략적인 워커 수 확인을 위해 작업을 몇 번 반복해서 실행하는 것이 좋습니다. 불안정하거나 급증하는 워크로드의 경우 자동 크기 조정과 최대 워커 수를 설정하여 동일한 작업을 수행할 수 있습니다.
비즈니스의 SLA 요구 사항에 따라 `windowSize`를 설정합니다. 예를 들어, 비즈니스상 처리된 데이터가 120초를 초과해서는 안 되는 경우, 평균 소비자 지연이 120초 미만이 되도록 `windowSize`를 60초 이상으로 설정합니다(위의 소비자 지연 섹션 참조). 여기에서 샤드의 `numRecords`와 수에 따라 DPU 단위로 용량을 계획하여 `batchProcessingTimeInMs`가 대부분의 경우 `windowSize`의 70% 미만이 되도록 합니다.
**참고**
핫 샤드는 데이터 스큐를 일으킬 수 있으며, 이는 일부 샤드/파티션이 다른 샤드/파티션보다 훨씬 크다는 것을 의미합니다. 이로 인해 병렬로 실행되는 일부 작업의 경우 시간이 오래 걸려 작업이 지연될 수 있습니다. 결과적으로 이전 배치의 모든 작업이 완료될 때까지 다음 배치를 시작할 수 없으며 이는 `batchProcessingTimeInMillis`와 최대 지연에 영향을 미칩니다.