Stream Analytics ストリーミングユニットの理解と調整

ストリーミングユニットとストリーミングノードについて

ストリーミングユニット (SU) は、Stream Analytics ジョブを実行するコンピューティングリソースを表します。 SU の数が多いほど、ジョブに割り当てる CPU リソースとメモリリソースが多くなります。この能力により、クエリロジックに集中することができ、Stream Analytics ジョブがタイミングよく実行されるようハードウェアを管理する必要がなくなります。

Azure Stream Analytics は、SU V1 (非推奨) と SU V2 (推奨) の 2 つのストリーミングユニット構造をサポートしています。

SU V1 モデルは、6 SU ごとにジョブの単一のストリーミングノードに対応する Azure Stream Analytics の最初の提供です。ジョブは 1 SU と 3 SU でも実行でき、共有ストリーミングノードに対応します。スケーリングは、分散コンピューティングリソースを提供するストリーミングノードを追加することで、6 SU ジョブから 12、18、24 まで、6 ずつ増加します。

SU V2 モデル (推奨) は、同じコンピューティングリソースに対して有利な価格で簡略化された構造です。 SU V2 モデルでは、1 SU V2 がジョブの 1 個のストリーミングノードに対応します。 2 SU V2 は、2 つのストリーミングノード、3 ~ 3 に対応します。 1/3 SU V2s と 2/3 SU V2s の各ジョブを 1 個のストリーミングノードで使用することもできますが、コンピューティングリソースは部分的になります。 1/3 SU V2 ジョブおよび 2/3 SU V2 ジョブは、小規模なスケールを必要とするワークロードにコスト効率の高いオプションを提供します。

次の表は、V1 および V2 ストリーミングユニットの基になるコンピューティング能力を示しています。

SU の価格については、「Azure Stream Analytics の価格に関するページ」をご覧ください。

ストリーミングユニットの変換とその適用場所を理解する

システムは、ストリーミングユニットを REST API レイヤーから UI (Azure portal および Visual Studio Code) に自動的に変換します。この変換はアクティビティログにも表示され、ストリーミングユニットの値は UI の値とは異なって表示されます。この動作は設計によるものです。 REST API フィールドは整数値に制限されますが、Stream Analytics ジョブは小数ノード (1/3 および 2/3 ストリーミングユニット) をサポートします。 Azure Stream Analytics UI ではノード値が 1/3、2/3、1、2、3 のように表示され、バックエンド (アクティビティログ、REST API レイヤー) には、それぞれ 3、7、10、20、30 と同じ値が乗算されて表示されます。

Standard	Standard V2 (UI)	Standard V2 (ログ、REST API などのバックエンド)
1	1/3	3
3	2/3	7
6	1	10
12	2	20
18	3	30
...	...	...

この変換は同じ粒度を伝達し、V2 在庫保管単位 (SKU) の API レイヤーの小数点を排除します。この変換は自動的に行われ、ジョブのパフォーマンスには影響しません。

消費量とメモリ使用率を把握する

待ち時間が短いストリーミング処理を実現するために、Azure Stream Analytics ジョブはすべての処理をメモリ内で実行します。ジョブがメモリ不足になると、ストリーミングジョブは失敗します。そのため、運用ジョブの場合は、ストリーミングジョブのリソース使用量を監視し、ジョブを 24 時間 365 日実行するために十分なリソースが割り当てられていることを確認することが重要です。

SU 使用率 (%) メトリックはワークロードのメモリ消費量を表し、その範囲は 0% から 100% となります。最小フットプリントのストリーミングジョブでは、このメトリックの範囲は、通常 10% から 20% です。 SU% 使用率が高い (80% を超える) 場合、または入力イベントのバックログが発生する場合 (CPU 使用率が表示されないため、SU% 使用率が低い場合でもバックログが発生する) は、ワークロードがより多くのコンピューティングリソースを必要としている可能性があります。その場合は、ストリーミングユニットの数を増やす必要があります。偶発的なスパイクを考慮して、SU メトリックを 80% 未満に維持することをお勧めします。増加したワークロードに対応し、ストリーミングユニットを増やすには、SU 使用率メトリックが 80% でのアラートを設定することを検討してください。また、透かしの遅延とバックログされたイベントのメトリックを使用して、影響があるかどうかを確認することもできます。

Stream Analytics のストリーミングユニット (SU) を構成する

Azure ポータルにサインインします。
リソースの一覧で、スケールする Stream Analytics ジョブを見つけて開きます。
ジョブページの [構成] 見出しで、 [スケーリング] を選択します。ジョブの作成時の SU の既定の数は 1 です。

ドロップダウンリストで SU オプションを選択して、ジョブの SU を設定します。特定の SU 範囲に制限されています。
ジョブの実行中に、そのジョブに割り当てられた SU の数を変更することができます。ジョブが非パーティション出力を使用している場合、または PARTITION BY 値が異なる複数ステップクエリがある場合は、ジョブの実行中に SU 値のセットから選択するように制限される場合があります。

