MQTTは1000以上のクライアントでスケーラブルですか？

TCPソケットを介してペイロードを1日1回サーバーに送信するシナリオ IoTデバイス（現在はIPv4デバイス）。サーバーにはパブリックIPアドレスがあり、デバイスはルーター/ NATの背後にあります。ESP8266に基づくモジュール（つまり、Olimexのモジュール）を使用します

目標は、サーバーは、それが必要とする時はいつでも任意のクライアントにデータを送信することができるはずです。ホールパンチングのように、クライアントからクライアントへの直接通信（つまり、スマートフォンからデバイスに接続）には興味がありません。

その他の要件
IoTデバイスは数千まで成長する可能性があります。彼らのインターネット接続は、多くの4G対応ルーター/モデムによって提供されています。それぞれが10〜20のクライアントを処理します。

提案される解決策
私が理解している限り、一般的な解決策はMQTTです。クライアントは定期的にブローカー（ホスティングサーバーで実行されているMosquitto）にデータを送信します。ブローカーは同じサーバーで実行されているメインのWebアプリを更新します。

質問
MQTTアプローチは、4Gルーターの背後にある「多数」のデバイス（1000以上）に適していますか？

1,000クライアントは、適切なMQTTブローカーで簡単に処理できます。Scalagentのベンチマークでは、次の機能を備えたPCを示しています。

• 3 GHz Intel Core 2 Duoプロセッサ
• 4 GBのRAM

Mosquittoを実行している60,000の発行元を処理できます。これは、必要な1,000のパブリッシャーをはるかに超えているため、比較的弱いサーバーでも、必要な数を処理できるはずです。

他のいくつかのブローカーは、1,000万のパブリッシャーを処理すると主張しているHiveMQなど、さらに優れたパフォーマンスを（当然、それに応じてサーバーの能力もより高く）主張しています。

MQTTブローカーは通常、永続的な接続を想定しており、ping応答（またはその他のアクティビティ）を定期的に送信しないクライアントをタイムアウトします。公開後にネットワークから切断することもできますが、当然、切断すると何も受信できなくなります。

MQTTは、便利な「保持」メッセージの概念をサポートします。Webクライアントは、保持されたフラグを使用してトピックに何かを公開でき、このメッセージはブローカーによって保管されます。クライアントが再接続してトピックにサブスクライブするたびに、保持されたメッセージを受信します（数時間前に公開された場合でも）。保持されたメッセージは、クライアントがそのトピックにサブスクライブするたびに公開されるため、パッチ接続があり、クライアントが再接続するまでメッセージを保存する必要がある場合に役立ちます。

クライアントからの永続的なセッションを使用できます。たとえば、接続時にクリーンフラグをfalseに設定します。そのシナリオでは、クライアントがオフラインの場合、ブローカーはメッセージを独自のキャッシュにバッファーし、デバイスが接続すると配信します。

数量について-1台のサーバーでも、10Kは比較的少ない金額です。500Kのアクティブな接続を保持するようにLinuxサーバーを構成できます。ブローカーがクラウドベースになる場合、たとえばプロバイダーによってサービスとして提供される場合は、何百万ものアクティブな接続を保持できます。

ちなみに、Mosquittoやその他のローカルインストールは、開発とテストに最適な選択肢だと思いますが、本番環境に入るときは、HA、冗長性、フェイルオーバーなどのすべての機能を備えたSaaS MQTTブローカーが必要です。