Azure Stream Analyticsのジョブの健全性を理解するには、ジョブの指標やディメンションの使い方を知る必要があります。 Azureポータル、Visual Studio CodeのStream Analytics拡張機能、またはSDKから、興味のあるメトリクスやディメンションを取得できます。
ウォーターマーク遅延と滞留している入力イベントは、Stream Analytics ジョブのパフォーマンスを左右する主な指標です。 ジョブのウォーターマーク遅延が継続的に増加し、入力イベントが蓄積されると、そのジョブは入力イベントの発生ペースに追いつけなくなり、時間通りに出力を生成できなくなります。
この記事では、AzureポータルのStream Analyticsジョブメトリクスとディメンションを使ってジョブのパフォーマンスをトラブルシューティングする方法を紹介します。 以下のセクションでは、 ウォーターマーク遅延 指標から始まるいくつかの例を紹介し、一般的なパフォーマンス問題を診断します。
特定のパーティションに入力がないためにジョブの透かしの遅延が増加する
驚異的並列が進んでいるジョブのウォーターマーク遅延が着実に増加している場合は、Azure portal で メトリクス を開いてください。 次に、入力ソースのいくつかのパーティションにデータが不足しているかどうかを判断するために、以下のステップを使ってください。
ウォーターマークの遅延が増えているパーティションを確認します。 ウォーターマーク遅延メトリックを選択し、パーティション ID ディメンションごとに分割します。 次の例では、パーティション 465 に高い透かしの遅延があります。
このパーティションに入力データが欠けていないか確認してください。 この特定のパーティション ID に対し、入力イベント メトリックを選択してフィルター処理します。
推奨されるアクション
このパーティションに入力イベントが流入していないため、このパーティションのウォーターマークの遅延が増加しています。 ジョブの遅延許容範囲が数時間あり、かつパーティションへの入力データが流入していない場合、そのパーティションのウォーターマーク遅延は、遅延許容範囲に達するまで増加し続けることが予想されます。
例えば、遅延到着ウィンドウが6時間で入力データが入力パーティション1に流れていない場合、出力パーティション1のウォーターマーク遅延は6時間に達するまで増加します。 入力ソースが期待通りにデータを生成しているか確認してください。
入力データ スキューは透かしの遅延増加の原因となる
恥ずかしいほど並列作業でウォーターマーク遅延が大きい場合は、まず ウォーターマーク遅延 メトリクスを パーティションID 次元で分割します。 次に、すべてのパーティションでウォーターマーク遅延が大きいのか、それとも一部のパーティションだけなのかを確認します。
以下の例では、パーティション0と1は他の8つのパーティションよりもウォーターマーク遅延が大きく(約20〜30秒)、 他のパーティションのウォーターマーク遅延は、常に約8～10秒で安定しています。
入力 イベント メトリクスを パーティションIDで分割して、これらのパーティション間で入力データの様子を確認してください:
推奨されるアクション
前述の例では、ウォーターマーク遅延の大きいパーティション(0と1)は他のパーティションよりもはるかに多くの入力データを受け取ります。 この状態は データスキューと呼ばれます。 データスキューを持つパーティションを処理するストリーミングノードは、他のノードよりも多くのCPUとメモリを消費しており、以下のスクリーンショットが示しています。
データスキューの大きいパーティションを処理するストリーミングノードは、 より高いCPU % 利用率 と SU(メモリ)% 利用率を示します。 このリソースの逼迫はジョブのパフォーマンスに影響を与え、ウォーターマーク遅延を増大させます。 それを軽減するために、入力データをより均等に再分割しましょう。
物理的なジョブ図を使ってこの問題をデバッグすることもできます。 詳細については、 物理ジョブ図:不均等分布入力イベント(データスキュー)の特定を参照してください。
CPU またはメモリの過負荷により、ウォーターマークの遅延が増加する
「驚異的並列性が高い」ジョブにおいて、ウォーターマークの遅延が増加した場合、その遅延は 1 つや数つのパーティションだけでなく、すべてのパーティションに影響を及ぼす可能性があります。 あなたの仕事がこのような状況にあることを確認するために、以下の手順を踏みましょう:
ウォーターマーク遅延メトリックをパーティション IDごとに分割します。 次に例を示します。
Input EventsメトリクスをパーティションIDで分割して、各パーティションの入力データにデータ歪があるかどうかを確認します。
CPU % 利用率やSU(メモリ)% 利用率指標を確認し、すべてのストリーミングノードで利用率が高すぎるかどうかを確認しましょう。
両方の指標がすべてのストリーミングノードで80%以上高くなれば、各ストリーミングノードが大量のデータを処理していると結論づけられます。
Input Eventsメトリックを使って、1つのストリーミングノードに割り当てられているパーティションの数を確認しましょう。 ノード名 ディメンションを使用してストリーミング ノード ID をフィルター処理し、パーティション ID で分割します。
先のスクリーンショットは、ストリーミング ノード リソースの約 90 から 100% を占める、あるストリーミング ノードに 4 つのパーティションが割り当てられていることを示しています。 同様の方法で他のストリーミングノードも確認し、4つのパーティションからのデータ処理が行われているか確認してください。
推奨されるアクション
各ストリーミングノードが処理するパーティションの数を減らし、ノードごとの入力データを減らしましょう。 そのためには、各ストリーミングノードが2つのパーティションからデータを処理できるようにSUを2倍にするか、または各ストリーミングノードが1つのパーティションからデータを処理するようにSUを4倍にします。 SU の割り当てとストリーミング ノード数の関係については、「ストリーミング ユニットの理解と調整」を参照してください。
1 つのストリーミング ノードが 1 つのパーティションからのデータを処理しているにもかかわらず、透かしの遅延が増加する場合はどうすればよいのでしょうか。 パーティション数を増やして入力を再分割することにより、パーティションあたりのデータ量を減らします。 詳しくは、「再分割を使用して Azure Stream Analytics ジョブを最適化する」を参照してください。
この問題は物理的なジョブ図でもデバッグできます。 詳細については、 物理ジョブ図:過負荷CPUまたはメモリの原因を特定することを参照してください。