# AWS Glue Streaming ジョブのモニタリングについて
ストリーミングジョブのモニタリングは、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 Streaming ジョブは 60 秒 (それまでに前のバッチが完了していない場合はそれ以上) 待ってから、ストリーミングソースからバッチのデータを読み取り、`ForEachBatch` で提供される変換を適用します。これはトリガー間隔とも呼ばれます。
メトリクスを詳しく見直して、ヘルスとパフォーマンスの特徴を理解しましょう。
**注記**
メトリクスは 30 秒ごとに出力されます。`windowSize` が 30 秒未満の場合、報告されるメトリクスは集計されたものとなります。例えば、`windowSize` が 10 秒で、マイクロバッチあたり 20 件のレコードを安定して処理しているとします。このシナリオでは、numRecords の出力メトリクス値は 60 になります。
メトリクスは、使用できるデータがない場合は出力されません。また、コンシューマーラグメトリクスの場合は、そのメトリクスを取得する機能を有効にする必要があります。
# AWS Glue ストリーミングメトリクスの視覚化
ビジュアルメトリクスをプロットするには:
1. Amazon CloudWatch コンソールの **[メトリクス]** に移動し、**[参照]** タブを選択します。次に、「カスタム名前空間」の **[Glue]** を選択します。
![\[このスクリーンショットは、AWS Glue Streaming ジョブをモニタリングする際に Amazon CloudWatch コンソールでメトリクスにアクセスしているところを示しています。\]](http://docs.aws.amazon.com/ja_jp/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/ja_jp/glue/latest/dg/images/streaming-monitoring-2.png)
1. これらのメトリクスを選択したら、**[グラフ化したメトリクス]** タブに移動して統計を適用できます。
1. メトリクスは 1 分ごとに出力されるため、`batchProcessingTimeInMs` および `maxConsumerLagInMs` には 1 分より長い「average」を適用できます。`numRecords` には、1 分ごとの「sum」を適用できます。
1. **[オプション]** タブでは、水平方向の `windowSize` の注釈をグラフに追加できます。
![\[このスクリーンショットは、ストリーミングジョブをモニタリングする際にグラフに windowSize の注釈を追加しているところを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/streaming-monitoring-3.png)
1. メトリクスを選択したら、ダッシュボードを作成して追加します。ダッシュボードの例を以下に示します。
![\[このスクリーンショットは、ストリーミングジョブをモニタリングするためのダッシュボードの例を示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/streaming-monitoring-4.png)
# AWS Glue ストリーミングメトリックの使用
このセクションでは、各メトリクスと、それらが相互にどう関連しているかについて説明します。
## レコード数 (メトリクス: streaming.numRecords)
このメトリクスは、処理中のレコードの数を示します。
![\[このスクリーンショットは、ストリーミングジョブのレコード数をモニタリングしているところを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/streaming-monitoring-5numrecords.png)
このストリーミングメトリクスにより、処理中のレコードの数をウィンドウ内で可視化できます。処理中のレコードの数だけでなく、入力トラフィックの動作を把握するのにも役立ちます。
+ インジケータ \$11 は、トラフィックが安定しており、バーストが発生していない例を示しています。一般に、これは定期的にデータを収集してストリーミングソースに送信する IoT センサーのようなアプリケーションです。
+ インジケータ \$12 は、他の負荷が安定しているのに、トラフィックで突然バーストが発生した例を示しています。これは、ブラックフライデーのようなマーケティングイベントがあり、クリック数が急増した場合に、クリックストリームアプリケーションで発生することがあります。
+ インジケータ \$13 は、予測不可能なトラフィックの例を示しています。予想できないトラフィックは問題があることを指しません。これは入力データの性質にすぎません。IoT センサーの例に話を戻すと、何百ものセンサーが気象変化イベントをストリーミングソースに送信していると考えることができます。気象の変化は予測できないため、データも予測できません。トラフィックパターンを理解することは、エグゼキュターのサイズを決定するうえで重要です。入力が非常に多い場合は、自動スケーリングの使用を検討してください (これについては後で詳しく説明します)。
![\[このスクリーンショットは、ストリーミングジョブのレコード数と Kinesis PutRecords メトリクスを使用したモニタリングを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/streaming-monitoring-6putrecords.png)
このメトリクスを Kinesis PutRecords メトリクスと組み合わせて、取り込まれるイベントの数と読み取られるレコードの数がほぼ同じになるようにすることができます。これは特に、ラグについて把握したい場合に便利です。取り込み率が高くなると、AWS Glue によって読み取られる `numRecords` も増加します。
## バッチ処理時間 (メトリクス: streaming.batchProcessingTimeInMs)
バッチ処理時間メトリクスは、クラスターがプロビジョニング不足かプロビジョニング過剰かを判断するのに役立ちます。
![\[このスクリーンショットは、ストリーミングジョブのバッチ処理時間をモニタリングしているところを示しています。\]](http://docs.aws.amazon.com/ja_jp/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/ja_jp/glue/latest/dg/images/streaming-monitoring-8lag.png)
## 派生メトリクス
より深い洞察を得るために、派生メトリクスを作成して、Amazon CloudWatch のストリーミングジョブについて理解を深めることができます。
![\[このスクリーンショットは、ストリーミングジョブの派生メトリクスをモニタリングしているところを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/streaming-monitoring-9derived.png)
派生メトリクスが含まれるグラフを作成して、DPU をさらに使用する必要があるかどうかを判断できます。自動スケーリングはこれを自動的に行うのに役立ちますが、派生メトリクスを使用することで、自動スケーリングが効果的に機能しているかどうかを判断できます。
+ **InputRecordsPerSecond** は、入力レコードを取得する速度を示します。これは次のように算出されます: 入力レコードの数 (glue.driver.streaming.numRecords)/ WindowSize。
+ **ProcessingRecordsPerSecond** は、レコードを処理する速度を示します。これは次のように算出されます: 入力レコードの数 (glue.driver.streaming.numRecords)/ batchProcessingTimeInMs。
入力速度が処理速度より高いときは、ジョブを処理するための容量を増やすか、並列処理を増やす必要がある場合があります。
## 自動スケーリングメトリクス
入力トラフィックが急増しているときは、自動スケーリングを有効にすることを検討し、最大ワーカー数を指定する必要があります。そのために、`numberAllExecutors` と `numberMaxNeededExecutors` という 2 つのメトリクスが用意されています。
+ **numberAllExecutors** は、アクティブに実行されているジョブエグゼキュターの数です。
+ **numberMaxNeededExecutors** は、現在の負荷を満たすために必要な (アクティブに実行中および保留中の) ジョブエグゼキュターの最大数です。
この 2 つのメトリクスは、自動スケーリングが正しく機能しているかどうかを判断するのに役立ちます。
![\[このスクリーンショットは、ストリーミングジョブの自動スケーリングをモニタリングしているところを示しています。\]](http://docs.aws.amazon.com/ja_jp/glue/latest/dg/images/streaming-monitoring-10autoscaling.png)
AWS Glue は、数マイクロバッチにわたって `batchProcessingTimeInMs` メトリクスをモニタリングし、次の 2 つのいずれかを実行します。`batchProcessingTimeInMs` が `windowSize` に近い場合はエグゼキュターをスケールアウトし、`batchProcessingTimeInMs` が `windowSize` より比較的低い場合はエグゼキュターをスケールインします。また、エグゼキュターをステップスケールするアルゴリズムも使用します。
+ インジケータ \$11 は、負荷を処理するために、アクティブなエグゼキュターがどのようにスケールアップし、必要最大数のエグゼキュターに追いついたかを示しています。
+ インジケータ \$12 は、`batchProcessingTimeInMs` が低くなってから、アクティブなエグゼキュターがどのようにスケールインしたかを示しています。
これらのメトリクスを使用して、現在のエグゼキュターレベルの並列処理をモニタリングし、それに応じて自動スケーリング構成の最大ワーカー数を調整できます。
## 最高のパフォーマンスを得る方法
Spark は、Amazon Kinesis ストリーム内の読み取りのために、シャードごとに 1 つのタスクを作成しようとします。各シャードのデータはパーティションになります。次に、各ワーカーのコア数に応じて、これらのタスクをエグゼキュター/ワーカーに分散します (ワーカーあたりのコア数は、選択したワーカータイプ (`G.025X` や `G.1X` など) によって異なります)。ただし、タスクがどのように分散されるかは非決定論的です。すべてのタスクは、それぞれのコアで並列実行されます。使用可能なエグゼキュターコアの数よりも多くのシャードがある場合、タスクはキューに入れられます。
上記のメトリクスとシャード数を組み合わせて、バーストのための余裕がある安定した負荷が実現するようにエグゼキュターをプロビジョニングできます。おおよそのワーカー数を決定するために、ジョブを数回繰り返すことをお勧めします。不安定で急激なワークロードの場合も、自動スケーリングと最大ワーカー数を設定することで同じことを実行できます。
`windowSize` は、ビジネスの SLA 要件に従って設定してください。例えば、処理されたデータが 120 秒を超えてはならないことをビジネスで義務付けている場合は、平均コンシューマーラグが 120 秒未満になるように `windowSize` を少なくとも 60 秒に設定します (前述のコンシューマーラグに関するセクションを参照)。そこから、`numRecords` とシャード数に応じて、DPU の容量を計画し、`batchProcessingTimeInMs` がほとんどいつも `windowSize` の 70% 未満になるようにします。
**注記**
ホットシャードはデータスキューの原因となる可能性があります。つまり、一部のシャード/パーティションが他のシャード/パーティションよりもはるかに大きくなる可能性があります。これにより、並列実行されている一部のタスクに時間がかかり、ストラグラータスクが発生する場合があります。その結果、前のバッチのすべてのタスクが完了するまで次のバッチを開始できず、これが `batchProcessingTimeInMillis` と最大ラグに影響することになります。