Azure Stream Analytics

解決する課題

絶え間なく流れ込むイベントを、サーバーを自分で立てずに、低レイテンシで集計・検知・変換するための処理層を提供します。バッチ処理と違い、データが到着した端から連続的に評価できる点が特徴です。

• 大量のテレメトリやログを リアルタイムに集計 したい（直近5分の平均、件数、しきい値超過の検知など）
• ストリーム処理を SQL に近い宣言的なクエリ で書きたい（独自フレームワークの学習やクラスター運用を避けたい）
• 取り込み（Event Hubs / IoT Hub）と保存（SQL / Blob / Cosmos DB）の間に 変換・フィルター・集計の中間層 を置きたい
• 異常値やパターンを その場で検知 し、ダッシュボードやアラート、後続処理へ流したい

主要概念と用語

• ジョブ（Streaming Job）: 入力・クエリ・出力をひとまとめにした実行単位。これを開始すると連続的な処理が走る
• 入力（Input）: データの取り込み元。ストリーム入力（Event Hubs / IoT Hub / Blob）と、結合に使う参照入力（Blob / SQL Database）がある
• 出力（Output）: 処理結果の送り先。SQL Database、Blob / Data Lake、Cosmos DB、Power BI、Service Bus、Functions などに対応
• クエリ: Stream Analytics クエリ言語（SQL のサブセット）で記述する変換ロジック
• ウィンドウ関数: 時間で区切って集計する仕組み。タンブリング、ホッピング、スライディング、セッションの各ウィンドウがある
• タイムスタンプと TIMESTAMP BY: イベント自身の発生時刻（イベント時間）を基準に集計するための指定
• ウォーターマーク: どこまでのイベント時間を処理済みとみなすかの進行点。遅延到着イベントの扱いに関わる
• ストリーミングユニット（SU）: 割り当てる計算リソース量の単位。スループットとレイテンシを左右するスケールの軸

仕様・制限・クォータ

• クエリは SQL のサブセットで、SELECT / WHERE / GROUP BY / JOIN に加え、時間ウィンドウ関数を組み込みで備える
• スケールはストリーミングユニット（SU）で調整する。SU を増やすと並列度とスループットが上がる
• 並列度はパーティションに依存する。入力（Event Hubs のパーティション）から出力まで一貫した分割キーで設計すると、ジョブを並列化しやすい（埋め込み並列）
• イベント時間（アプリケーション時間）とウォーターマークで順序と遅延を扱い、到着順の乱れや遅延到着を許容範囲として設定できる
• 時間ベースの結合（JOIN） では結合対象の時間範囲を指定する必要がある（無制限の結合はできない）
• 入力・出力の種類、1ジョブあたりの SU、サブスクリプションあたりのジョブ数などには上限がある。具体的な数値は SKU や時期で変動し得るため、最新のドキュメントで確認する

内部の仕組み

Stream Analytics は、入力アダプターでイベントを取り込み、クエリエンジンで連続的に評価し、出力アダプターで結果を書き出す、というパイプラインとして動きます。クエリ言語に時間ウィンドウと TIMESTAMP BY が組み込まれているため、「直近 N 分の集計」のような時間軸の処理を宣言的に書けるのが本質的な強みです。

• 各イベントには到着時刻とは別に イベント時間 があり、TIMESTAMP BY でその列を指定すると、ネットワーク遅延による到着順の乱れがあっても本来の発生時刻で集計できる
• ウォーターマーク が処理の進行点を表し、これより前のイベント時間は処理済みとみなされる。遅延到着の許容や順不同の許容を設定して、遅れて来たイベントの扱いを制御する
• ウィンドウ関数で時間を区切る。タンブリングは重ならない固定長、ホッピングは一定間隔でずらした重なりあり、スライディングはイベント発生時点を起点、セッションは無活動期間で区切る
• 入力・クエリ・出力を通してパーティションキーを揃えると、各パーティションが独立に処理され（埋め込み並列）、SU を増やしたときにスループットが線形に近く伸びる

