ストリーミング ユニットの理解と調整Understand and adjust Streaming Units

ストリーミング ユニット (SU) は、Stream Analytics ジョブを実行するために割り当てられているコンピューティング リソースを表しています。Streaming Units (SUs) represents the computing resources that are allocated to execute a Stream Analytics job. SU 数が大きいほど、多くの CPU とメモリ リソースがジョブ用に割り当てられます。The higher the number of SUs, the more CPU and memory resources are allocated for your job. この能力により、クエリ ロジックに集中することができ、Stream Analytics ジョブがタイミングよく実行されるようハードウェアを管理する必要がなくなります。This capacity lets you focus on the query logic and abstracts the need to manage the hardware to run your Stream Analytics job in a timely manner.

待ち時間が短いストリーミング処理を実現するために、Azure Stream Analytics ジョブはすべての処理をメモリ内で実行します。To achieve low latency stream processing, Azure Stream Analytics jobs perform all processing in memory. メモリが不足した場合は、ストリーミング ジョブが失敗します。When running out of memory, the streaming job fails. そのため、実稼働ジョブでは、ストリーミング ジョブのリソース使用状況を監視し、ジョブの稼働を 24 時間、週 7 日維持するのに十分なリソースが割り当てられていることを確認することが重要です。As a result, for a production job, it’s important to monitor a streaming job’s resource usage, and make sure there is enough resource allocated to keep the jobs running 24/7.

SU 使用率 (%) メトリックはワークロードのメモリ消費量を表し、その範囲は 0% から 100% となります。The SU % utilization metric, which ranges from 0% to 100%, describes the memory consumption of your workload. 最小フットプリントのストリーミング ジョブでは、このメトリックの範囲は、通常 10% から 20% です。For a streaming job with minimal footprint, this metric is usually between 10% to 20%. SU% 使用率が高い (80% を超える) 場合、または入力イベントのバックログが発生した場合 (CPU 使用率には示されないため、SU% の使用率が低い場合でも)、ワークロードに多くのコンピューティング リソースが必要になる可能性があり、結果として SU の数を増やす必要が生じます。If SU% utilization is high (above 80%), or if input events get backlogged (even with a low SU% utilization since it does not show CPU usage), your workload likely requires more compute resources, which requires you to increase the number of SUs. 偶発的なスパイクを考慮して、SU メトリックを 80% 未満に維持することをお勧めします。It’s best to keep the SU metric below 80% to account for occasional spikes. リソースの枯渇を防ぐために SU 使用率メトリックは 80% でアラートを設定することをお勧めします。Microsoft recommends setting an alert on 80% SU Utilization metric to prevent resource exhaustion. 詳細については、「チュートリアル:Azure Stream Analytics ジョブのアラートを設定する」を参照してください。For more information, see Tutorial: Set up alerts for Azure Stream Analytics jobs.

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

  1. Azure Portal にサインインしますSign in to Azure portal

  2. リソースの一覧で、スケールする Stream Analytics ジョブを見つけて開きます。In the list of resources, find the Stream Analytics job that you want to scale and then open it. 

  3. ジョブ ページの [構成] 見出しで、 [スケーリング] を選択します。In the job page, under the Configure heading, select Scale. ジョブを作成するときの既定の SU 数は 3 です。 Default number of SUs is 3 when creating a job.

    Azure Portal での Stream Analytics ジョブの構成

  4. スライダーを使用してジョブの SU 数を設定します。Use the slider to set the SUs for the job. 特定の SU 設定に限定されることに注意してください。Notice that you are limited to specific SU settings. 

  5. ジョブが実行されている場合でも、それに割り当てられている SU の数を変更することができます。You can change the number of SUs assigned to your job even when it is running. ジョブでパーティション分割されていない出力を使用している場合、または異なる PARTITION BY 値を使用する複数ステップのクエリがある場合は、これを行うことはできません。This is not possible if your job uses a non-partitioned output or has a multi-step query with different PARTITION BY values. ジョブを実行している場合、SU 値のセットからの選択に限られる可能性があります。You maybe restricted to choosing from a set of SU values when the job is running.

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

