リアルタイム通信ソリューション - ApsaraMQ for MQTT - Alibaba Cloud ドキュメントセンター

ApsaraMQ for MQTT と Alibaba Cloud Real-Time Communication (RTC) を組み合わせることで、オンライン会議、1対1の音声通話、ビデオ会議などのリアルタイム音声・ビデオアプリケーションの基盤を構築できます。ApsaraMQ for MQTT はシグナリングチャネル (通話招待、セッション制御) を処理し、RTC はメディアストリーム (音声およびビデオデータ) を伝送します。

ソリューションアーキテクチャ

以下の図は、システム内でのシグナリングとメディアのフローを示しています。

2つの通信パスが並行して実行されます。

シグナリングパス：端末アプリケーションは、ApsaraMQ for MQTT を介して通話制御メッセージを送受信します。これらのメッセージは ApsaraMQ for RocketMQ を経由して音声/ビデオ管理サービスにルーティングされます。
メディアパス：シグナリングによってセッションが確立されると、音声およびビデオデータは Alibaba Cloud RTC サーバーを介して流れます。

メリット	詳細
弾性スケーリング	ApsaraMQ for MQTT と RTC はどちらも、トラフィックスパイクに対応するためにオンデマンドでスケーリングします。
グローバルリーチ	ローカルアクセスポイントを備えたグローバルデプロイメントにより、クロスリージョンおよび国際通信コストを削減します。
迅速な統合	フルマネージドサービスにより、インフラストラクチャのセットアップや継続的な運用保守が不要になり、人件費とハードウェアコストを削減できます。使いやすい API が迅速な実装をサポートします。
エンドツーエンドのセキュリティ	ApsaraMQ for MQTT は SSL/TLS 暗号化をサポートしています。メディアストリームは SRTP によって保護されます。
高信頼性	すべてのサービスノードは高可用性で安定しています。

通話設定シーケンス

以下の図は、ユーザー A がユーザー B を通話に招待する際のデータフローを示しています。

ユーザー A が通話リクエストを送信します。 端末アプリケーションは MQTT メッセージをブローカーにパブリッシュします。ApsaraMQ for MQTT は、メッセージを ApsaraMQ for RocketMQ を経由して音声/ビデオ管理サービスにルーティングします。
管理サービスがセッションを登録します。 リクエストを検証した後、サービスは Alibaba Cloud RTC API を呼び出して、この通信のためのリソースとパラメーターを登録します。
ユーザー A がセッションパラメーターを受信します。 管理サービスはパラメーターを招待メッセージにパッケージ化し、ApsaraMQ for RocketMQ に送信します。そして ApsaraMQ for MQTT がそれをユーザー A の端末アプリケーションに配信します。ユーザー A はこれらのパラメーターを使用して会議チャネルに参加します。
ユーザー B が招待を受信します。 管理サービスはユーザー A のリクエストからユーザー B の情報を検索し、セッションパラメーターを招待メッセージにパッケージ化します。メッセージは同じ ApsaraMQ for MQTT パスを通じてユーザー B に配信されます。
ユーザー B が通話に参加します。 ユーザー B の端末アプリケーションが会議チャネルに参加します。これで通話が確立されます。

ApsaraMQ for MQTT はシグナリングチャネルとして機能します。会議の終了、通話中の参加者の追加招待、参加者のミュートなど、追加のワークフローを実装するには、同じメッセージベースのパターンを使用します。

クライアント ID の設計

すべての MQTT クライアントは、グローバルに一意のクライアント ID を持つ必要があります。クライアント ID は 2 つの部分で構成され、@@@ という区切り文字で結合されます。

<GroupID>@@@<DeviceID>

全長は 64 文字を超えてはなりません。

部分	ソース	ガイドライン
グループ ID (プレフィックス)	ApsaraMQ for MQTT コンソールで登録します。	プラットフォームやチャネルごとに個別のグループ ID を割り当てます (例：Android クライアント用と iOS クライアント用にそれぞれ割り当てる)。これにより、トラブルシューティングが簡素化され、プラットフォーム固有の権限付与が可能になります。
デバイス ID (サフィックス)	アプリケーションによって生成されます。	各デバイス ID をアプリケーションアカウント ID にマッピングして、グローバルな一意性を保証します。

詳細については、「用語」をご参照ください。

トピック名の設計

MQTT はパブリッシュ/サブスクライブモデルを使用します。トピックは、親トピックとサブトピックを持つ階層的なディレクトリツリー構造に従います。トピックの全長 (すべてのレベルを含む) は 64 文字を超えてはなりません。

レベル	登録	説明
親トピック	ApsaraMQ for MQTT コンソールで登録します。	階層の第1レベルのトピック。名前空間に相当します。
サブトピック	登録は不要です。	親トピックより下の任意のレベル。必要に応じてサブトピックを自由に定義します。

トピック設計の原則

