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はExProtoゲートウェイを提供しており、ユーザーはJava、Python、Goなど慣れ親しんだプログラミング言語でgRPCサービスを開発し、デバイスで使用されるカスタマイズされたプロトコルを解析し、デバイス接続、認証、メッセージ送信などの機能を容易に実現できます。
詳細はExProtoプロトコルゲートウェイをご覧ください。
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接続を手動で切断できます。また、ダッシュボードのクライアントページからも操作可能です。
REST APIの詳細な使い方はEMQX Enterprise APIをご参照ください。
デバイスのオンライン・オフラインイベントを監視したいのですが、どうすればよいですか?
EMQXはデバイスのオンライン・オフラインイベントを監視するために以下の3つの方法を提供しています:
- WebHookを使ってオンライン・オフラインイベントメッセージを外部HTTPサービスに転送する。
- MQTTクライアントでシステムトピックをサブスクライブしてオンライン・オフライン通知を取得する。
- ルールエンジンで
client.connectedおよびclient.disconnectedイベントを監視し、データ統合と連携してイベントメッセージを指定のデータベースに書き込む。(EMQX Enterpriseのみ)
MQTTを使ってサーバーとEMQXを統合する際に、データのスループットと信頼性を向上させるには?
アプリケーションサービスがMQTTプロトコルでEMQXと統合する場合、各クライアントは通常高負荷を処理します。クライアント性能を最大限に活用し、システムの可用性を確保するために、以下のベストプラクティスを推奨します:
- メッセージのサブスクライブとパブリッシュを分離する:単一クライアントがパブリッシャーとサブスクライバーの両方を兼ねることを避ける。
- 共有サブスクリプションを利用する:メッセージ受信には共有サブスクリプションを優先的に使用し、ビジネスシナリオやメッセージ量に応じてサブスクライバー数を設定する。
- 複数クライアントでメッセージをパブリッシュする:ビジネスニーズやメッセージ量に応じてパブリッシュ用クライアント数を設定し、ロードバランス戦略を実装する。
基本原則は単一クライアントのメッセージ負荷を減らすことです。複数チャネルでMQTTをやり取りすることで、全体のメッセージスループット性能を向上させ、システムの高可用性を実現できます。