設計パターン / ベストプラクティス

• パイプラインは 取り込み（Event Hubs / IoT Hub）→ 処理（Stream Analytics）→ 保存・可視化（SQL / Blob / Cosmos DB / Power BI） の三段で組む
• 集計の基本は タンブリングウィンドウ + GROUP BY。重複なく区切れるため、件数や平均などの定期集計に向く
• 入力から出力までパーティションキーを一貫させて 埋め込み並列 を成立させ、SU を増やしたときに効率よくスケールさせる
• 単純なしきい値検知や軽い変換だけなら Stream Analytics で完結させ、複雑な独自ロジックが必要なら出力先に Azure Functions を挟んで拡張する
• マスターデータとの突き合わせには 参照入力（Blob / SQL） を使い、ストリームと静的データを結合する

運用・監視

• Azure Monitor のメトリクスで監視する。代表的なものは入力イベント数、出力イベント数、そして ウォーターマーク遅延（Watermark Delay） とバックログ（未処理入力イベント数）
• ウォーターマーク遅延が継続的に増える 場合は、処理がデータの流入に追いつけていないサインで、SU 不足やクエリの非効率を疑う（AWS でいう Kinesis の処理遅延の考え方に近い）
• スケールが頭打ちなら SU 使用率 を確認し、まずクエリの並列化（パーティション整合）を見直してから SU を増やす
• 診断ログを Log Analytics へ送り、変換エラーや出力先への書き込み失敗を可視化する
• 異常時の再処理に備え、入力側の保持期間内であれば 開始時刻を指定してジョブを再開 できる設計にしておく

コスト

課金は主に 割り当てたストリーミングユニット（SU）と稼働時間 に基づきます。SU を増やすほど処理能力は上がりますが、その分コストも増えるため、必要十分な SU に収めることが最適化の要点です。

セキュリティ

• 入力・出力への接続は Microsoft Entra ID（マネージド ID） で認証するのが基本で、接続文字列やキーの直書きを避ける
• ジョブの操作権限は Azure RBAC のロール割り当てで制御する
• 保存・転送中のデータは暗号化され、出力先（SQL / Blob / Cosmos DB）側のアクセス制御と組み合わせて保護する
• 仮想ネットワーク統合 / プライベートエンドポイント に対応する構成を使い、公開経路を絞ってプライベートに接続する

Well-Architected の観点

• パフォーマンス効率: SU とパーティション整合がスループットとレイテンシを決める中心要素。埋め込み並列を成立させ、ウォーターマーク遅延を指標にスケールを調整する
• 信頼性: イベント時間とウォーターマークで順不同・遅延到着を許容範囲として扱い、出力先の一時障害に備えて再処理（開始時刻指定での再開）を設計に織り込む
• 運用性: フルマネージドで基盤運用が不要な分、クエリとメトリクス（遅延・バックログ）の監視に運用の焦点を置く

試験で問われるポイント

関連サービス・比較

リアルタイム処理の中で Stream Analytics がどの役割を担うか、また AWS の相当サービスとの対応を押さえます。Event Hubs などの取り込み層と、SQL や Power BI などの保存・可視化層の「あいだ」に位置する処理エンジンです。

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Stream Analytics ジョブを作成（イベント時間順序の乱れと到着遅延の許容を指定）
az stream-analytics job create \
  --resource-group demo-rg \
  --name demo-asa-job \
  --location japaneast \
  --output-error-policy Drop \
  --out-of-order-policy Adjust \
  --order-max-delay 5 \
  --arrival-max-delay 16

# 既存ジョブの構成を確認
az stream-analytics job show \
  --resource-group demo-rg \
  --name demo-asa-job

# ジョブを開始（保存済みのクエリ・入力・出力で連続処理を開始）
az stream-analytics job start \
  --resource-group demo-rg \
  --name demo-asa-job \
  --output-start-mode JobStartTime