Azure Time Series Insights

解決する課題

工場の設備やセンサーが生み出す時系列データは、時間とともに膨大に積み上がり、生のメッセージのままでは「いつ・どの設備が・どう変化したか」を読み取れません。Azure Time Series Insights は、こうした IoT 由来の時系列データ を取り込み、時系列向けに最適化した形で蓄積し、時間軸での可視化と分析を素早く始められる基盤を提供します。

• 多数のセンサーから流れ込む 時系列テレメトリ を、まとめて蓄積・検索したい
• 自前で時系列データベースや可視化ツールを構築せず、短期間で傾向分析 を始めたい
• 設備ごと・期間ごとの トレンドや異常 を、時間軸のチャートで直感的に確認したい
• AWS の IoT SiteWise や Amazon Timestream のように、時系列に特化した分析基盤 を IoT ソリューションに組み込みたい

主要概念と用語

• 環境（Environment）: Time Series Insights の最上位のリソース。データの取り込み・保持・クエリの単位となる
• イベントソース（Event Source）: データの入口。IoT Hub や Event Hubs を接続し、メッセージを取り込む
• Time Series ID: 各時系列（センサーや機器）を識別するキー。このキー単位でデータが整理・分割される
• タイムスタンププロパティ: イベントの発生時刻を表すプロパティ。時間軸の基準として使われる
• ウォーム / コールドストア: 直近データを高速参照する保持層（ウォーム）と、長期保管する保持層（コールド）の二層構成
• Time Series Model（TSM）: 機器の階層・型・計算式などを定義し、生データに意味づけするモデル
• 環境エクスプローラー: 時系列をチャートで探索する Web の可視化 UI
• 時系列クエリ: 集計・補間・差分などを時間軸で行う、専用のクエリ機能

仕様・制限・クォータ

• 取り込みは IoT Hub / Event Hubs を介して行い、メッセージ内の タイムスタンプ と Time Series ID が時系列の整理に使われる
• 保持は ウォーム（直近・高速） と コールド（長期・大容量） の二層で構成され、保持期間や容量はプラン・設定に依存する
• 取り込みのスループット（レート）や保持容量、Time Series ID の設計には 上限や前提 があり、規模が大きい場合は事前確認が必要
• クエリ結果の件数やページングには制約があり、広い期間・多数の時系列をまたぐ場合は 絞り込みと分割 が前提となる
• リージョン可用性・具体的な上限値・提供状況は変動するため、設計時に最新の公式ドキュメントで確認すること

内部の仕組み

Time Series Insights の中心は 取り込み → 保持 → クエリ／可視化 の流れです。まず イベントソース として IoT Hub や Event Hubs を接続すると、メッセージが時系列向けの形式で取り込まれます。各イベントは タイムスタンプ と Time Series ID によって時間軸と系列に整理され、後続のクエリで効率よく走査できるよう蓄積されます。

• 取り込んだデータは ウォームストア で直近分を高速に参照し、古いデータは コールドストア に長期保管する二層構成で扱う
• Time Series Model を定義すると、生のセンサー値に階層・型・計算式といった意味づけを与えられる
• 蓄積データは 時系列クエリ で集計・補間・差分などを行い、環境エクスプローラー でチャートとして可視化する
• API を通じて外部アプリやダッシュボードからデータを取得し、独自の分析・表示に組み込むこともできる

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

• 入口＝ IoT Hub / Event Hubs、蓄積・分析＝ Time Series Insights という素直な流れを基本形にする
• Time Series ID は系列の識別単位として後から変えにくいため、機器の粒度を見据えて 最初に設計 する
• タイムスタンプは デバイス側の発生時刻 を明示的に持たせ、取り込み時刻との混同を避ける
• 直近の高速参照と長期保管で ウォーム／コールドの保持期間 を要件に合わせて使い分ける
• 階層や計算が必要なら Time Series Model で意味づけし、生データへの依存を減らす
• 新規構築では、後継となる時系列基盤（Azure Data Explorer 系）への移行を前提に 取り込み経路を疎結合 にしておく

運用・監視

• Azure Monitor のメトリクスで取り込みレート・保持容量・スロットリングなどを監視する
• 診断設定で関連ログを Log Analytics へ送り、取り込み失敗や遅延を追跡する
• イベントソース側（IoT Hub / Event Hubs）の 滞留やエラー とあわせて、データ欠損を早期に検知する
• 保持容量がプラン上限に近づくと取り込みに影響するため、容量と保持期間 を定期的に見直す

コスト

Time Series Insights のコストは、主に 取り込むデータ量・保持する容量・クエリの実行量 といった使用量で構成されます。常時のクラスタ料金より、流入レートと保持期間・容量がコストを左右します。

• 取り込みレートと 保持容量（特に長期のコールドストア） が増えるほどコストに直結する
• 高頻度・広範囲のクエリは処理量を押し上げるため、期間と系列の絞り込み でコストを抑える
• 具体的な単価や無料枠は変動するため、見積もりは最新の料金ページと実トラフィック見込みで行う

セキュリティ

• 制御は Microsoft Entra ID + RBAC が基本。環境への読み書き権限を最小権限で付与する
• 接続元のアプリ・サービスは マネージド ID を用い、キーや接続文字列の直書きを避ける
• 転送は TLS で保護し、保存データはサービス側で暗号化される
• イベントソースとなる IoT Hub / Event Hubs 側の認証・アクセス制御 とあわせて、入口から出口まで権限を一貫させる

関連サービス・比較

Time Series Insights は単体ではなく、入口の IoT Hub と組み合わせて使うのが基本でした。ここでは IoT データを階層化して扱う AWS の IoT SiteWise との対応を押さえます。

ハンズオン / CLI例

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

# Time Series Insights 環境を作成（プラン種別やSKUは要件に合わせて指定）
az tsi environment gen2 create \
  --resource-group demo-rg \
  --name demo-tsi-env \
  --location japaneast \
  --sku name=L1 capacity=1 \
  --time-series-id-properties name=deviceId type=String \
  --storage-configuration account-name=demosa management-key=<キーは安全に管理>

# IoT Hub をイベントソースとして接続
az tsi event-source iothub create \
  --resource-group demo-rg \
  --environment-name demo-tsi-env \
  --name demo-iothub-source \
  --consumer-group-name tsi-cg \
  --iot-hub-name demo-iothub \
  --key-name service \
  --shared-access-key <キーは安全に管理> \
  --event-source-resource-id <IoT Hub のリソースID>

# 作成した環境を確認
az tsi environment gen2 show \
  --resource-group demo-rg \
  --name demo-tsi-env