Azure portal の物理ジョブ ダイアグラム (プレビュー) を使用したデバッグ
Azure portal の物理ジョブ ダイアグラムは、ストリーミング ノードを使用してジョブの主要なメトリック (CPU 使用率、メモリ使用率、入力イベント、パーティション ID、透かしの遅延など) をダイアグラムまたはテーブル形式で視覚化するのに役立ちます。 問題のトラブルシューティングを行うときに、問題の原因を特定するのに役立ちます。
この記事では、物理ジョブ ダイアグラムを使用してジョブのパフォーマンスを分析し、Azure portal のボトルネックをすばやく特定する方法について説明します。
重要
現在、この機能はプレビュー段階にあります。 ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。
ジョブの並列処理を識別する
並列化を使用したジョブは、より優れたパフォーマンスを提供できる Stream Analytics のスケーラブルなシナリオです。 ジョブが並列モードでない場合、パフォーマンスに何らかのボトルネックがある可能性が高くなります。 ジョブが並列モードであるかどうかを識別することが重要です。 物理ジョブ ダイアグラムは、ジョブの並列処理を示す視覚的なグラフを提供します。 物理ジョブ ダイアグラムで、異なるストリーミング ノード間でデータの相互作用がある場合、このジョブは、より注意が必要な非並列ジョブです。 例として、次の非並列ジョブ ダイアグラムを次に示します。
これを並列ジョブに最適化することを検討できます (次の例を参照)。そのためには、クエリを書き直すか、Visual Studio Code ASA 拡張機能内のジョブ ダイアグラム シミュレーターまたは Azure portal のクエリ エディターを使用して、入力/出力構成を更新します。 詳細については、ジョブ ダイアグラム シミュレーターを使用してクエリを最適化する (プレビュー) に関するページを参照してください。
並列ジョブのボトルネックを識別するための主要なメトリック
透かしの遅延とバックログされた入力イベントは、Stream Analytics ジョブのパフォーマンスを決定するための主要なメトリックです。 ジョブの透かしの遅延が増え続け、入力イベントがバックログとしてたまっている場合、入力イベントの速度にジョブが追い付かず、適切なタイミングで出力を生成できていないことを意味します。 計算リソースの観点からは、このケースが発生すると、CPU とメモリ リソースが高レベルで使用されます。
物理ジョブ ダイアグラムは、これらの主要なメトリックをダイアグラムにまとめて視覚化して、ボトルネックを簡単に特定するための全体像を提供します。
メトリック定義の詳細については、「Azure Stream Analytics ノード名ディメンション」を参照してください。
不均等な分散入力イベント (データ スキュー) を特定する
既に並列モードで実行されているジョブがあり、高い透かしの遅延が発生する場合は、この方法を使用して理由を特定します。
根本原因を見つけるには、Azure portal で物理ジョブ ダイアグラムを開きます。 [監視] で [ジョブ ダイアグラム (プレビュー)] を選び、[物理ダイアグラム] に切り替えます。
物理ダイアグラムから、各ノードの透かしの遅延値を表示するか、透かしの遅延ヒートマップ設定を選択してストリーミング ノードを並べ替える (推奨) ことで、高い透かし遅延がすべてのパーティションで発生しているのか、一部のパーティションでのみ発生しているのかを簡単に識別できます。
上で行ったヒートマップ設定を適用すると、左上隅に高い透かし遅延があるストリーミング ノードが表示されます。 その後、対応するストリーミング ノードの入力イベントが他のノードよりも大幅に多いかどうかを確認できます。 この例では、streamingnode#0 と streamingnode#1 により多くの入力イベントがあります。
ストリーミング ノードに個別に割り当てられているパーティションの数をさらに確認して、入力イベントが増えたのが、割り当てられたパーティション数が増えたことが原因なのか、より多くの入力イベントを持つ特定のパーティションが原因なのかを調べることができます。 この例では、すべてのストリーミング ノードに 2 つのパーティションがあります。 つまり、streamingnode#0 と streamingnode#1 には、他のパーティションよりも多くの入力イベントを含む特定のパーティションがあります。
streamingnode#0 および streamingnode#1 内で他のパーティションよりも多くの入力イベントがあるパーティションを特定するには、次の手順を実行します。
- グラフ セクションで [グラフの追加] を選びます
- メトリックに [入力イベント] を追加し、スプリッターに [パーティション ID] を追加します
- [適用] を選び、入力イベント グラフを表示します
- ダイアグラムの streamingnode#0 と streamingnode#1 にチェックマークを付けます
2 つのストリーミング ノードのパーティションによってフィルター処理された入力イベント メトリックを使用した次のグラフが表示されます。
他にどのようなアクションを実行できますか?
例に示すように、パーティション (0 と 1) には、他のパーティションよりも多くの入力データがあります。 これを "データ スキュー" と呼びます。 データ スキューを使用してパーティションを処理しているストリーミング ノードは、他のノードよりも多くの CPU リソースとメモリ リソースを消費してしまいます。 この不均衡により、パフォーマンスが低下し、透かしの遅延が増加します。 2 つのストリーミング ノードと物理ダイアグラムで、CPU とメモリ使用量を確認できます。 この問題を軽減するには、入力データをより均等に再分割する必要があります。
オーバーロードされた CPU またはメモリの原因を特定する
前述のデータ スキューの状況がなくても並列ジョブで透かしの遅延が増加する場合は、パフォーマンスを阻害するすべてのストリーミング ノードにまたがる大量のデータが原因である可能性があります。 物理ダイアグラムを使用して、ジョブがこの特性を持っていることを識別できます。
物理ジョブ ダイアグラムを開き、[監視] の下にあるジョブの Azure portal に移動し、[ジョブ ダイアグラム (プレビュー)] を選び、[物理ダイアグラム] に切り替えます。 次のように読み込まれた物理ダイアグラムが表示されます。
ストリーミング ノードごとに CPU とメモリ使用率をチェックして、すべてのストリーミング ノードの使用率が極端に上昇しているかどうかを確認します。 すべてのストリーミング ノードで CPU と SU の使用率が高い (80% を超える) 場合、このジョブには各ストリーミング ノード内でデータが大量に処理されていると結論付けることができます。
上記のケースから、CPU 使用率は約 90% で、メモリ使用率は既に 100% です。 これは、各ストリーミング ノードがデータを処理するためのリソースを使い果たしていることを示しています。
各ストリーミング ノードに割り当てられているパーティションの数を確認して、既存のストリーミング ノードの負荷を軽減するために、ストリーミング ノードを増やしてパーティションのバランスを取る必要があるかどうかを判断できるようにします。
この場合、各ストリーミング ノードには 4 つのパーティションが割り当てられていますが、これはストリーミング ノードには大きすぎるように見えます。
他にどのようなアクションを実行できますか?
各ストリーミング ノードのパーティション数を減らして、入力データを減らすことを検討してください。 ストリーミング ノード数を 8 から 16 に増やし、各ストリーミング ノードに割り当てられる SU を 2 倍にして、ノードあたり 2 つのパーティションにすることができます。 または、SU を 4 倍にして、各ストリーミング ノードで 1 つのパーティションのデータを処理することもできます。
ストリーミング ノードとストリーミング ユニットのリレーションシップの詳細については、「ストリーミング ユニットとストリーミング ノードについて」を参照してください。
1 つのストリーミング ノードが 1 つのパーティションからのデータを処理しているにもかかわらず、透かしの遅延が増加する場合はどうすればよいのでしょうか。 パーティション数を増やして入力を再分割することにより、パーティションあたりのデータ量を減らします。 詳しくは、「再分割を使用して Azure Stream Analytics ジョブを最適化する」を参照してください。