アップストリームとダウンストリームのトラフィックを分離する。 端末アプリケーションから管理サービスに送信されるメッセージ (アップストリーム) と、管理サービスから端末アプリケーションに送信されるメッセージ (ダウンストリーム) には、異なる親トピックを使用します。
優先度またはサイズで分離する。 優先度が異なるメッセージや、ペイロードサイズが著しく異なるメッセージには、異なる親トピックを割り当てます。これにより、大きなペイロードが時間的制約の厳しいシグナリングメッセージをブロックするのを防ぎます。
直接的なシグナリングには P2P メッセージを使用する。 上記の通話設定フローでは、P2P メッセージが最適です。送信者がターゲットクライアントを直接指定するため、サブスクリプションは不要です。詳細については、「P2P メッセージングモデル」をご参照ください。

トピックの詳細については、「用語」および「MQTT 3.1.1 仕様」をご参照ください。

モバイルクライアントのメッセージパラメーター設定

モバイルアプリケーションは、バックグラウンドで実行中に OS によって頻繁に強制終了され、MQTT クライアントがオフラインになることがあります。クライアントが再接続後に未受信のメッセージを確実に受信できるように、以下のパラメーターを設定してください。

パラメーター	値	理由
CleanSession	`false`	永続セッションを設定すると、クライアントがオフラインの間、ブローカーはサブスクリプションと未配信の QoS 1/2 メッセージを保存します。クライアントが再接続すると、ブローカーはキュー内のメッセージを自動的に配信します。これにより、再サブスクライブのオーバーヘッドを回避し、通話招待の受信漏れを防ぎます。
QoS	`1`	QoS 1 (少なくとも1回の配信) は、各メッセージが少なくとも1回クライアントに到達することを保証します。ブローカーが確認応答を受信しない場合、メッセージを再送します。QoS 0 (最大1回) では、通話招待が完全に失われるリスクがあります。QoS 2 (厳密に1回) は、4ステップのハンドシェイクを追加するため、レイテンシーが増加しますが、アプリケーション側で重複排除を処理するため、シグナリングにとって有益な利点はありません。

注：CleanSession を false に設定する場合、クライアント ID は再接続後も安定している必要があります。クライアント ID が変更されると、ブローカーはその接続を新しいセッションとして扱い、キュー内のメッセージは失われます。

重複の処理

QoS 1 では、メッセージが複数回配信される可能性があります。例えば、確認応答が転送中に失われた場合などです。これが発生するシナリオは2つあります。

PUBLISH パケットがブローカーに到達しなかったため、クライアントが再送する。
PUBLISH パケットはブローカーに到達したが、PUBACK がクライアントに到達する前に失われたため、クライアントが再送する。

重複を処理するには、メッセージペイロードに一意のメッセージ ID またはタイムスタンプを含めます。端末アプリケーションは、受信メッセージの重複を排除し、適時性を検証する必要があります。クライアントが1日以上オフラインだった後に受信した招待など、定義されたしきい値よりも古い通話招待は破棄してください。

CleanSession と QoS の詳細については、「用語」をご参照ください。

基本概念

用語	定義
MQTT プロトコル	Message Queuing Telemetry Transport の略。軽量なデータ伝送に最適化された、業界標準の IoT およびモバイルインターネットプロトコルです。ApsaraMQ for MQTT はデフォルトで MQTT をサポートしています。
MQTT ブローカー	MQTT クライアントと ApsaraMQ for RocketMQ の間でメッセージをルーティングするサーバーノード。このソリューションでは、ApsaraMQ for MQTT が MQTT ブローカーとして機能します。
MQTT クライアント	MQTT ブローカーに接続してメッセージを送受信するノード。このソリューションでは、各 MQTT クライアントは音声/ビデオモバイルアプリケーションです。
P2P メッセージ	標準 MQTT に対する ApsaraMQ for MQTT の拡張機能。P2P メッセージは、サブスクリプションのマッチングなしで、指定されたターゲットクライアントに直接配信されます。詳細については、「P2P メッセージングモデル」をご参照ください。
RTC	Real-Time Communication の略。音声およびビデオのためのリアルタイムネットワーク通信方式です。一般的なユースケースには、音声通話、ビデオ通話、ビデオ会議などがあります。
RTC サーバー	Alibaba Cloud RTC が提供する音声/ビデオメディアチャネルサービスをホストします。
音声/ビデオ管理サービス	Alibaba Cloud プロダクトを使用して構築し、クラウドにデプロイする制御サービス。すべての RTC セッションのライフサイクルを管理します。
端末アプリケーション	音声/ビデオ通話を開始または参加するために使用されるエンドユーザー向けモバイルアプリケーション。

次のステップ

ApsaraMQ for MQTT SDK：ご利用のプラットフォーム用の MQTT クライアント SDK をダウンロードします。
ApsaraMQ for RocketMQ SDK：バックエンドのメッセージルーティングサービスを統合します。
Alibaba Cloud RTC ドキュメント：メディアチャネルをセットアップし、音声/ビデオパラメーターを設定します。