すべてのプロダクト
Search

このプロダクト

    ApsaraMQ for MQTT:リアルタイムコミュニケーションソリューション (MQTT)

    ドキュメントセンター

    ApsaraMQ for MQTT:リアルタイムコミュニケーションソリューション (MQTT)

    最終更新日:Jan 14, 2025

    リアルタイムコミュニケーションソリューションは、Alibaba Cloud ApsaraMQ for MQTT Alibaba CloudとAlibaba Real-Time Communication RTCが共同で立ち上げた製品であり、オンライン音声ビデオ会議や1対1の音声通話アプリケーションなど、さまざまなリアルタイムコミュニケーションシナリオを迅速に構築するのに役立ちます。このトピックでは、システムアーキテクチャ、データフロー設計、および関連する注意事項について詳しく説明します。

    用語

    • メッセージキューイングテレメトリトランスポート (MQTTプロトコル)

      • MQTTプロトコルは、モノのインターネット (IoT) およびモバイルインターネット向けの業界標準プロトコルであり、モバイルデバイス間のデータ送信に適しています。ApsaraMQ for MQTT MQTTプロトコルはデフォルトでサポートされています。

    • MQTTブローカー

      • ApsaraMQ for MQTT MQTTブローカーは、MQTTクライアントとApsaraMQ for RocketMQ との間でやり取りを行い、それぞれのメッセージの送受信を行うサーバーノードとして使用されます。

    • MQTTクライアント

      • MQTTクライアントは、MQTTブローカーと対話するために使用されるノードです。このソリューションでは、具体的には、音声/ビデオ通話のリクエストを送受信する音声/ビデオモバイルアプリケーションを指します。

    • P2Pメッセージ

      • ApsaraMQ for MQTT 標準MQTTプロトコルに基づいて提供される特殊なタイプのメッセージです。このタイプのメッセージは、サブスクリプションのマッチングなしで、指定されたターゲットMQTTクライアントに直接送信できます。詳細については、「P2Pメッセージングモデル (MQTT)」をご参照ください。

    • リアルタイムコミュニケーション (RTC)

      • 音声およびビデオ分野向けのリアルタイムネットワーク通信方法です。現在、主流のユースケースには、音声通話、ビデオ通話、ビデオ会議などがあります。

    • RTCサーバー

      • このサーバーは、Alibaba Cloud RTCによって提供される音声/ビデオおよび関連メディアチャネルサービスをホストします。

    • RTCサービス管理サーバー

      • これらのサーバーは、音声/ビデオ通信システムの制御ノードであり、このトピックでは音声/ビデオ管理サービスと呼ばれます。RTC管理サービスは手動で作成する必要があり、すべてのRTCセッションのライフサイクルを制御します。管理ノードは通常クラウドにデプロイされ、Alibaba Cloud製品を使用して構築されます。

    • 音声/ビデオモバイルアプリケーション

      • これは、音声/ビデオ通信システムでエンドユーザーが使用する端末上のアプリケーションであり、このトピックでは端末アプリケーションと呼ばれます。ユーザーはこのアプリケーションを使用して、音声/ビデオ通話を開始または参加します。

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

    ソリューションアーキテクチャは、音声/ビデオコミュニケーションソリューションのアーキテクチャを示しています。

    図 1. ソリューションアーキテクチャSolution architecture

    ソリューションアーキテクチャに示すように、音声/ビデオ管理サービスと端末アプリケーションは、AliwareMQ for RocketMQを使用してシグナルを送信し、Alibaba Cloud RTCを介してサービスデータの相互作用を実装します。詳細については、「データの相互作用」をご参照ください。

    ハイライト

    音声/ビデオコミュニケーションソリューションの利点は次のとおりです。

    • サービス機能はスケーラブルです。

      • ApsaraMQ for MQTTとAlibaba Cloud RTCはオンデマンドで使用でき、バーストトラフィックのピークを処理するために動的にスケールアップできます。

    • ネットワークカバレッジは広範囲です。

      • ApsaraMQ for MQTTとAlibaba Cloud RTCはグローバルデプロイ機能を提供し、ローカルサービスアクセスを実現し、ゾーン間および国間の費用を節約します。

    • 構築期間は短く、容易なアクセスをサポートします。

      • 構築プロセスはO&M不要で、労力とハードウェアのコストを削減します。

      • APIは使いやすく、迅速な実装をサポートします。

    • 高信頼性

      • すべてのサービスノードは高可用性で安定しています。

      • ApsaraMQ for MQTTはSSL/TLS暗号化をサポートし、メディアストリームはSRTP保護をサポートします。

    データの相互作用

    データフロー プレゼンテーションは、ApsaraMQ for MQTTとReal-Time Communication RTCに基づいて音声/ビデオ会議を呼び出す方法を示しています。灰色の部分は、独自に構築した開発プログラムまたはサービスを示しています。青い部分は、ApsaraMQ for MQTT、ApsaraMQ for RocketMQ、およびReal-Time Communication RTCサービスを示しています。

    図 2. データフローData flows

    データフローに示すように、ユーザーAはユーザーBを音声/ビデオ会議への参加に招待します。具体的なプロセスは次のとおりです。

    1. 端末アプリケーションのユーザーAが会議リクエストを開始し、MQTTメッセージを送信することでリクエストをMQTTブローカーに送信します。メッセージは ApsaraMQ for MQTT 経由で ApsaraMQ for RocketMQ にルーティングされます。ビジネス側で開発された音声/ビデオ管理サービスは、メッセージを受信することで会議リクエストを処理します。検証後、Alibaba Cloud RTC API Real-Time Communication を呼び出して、この通信のリソースとパラメーターを登録します。

    2. パラメーターを受信した後、音声/ビデオ管理サービスはパラメーターを招待メッセージにカプセル化し、ApsaraMQ for RocketMQに送信します。ApsaraMQ for MQTT を経由した後、メッセージはユーザーAの端末アプリケーションに配信されます。ユーザーAの端末アプリケーションは、パラメーターに基づいて会議チャネルに追加されます。

    3. 音声/ビデオ管理サービスは、ユーザーAの招待状の情報に基づいてユーザーBの情報を見つける必要もあります。同様に、サービスはパラメーターを招待メッセージにカプセル化し、ユーザーBの転送プロセスは 手順 2 で説明したユーザーAの転送プロセスと同じです。

    4. 会議メンバーのユーザーBは、パラメーターを受信した後に会議に参加し、通信の初期化が完了します。

    上記の設計アイデアに基づいて、ApsaraMQ for MQTT を使用して、メッセージを送信するための他のカスタムプロセスを実装できます。たとえば、会議の破棄、会議への他のユーザーの招待、スピーチのブロックなどが可能です。ApsaraMQ for MQTT は、音声/ビデオ会議シナリオでシグナリングの役割を果たします。

    注意事項

    上記のプロセスでは、ApsaraMQ for MQTTとReal-Time Communication RTCを使用して独自のオーディオおよびビデオ通話アプリを迅速に構築する方法について簡単に説明しました。SDKの説明の詳細については、「ApsaraMQ for MQTT」、「ApsaraMQ for RocketMQ」、およびReal-Time Communication (RTC)ドキュメントをご参照ください。

    ApsaraMQ for MQTT を使用してリアルタイムコミュニケーションのシグナリングチャネルを構築する場合、メッセージタイプとパラメーター設計について次の原則に従ってください。

    • MQTTクライアントIDのマッピング

      MQTTプロトコルでは、各クライアントにグローバルに一意のクライアントIDが必要です。クライアントIDは、@@@セパレーターで連結された2つの部分で構成されます。最終的なクライアントIDは一意である必要があり、全長は64文字を超えることはできません。クライアントIDの2つの部分について以下に説明します。

      • プレフィックスグループID：グループIDは、ApsaraMQ for MQTT コンソールで申請する必要があります。トラブルシューティングを容易にするために、アプリケーションプラットフォームまたはチャネル別にグループIDを分類することをお勧めします。たとえば、AndroidクライアントとiOSクライアントを異なるグループIDに分割したり、異なるバージョンのクライアントで異なるグループIDを使用したりできます。

      • クライアントIDのサフィックスであるデバイスID：デバイスIDはアプリケーションによって生成されます。デバイスIDはアプリケーションアカウントIDにマッピングして、グローバルに一意であることを保証できます。

      クライアント ID の詳細については、「用語」をご参照ください。

    • トピック名のマッピング

      ApsaraMQ for MQTT を使用してメッセージを送受信するには、MQTTプロトコルのパブリッシュ/サブスクライブパターンを理解する必要があります。詳細については、契約文書と公式ドキュメントを参照してください。

      MQTTプロトコルは、パブリッシュ/サブスクライブパターンに基づくメッセージプロトコルです。サブスクリプションとトピックは、ディレクトリツリー形式に従います。トピックは、親トピックとサブトピックに分割できます。親トピックとサブトピックを含むトピックの全長は、64文字を超えることはできません。トピックのタイプについて以下に説明します。

      • 親トピック：ディレクトリツリーの第1レベルにあるトピックは親トピックです。親トピックは、ApsaraMQ for MQTT コンソールで権限を申請した後にのみ使用できます。名前空間は名前空間に相当します。

      • サブトピック：MQTTのディレクトリツリーのレベル1トピックの下にあるトピックはサブトピックです。サブトピックは、申請することなく必要に応じて指定できます。

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

      メッセージの送受信用のトピックを設計する場合は、次の原則に従う必要があります。

      • アップストリームメッセージ (端末アプリケーションから管理サービスに送信されるメッセージ) とダウンストリームメッセージ (管理サービスから端末アプリケーションに送信されるメッセージ) には、異なる親トピックが使用されます。

      • 優先順位が異なるメッセージまたはサイズが大きく異なるメッセージには、異なる親トピックが使用されます。

      上記の相互作用プロセスでは、ApsaraMQ for MQTT P2Pメッセージを使用することをお勧めします。P2Pメッセージはサブスクライブする必要がなく、送信者は受信するピアエンドを直接指定できます。詳細については、「P2Pメッセージングモデル (MQTT)」をご参照ください。

    • メッセージの送受信のためのパラメーター設計

      モバイルアプリケーションはバックグラウンドで強制終了される可能性があり、モバイルアプリケーションがオフラインになる可能性があります。この状況に対処するために、端末アプリケーションがオンラインに戻った後に前のメッセージを受信できるように、端末アプリケーションを次のように構成することをお勧めします。

      • CleanSession パラメーターを「false」に設定します。

      • QoSを「1」に設定します。

      端末アプリケーションは、受信したメッセージに対して重複排除と適時性検証を実行する必要があります (たとえば、端末アプリケーションが1日以上オフラインのままで、オンラインに戻ったときに前の日のメッセージを受信した場合など)。

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