ジョブのパフォーマンスを監視する

Azure portal を使用すると、ジョブのパフォーマンス関連のメトリックを追跡できます。メトリック定義の詳細については、「 Azure Stream Analytics ジョブメトリック」を参照してください。ポータルでのメトリックの監視の詳細については、 Azure portal での Stream Analytics ジョブの監視に関するページを参照してください。

ワークロードの予想されるスループットを計算します。スループットが予想よりも低い場合は、入力パーティションを調整し、クエリをチューニングして、ジョブに SU を追加します。

ジョブに必要な SU の数

必要な SU の数は、入力のパーティション構成と、ジョブ内で定義するクエリによって異なります。 [スケール] ページでは、適切な SU の数を設定することができます。必要な数よりも多くの SU を割り当てます。 Stream Analytics 処理エンジンは、余分なメモリを割り当てるコストで待機時間とスループットを最適化します。

一般に、 PARTITION BY を使用しないクエリでは 1 SU V2 から始めます。次に、試用版とエラーで最適な数を見つけます。代表的な量のデータを渡し、SU% 使用率メトリックを調べた後、SU の数を変更します。 Stream Analytics ジョブで使用できるストリーミングユニットの最大数は、ジョブに定義されているクエリのステップ数と各ステップのパーティション数によって異なります。制限の詳細については、こちらを参照してください。

適切な数の SU を選択する方法の詳細については、「スループットを向上させるために Azure Stream Analytics ジョブをスケーリングする」を参照してください。

注意

ジョブに必要な SU の数は、入力のパーティション構成と、ジョブに対して定義したクエリによって異なります。 1 つのジョブについて、クォータまでの SU 数を選択できます。 Azure Stream Analytics サブスクリプションクォータの詳細については、「 Stream Analytics の制限」をご覧ください。このクォータを超えてサブスクリプションの SU 数を増やす場合は、Microsoft サポートまでご連絡ください。ジョブあたりの SU 数の有効な値は、1/3、2/3、1、2、3 などです。

SU％の使用率を増加させる要因

Stream Analytics によって提供されるステートフルな演算子のコアセットは、一時的な (時間指向の) クエリ要素です。 Stream Analytics は、ユーザーに代わってこれらの操作の状態を内部的に管理します。これは、メモリ使用量、回復性のチェックポイント処理、およびサービスのアップグレード中の状態回復を管理します。 Stream Analytics は状態を完全に管理しますが、多くのベストプラクティスの推奨事項を検討してください。

複雑なクエリロジックを持つジョブは、入力イベントを継続的に受信していない場合でも、SU% 使用率が高くなる可能性があります。これは、入出力イベントが突然急増した後に発生する可能性があります。ジョブは、クエリが複雑な場合は、メモリ内に状態を保持し続けることがあります。

一時的なエラーまたはシステムによって開始されたアップグレードにより、SU% 使用率が予期したレベルに戻る前に、短期間に突然 0 に低下する可能性があります。クエリが完全に並列になっていない場合は、ジョブのストリーミングユニットの数を増やしても、SU 使用率 (%) は減少しないことがあります。

一定期間の使用率を比較する場合は、イベントレートメトリックを使用します。 InputEvents メトリックと OutputEvents メトリックは、読み取りおよび処理されたイベントの数を示します。逆シリアル化エラーなどのメトリックは、エラーイベントの数を示します。時間単位あたりのイベント数が増えると、ほとんどの場合、SU 使用率 (%) が増加します。

一時的な要素のステートフルなクエリロジック

Azure Stream Analytics ジョブの固有の機能の 1 つは、ウィンドウ集計、テンポラル結合、テンポラル分析関数などのステートフル処理です。これらの各演算子によって状態情報が保持されます。これらのクエリ要素の最大ウィンドウサイズは 7 日間です。

テンポラルウィンドウの概念は、いくつかの Stream Analytics クエリ要素に現れます。

ウィンドウ集計 (タンブリングウィンドウ、ホッピングウィンドウ、スライディングウィンドウの GROUP BY)
テンポラル結合: JOINとDATEDIFF関数による
テンポラル分析関数: ISFIRST、LAST、およびLAGLIMIT DURATION

Stream Analytics ジョブが使用するメモリ (ストリーミングユニットメトリックの一部) は、次の要因の影響を受けます。

ウィンドウ集計

ウィンドウ集計のために消費されたメモリ（状態サイズ）は、必ずしもウィンドウのサイズに比例するわけではありません。代わりに、使用されるメモリはデータの基数または各時間枠のグループ数と比例しています。

たとえば、次のクエリは、clusterid に関連付けられた数字がクエリの基数です。

SELECT count(*)
FROM input 
GROUP BY  clusterid, tumblingwindow (minutes, 5)

前のクエリでカーディナリティが高い場合に発生する問題を軽減するには、 clusteridでパーティション分割された Event Hubs にイベントを送信します。次の例に示すように、 PARTITION BY を使用してシステムが各入力パーティションを個別に処理できるようにすることで、クエリをスケールアウトします。