Azure Portal を使用して、ジョブのスループットを追跡できます。Using the Azure portal, you can track the throughput of a job:

Azure Stream Analytics のジョブの監視

ワークロードの予想されるスループットを計算します。Calculate the expected throughput of the workload. スループットが予想よりも低い場合は、入力パーティションを調整し、クエリをチューニングして、ジョブに SU を追加します。If the throughput is less than expected, tune the input partition, tune the query, and add SUs to your job.

ジョブに必要な SU の数How many SUs are required for a job?

特定のジョブに必要な SU の数の選択は、入力のパーティション構成と、ジョブで定義されたクエリによって異なります。Choosing the number of required SUs for a particular job depends on the partition configuration for the inputs and the query that's defined within the job. [スケール] ページでは、適切な SU の数を設定することができます。The Scale page allows you to set the right number of SUs. SU は、必要な量より多めに割り当てておくことをお勧めします。It is a best practice to allocate more SUs than needed. メモリをより多く割り当てると、Stream Analytics 処理エンジンによって待ち時間とスループットが最適化されます。The Stream Analytics processing engine optimizes for latency and throughput at the cost of allocating additional memory.

一般に、PARTITION BY を使用していないクエリであれば、6 個の SU から始めることがベスト プラクティスです。In general, the best practice is to start with 6 SUs for queries that don't use PARTITION BY. そのうえで、試行錯誤により最適な数を検討します。具体的には、典型的な量のデータを渡して SU% 使用率のメトリックを確認し、SU の数を調整する作業を繰り返すことによって、最適な SU の数を割り出します。Then determine the sweet spot by using a trial and error method in which you modify the number of SUs after you pass representative amounts of data and examine the SU% Utilization metric. Stream Analytics ジョブで使用できるストリーミング ユニットの最大数は、ジョブに定義されたクエリのステップ数と各ステップのパーティション数によって異なります。The maximum number of streaming units that can be used by a Stream Analytics job depends on the number of steps in the query defined for the job and the number of partitions in each step. 制限の詳細については、こちらを参照してください。You can learn more about the limits here.

適切な SU 数の選択について詳しくは、「スループット向上のための Azure Stream Analytics ジョブのスケーリング」をご覧くださいFor more information about choosing the right number of SUs, see this page: Scale Azure Stream Analytics jobs to increase throughput

注意

特定のジョブに必要な SU 数の選択は、入力のパーティション構成と、ジョブに定義されたクエリによって異なります。Choosing how many SUs are required for a particular job depends on the partition configuration for the inputs and on the query defined for the job. 1 つのジョブについて、クォータまでの SU 数を選択できます。You can select up to your quota in SUs for a job. 既定では、各 Azure サブスクリプションには、特定のリージョン内のすべての分析ジョブを対象に最大 500 個という SU のクォータが設定されています。By default, each Azure subscription has a quota of up to 500 SUs for all the analytics jobs in a specific region. このクォータを超えてサブスクリプションの SU 数を増やす場合は、Microsoft サポートまでご連絡ください。To increase SUs for your subscriptions beyond this quota, contact Microsoft Support. ジョブごとの SU 数の有効な値は 1、3、6 であり、6 ずつ増加します。Valid values for SUs per job are 1, 3, 6, and up in increments of 6.

SU の使用率を上げる要因Factors that increase SU% utilization 

Stream Analytics によって提供されるステートフルな演算子のコア セットは、一時的な (時間指向の) クエリ要素です。Temporal (time-oriented) query elements are the core set of stateful operators provided by Stream Analytics. Stream Analytics では、サービスのアップグレード時の、メモリ消費量、回復性のチェックポイント処理、および状態の回復を管理することにより、ユーザーの代わりに内部的にこれらの操作の状態を管理します。Stream Analytics manages the state of these operations internally on user’s behalf, by managing memory consumption, checkpointing for resiliency, and state recovery during service upgrades. Stream Analytics では、状態を完全に管理していますが、ユーザーが考慮する必要のある推奨事項が多数があります。Even though Stream Analytics fully manages the states, there are a number of best practice recommendations that users should consider.

