Azure Time Series Insights

解決する課題

工場の設備やセンサーが生み出す時系列データは、時間とともに膨大に積み上がります。Azure Time Series Insights はこの用途を担っていましたが、2024年7月7日に退役済みです。現在の課題は、旧環境の取り込み契約・モデル・履歴・利用画面を棚卸しし、KQL ベースの現行基盤へ安全に移すことです。

• 旧イベントソース、Time Series ID、Time Series Model、API 利用者を 漏れなく棚卸ししたい
• Gen2 の顧客所有ストレージに残る履歴を 保持・移行・削除のどれにするか決めたい
• 旧クエリと画面を KQL と現行の可視化へ移植し、件数・時刻・集計結果を照合したい
• 新しい取り込み先を Azure Data Explorer または Fabric Eventhouseへ切り替えたい

主要概念と用語

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

仕様・制限・クォータ

• 提供状況: TSI の環境、取り込み、Explorer、クエリ API は退役済みで、新規設計の選択肢ではない
• 旧入力契約: IoT Hub / Event Hubs、タイムスタンプ、Time Series ID、型変換を記録し、新基盤のスキーマへ対応付ける
• 旧モデル: Time Series Model の階層・型・変数・計算式を、KQL 関数、参照表、セマンティックモデルなどへ明示的に移植する
• 旧履歴: Gen2 は顧客所有の Azure Storage を使っていた。原本の形式・保持ポリシー・アクセス権を確認し、必要なら Azure Data Explorer の外部テーブルで参照するか取り込む
• 移行先: 独立した Kusto 基盤が必要なら Azure Data Explorer、Fabric 内の統合分析を優先するなら Eventhouse / KQL データベースを選ぶ
• 検証: 時刻帯、遅延到着、重複、欠損、型、集計窓を含む照合基準を作り、件数だけで完了判定しない

内部の仕組み

横にスクロール

Time Series Insights の旧構成は 取り込み → 保持 → クエリ／可視化 の流れでした。イベントソース として IoT Hub や Event Hubs を接続し、各イベントを タイムスタンプ と Time Series ID で系列化していました。現在は同じ上流を Azure Data Explorer または Fabric Eventhouse へ向け直し、KQLによる保持・分析・可視化へ移行します。

• 旧環境では ウォームストア と コールドストア、Time Series Model、専用クエリ、環境エクスプローラーを組み合わせていた
• 現在は IoT Hub / Event Hubs のルートを Azure Data Explorer または Fabric Eventhouse に向け、KQL で系列化・集計する
• 旧 API の利用者、保存済みクエリ、画面、アラート、認証先を一覧化し、新しい接続先と Entra ID / RBAC へ切り替える
• 旧 Gen2 ストレージはサービスと別の顧客資産なので、削除せずに原本確認・アクセス権・保持期限を先に確定する

移行パターン / ベストプラクティス

• 依存関係を先に固定: イベントソース、Time Series ID、モデル、クエリ、画面、API 利用者、権限、Gen2 ストレージを一覧化する
• 新しい正本を決める: 発生時刻と取り込み時刻、系列 ID、スキーマ、保持期間、重複排除キーを新基盤で定義する
• 履歴を検証する: 旧 Gen2 ストレージを外部テーブルで参照するか取り込み、期間別の件数・最小最大時刻・代表集計を原本と比較する
• KQL へ移植する: 旧モデルの変数・補間・集計と保存済みクエリを KQL に書き換え、境界時刻と欠損時の結果も確認する
• 利用側を切り替える: API、Power BI、Grafana、業務アプリの接続先と認証を切り替え、失敗時の再処理経路を用意する
• 保持と削除を承認する: 法令・監査・復旧要件を確認し、旧ストレージの保持、アーカイブ、削除を明文化する

運用・監視

• Azure Data Explorer または Fabric 側で、取り込み成功・失敗・遅延・スロットリング・キャッシュ・ストレージを監視する
• IoT Hub / Event Hubs の滞留と新基盤の受信件数を突き合わせ、欠損・重複・遅延到着を検知する
• 移行済みアプリから旧 TSI URL や旧資格情報へのアクセスが残っていないか、コード・構成・ログを監査する
• 旧 Gen2 ストレージの権限と保持ポリシーを定期確認し、移行完了前の誤削除を防ぐ

コスト

退役済みの TSI 料金ではなく、移行先で見積もります。Azure Data Explorer はクラスター / コンピューティング、ホットキャッシュ、ストレージ、データ転送が中心です。Fabric Eventhouse は Fabric 容量と OneLake 保持などが中心です。旧 Gen2 ストレージを残す期間は、その保存・読み取り料金も重複して発生します。

セキュリティ

• 新しい Azure Data Explorer / Fabric と IoT Hub / Event Hubs は Entra ID、RBAC、マネージド IDで最小権限にする
• 旧 TSI のサービスプリンシパル、URL、保存済みトークン、接続文字列を棚卸しし、移行後に失効する
• 旧 Gen2 ストレージは TSI 退役後も顧客資産として残り得る。ネットワーク、暗号化、保持、削除、監査ログの責任を明確にする
• 履歴を書き出す際は、作業者の一時権限と出力先を限定し、移行コピーを新たな野良データにしない

移行先の比較

Time Series Insights は退役済みです。新規の時系列分析では、運用境界と既存の分析基盤に合わせて次の現行サービスを選びます。

既存環境の棚卸し / CLI例

以下は退役済み環境を新規作成する手順ではなく、残っているリソースと設定を移行前に確認する例です。

# サブスクリプション内に残る旧TSI環境を一覧化
az resource list \
  --resource-type Microsoft.TimeSeriesInsights/environments \
  --query "[].{name:name, resourceGroup:resourceGroup, location:location, id:id}" \
  --output table

# 対象環境のプロパティをJSONで保存し、ID・SKU・ストレージ設定を確認
az resource show \
  --ids <旧TSI環境のリソースID> \
  --output json

# 同じリソースグループのIoT Hub、Event Hubs、ストレージも一覧化
az resource list \
  --resource-group <リソースグループ名> \
  --query "[].{name:name, type:type, id:id}" \
  --output table