Azure IoT Operationsの展開計画

多くのAzure IoT Operations設定はデプロイ時に修正され、再デプロイによってのみ変更できます。 デプロイする前に、クラスター トポロジ、ブローカーカーディナリティ、メモリ プロファイル、必要なオプションのブローカー設定を計画します。 この記事では、行う必要がある決定の概要を示します。

アーキテクチャを理解する

Azure IoT Operationsは、Azure Arc対応クラスターにデプロイされた一連のモジュール型の Kubernetes ネイティブ サービスです。 主なコンポーネントは次のとおりです。

ドキュメント全体で 2 つの用語が使用されます。

• デプロイ - インスタンス、Arc 拡張機能、カスタムの場所、および構成可能なすべてのリソース (資産、デバイス、データ フロー)。
• インスタンス — サービスをバンドルする親リソース。

クラスター トポロジを選択する

デプロイする前に、単一ノードクラスターとマルチノード クラスターのどちらを必要とするかを決定します。 この決定により、ハードウェア要件とブローカーのカーディナリティ設定が決まります。

ブローカーのカーディナリティを理解する

カーディナリティは、ブローカー デプロイ内のフロントエンド レプリカ、フロントエンド ワーカー、バックエンド パーティション、バックエンド ワーカーの数です。 カーディナリティは、ブローカーの水平方向のスケーリング方法と、ポッドまたはノードの障害に対する回復性を制御します。

MQTT ブローカーには 2 層アーキテクチャがあります。 フロントエンド ポッドはクライアント接続とプロトコル処理を処理し、 バックエンド ポッドはメッセージのストレージと配信を処理します。 容量計画では、各レベルがどのようにスケーリングされるかを理解することが重要です。

Frontend

フロントエンド ポッドは MQTT クライアント接続を受け入れ、バックエンドにメッセージを転送します。 フロントエンド ポッドは、メッセージ自体を格納しません。 フロントエンド層には、次の 2 つの主要な設定があります。

• レプリカ: デプロイするフロントエンド ポッドの数。 フロントエンド レプリカを追加すると、ブローカーが処理できる同時クライアント接続の数が増え、フロントエンド ポッドの 1 つが失敗した場合に高可用性が提供されます。
• ワーカー: フロントエンド ポッドあたりの論理ワーカーの数。 ワーカーを増やすと、フロントエンド ポッドはより多くの CPU コアを使用できます。 各ワーカーは、最大 1 つの CPU コアを消費できます。

バックエンド チェーン

バックエンド ポッドは、メッセージのストレージと配信を処理します。 バックエンド層には、次の 3 つの主要な設定があります。

• パーティション: デプロイするパーティションの数。 パーティションは、メッセージ スループットの水平スケーリングの単位です。 シャーディングと呼ばれるプロセスを通じて、各パーティションはメッセージの一部を処理し、トピックとセッションによってシャード化されます。 フロントエンド ポッドは、パーティション間でメッセージ トラフィックを分散します。 パーティションを追加すると、ブローカーが処理できるメッセージの合計スループットが増加します。
• 冗長性係数: パーティションごとにデプロイするバックエンド ポッドの数。 冗長性係数を大きくすると、データ コピーの数が増加し、クラスター内のノード障害に対する回復性を提供することができます。
• ワーカー: バックエンド ポッドあたりのワーカーの数。 ワーカーは、パーティション内での垂直スケーリングの単位です。ワーカーを追加すると、バックエンド ポッドは同じノード上でより多くの CPU コアを使用できます。 各ワーカーは最大 2 つの CPU コアを消費できるため、レプリカあたりのワーカー数を増やして、クラスター内の CPU コア数を超えないように注意してください。

スループットの見積もり

個々のパーティションのパフォーマンスは、実行されているノードの CPU 特性によって大きく異なります。 原則として、 パーティションあたり約 5,000 ~ 6,000 QoS 1 メッセージ/秒 、2 GHz CPU (最大 4 GHz ターボ) で 8 KB のペイロードが想定されます。 実際のパフォーマンスは多くの要因に依存するため、この数値は容量計画の開始点としてのみ使用してください。

ベンチマーク データの詳細については、 MQTT Broker のパフォーマンス ベンチマークに関する記事を参照してください。

単一ノードの推奨事項

• フロントエンド レプリカ: 1 に設定します。
• フロントエンド ワーカー: ノードあたりの CPU コア数の半分 に設定します。
• バックエンド レプリカ (冗長性係数): ブローカーがローリング更新を実行できるように、少なくとも 2 に設定します。