複雑なクエリ ロジックを持つジョブは、入力イベントを継続的に受け取らない場合でも、高い SU 使用率 (%) になる可能性があることに注意してください。Note that a job with complex query logic could have high SU% utilization even when it is not continuously receiving input events. これは、入出力イベントが突然急増した後に発生する可能性があります。This can happen after a sudden spike in input and output events. ジョブは、クエリが複雑な場合は、メモリ内に状態を保持し続けることがあります。The job might continue to maintain state in memory if the query is complex.

SU% 使用率は、予想されるレベルに戻る前に、短期間で突然 0 に低下することがあります。SU% utilization may suddenly drop to 0 for a short period before coming back to expected levels. この現象は、一時的なエラーや、システムによって開始されたアップグレードが原因で発生します。This happens due to transient errors or system initiated upgrades. クエリが完全に並列になっていない場合は、ジョブのストリーミング ユニットの数を増やしても、SU 使用率 (%) は減少しないことがあります。Increasing number of streaming units for a job might not reduce SU% Utilization if your query is not fully parallel.

一定期間にわたって使用率を比較している間、イベント率のメトリックを使用します。While comparing utilization over a period of time, use event rate metrics. InputEvents と OutputEvents のメトリックでは、読み取りおよび処理されたイベント数が示されます。InputEvents and OutputEvents metrics show how many events were read and processed. 逆シリアル化エラーなど、エラー イベントの数を示すメトリックもあります。There are metrics that indicate number of error events as well, such as deserialization errors. 時間単位あたりのイベント数が増えると、ほとんどの場合、SU 使用率 (%) が増加します。When the number of events per time unit increases, SU% increases in most cases.

一時的な要素のステートフルなクエリ ロジックStateful query logic in temporal elements

Azure Stream Analytics ジョブの固有の機能の 1 つに、ウィンドウ集計、一時的な結合、一時的な分析関数などのステートフル処理の実行があります。One of the unique capability of Azure Stream Analytics job is to perform stateful processing, such as windowed aggregates, temporal joins, and temporal analytic functions. これらの各演算子によって状態情報が保持されます。Each of these operators keeps state information. これらのクエリ要素の最大ウィンドウ サイズは 7 日間です。 The maximum window size for these query elements is seven days.

テンポラル ウィンドウの概念は、いくつかの Stream Analytics クエリ要素に現れます。The temporal window concept appears in several Stream Analytics query elements:

  1. ウィンドウ集計 (タンブリング ウィンドウ、ホッピング ウィンドウ、スライディング ウィンドウの GROUP BY)Windowed aggregates: GROUP BY of Tumbling, Hopping, and Sliding windows

  2. テンポラル結合: DATEDIFF 関数を使用した JOINTemporal joins: JOIN with DATEDIFF function

  3. テンポラル分析関数: LIMIT DURATION を使用した ISFIRST、LAST、LAGTemporal analytic functions: ISFIRST, LAST, and LAG with LIMIT DURATION

Stream Analytics ジョブが使用するメモリ (ストリーミング ユニット メトリックの一部) は、次の要因の影響を受けます。The following factors influence the memory used (part of streaming units metric) by Stream Analytics jobs:

ウィンドウ集計Windowed aggregates

ウィンドウ集計用に使用されたメモリ (状態のサイズ) は、常にウィンドウのサイズと比例していません。The memory consumed (state size) for a windowed aggregate is not always directly proportional to the window size. 代わりに、使用されるメモリはデータの基数または各時間枠のグループ数と比例しています。Instead, the memory consumed is proportional to the cardinality of the data, or the number of groups in each time window.

たとえば、次のクエリは、clusterid に関連付けられた数字がクエリの基数です。For example, in the following query, the number associated with clusterid is the cardinality of the query. 

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

