はじめに

MQTT でグループチャットを実現する方法について考えてみます。

基礎知識

MQTT とは

MQTT (Message Queue Telemetry Transport の略称) とは、publish/subscribe パターンに基づく軽量なメッセージングプロトコルです。TCP、TLS over TCP、WebSocket 上で動作します。MQTT は制限されたネットワーク帯域でも小さなコードフットプリントで動作するよう設計されています。

MQTT プロトコルの詳細は、参考資料で詳しく解説されているのでここでは触れません。

publish/subscribe パターンとは

publish/subscribe パターンでは、メッセージの送信者 (publisher、出版者) が特定の受信者 (subscriber、購読者) に直接メッセージを送信しないようにプログラムされています。このパターンでは、message broker (メッセージの仲介役) が必要になります。message broker は、メッセージの「トピック」に関心のあるクライアントにメッセージを配信する責任をもっています。

基本的には publisher と subscriber がクライアント、message broker がサーバで動作することになります。これ以降、publisher/subscriber を MQTT クライアントと呼ぶことにします。

考察

MQTT の利用例

少し前に Facebook が Beluga というグループチャットアプリを開発していた企業を買収しましたが、その目的は Facebook で行われるチャットを Beluga で使われていた MQTT ベースのインフラに置き換え、チャットをもっと快適に行えるようにすることでした。

MQTT プロトコルを使わずとも、HTTP/HTTPS などでも同様なことは実現可能です。しかし、MQTT はプロトコルのオーバーヘッドが非常に小さく、接続指向のプロトコルなので大量の接続からのちょっとしたデータを低遅延・小消費電力でリアルタイムにやりとりするのに向いています。

うまくやれば、Facebook Messenger のように超大規模チャットを支えることができるプロトコルというわけです。また、IoT を支える技術としても注目されています。

IBM の資料によると、HTTP に比べるとトラフィックが 1/10 〜 1/100 で済み、電池の消費量が 1/10 以下になるとのことです。HTTPS だとトラフィック量に比例して SSL/TLS の暗号化・復号化のオーバーヘッドが大きくなるので、さらに電池の消費量が減りそうに思えます。

MQTT クライアントの機能

基本的には以下の５つの機能しかありません。

MQTT broker に接続する
MQTT broker から切断する
メッセージを publish する
購読を開始する
購読を終了する

グループチャットクライアントを実装しようとした場合、ユーザ管理やグループ管理などは別途容易する必要があることが分かります。

MQTT broker の機能

先ほど「ユーザ管理やグループ管理などは別途容易する必要がある」と述べました。例えば MQTT broker の実装である「RabbitMQ」は、コマンドラインツールや RabbitMQ Management HTTP API でユーザの管理を行うことができます。しかし、グループチャットを実装しようとするとユーザごとのコンタクトリストの管理なども必要なのでこれだけでは限界がありますし、RabbitMQ Management HTTP API 自体は RabbitMQ の持つ機能にフルアクセスができてしまうのでよろしくありません。

となると、グループチャットサービスサーバを別途用意し、そこから RabbitMQ Management HTTP API を呼び出して MQTT レベルのユーザ管理や権限管理を行い、足りない機能はグループチャットサービスサーバで別途実装する、というのが現実的だと思います。

MQTT でグループチャット ことはじめ