EMQX Enterprise

日本語

简体中文
English

日本語

简体中文
English

Appearance

お問い合わせ
お問い合わせ

Feature FAQs ​

単一クライアントのACL数に制限はありますか？ ​

理論上、制限はありません。ただし、メッセージのサブスクライブおよびパブリッシュのパフォーマンス向上のため、ACLルールが多すぎることは避けるべきです。単一クライアントあたり10個以下のACLを推奨します。ワイルドカードルールを使用するとACLエントリ数を減らすことができます。

EMQXはメッセージをデータベースに保存できますか？ ​

EMQX Enterpriseはデータのパーシステンスをサポートしています。詳細はデータ統合をご参照ください。

EMQXはMQTTメッセージをデータベースに保存できますか？ ​

はい。EMQX Enterpriseのデータ統合を利用してメッセージのパーシステンスを実現できます。EMQXは多様なSQL、NoSQL、時系列データベースをサポートしており、必要に応じて選択可能です。

EMQXはMQTTメッセージをKafkaなどのメッセージキューに転送できますか？ ​

はい。EMQX Enterpriseのデータ統合を通じて、KafkaやRabbitMQなどのメッセージキューにメッセージを転送できます。

EMQXはMQTTメッセージを他のMQTTサービスに転送できますか？ ​

はい。EMQXのMQTTブリッジを利用して、AWSやAzureなどのパブリッククラウド上に展開されたIoT Hubや、EMQXやMosquittoなどの標準MQTTブローカーを含む他のMQTTサービスにメッセージを転送できます。

共有サブスクリプションとは何ですか？ ​

共有サブスクリプションはMQTT 5.0で導入された新機能で、クライアントが負荷分散された形でメッセージを消費できるようにします。クライアントを複数のサブスクリプショングループに分けることができ、メッセージはすべてのグループに転送されますが、グループ内のクライアントはランダムやラウンドロビンなどの戦略で交互にメッセージを受信します。

MQTT 3.1.1のクライアントも同様に共有サブスクリプションを利用可能です。共有サブスクリプションの処理ロジックはすべてサーバー側で行われるため、クライアントは単に$share/group/{topic filter}をサブスクライブするだけで済みます。

共有サブスクリプションは、パブリッシャーが多くサブスクライバーが少ないデータ収集シナリオで有効です。詳細は共有サブスクリプションをご覧ください。

システムトピックとは何ですか？ ​

EMQXは定期的に自身の稼働状況、MQTTメッセージ数、クライアントのオンライン／オフラインイベントを$SYS/で始まるシステムトピックにパブリッシュします。クライアントはシステムトピックをサブスクライブして関連情報を取得できます。

システムトピックの詳細な紹介はこちらをご参照ください。

EMQXはクライアントが共有サブスクリプションを通じてシステムトピックをサブスクライブすることをサポートしていますか？ ​

はい。クライアントのオンライン・オフラインイベントなど頻繁にパブリッシュされるシステムメッセージには、共有サブスクリプションの利用が非常に有効です。サブスクリプション例：$share/group1/$SYS/brokers/+/clients/+/connected。

EMQXはクライアントがパブリッシュまたはサブスクライブできるトピックを制限できますか？ ​

はい。EMQXの認可管理機構により、クライアント権限の細粒度管理が可能です。

EMQXはデフォルトでacl.confファイルからACLルールを参照します。ユーザーはEMQX組み込みデータベース、MySQL、RedisなどのデータベースをACLルールのデータソースとして設定することも可能です。

通常、複数クライアントに有効なルールはacl.confに追加し、例えば同一ネットワークセグメントのクライアントのみシステムトピックをサブスクライブ可能にします。一方、単一クライアントに有効なルールはデータベースに追加し、例えばクライアントclient1にトピックexampleのサブスクライブを許可します。

認可の詳細はこちらをご覧ください。

EMQXはレート制限をサポートしていますか？ ​

はい。EMQXは接続レートおよびメッセージ流入レートの制御をサポートし、入口でのシステム過負荷を防止します。詳細はこちらをご参照ください。

EMQXクライアントのメッセージ受信レートに制限はありますか？ ​

EMQXやMQTTプロトコル自体は、各クライアントのメッセージ受信レートを直接制限しません。しかし、受信したメッセージをクライアントが処理しきれずに積み重なると、最終的にメッセージが破棄される可能性があります。システムの安定性とメッセージの信頼性を確保するため、各クライアントは1秒あたり1500メッセージ（1KB/メッセージ）以下の受信レートでサブスクライブすることを推奨します。

受信レートが推奨値を超える場合は、共有サブスクリプションを利用して複数のサブスクライバーを追加し、負荷分散して単一サブスクライバーの受信レートを下げることが可能です。

EMQXはクラスターの自動検出をサポートしていますか？実装方法は？ ​

手動でクラスターを作成する以外に、EMQXはDNSやetcdなどのノード検出戦略をサポートし、自動クラスタリングを実現できます。詳細はクラスターの作成と管理をご参照ください。

EMQXはサーバー側でMQTT接続をユーザーが能動的に切断できますか？ ​

はい。EMQXはコマンドラインインターフェースのemqx_ctl clients kick <Client ID>やREST APIのDELETE /clients/{clientid}を提供しており、ユーザーが手動でMQTT接続をキックできます。Dashboardのクライアントページからも操作可能です。

REST APIの詳細はEMQX Enterprise APIをご覧ください。

デバイスのオンライン・オフラインイベントを監視したいのですが、どうすればよいですか？ ​

EMQXはデバイスのオンライン・オフラインイベントを監視するために以下の3つの方法を提供しています：

  • WebHookを利用してオンライン・オフラインイベントメッセージを外部HTTPサービスに転送する。
  • MQTTクライアントでシステムトピックをサブスクライブし、オンライン・オフライン通知を取得する。
  • ルールエンジンでclient.connectedおよびclient.disconnectedイベントを監視し、データ統合と連携してイベントメッセージを指定データベースに書き込む。（EMQX Enterpriseのみ）

MQTTを使ってサーバーとEMQXを連携する際に、データのスループットと信頼性を向上させるには？ ​

アプリケーションサービスがMQTTプロトコルでEMQXと連携する場合、各クライアントは高負荷を処理することが多いです。クライアント性能を最大限に活用し、システムの可用性を確保するために、以下のベストプラクティスを推奨します：

  1. メッセージのサブスクライブとパブリッシュを分離する：単一クライアントがパブリッシャーとサブスクライバーの両方を兼ねることを避ける。
  2. 共有サブスクリプションを利用する：メッセージ受信には共有サブスクリプションを優先的に利用し、ビジネスシナリオやメッセージ量に応じてサブスクライバーの数を設定する。
  3. 複数クライアントでメッセージをパブリッシュする：ビジネスニーズやメッセージ量に応じてパブリッシュ用クライアント数を設定し、ロードバランシング戦略を実装する。

基本原則は単一クライアントのメッセージ負荷を減らすことです。複数チャネルでMQTTをやり取りすることで、全体のメッセージスループット性能を向上させ、システムの高可用性を実現できます。