前のクエリで大きな基数によって引き起こされる問題を軽減するために、clusterid でパーティション分割されたイベントをイベント ハブに送信し、次の例で示すように PARTITION BY を使用してシステムで各入力パーティションを個別に処理できるようにすることでクエリをスケールアウトできます。In order to mitigate any issues caused by high cardinality in the previous query, you can send events to Event Hub partitioned by clusterid, and scale out the query by allowing the system to process each input partition separately using PARTITION BY as shown in the example below:

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

クエリは、パーティション分割されると、複数のノードに広がります。Once the query is partitioned out, it is spread out over multiple nodes. その結果、各ノードで受信される clusterid 値の数が削減されるため、group by 演算子の基数が減少します。As a result, the number of clusterid values coming into each node is reduced thereby reducing the cardinality of the group by operator. 

削減手順の必要性をなくすには、イベント ハブ パーティションをグループ化キーでパーティション分割する必要があります。Event Hub partitions should be partitioned by the grouping key to avoid the need for a reduce step. 詳細については、「Event Hubs の概要」を参照してください。For more information, see Event Hubs overview. 

一時的な結合Temporal joins

一時的な結合で消費されるメモリ (状態サイズ) は、イベント入力速度にウィグル領域サイズを乗算した、結合の一時的なウィグル領域におけるイベント数に比例します。The memory consumed (state size) of a temporal join is proportional to the number of events in the temporal wiggle room of the join, which is event input rate multiplied by the wiggle room size. つまり、結合によって消費されたメモリは、平均イベント率に DateDiff 時間の範囲を掛けたものと比例しています。In other words, the memory consumed by joins is proportional to the DateDiff time range multiplied by average event rate.

結合内の不一致のイベントの数は、クエリのメモリ使用率に影響します。The number of unmatched events in the join affect the memory utilization for the query. 次のクエリは、クリックに結びつく広告のインプレッションを検索します。The following query is looking to find the ad impressions that generate clicks:

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

この例では、多数の広告が表示されても、ほとんどのユーザーがクリックしていない可能性があり、時間枠内にすべてのイベントを保持する必要があります。In this example, it is possible that lots of ads are shown and few people click on it and it is required to keep all the events in the time window. 消費されるメモリは、時間枠のサイズおよびイベント レートに比例します。Memory consumed is proportional to the window size and event rate. 

これを修復するには、結合キー (この場合は ID) でパーティション分割されたイベントをイベント ハブに送信し、次に示すように PARTITION BY を使用して各入力パーティションをシステムが個別に処理できるようにすることでクエリをスケールアウトします。To remediate this, send events to Event Hub partitioned by the join keys (ID in this case), and scale out the query by allowing the system to process each input partition separately using PARTITION BY as shown:

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 

クエリは、パーティション分割されると、複数のノードに広がります。Once the query is partitioned out, it is spread out over multiple nodes. その結果、各ノードで受信されるイベントの数が減少するため、結合ウィンドウに保持される状態のサイズが減少します。As a result the number of events coming into each node is reduced thereby reducing the size of the state kept in the join window. 

一時的な分析関数Temporal analytic functions

一時的な分析関数で使用されたメモリ (状態サイズ) は、期間で乗算したイベント レートに比例します。The memory consumed (state size) of a temporal analytic function is proportional to the event rate multiply by the duration.分析関数によって消費されるメモリは、時間枠のサイズではなく、むしろ各時間枠のパーティション数に比例しています。 The memory consumed by analytic functions is not proportional to the window size, but rather partition count in each time window.

修復は、一時的な結合と同様です。The remediation is similar to temporal join. PARTITION BY を使用してクエリをスケールアウトできます。You can scale out the query using PARTITION BY. 

誤順序バッファーOut of order buffer 

