Microsoft Ignite (2023) などで徐々に推されており、気になったので調べつつメモしてみます。

sou (08thse)

アーキテクチャ

実体としては Edge 拠点に構築された Azure Arc 上の Kubernetes で一連のコンポーネントが動作する
- HW スペック的には CPU 8 Cores, 16GB RAM で検証されているとのこと
OPC UA Server を繋げて、そこからデバイス情報を取り込むイメージ
- 基本は OPC UA Server と一緒に構築するエコシステムになるのかな？
Akri にて、デバイスの検出が可能
Azure IoT Central と比べると、分析系はゴッソリ外 (Microsoft Fablic) に移した感がある
- Azure IoT Operations 的には、あくまでデバイス管理やデータ送信までで、分析等は担っていない建付けになったか

資産管理

Azure Device Registry に登録されると Azure リソースとしてもデバイスが見えるようになる

sou (08thse)

Linux (k3s) だけではなく、もちろん Edge Essentials にもデプロイ可能
ここで作成したシミュレーターを次の手順で利用している

Azure IoT Central みたいに、管理 Web サイト (Azure IoT Operations ポータル = Operations Experience ポータル) が用意され、管理操作は当該ポータル上で行う
- 既知の問題の最後にポツンと書いてあるのですが、Microsoft アカウント (MSA) ではサインインできず、Microsoft Entra ID アカウントが必要
OPC UA 資産エンドポイントは Kubernetes リソース (assetendpointprofile) として作成される
OPC UA 資産エンドポイント毎に、そこに接続する Pod も作成される
Akri から検出した OPC UA データソース (デバイス) は、Kubernetes リソースとして作成される

パイプラインだけなら Fablic は不要かな？

Azure IoT Central と比べると、分析系はゴッソリ外 (Microsoft Fablic) に移した感がある
Azure IoT Operations 的には、あくまでデバイス管理やデータ送信までで、分析等は担っていない建付けになったか

sou (08thse)

デプロイアーキテクチャ

Azure IoT Orchestrator を使用して、Azure IoT Operations Preview エッジコンピューティングシナリオのコンポーネントをデプロイ、構成、更新します。

Orchestrator は、Arc 対応の Kubernetes クラスター上のアプリケーションワークロードを管理するサービスです。 Helm、Kubectl、Arc などの既存のツールを使用して、ターゲットクラスターで目的の状態を実現します。 Orchestrator は、プロバイダーと呼ばれる拡張性モデルを使用します。これにより、広範な OS プラットフォームとデプロイメカニズムにわたるデプロイと構成をサポートできます。 Orchestrator には、望ましい状態を維持するための、調整機能と状態レポート機能も用意されています。

個別の Helm チャートを使ったコンポーネントなども、Azure IoT Orchestrator を利用してデプロイが可能とのこと。

sou (08thse)

Azure IoT Akri

Akri の Microsoft Managed 版 (PaaS という意味ではなく、Optimized 的な意味の "Managed" みたいです)

Akri で構成されたサイトに接続されている小型デバイスは、メモリや CPU と同様に Kubernetes リソースとして表示されます。 Azure IoT Akri コントローラーを使用すると、クラスターオペレーターは、接続された個々のデバイスまたはデバイスグループに対してブローカー、ジョブ、またはその他のワークロードを開始できます。

これらの Azure IoT Akri デバイスの構成とプロパティはクラスターに残るため、ノード障害が発生した場合に、失われた作業を他のノードが引き取ることができます。

単一ノード Kubernetes クラスターだと、簡単には引き取れないかな…　ここはマルチノード Kubernetes クラスターの話が前提か。

サポートされている動的検出プロトコルは OPC UA, ONVIF, udev とのこと
Akri 自体のメトリクスやログは、Azure Monitor ではなく Prometheus / Grafana を使って活用する
「Azure IoT Akri では、Azure Device Registry に取り込むことができる資産が検出されて作成されます」と「ISV は、Azure IoT Operations ソリューション用のカスタムプロトコルハンドラーを構築して販売できます」がサポートされていない、というのは具体的な内容を含めて気になる
- 前者は「Akri で検出して Kubernetes リソースとして構成できても、Azure 側 (Azure Device Registory) には作られないよ」と言っている？

