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メッセージ（1メッセージあたり1KB）以下の受信レートでサブスクライブすることを推奨します。

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

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

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

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

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

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

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

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

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

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

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

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

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