高可用性、スケーリング、メモリ使用量のブローカー設定を構成する
Broker リソースは、MQTT ブローカーの全体的な設定を定義するメイン リソースです。 また、フロントエンドやバックエンドなど、"ブローカー" 構成を実行するポッドの数と種類も決定します。 Broker リソースを使用して、そのメモリ プロファイルを構成することもできます。 自己復旧メカニズムはブローカーに組み込まれており、多くの場合、コンポーネントの障害から自動的に復旧できます。 たとえば、高可用性のために構成された Kubernetes クラスターでノードが失敗するとします。
フロントエンド レプリカとバックエンド パーティションを追加することで、MQTT ブローカーを水平方向にスケーリングできます。 フロントエンド レプリカは、クライアントからの MQTT 接続を受け入れ、バックエンド パーティションに転送する役割を担います。 バックエンド パーティションは、メッセージを格納してクライアントに配信する役割を担います。 フロントエンド ポッドはバックエンド ポッド間にメッセージ トラフィックを分散し、バックエンド冗長係数によって、クラスター内のノード障害に対する回復性を提供するデータ コピーの数が決まります。
利用可能な設定の一覧については、Broker API リファレンスを参照してください。
スケーリング設定を構成する
重要
この設定では、ブローカー リソースを変更する必要があり、Azure CLI または Azure portal を使用して初期デプロイ時にのみ構成できます。 "ブローカー" 構成の変更が必要な場合は、新しいデプロイが必要です。 詳細については、既定のブローカーのカスタマイズに関する記事を参照してください。
MQTT ブローカーのスケーリング設定を構成するには、Azure IoT Operations デプロイ中、ブローカー リソースの仕様でカーディナリティ フィールドを指定します。
自動デプロイのカーディナリティ
デプロイ時に初期カーディナリティを自動的に判断するには、ブローカー リソースのカーディナリティ フィールドを省略します。
Azure portal を使用して Azure IoT Operations をデプロイする場合、自動カーディナリティはまだサポートされていません。 ただし、クラスター デプロイ モードは、単一ノードまたはマルチノードとして手動で指定することはできます。 詳細については、Deploy Azure IoT Operations の展開に関するページを参照してください。
MQTT ブローカー オペレーターは、デプロイ時に使用可能なノードの数に基づいて、適切な数のポッドを自動的にデプロイします。 これは、高可用性やスケールが不要な非運用シナリオの場合に役立ちます。
ただし、これは自動スケーリングではありません。 オペレーターは、負荷に基づいてポッドの数を自動的にスケーリングしません。 オペレーターは、クラスター ハードウェアに基づいてデプロイするポッドの初期数のみを決定します。 前述のように、カーディナリティは初期デプロイ時にのみ設定できます。カーディナリティ設定を変更する必要がある場合は、新しいデプロイが必要です。
カーディナリティを直接構成する
カーディナリティ設定を直接構成するには、各カーディナリティ フィールドを指定します。
Azure IoT Operations をデプロイするためのガイドに従う場合は、[構成] セクションで [MQTT ブローカーの構成] を確認します。 ここで、フロントエンド レプリカ、バックエンド パーティション、およびバックエンド ワーカーの数を指定できます。
カーディナリティについて
カーディナリティは、セット内にある特定のエンティティのインスタンス数を意味します。 MQTT ブローカーのコンテキストでは、カーディナリティは、デプロイするフロントエンド レプリカ、バックエンド パーティション、バックエンド ワーカーの数を意味します。 カーディナリティ設定は、ブローカーの水平方向のスケーリング、およびポッドまたはノードの障害が発生した場合の高可用性の改善に使用されます。
カーディナリティ フィールドは入れ子になったフィールドで、フロントエンドと backendChain のサブフィールドが含まれます。 このサブフィールドそれぞれに独自の設定があります。
フロントエンド
フロントエンド サブフィールドでは、フロントエンド ポッドの設定を定義します。 主な設定は次の 2 つです。
レプリカ: デプロイするフロントエンド レプリカ (ポッド) の数。 フロントエンド ポッドの 1 つが失敗した場合に備えて、フロントエンド レプリカの数を増やすと高可用性を実現できます。
ワーカー: レプリカあたりの論理フロントエンド ワーカーの数。 各ワーカーが消費できる CPU コアは最大 1 つです。
バックエンド チェーン
バックエンド チェーン サブフィールドでは、バックエンド パーティションの設定を定義します。 主な設定は次の 3 つです。
パーティション: デプロイするパーティションの数。 シャーディングと呼ばれるプロセスを通じて、各パーティションはメッセージの一部をトピック ID とセッション ID で割って処理します。 フロントエンド ポッドは、パーティション間でメッセージ トラフィックを分散します。 パーティションの数を増やすと、ブローカーが処理できるメッセージの数が増えます。
冗長性係数: パーティションあたりのデプロイするバックエンド レプリカ (ポッド) の数。 冗長性係数を大きくすると、データ コピーの数が増加し、クラスター内のノード障害に対する回復性を提供することができます。
ワーカー: バックエンド レプリカあたりのデプロイするワーカーの数。 バックエンド レプリカあたりのワーカー数を増やすと、バックエンド ポッドで処理できるメッセージの数が増える場合があります。 各ワーカーは最大 2 つの CPU コアを消費するため、レプリカあたりのワーカー数を増やしてクラスター内の CPU コアの数を超えないように注意してください。
考慮事項
カーディナリティの値を増やすと、一般的にはより多くの接続とメッセージを処理するブローカーの容量が向上し、ポッドまたはノードの障害が発生した場合の高可用性が向上します。 ただし、これにより、リソースの消費量も増加します。 そのため、カーディナリティ値を調整するときは、メモリ プロファイルの設定とブローカーの CPU リソース要求を検討してください。 フロントエンド レプリカあたりのワーカー数を増やすと、フロントエンドの CPU 使用率がボトルネックであることがわかった場合に、CPU コアの使用率を高めるのに役立ちます。 バックエンド ワーカーの数を増やすと、バックエンド CPU がボトルネックである場合のメッセージのスループットに役立ちます。
たとえば、クラスターに 3 つのノードがあり、それぞれが 8 つの CPU コアを持つ場合は、ノードの数 (3) に合わせてフロントエンド レプリカの数を設定し、ワーカーの数を 1 に設定します。 ノードの数 (3) に合わせてバックエンド パーティションの数を設定し、バックエンド ワーカーを 1 に設定します。 必要に応じて冗長性係数を設定します (2 または 3)。 フロントエンド CPU がボトルネックであることがわかった場合は、フロントエンド ワーカーの数を増やします。 バックエンドとフロントエンドのワーカーは、CPU リソースの確保を求めて、お互いに、および他のポッドと競合する可能性があることに注意してください。
メモリ プロファイルを構成する
重要
この設定では、ブローカー リソースを変更する必要があり、Azure CLI または Azure portal を使用して初期デプロイ時にのみ構成できます。 "ブローカー" 構成の変更が必要な場合は、新しいデプロイが必要です。 詳細については、既定のブローカーのカスタマイズに関する記事を参照してください。
MQTT ブローカーのメモリ プロファイル設定を構成するには、Azure IoT Operations デプロイ中、ブローカー リソースの仕様でメモリ プロファイル フィールドを指定します。
Azure IoT Operations をデプロイするためのガイドに従う場合は、[構成] セクションで [MQTT ブローカーの構成] の [メモリ プロファイル] 設定を確認します。 ここでは、ドロップダウン リストの使用可能なメモリ プロファイルから選択できます。
メモリ使用量の特性が異なるいくつかのメモリ プロファイルから選択できます。
最小
このプロファイルを使用する場合:
- 各フロントエンド レプリカの最大メモリ使用量は約 99 MiB ですが、実際の最大メモリ使用量は高くなる可能性があります。
- 各バックエンド レプリカの最大メモリ使用量は、約 102 MiB にバックエンド ワーカーの数を乗算しますが、実際の最大メモリ使用量は高くなる可能性があります。
このプロファイルを使用する場合の推奨事項:
- 使用するフロントエンドは 1 つだけです。
- クライアントは大きなパケットを送信しないでください。 送信するパケットは 4 MiB 未満にする必要があります。
低
このプロファイルを使用する場合:
- 各フロントエンド レプリカの最大メモリ使用量は約 387 MiB ですが、実際の最大メモリ使用量は高くなる可能性があります。
- 各バックエンド レプリカの最大メモリ使用量は、約 390 MiB にバックエンド ワーカーの数を乗算しますすが、実際の最大メモリ使用量は高くなる可能性があります。
このプロファイルを使用する場合の推奨事項:
- 1 つまたは 2 つのフロントエンドのみを使用する必要があります。
- クライアントは大きなパケットを送信しないでください。 送信するパケットは 10 MiB 未満にする必要があります。
中
Medium は既定のプロファイルです。
- 各フロントエンド レプリカの最大メモリ使用量は約 1.9 GiB ですが、実際の最大メモリ使用量は高くなる可能性があります。
- 各バックエンド レプリカの最大メモリ使用量は、約 1.5 GiB にバックエンド ワーカーの数を乗算しますすが、実際の最大メモリ使用量は高くなる可能性があります。
高
- 各フロントエンド レプリカの最大メモリ使用量は約 4.9 GiB ですが、実際の最大メモリ使用量は高くなる可能性があります。
- 各バックエンド レプリカの最大メモリ使用量は、約 5.8 GiB にバックエンド ワーカーの数を乗算しますすが、実際の最大メモリ使用量は高くなる可能性があります。
カーディナリティと Kubernetes リソースの制限
クラスター内のリソース不足を防ぐために、ブローカーは既定で Kubernetes CPU リソース制限を要求するように構成されます。 レプリカまたはワーカーの数をスケーリングすると、それに比例して必要な CPU リソースが増加します。 クラスターで使用可能な CPU リソースが不足すると、デプロイ エラーが発生します。 これにより、要求されたブローカー カーディナリティで、最適な実行に必要なリソースが不足するという状況を回避できます。 また、潜在的な CPU 競合やポッド削除を防ぐのにも役立ちます。
MQTT ブローカーは現在、フロントエンド ワーカーごとに 1 つの (1.0) CPU ユニットと、バックエンド ワーカーごとに 2 つの (2.0) CPU ユニットを要求しています。 詳細については、Kubernetes CPU リソース ユニットに関する記事を参照してください。
たとえば、以下のカーディナリティでは、次の CPU リソースが要求されます。
- フロントエンド: フロントエンド ポッドあたり 2 CPU ユニット、合計 6 CPU ユニット。
- バックエンド: バックエンド ポッドあたり 4 CPU ユニット (2 つのバックエンド ワーカーの場合)、x 2 (冗長性係数)、x 3 (パーティション数)、合計 24 CPU ユニット。
{
"cardinality": {
"frontend": {
"replicas": 3,
"workers": 2
},
"backendChain": {
"partitions": 3,
"redundancyFactor": 2,
"workers": 2
}
}
}
この設定を無効にするには、generateResourceLimits.cpu フィールドを、ブローカー リソースで Disabled に設定します。
generateResourceLimits フィールドの変更は、Azure portal ではサポートされていません。 この設定を無効にするには、Azure CLI を使用します。
マルチノード デプロイ
マルチノード デプロイで高可用性と回復性を確保するために、Azure IoT Operations MQTT ブローカーでは、バックエンド ポッド用にアンチアフィニティ ルールが自動的に設定されます。
これらのルールはあらかじめ定義されており、変更できません。
アンチアフィニティ ルールの目的
アンチアフィニティ ルールは、同じパーティションのバックエンド ポッドが同じノードで実行されないようにします。 これは負荷を分散するのに役立ち、ノード障害に対する回復性を提供します。 具体的には、同じパーティションのバックエンド ポッドには、お互いにアンチアフィニティがあります。
アンチアフィニティ設定の確認
バックエンド ポッドのアンチアフィニティ設定を確認するには、次のコマンドを使用します。
kubectl get pod aio-broker-backend-1-0 -n azure-iot-operations -o yaml | grep affinity -A 15
出力には、次のようなアンチアフィニティ構成が表示されます。
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: chain-number
operator: In
values:
- "1"
topologyKey: kubernetes.io/hostname
weight: 100
これらは、ブローカーに設定された唯一のアンチアフィニティ ルールです。