SELECT count(*) 
FROM input PARTITION BY PartitionId
GROUP BY PartitionId, clusterid, tumblingwindow (minutes, 5)

クエリがパーティション分割されると、複数のノードに分散されます。その結果、各ノードに入ってくる clusterid 値の数が減り、 GROUP BY 演算子のカーディナリティが低下します。

グループ化キーを使用して Event Hubs をパーティション分割し、reduce ステップの必要性を回避します。詳細については、「Event Hubs の概要」を参照してください。

一時的な結合

テンポラル結合によって消費されるメモリ (状態サイズ) は、結合のテンポラルウィグルルーム内のイベントの数に比例します。この数値は、イベント入力率にウィグルルームサイズを乗算した値と等しくなります。つまり、結合によって消費されるメモリは、DateDiff 時間範囲に平均イベントレートを乗算した値に比例します。

結合内の一致しないイベントの数は、クエリのメモリ使用率に影響します。次のクエリでは、クリックを生成する広告インプレッションを検索します。

SELECT clicks.id
FROM clicks 
INNER JOIN impressions ON impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10.

この例では、多数の広告が表示され、クリックするユーザーが少ない可能性があります。時間枠内のすべてのイベントを保持する必要があります。消費されるメモリは、時間枠のサイズおよびイベントレートに比例します。

この動作を修復するには、結合キー (この場合は ID) でパーティション分割されたイベントをイベントハブに送信し、次に示すように PARTITION BY を使用して各入力パーティションをシステムで個別に処理できるようにすることでクエリをスケールアウトします。

SELECT clicks.id
FROM clicks PARTITION BY PartitionId
INNER JOIN impressions PARTITION BY PartitionId 
ON impression.PartitionId = clicks.PartitionId AND impressions.id = clicks.id AND DATEDIFF(hour, impressions, clicks) between 0 AND 10

クエリをパーティション分割すると、複数のノードに分散されます。その結果、各ノードに入ってくるイベントの数を減らし、結合ウィンドウに保持される状態のサイズを小さくします。

一時的な分析関数

テンポラル分析関数によって消費されるメモリ (状態サイズ) は、イベントレートに継続時間を乗算した値に比例します。分析関数によって消費されるメモリは、ウィンドウサイズに比例するのではなく、各時間枠のパーティション数に比例します。

修復は、一時的な結合と同様です。 PARTITION BY を使用してクエリをスケールアウトできます。

アウト・オブ・オーダー・バッファー

[イベントの順序付け] 構成ウィンドウで、順序が乱れるバッファーサイズを構成できます。バッファーは、ウィンドウの期間の入力を保持し、並べ替えます。バッファーのサイズは、イベント入力レートに順切れのウィンドウサイズを乗算した値に比例します。既定のウィンドウサイズは 0 です。

誤順序バッファーのオーバーフローを修復するには、PARTITION BY を使用してクエリをスケールアウトします。クエリは、パーティション分割されると、複数のノードに広がります。その結果、各ノードで受信されるイベントの数が減少するため、各並べ替えバッファー内のイベント数が減少します。

入力パーティション数

各ジョブ入力パーティションにはバッファーがあります。入力パーティションの数が多いほど、ジョブが消費するリソースが多くなります。ストリーミングユニットごとに、Azure Stream Analytics は約 7 MB/秒の入力を処理できます。したがって、Stream Analytics のストリーミングユニットの数と、イベントハブのパーティション数を調整することにより、最適化することができます。

通常、3 分の 1 のストリーミングユニットで構成されたジョブは、2 つのパーティション (イベントハブの最小) を持つイベントハブに対して十分です。イベントハブのパーティション数が多い場合、Stream Analytics ジョブはより多くのリソースを消費しますが、Event Hubs によって提供される追加のスループットが必ずしも使用されるとは限りません。

1 つの V2 ストリーミングユニットを持つジョブの場合、イベントハブから 4 つまたは 8 つのパーティションが必要になる場合があります。ただし、過剰なリソース使用量が発生するため、不要なパーティションが多くなりすぎないようにしてください。たとえば、ストリーミングユニットが 1 つある Stream Analytics ジョブで、イベントハブのパーティションが 16 以上ある場合などです。

参照データ

Azure Stream Analytics は、高速検索のために参照データをメモリに読み込みます。現在の実装では、同じ参照データで複数回結合する場合でも、参照データを使用する結合操作ごとに参照データのコピーがメモリに保持されます。 PARTITION BY を使用したクエリでは、各パーティションに参照データのコピーが 1 つあるため、パーティションは完全に分離されます。相乗効果により、複数のパーティションで参照データを使用して複数回結合した場合、メモリ使用量がすぐに非常に高くなることがあります。

UDF 関数の使用

UDF 関数を追加すると、Azure Stream Analytics により、JavaScript ランタイムがメモリに読み込まれ、SU% に影響します。

次のステップ

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-02-20