例: 単一ノード、4 CPU コア

マルチノードの推奨事項

最適なパフォーマンスを得るための値を次に示します。 トラフィックが少ない大規模なクラスターでは、問題を引き起こさずに、これらの値を推奨事項よりも低く設定できます。 メモリ (RAM) やパフォーマンス特性などのその他の考慮事項については、次のセクションで説明します。 パフォーマンスを確認するには、常に予想されるワークロードで構成をテストします。

• フロントエンド レプリカ: クラスター内 のノードの数 に等しく設定します。
• フロントエンド ワーカー: ノードあたりの CPU コア数の半分 に設定します。
• バックエンド レプリカ (冗長性係数): 冗長性とローリング 更新プログラムのサポートのために 2 に設定します。
• バックエンド パーティション: クラスター内 のノードの数 に等しく設定します。
• バックエンド ワーカー: ノードあたりの CPU コア数の半分 に設定します。

例: 3 ノード クラスター、ノードあたり 8 CPU コア

例: 5 ノード クラスター、ノードあたり 16 CPU コア

CPU リソースの制限

クラスター内のリソース不足を防ぐために、カーディナリティ設定に基づいて Kubernetes CPU リソース制限を要求 するようにブローカーを構成できます。 有効にすると、レプリカまたはワーカーの数をスケーリングすると、必要な CPU リソースが比例して増加します。

REST API、Bicep、ARM テンプレートの既定値は、Broker API 仕様で定義されています。

MQTT ブローカーは、構成されたワーカーの数に基づいてポッドごとの CPU リソースを要求します。

• フロントエンド ポッド: ワーカーあたり 1.0 CPU
• バックエンド ポッド: ワーカーあたり 2.0 CPU

合計 CPU 要件を計算するには、次の数式を使用します。

例: 小規模クラスター

次のカーディナリティを持つノードあたり 4 つの CPU コア (合計 8 コア) を持つ 2 ノード クラスターについて考えてみましょう。

{
  "cardinality": {
    "frontend": {
      "replicas": 2,
      "workers": 2
    },
    "backendChain": {
      "partitions": 1,
      "redundancyFactor": 2,
      "workers": 1
    }
  }
}

ブローカーは次の要求を行います。

• フロントエンド CPU: 2 つのレプリカ× 2 つのワーカー× 1.0 = 4.0 CPU
• バックエンド CPU: 1 パーティション × 2 RF × 1 ワーカー × 2.0 = 4.0 CPU
• ブローカー CPU の合計: 8.0 CPU

この構成では、8 コアのみのクラスターで 8.0 CPU が要求され、他のAzure IoT Operations コンポーネント (200 ~ 300m) や Kubernetes システム ポッドには何も残されません。 ブローカーポッドは、Pending エラーが発生した Insufficient cpu 状態のままです。

これを解決するには、ノードを追加するか、ノードあたりのコア数を増やすか、ブローカーのカーディナリティを減らします。

例: 大規模なデプロイ

次のカーディナリティ要求では、CPU リソースが大幅に多くなります。

{
  "cardinality": {
    "frontend": {
      "replicas": 3,
      "workers": 2
    },
    "backendChain": {
      "partitions": 3,
      "redundancyFactor": 2,
      "workers": 2
    }
  }
}

• フロントエンド CPU: 3 つのレプリカ× 2 つのワーカー× 1.0 = 6.0 CPU
• バックエンド CPU: 3 つのパーティション× 2 RF × 2 ワーカー × 2.0 = 24.0 CPU
• ブローカー CPU の合計: 30.0 CPU

クラスターには、ブローカー ポッドのみで使用できる少なくとも 30 個の CPU コアと、他のAzure IoT Operations コンポーネントと Kubernetes システム ポッドのヘッドルームが必要です。

CPU リソース制限の構成

CPU リソースの制限は、Broker リソースの generateResourceLimits.cpu フィールドによって制御されます。 この構成は、--broker-config-file コマンドを使用してAzure IoT Operationsをデプロイするときに、az iot ops create フラグを使用してのみサポートされます。 詳細については、 高度な MQTT ブローカー構成に対する Azure CLI のサポートを参照してください。

GenerateResourceLimits API リファレンスに従って、ブローカー構成ファイルを準備します。 次の例は、使用可能な 2 つの値を示しています。

{
  "generateResourceLimits": {
    "cpu": "Enabled"
  }
}

