このリファレンスでは、アイドル状態でのAzure IoT Operationsデプロイのベースライン リソース使用量を測定します (アクティブなワークロードはありません)。 これらのプロファイルを使用して、ハードウェアが最小要件を満たしていることを検証し、リソース監視ベースラインを確立します。
Overview
Azure IoT Operationsは、複数の Kubernetes 名前空間に複数のコンポーネントをデプロイします。 リソースフットプリントの合計は、MQTT ブローカー メモリ プロファイル (ポッドごとのメモリ割り当てを制御する) とブローカーの カーディナリティ (フロントエンド レプリカの数、バックエンド パーティション、およびデプロイされるポッドの数を制御する冗長性係数) の 2 つの要因によって異なります。 カーディナリティが高いほどポッドが多く、メモリ プロファイルが高いほど、各ポッドはより多くのメモリを使用します。
アイドル状態の単一ノード クラスターで 3 つの構成が測定されました (接続された資産なし、アクティブなデータ フローなし、ほぼゼロのトラフィック)。 これらは ベースライン番号であり、最大値ではありません。 運用環境のワークロードでは、消費が大幅に増加します。
| Configuration | メモリ プロファイル | Cardinality | ノード ピーク メモリ | Azure IoT Operations 名前空間の RSS のピーク | Pod のピーク RSS 合計 | ポッド数 |
|---|---|---|---|---|---|---|
| 構成 A | 最小 | 1 フロントエンド 1 パーティション 冗長性係数 2 |
約 4,979 MiB | 約 1,298 MiB | 約 5,409 MiB | 55 |
| 構成 B | 低 | 2 フロントエンド 2 つのパーティション 冗長性係数 2 |
約 5,130 MiB | 約 1,559 MiB | 約 5,695 MiB | 58 |
| 構成 C | 中程度 | 2 フロントエンド 2 つのパーティション 冗長性係数 2 |
約 6,088 MiB | 約 2,407 MiB | 約 6,564 MiB | 58 |
Note
Config A と Config B の違いは、カーディナリティの向上 (ブローカー ポッドの増加) と異なる メモリ プロファイルの両方に起因します。 Config B と Config C の違いは、純粋にメモリ プロファイル (同じカーディナリティ、同じポッド数) です。 負荷シナリオについては、本番環境へのデプロイ例を参照してください。
名前空間の内訳
次の表は、アイドル時の 3 つの構成すべてに対する名前空間別のピーク RSS メモリを示しています。
| 名前空間 | 構成 A、極小 (MiB) | 構成 B、低 (MiB) | 構成 C、中 (MiB) | Description |
|---|---|---|---|---|
| azure-iot-operations | 1,298 | 1,559 | 2,407 | Azure IoT Operationsコア サービス (ブローカー、データ フロー、コネクタ、可観測性) |
| azure-arc | 1,964 | 1,985 | 1,990 | Azure Arc エージェントとコントローラー |
| cert-manager | 1,351 | 1,357 | 1,362 | 証明書の管理 |
| gatekeeper-system | 338 | 338 | 350 | ポリシーの適用 |
| azure-extensions-usage-system | 279 | 277 | 278 | 課金担当者 |
| arc-workload-identity | 90 | 90 | 91 | ワークロード ID Webhook |
| azure-secret-store | 87 | 88 | 87 | シークレット同期コントローラー |
| 合計 | ~5,409 | ~5,695 | ~6,564 |
Note
- Azure Arc、cert-manager、gatekeeper、およびその他のインフラストラクチャ名前空間は、ブローカーの構成に関係なく、最大 3.8 から 4.1 GB を消費します。 このオーバーヘッドは、Azure IoT Operationsを使用して Arc 対応クラスターを実行する固定コストです。
-
azure-iot-operations1.3 GB (小さいカーディナリティ、最小カーディナリティ) から最大 2.4 GB (中、カーディナリティが高い) まで、名前空間のみです。 - ワークロードを考慮する前のアイドル状態で、Azure IoT Operations インフラストラクチャ専用に少なくとも 6 GB のメモリ を見込んでください。
MQTT ブローカー ポッドのリソース消費量
MQTT ブローカーは、最大の変数コンポーネントです。 構成間のメモリの違いは、メモリ プロファイル (ポッドごとの割り当て) とカーディナリティ (ポッドの数) の 両方 にあります。 次の表は、ポッドごとのアイドル状態の RSS を示しています。 トラフィックの増加に伴い、次の数値が増加します。
| ポッド | 構成 A、極小 (MiB) | 構成 B、低 (MiB) | 構成 C、中 (MiB) | メモ |
|---|---|---|---|---|
| aio-broker-frontend-0 | 二十九 | 33 | 169 | プロファイルに応じて変動するポッドごとのメモリ |
| aio-broker-frontend-1 | N/A | 33 | 169 | Config A に存在しない (1 つのフロントエンド レプリカ) |
| aio-broker-backend-1-0 | 41 | 66 | 211 | プロファイルに応じて変動するポッドごとのメモリ |
| aio-broker-backend-1-1 | 41 | 65 | 210 | 冗長性係数レプリカ |
| aio-broker-backend-2-0 | N/A | 66 | 212 | Config A に存在しない (1 つのパーティション) |
| aio-broker-backend-2-1 | N/A | 65 | 211 | Config A に存在しない (1 つのパーティション) |
| aio-broker-health-manager-0 | 41 | 41 | 42 | 全プロファイルで共通 |
| aio-broker-operator-0 | 60 | 60 | 56 | 全プロファイルで共通 |
| aio-broker-diagnostics-probe-0 | 24 | 43 | 43 | |
| aio-broker-diagnostics-service-0 | 49 | 66 | 66 | |
| aio-broker-authentication-0 | 24 | 24 | 24 | 全プロファイルで共通 |
| aio-broker-webhook-0 | 33 | 35 | 32 | 全プロファイルで共通 |
テストされたプロファイルごとのブローカー構成
| Setting | 構成 A (極小) | 構成 B (低) | 構成 C (中) |
|---|---|---|---|
| フロントエンドのレプリカ | 1 | 2 | 2 |
| バックエンド パーティション | 1 | 2 | 2 |
| バックエンドの冗長性係数 | 2 | 2 | 2 |
| ブローカー ポッドの合計数 | 10 | 13 | 13 |
| ポッドあたりの未使用フロントエンド メモリ | 約 29 MiB | 約 33 MiB | 約 169 MiB |
| ポッドあたりのアイドル時バックエンド メモリ | 約 41 MiB | 約 66 MiB | 約211 MiB |
| メッセージの最大サイズ | 4 MB | 16メガバイト | 64 MB |
その他のAzure IoT Operations コンポーネントの消費量
これらのコンポーネントは、メモリ プロファイルやカーディナリティに関係なく、一貫したアイドル 状態のリソース使用量を持ちます。
| コンポーネント | ピーク RSS (MiB) | ピーク CPU (コア) | メモ |
|---|---|---|---|
| adr-schema-registry (x2) | 各約52 | 0.002 | スキーマ レジストリ ポッド |
| aio-akri-operator-0 | ~39 | 0.001 | Akri デバイスの検出 |
| aio-akri-adr-service-0 | ~30 | 0.001 | Akri Azure Device Registry (ADR) サービス |
| aio-dataflow-dev-0 | ~67 | 0.002 | データ フロー ランタイム |
| aio-dataflow-operator-0 | ~56 | 0.001 | データ フロー演算子 |
| aio-operator | ~114 | 0.003 | Azure IoT Operations オペレーター |
| aio-observability (x2) | 各約125個 | 0.005 | OpenTelemetry コレクター |
| aio-observability-operator | ~106 | 0.003 | 可観測性演算子 |
| aio-observability-cluster-metrics-agent | ~114 | 0.004 | 指標エージェント |
| aio-wasm-graph-controller-0 | ~30 | 0.001 | WebAssembly (WASM) グラフ コントローラー |
CPU 使用量
CPU 消費量は、テストされたすべての構成でアイドル時に最小限に抑えられます。
| Configuration | Azure IoT Operations 名前空間の CPU のピーク | クラスターのCPUピーク値の合計 | ノードの割合 |
|---|---|---|---|
| Config A (Tiny) | 0.025 コア | 0.099 コア | 1.3% |
| 設定 B（低） | 0.044 コア | 0.104 コア | 1.3% |
| 構成 C (中) | 0.048 コア | 0.093 コア | 1.2% |
アイドル時のCPU使用率はほとんど無視できる程度です。 運用環境の負荷では、メッセージのスループットと構成されたフロントエンド/バックエンド ワーカーの数に比例して、CPU 消費量が大幅に増加することが予想されます。
ハードウェアのサイズ設定に関するガイダンス
これらのアイドル状態のベースライン測定に基づいて、次の最小ハードウェア推奨事項が単一ノードデプロイに適用されます。 実稼働トラフィックでは、実際の要件が高くなります。
| メモリ プロファイル | 最小 RAM（余裕分を含む） | 推奨 RAM | ユースケース(事例) |
|---|---|---|---|
| 小さな | 8 GB | 8 ~ 10 GB | トラフィックが少なく、パケットが小さい場合のみ |
| Low | 10 GB | 12 ~ 16 GB | メモリが制限され、パケットが小さい |
| Medium | 12 GB | 16 ~ 32 GB | トラフィックとメッセージのサイズをモデレートする |
| 高い | 16 GB | 32 GB 以上 | 高スループット、大きなメッセージ |
Important
これらの推奨事項では、固定的なインフラストラクチャのオーバーヘッド約 4 GB（Azure Arc、cert-manager、gatekeeper）に加え、Azure IoT Operations コンポーネントの可変フットプリントを考慮しています。 運用ワークロードでは、MQTT メッセージ バッファリング、データ フロー処理、および OPC UA コネクタ アクティビティ用の追加のヘッドルームが必要です。