ユーザーは、[イベント順序] 構成ウィンドウで誤順序バッファー サイズを構成できます。User can configure the out of order buffer size in the Event Ordering configuration pane. バッファーは、ウィンドウの継続期間にわたって入力を保持し、それらを並べ替えるために使用されます。The buffer is used to hold inputs for the duration of the window, and reorder them. バッファーのサイズは、誤順序ウィンドウのサイズを乗算したイベント入力速度に比例します。The size of the buffer is proportional to the event input rate multiply by the out of order window size. 既定のウィンドウ サイズは 0 です。The default window size is 0. 

誤順序バッファーのオーバーフローを修復するには、PARTITION BY を使用してクエリをスケールアウトします。To remediate overflow of the out of order buffer, scale out query using PARTITION BY. クエリは、パーティション分割されると、複数のノードに広がります。Once the query is partitioned out, it is spread out over multiple nodes. その結果、各ノードで受信されるイベントの数が減少するため、各並べ替えバッファー内のイベント数が減少します。As a result, the number of events coming into each node is reduced thereby reducing the number of events in each reorder buffer. 

入力パーティション数Input partition count 

ジョブ入力の各入力パーティションにはバッファーがあります。Each input partition of a job input has a buffer. 入力パーティション数が多いほど、ジョブで消費されるリソースが多くなります。The larger number of input partitions, the more resource the job consumes. ストリーミング ユニットごとに、Azure Stream Analytics ではおおよそ 1 MB/s の入力を処理できます。For each streaming unit, Azure Stream Analytics can process roughly 1 MB/s of input. したがって、Stream Analytics のストリーミング ユニットの数と、イベント ハブのパーティション数を調整することにより、最適化することができます。Therefore, you can optimize by matching the number of Stream Analytics streaming units with the number of partitions in your Event Hub.

通常、(イベント ハブの最小値である) 2 つのパーティションを使用するイベント ハブでは、1 つのストリーミング ユニットで構成されている 1 つのジョブで十分です。Typically, a job configured with one streaming unit is sufficient for an Event Hub with two partitions (which is the minimum for Event Hub). イベント ハブにより多くのパーティションがある場合、Stream Analytics ジョブはより多くのリソースを消費しますが、イベント ハブによって提供される追加のスループットを必ずしも使用しません。If the Event Hub has more partitions, your Stream Analytics job consumes more resources, but not necessarily uses the extra throughput provided by Event Hub.

6 つストリーミング ユニットがあるジョブでは、イベント ハブのパーティションは 4 または 8 必要な場合があります。For a job with 6 streaming units, you may need 4 or 8 partitions from the Event Hub. ただし、リソースの使用を抑えるために不要なパーティションは増やさないようにします。However, avoid too many unnecessary partitions since that causes excessive resource usage. たとえば、ストリーミング ユニットが 1 つある Stream Analytics ジョブで、イベント ハブのパーティションが 16 以上ある場合などです。For example, an Event Hub with 16 partitions or larger in a Stream Analytics job that has 1 streaming unit.

参照データReference data 

ASA の参照データは、高速検索を行うためにメモリに読み込まれます。Reference data in ASA are loaded into memory for fast lookup. 現在の実装では、同じ参照データで複数回結合する場合でも、参照データを使用する結合操作ごとに参照データのコピーがメモリに保持されます。With the current implementation, each join operation with reference data keeps a copy of the reference data in memory, even if you join with the same reference data multiple times. PARTITION BY を使用したクエリでは、各パーティションに参照データのコピーが 1 つあるため、パーティションは完全に分離されます。For queries with PARTITION BY, each partition has a copy of the reference data, so the partitions are fully decoupled. 相乗効果により、複数のパーティションで参照データを使用して複数回結合した場合、メモリ使用量がすぐに非常に高くなることがあります。With the multiplier effect, memory usage can quickly get very high if you join with reference data multiple times with multiple partitions.  

UDF 関数の使用Use of UDF functions

UDF 関数を追加すると、Azure Stream Analytics は、JavaScript ランタイムをメモリに読み込みます。When you add a UDF function, Azure Stream Analytics loads the JavaScript runtime into memory. これは SU% に影響します。This will affect the SU%.

次のステップNext steps