この記事では、エッジからデータを収集してクラウドに転送する 2 つのAzure IoT Operationsデプロイの例について説明します。 これらの例は、ハードウェア機能とデータ ボリュームを考慮した実際のシナリオに基づいています。 これらの例を使用して、特定のハードウェアで処理できるデータAzure IoT Operations量をより深く理解します。
Microsoft同様の構成とデータ ボリュームを使用して、Azure IoT Operationsを検証し、そのパフォーマンスを測定しました。
シングル ノード クラスター
この例では、ハードウェア仕様が比較的低いホストで実行される場合のAzure IoT Operationsの機能を示します。 この例では、Azure IoT Operationsは単一ノード クラスターにデプロイされます。 資産から生成されたデータは、最初に PLC で集計され、OPC UA のAzure IoT Operations コネクタに送信されます。
構成
ハードウェア仕様の例:
Azure VM 上の K3 (Intel Xeon Platinum 8370C を使用したStandard_D4ds_v5)、4 コア (4 vCPU)、16 GB メモリ、30 GB ストレージ。
P3 Tiny Workstation 上の AKS-EE (第 13 世代 Intel® Core™ i7-13700 vPro® プロセッサ)、16 コア (24 スレッド)、32 GB メモリ、1 TB ストレージ。
重要
現在、Ubuntu 24.04 および vSphere Kubernetes Service 上の K3 は、運用環境で Azure IoT 操作をデプロイするための唯一のプラットフォームです。 詳細については、「サポートされている環境」を参照してください。
次の表に、単一ノードの MQTT ブローカー構成の例を示します。
| パラメーター | 値 |
|---|---|
| frontendReplicas | 1 |
| フロントエンドワーカー | 2 |
| バックエンド冗長性係数 | 2 |
| バックエンドワーカー | 1 |
| バックエンドパーティションズ | 1 |
| メモリプロファイル (memoryProfile) | low |
この例のエンド ツー エンドのデータ フローは次のようになります。
Assets -> PLC -> Connector for OPC UA -> MQTT broker -> Data flows -> Event Hubs
この例のデータ ボリュームは次のとおりです。
- 単一の OPC UA サーバーによって集計された 125 個の資産。
- 各資産の 50 個のタグに基づく 6,250 個のタグ。 各タグは 2/秒で更新され、平均サイズは 20 バイトです。
- OPC UA 用コネクタで、MQTT ブローカーに 125 メッセージ/秒が送信されます。
- 1 つのデータ フロー パイプラインで、6,250 個のタグが Event Hubs エンドポイントにプッシュされます。
この例では、4 コア CPU を持つデータ フロー インスタンスを 1 つだけ作成できるため、Microsoft Event Hubs の使用をお勧めします。 Event Grid を選択した場合、処理できるのは 100 メッセージ/sec のみです。
パフォーマンス
この例の主要なパフォーマンス メトリックは次のとおりです。
- Azure IoT Operationsとその依存関係は、6 GB から 8 GB の RAM の間で消費されます。
- Azure IoT Operationsとその依存関係は平均 2,400 ~ 2,600 ミリコアで消費されます。
- データの 100% が Event Hubs にプッシュされます。
- 理想的なネットワーク条件の場合、エンドツーエンドのデータ プロセスの待機時間は 10 秒未満です。
マルチノード クラスター
Azure IoT Operationsがマルチノード クラスターで実行されると、より多くのデータを処理し、Kubernetes の高可用性機能を利用できます。 この例では、Azure IoT Operationsは 5 ノード クラスターでホストされ、2 つの異なるデータ ソースから 1 秒あたり約 50,000 個のデータ ポイントを処理します。
構成
ハードウェア仕様の例:
Azure VM を備えた 5 ノード K3 (Intel Xeon Platinum 8370C を使用したStandard_D8d_v5)、8 コア (8 vCPU)、32 GB メモリ、30 GB。
P3 Tiny Workstations を備えた 5 ノード K3S (第 13 世代 Intel® Core™ i7-13700 vPro® プロセッサ)、16 コア (24 スレッド)、32 GB メモリ、1 TB ストレージ。
重要
現在、Ubuntu 24.04 および vSphere Kubernetes Service 上の K3 は、運用環境で Azure IoT 操作をデプロイするための唯一のプラットフォームです。 詳細については、「サポートされている環境」を参照してください。
次の表は、マルチノードの例の MQTT ブローカー構成を示しています。
| パラメーター | 値 |
|---|---|
| frontendReplicas | 5 |
| フロントエンドワーカー | 4 |
| バックエンド冗長性係数 | 2 |
| バックエンドワーカー | 4 |
| バックエンドパーティションズ | 5 |
| メモリプロファイル (memoryProfile) | 高 |
この例では、2 種類のデータ ソースがあります。 1 つは OPC UA 用コネクタを介して接続し、もう 1 つは MQTT ブローカーを介して接続します。
この例では、資産は実際の機器を表すのではなく、データ ポイントを集計してメッセージを送信する論理グループです。
この例の最初のエンド ツー エンド データ フローは次のようになります。
Assets -> PLC -> Connector for OPC UA -> MQTT broker -> Data flows -> Event Hubs
この例の最初のデータ フローのデータ ボリュームは次のとおりです。
- 5 つの OPC UA サーバーによって集計された 85 個の資産。
- 各資産の 1,000 個のタグに基づく 85,000 個のタグ。 各タグは 1/秒で更新され、平均サイズは 8 バイトです。 タグ値の約 50% がサイクルごとに変更されます。 データ ポイントの更新速度は 45,000/秒です。
- OPC UA 用コネクタで、MQTT ブローカーに 85 メッセージ/秒が送信されます。
- 1 つのデータ フロー パイプラインで、85,000 個のタグが Event Hubs エンドポイントにプッシュされます。
この例の 2 番目のエンド ツー エンド データ フローは次のようになります。
MQTT client (Paho) -> MQTT Broker -> Data flows -> Event Hubs
この例の 2 番目のデータ フローのデータ ボリュームは次のとおりです。
- MQTT ブローカーに直接接続された 2 つの MQTT クライアント。
- 各クライアントは 10,000 値/秒を発行します。
- タグ値の約 1/3 がサイクルごとに変更されます。
- JSON 形式でエンコードされます。 おおよそのサイズが 180 バイトの各項目 (値)。
パフォーマンス
この例の主要なパフォーマンス メトリックは次のとおりです。
- Azure IoT Operationsとその依存関係は、25 GB から 30 GB の RAM を消費します。
- Azure IoT Operationsとその依存関係は、平均 2,500 ~ 3,000 ミリコアで消費されます。
- データの 100% が Event Hubs にプッシュされます。
- 理想的なネットワーク条件の場合、エンドツーエンドのデータ プロセスの待機時間は 10 秒未満です。