Azure Stream Analytics ジョブをスケーリングしてスループットを向上させる

この記事では、スループットを向上させるためにAzure Stream Analytics クエリを調整する方法について説明します。 これらのスケーリング パターンを使用して、より多くの帯域幅、CPU、およびメモリ リソースを使用して、より高い負荷を処理します。

Azure Stream Analyticsは、streaming units (SU) のコンピューティング容量を測定します。 各 SU V2 は、1 つのコンピューティング ノードの完全な容量を表します。 エンバラッシングリー並列クエリとは、各入力パーティションをそれぞれ独立して処理でき、パーティション間でデータが共有されないクエリのことです。

Prerequisites

開始する前に、次の記事を確認してください。

完全に並列化可能なクエリをスケーリングする

クエリが入力パーティション間で驚異的に並列である場合は、次の手順に従います。

  1. PARTITION BY キーワードを使用するクエリを作成します。 詳細については、「 Azure Stream Analytics でのクエリの並列化の使用」を参照してください。

  2. クエリで使用される出力の種類によっては、一部の出力を並列化できない場合や、追加の構成が恥ずかしいほど並列である必要がある場合があります。 たとえば、並列化用に出力を構成します。 すべての出力の種類が並列書き込みをサポートしているわけではありません。

    出力の種類 並列化のサポート
    Azure Blob Storage、Azure Table Storage、Azure Data Lake Storage、Azure Service Bus、Azure Functions 自動
    Azure SQL Database、Azure Synapse Analytics オプション。 構成が必要
    Azure Event Hubs PartitionKey フィールド一致するように設定する必要があります (通常はPartitionId)。 クロスオーバーを回避するために、入力パーティションと出力パーティションの数を一致させます。
    Power BI 並列化できません。 出力は、シンクに送信する前に常にマージされます
  3. 達成可能な最大スループットを測定するために、 1 SU V2 (1 つのコンピューティング ノードの最大容量) でクエリを実行します。 GROUP BY を使用する場合は、ジョブで処理できるグループ (カーディナリティ) の数を測定します。

  4. システム リソースの制限を確認します。 次の現象は、Azure Stream Analytics ジョブがリソース制限に達したことを示しています。

    症状: 考えられる原因 アクション
    SU % 使用率メトリックが 80% を超えています メモリ使用量が多い。 ストリーミング ユニットの理解と調整を参照してください。 SU V2 を追加します。
    出力タイムスタンプがウォールクロック時間より遅れる クエリ ロジックによっては、出力タイムスタンプにウォール クロック時間からのロジック オフセットを設定できます。 ただし、ほぼ同じ速度で進行する必要があります。 出力タイムスタンプがさらに遅れている場合は、システムが過剰に稼働していることを示すインジケーターです。 ダウンストリーム出力シンクの調整の結果、または CPU 使用率が高い場合があります。 現時点では、Stream Analytics では CPU 使用率メトリックが提供されないため、2 つを区別するのは困難な場合があります。 シンクの調整が原因で問題が発生した場合は、出力パーティション (および並列処理を維持するための入力パーティション) を増やすか、シンク リソース (たとえば、Azure Cosmos DBの要求ユニット) を増やします。
    パーティションごとのバックログ イベント メトリックが増加し続ける (ジョブダイアグラムに表示されます) 出力シンクのスロットリングまたは CPU 使用率が高い 上記と同じです。
  5. 容量を線形に推定します。 1 SU V2 で処理できる内容を決定したら、パーティション間でデータスキューが発生しないと仮定して、それに比例して SU を追加します。

適切な数の SU V2 を選択します: Azure Stream Analytics では、SU V2 ごとに 1 つの処理ノードが作成されます。 SU V2 の数を入力パーティション数の除数にして、パーティションが均等に分散されるようにします。

例: 1 SU V2 ジョブは、4 つの入力パーティションで 4 MB/秒を処理します。 最大 8 MB/秒の場合は 2 SU V2、最大 16 MB/秒の場合は 4 SU V2 を使用します。 ターゲット入力レートに基づいて SU V2 カウントを選択します。

非パラメーター クエリをスケーリングする