または

{
  "generateResourceLimits": {
    "cpu": "Disabled"
  }
}

メモリ プロファイルを選択する

メモリ プロファイルは、ブローカーが受け入れる MQTT メッセージの最大サイズ、アイドル状態のメモリ使用量、および各ポッドの最大メモリ使用量を制御します。 予想されるメッセージ サイズとスループットに基づいて、デプロイ前に適切なメモリ プロファイルを決定します。

受信バッファーとバックプレッシャ

各メモリ プロファイルは、バックエンド ワーカーごとの PUBLISH データの最大受信バッファー サイズを定義します。 バッファーが 75% 容量に達すると、ブローカーはバックプレッシャ メカニズムをアクティブ化し、受信メッセージの拒否を開始します。 拒否されたパケットは、 クォータ超過 エラー コードを含む PUBACK 応答を受信します。

次の表に、各プロファイルのワーカーごとの受信バッファー サイズを示します。

メモリ プロファイルを選択する場合は、次の点を考慮してください。

• 小さい: フロントエンドは 1 つだけ使用する必要があります。 4 MiB 未満のパケットのみを送信します。
• 低: 1 つまたは 2 つのフロントエンドのみを使用する必要があります。 16 MiB 未満のパケットのみを送信します。
• 中: メッセージ サイズが中程度のほとんどの運用ワークロードに適しています。
• 高: 大きなメッセージを処理する必要がある場合、または大きなバッファーで高スループットを処理する必要がある場合に使用します。

ブローカー メモリの合計は、メモリ プロファイルとカーディナリティ (フロントエンド レプリカの数、バックエンド パーティション、冗長性係数) の 両方 に依存します。 ポッドの数が多いほど、メモリの合計が多くなります。 さまざまな構成での基準リソース使用量の測定については、「 ベースライン リソース プロファイル」を参照してください。

メモリ使用量の合計を計算する

次の数式を使用して、メモリ使用量の合計を計算できます。

M_total = (R_fe × M_fe) + (P_be × RF_be × M_be × W_be)

Where:

たとえば、 中 メモリ プロファイルを選択した場合、プロファイルのフロントエンド メモリ使用量は 1.9 GiB、バックエンド メモリ使用量は 1.5 GiB です。 ブローカー構成は、2 つのフロントエンド レプリカ、2 つのバックエンド パーティション、およびバックエンド冗長係数 2 であるとします。 メモリ使用量の合計は次のとおりです。

M_total = (2 × 1.9 GiB) + (2 × 2 × 1.5 GiB × 2)
        = 15.8 GiB

これに対し、 Tiny メモリ プロファイルのフロントエンド メモリ使用量は 99 MiB、バックエンド メモリ使用量は 102 MiB です。 同じブローカー構成では、メモリ使用量の合計は次のようになります。

M_total = (2 × 99 MiB) + (2 × 2 × 102 MiB × 2)
        = 198 MiB + 816 MiB
        = 1014 MiB (≈ 1.0 GiB)

メモリ プロファイルの構成

az iot ops create コマンドを使用して IoT 操作をデプロイする場合、--broker-mem-profile パラメーターはメモリ プロファイルの設定を指定します。

たとえば、次のコマンドは、メモリ プロファイルを Tiny に設定します (簡潔にするために他のパラメーターは省略されます)。

az iot ops create ... --broker-mem-profile Tiny

詳細については、オプションの az iot ops create パラメーターに関するページを参照してください。

オプションのブローカー設定

次のブローカー設定はデプロイ時にも構成され、後で変更することはできません。 シナリオに該当する場合は、これらを確認します。

• ディスクに基づくメッセージ バッファー — サブスクライバー キューが使用可能なメモリを超えたときに、メッセージをディスクにバッファーします。 永続的なセッションと接続の課題に役立ちます。
• 永続性 - 重要なブローカー データをディスクに書き込み、再起動後も保持します。
• 診断 — MQTT ブローカーのメトリック、ログ、自己チェック プローブを構成します。
• 詳細 MQTT オプション - セッションの有効期限、メッセージの有効期限、サブスクライバー キューの制限、キープアライブ設定をカスタマイズします。
• 内部トラフィック暗号化 — ブローカー フロントエンドとバックエンド ポッドの間の内部トラフィックの暗号化を構成します (既定ではオン)。

次のステップ

• クラスターを準備する
• 運用クラスターにデプロイする
• 可観測性を構成する
• デプロイをセキュリティで保護する