Feature FAQs
単一クライアントのACL数に制限はありますか？
理論上、制限はありません。しかし、メッセージのサブスクライブおよびパブリッシュのパフォーマンス向上のため、ACLルールを多く持ちすぎないことが望ましいです。単一クライアントあたり10個以内のACLを推奨します。ワイルドカードルールを使用することでACLエントリ数を減らすことが可能です。
EMQXはメッセージをデータベースに保存できますか？
EMQX Enterpriseはデータのパーシステンスをサポートしています。詳細はData Integrationをご参照ください。
EMQXはMQTTメッセージをデータベースに保存できますか？
はい。EMQX EnterpriseのData Integrationを利用してメッセージのパーシステンスを実現できます。EMQXは各種SQL、NoSQL、時系列データベースをサポートしており、用途に応じて選択可能です。
EMQXはMQTTメッセージをKafkaなどのメッセージキューに転送できますか？
はい。EMQX EnterpriseのData Integrationを通じて、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}にサブスクライブするだけで同様に利用可能です。
共有サブスクリプションは、メッセージのパブリッシャーが多数でサブスクライバーが少数のデータ収集シナリオに有効です。詳細はShared Subscriptionをご参照ください。
システムトピックとは何ですか？
EMQXは自身の稼働状況、MQTTメッセージ数、クライアントのオンライン／オフラインイベントを$SYS/で始まるシステムトピックに定期的にパブリッシュします。クライアントはシステムトピックをサブスクライブして関連情報を取得できます。
システムトピックの詳細な説明はこちらをご覧ください。
EMQXはクライアントが共有サブスクリプション経由でシステムトピックをサブスクライブすることをサポートしていますか？
はい。クライアントのオンライン・オフラインイベントなど頻繁にパブリッシュされるシステムメッセージに対して、共有サブスクリプションは非常に有効です。サブスクリプション例：$share/group1/$SYS/brokers/+/clients/+/connected
EMQXはカスタマイズされたプロトコルへのアクセスをサポートしていますか？
EMQXはExProtoゲートウェイを提供しており、Java、Python、Goなどの慣れ親しんだプログラミング言語でgRPCサービスを開発し、デバイスが使用するカスタマイズプロトコルの解析や、デバイス接続、認証、メッセージ送信などの機能を実現できます。
詳細はExProto Protocol Gatewayをご参照ください。
EMQXはクライアントがパブリッシュまたはサブスクライブできるトピックの制限をサポートしていますか？
はい。EMQXの認可管理機構により、クライアント権限の細粒度管理が可能です。
EMQXはデフォルトでacl.confファイルからACLルールを参照します。ユーザーはEMQX組み込みデータベース、MySQL、RedisなどのデータベースをACLルールのデータソースとして設定することもできます。
通常、複数クライアントに有効なルールはacl.confに記述し、例えば同一ネットワークセグメントのクライアントのみがシステムトピックをサブスクライブ可能にします。一方、単一クライアントに有効なルールはデータベースに記述し、例えばクライアントclient1がトピックexampleをサブスクライブ可能にします。
認可の詳細はこちらをご覧ください。
EMQXはレート制限をサポートしていますか？
はい。EMQXは接続レートおよびメッセージ流入レートの制御をサポートし、入口でのシステム過負荷を防止します。詳細はこちらをご参照ください。
EMQXクライアントのメッセージ受信レートに制限はありますか？
EMQXやMQTTプロトコル自体はクライアントごとのメッセージ受信レートを直接制限しません。しかし、多数のメッセージを受信してクライアントが処理しきれない場合、メッセージが積み重なり最終的に破棄される可能性があります。システムの安定性とメッセージ信頼性を確保するため、クライアントごとのメッセージ受信レートは1秒あたり1500メッセージ（1KB/メッセージ）以内を推奨します。
受信レートが推奨値を超える場合は、Shared Subscriptionを利用して複数のサブスクライバーを追加し、単一サブスクライバーの受信レートを分散してください。
EMQXはクラスターの自動検出をサポートしていますか？実装方法は？
手動でクラスターを作成するほか、EMQXはDNSやetcdなどのノード検出戦略をサポートし、自動クラスタリングを実現できます。詳細はCreate and Manage Clusterをご参照ください。
EMQXはサーバー側でMQTT接続をユーザーが能動的に切断することをサポートしていますか？
はい。EMQXはCLIの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イベントを監視し、Data Integrationと連携してイベントメッセージを指定データベースに書き込む（EMQX Enterpriseのみ）。
MQTTを使ってサーバーとEMQXを連携する際、データのスループットと信頼性を向上させるには？
アプリケーションサービスがMQTTプロトコルでEMQXと連携する場合、各クライアントは高負荷を処理します。クライアント性能を最大限に活用し、システムの可用性を確保するため、以下のベストプラクティスを推奨します：
- メッセージのサブスクライブとパブリッシュを分離する：単一クライアントがパブリッシャーとサブスクライバーの両方を兼ねることを避ける。
- 共有サブスクリプションを利用する：メッセージ受信には共有サブスクリプションを優先し、業務シナリオやメッセージ量に応じてサブスクライバー数を設定する。
- 複数クライアントでメッセージをパブリッシュする：業務ニーズやメッセージ量に応じてパブリッシュ用クライアント数を設定し、ロードバランス戦略を実装する。
基本原則は単一クライアントのメッセージ負荷を軽減することです。複数チャネルでMQTTと連携することで、全体のメッセージスループット性能を向上させ、システムの高可用性を実現できます。