Akri

Akri Configuration でデバイスを定義する
⇒ Akri 検出ハンドラーが上記をもとにデバイスを探す。見つかったら Akri Agent へ通知する
⇒ Akri Agent は Akri インスタンス (CRD) を作成する
⇒ Akri Controller が Akri インスタンスに対応した Broker Pod をデプロイする
⇒ Broker Pod が実デバイスと通信する

sou (08thse)

Azure IoT MQ

MQTT v3.1.1 と MQTT v5 の両方をサポート

既定では「broker」という名前の Azure IoT MQ クラスターリソースが作られる

IoT MQ は、サービスの種類として ClusterIp を指定し、ポート 8883 に TLS 対応リスナーをデプロイします。

IoT MQ は、クラスター内からの接続に対して認証用の Kubernetes サービスアカウントのみを受け入れます。クラスターの外部から接続するには、別の認証方法を構成する必要があります。

sou (08thse)

Azure IoT Data Processor

基本的にはデータの読み込み～処理～送信、といったあたり。ビジュアライゼーションは役割外のよう。

Protobuf がサポートされているみたい。IoT Central (単体) ではサポートされていなかった。

パイプラインの編集

「Digital Operations ポータル」で実施する
一部は GUI では管理できないので JSON を編集する

データの読み取り

MQ からだけではなく、外部の HTTP エンドポイントや SQL Server から取得したデータも使える
- この SQL Server は、アーキテクチャ的には同一拠点のオンプレ SQL Server とかもいけそうかな

データの処理

集計やフィルター処理 (jq)、外部エンドポイントの利用 (gRPC, HTTP)、データ変換 (jq) など。

エンリッチ化 (パイプラインのコンテキスト化)

別のパイプラインのデータをもとに、パイプライン内でコンテキスト化できる…　ということだが、具体的なケースを見ないと抽象的すぎてイメージが😅

データの送信

gRPC エンドポイント, MQTT ブローカーへ送信が可能
gRPC では Protobuf を使う
- 変換先ステージの JSON 構成の "descriptor" へ .proto ファイルの中身を base64 エンコードした文字列を渡す

sou (08thse)

クラウドへの接続

いずれもローカル (IoT Operations) との接続は Azure IoT MQ の MQTT ブローカーと、リモート (クラウド等の送信先) との接続は各接続形式に応じた Kubernetes カスタムリソース経由で行うイメージになっている。

Event Grid / MQTT との接続

接続先の MQTT ブローカーに応じて、Kubernetes のカスタムリソースとして「MqttBridgeConnector」と「MqttBridgeTopicMap」を作成する
サンプルはこちら、その定義はこちらを参照

Azure Data Lake Storage / Microsoft Fablic との接続

接続先に応じて、Kubernetes のカスタムリソースとして「DataLakeConnector」と「DataLakeConnectorTopicMap」を作成する

Kafka / Azure Event Hubs

接続先に応じて、Kubernetes のカスタムリソースとして「KafkaConnector」と「KafkaConnectorTopicMap」を作成する

sou (08thse)

正常性監視

Container Insights および Prometheus (Azure Monitor managed service for Prometheus) / Grafana (Azure Managed Grafana) による監視基盤
- デプロイ時に一緒に作成されるわけではなく、別途作成が必要

MQ 診断サービス

まだ情報が薄くてよく分からない。今後の情報充実に期待か…

sou (08thse)

Azure IoT Layered Network Management

Layered Network Management サービスを使用すると、インターネットに接続していないレイヤーからインターネットに接続しているレイヤーを介して Azure にネットワークトラフィックをルーティングできます。このサービスは、Arc 対応 Kubernetes クラスター上で Azure IoT Operations Preview の一つのコンポーネントとしてデプロイされ、管理されています。

つまるところ、インターネット非接続な環境にクラスターを置いた時に、どうやって Azure Arc へ接続するルートを作ってあげるか、管理してあげるか、というポイントに対するソリューション
ただ、下記の図にもあるように、完全に隔離されたネットワークではなく、あくまでインターネット接続が可能なネットワークとの経路は存在しないとダメ