クエリが「驚異的並列」ではない場合は、以下の手順に従います:

  1. 複雑さを避けるために PARTITION BY を使用せずに開始します。 最大スループットを測定するには、1 SU V2 でクエリを実行します。 前のセクションで説明したのと同じ リソース制限の症状 (80%を超える SU 使用率、出力タイムスタンプのラグ、バックログの増加) を確認します。

  2. 目標スループットを達成したら、完了です。 必要に応じて、2/3 SU V2 と 1/3 SU V2 でテストし、シナリオの最小 SU V2 数を見つけます。

  3. 目的のスループットを達成できない場合は、クエリを複数の手順に分割します。 各ステップに最大 1 SU V2 を割り当てます。 たとえば、3 ステップクエリには 3 SU V2 が必要です。 Azure Stream Analyticsは、各ステップを独自の専用ノードに配置します。

  4. まだスループット ターゲットに達していない場合は、入力に近い手順に PARTITION BY を追加します。 自然にパーティション分割できない GROUP BY 操作の場合は、ローカル/グローバル集計パターンを使用します。パーティション分割された GROUP BY を最初に実行してから、パーティション分割されていない GROUP BY を実行します。 たとえば、ボリュームが 1 SU V2 で処理できる量を超えたときに、各有料ブースを通過する車を 3 分ごとにカウントするには、次のようにします。

    WITH Step1 AS (
    SELECT COUNT(*) AS Count, TollBoothId, PartitionId
    FROM Input1 Partition By PartitionId
    GROUP BY TumblingWindow(minute, 3), TollBoothId, PartitionId
    )
    SELECT SUM(Count) AS Count, TollBoothId
    FROM Step1
    GROUP BY TumblingWindow(minute, 3), TollBoothId
    

    このクエリでは、手順 1 でパーティションごとに料金所ブースあたりの自動車数をカウントし、最後の手順でパーティション分割された数を集計します。

    クエリをパーティション分割した後、各パーティションが独自の処理ノードで実行されるように、各ステップの各パーティションに 1 SU V2 を割り当てます。

    クエリをパーティション分割できない場合、マルチステップ クエリで SU V2 を追加してもスループットが向上しない可能性があります。 パフォーマンスを向上させるには、手順 4 で示したローカル/グローバル集計パターンを使用して、最初の手順でボリュームを減らします。

1 つのジョブで複数の独立したクエリをスケーリングする

マルチテナント独立系ソフトウェア ベンダー (ISV) シナリオでは、(テナントごとに個別の入力と出力を使用して) 1 つのAzure Stream Analytics ジョブで複数のテナントからのデータを処理する場合、通常、各サブクエリの負荷は小さくなります。 次の手順に従います。

  1. クエリでは PARTITION BY を使用しないでください。

  2. Azure Event Hubsを使用する場合は、入力パーティションの数を最小値の 2 に減らします。

  3. 1 SU V2 でクエリを実行します。 ジョブがリソース制限に達するまでサブクエリを追加します。 症状は 、完全に並列化可能なクエリの場合と同じです。80%を超える SU 使用率、出力タイムスタンプのラグ、バックログの増加。

  4. サブクエリの制限に達したら、新しいサブクエリを別のジョブに追加します。 ジョブの数は、(負荷スキューがないと仮定して) 独立したクエリの数に比例してスケーリングされます。 次に、サービスを提供したいテナントの数に応じて実行する必要があるSU V2ジョブの数を予測できます。

  5. 参照データ結合の場合は、参照データと結合する前にすべての入力を結合してから、後でイベントを分割します。 それ以外の場合、各参照データ結合では参照データの個別のコピーがメモリ内に保持されるため、不要なメモリ使用量が発生する可能性があります。

ジョブあたりの最大テナント数: 1/3 SU V2 ジョブの場合は 40 テナント未満、2/3 ジョブと 1 SU V2 ジョブの場合は 60 テナント未満です。 多数のサブクエリによって、ジョブ コントローラーが処理できない複雑なトポロジが作成されるため、ジョブが開始できなくなります。

ヘルプを取得する

詳細については、 Azure Stream Analytics の Microsoft Q&A 質問ページをお試しください。