# Feature FAQs

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

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

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

EMQX Enterpriseはデータのパーシステンスをサポートしています。詳細は[データ統合](../develop/data-integration/data-bridges.md)をご参照ください。

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

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

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

はい。**EMQX Enterprise**の[データ統合](../develop/data-integration/data-bridges.md)を通じて、KafkaやRabbitMQなどのメッセージキューにメッセージを転送できます。

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

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

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

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

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

共有サブスクリプションは、パブリッシャーが多くサブスクライバーが少ないデータ収集シナリオで有効です。詳細は[共有サブスクリプション](messaging/mqtt-shared-subscription.md)をご覧ください。

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

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

システムトピックの詳細な紹介は[こちら](../guides/observability/mqtt-system-topics.md)をご参照ください。

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

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

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

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

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

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

認可の詳細は[こちら](../guides/access-control/authz/authz.md)をご覧ください。

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

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

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

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

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

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

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

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

はい。EMQXは[コマンドラインインターフェース](../guides/cli.md#clients)の`emqx_ctl clients kick <Client ID>`や[REST API](https://docs.emqx.com/en/emqx/v5.8/admin/api-docs.html)の`DELETE /clients/{clientid}`を提供しており、ユーザーが手動でMQTT接続をキックできます。Dashboardのクライアントページからも操作可能です。

REST APIの詳細は[EMQX Enterprise API](https://docs.emqx.com/en/enterprise/v6.3/admin/api-docs.html)をご覧ください。

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

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

- [WebHook](../develop/data-integration/data-bridge-webhook.md)を利用してオンライン・オフラインイベントメッセージを外部HTTPサービスに転送する。
- MQTTクライアントで[システムトピック](../guides/observability/mqtt-system-topics.md)をサブスクライブし、オンライン・オフライン通知を取得する。
- [ルールエンジン](../develop/data-integration/rules.md)で`client.connected`および`client.disconnected`イベントを監視し、[データ統合](../develop/data-integration/data-bridges.md)と連携してイベントメッセージを指定データベースに書き込む。（EMQX Enterpriseのみ）

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

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

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

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