Options d'hébergement d'un broker MQTT comparées : VPS, Kubernetes, serverless, dédié et BYOC

L'hébergement d'un broker MQTT va du simple serveur virtuel que vous configurez vous-même jusqu'au broker MQTT managé qui tourne dans votre propre compte cloud. Ce comparatif passe en revue les cinq options courantes, montre le travail réel qu'implique chacune et se termine par une checklist qui vous aide à choisir la bonne option pour votre projet aujourd'hui, sans bloquer son évolution de demain.

Les cinq options courantes d'hébergement d'un broker MQTT

1. Auto-hébergé sur un VPS ou un serveur on-premise, généralement avec Mosquitto.
2. Auto-hébergé sur Kubernetes, avec un broker open source en conteneurs.
3. Serverless managé, un broker mutualisé multi-tenant que vous consommez comme un service.
4. Dédié managé, un cluster de broker isolé exploité par un fournisseur.
5. BYOC (bring your own cloud), un broker exploité par le fournisseur mais qui tourne dans votre propre compte cloud.

Une sixième variante, un logiciel éditeur que vous installez et exploitez vous-même sous licence entreprise, se situe entre les options 1 et 5.

Comparatif côte à côte

Option 1 : VPS ou on-premise avec Mosquitto

Eclipse Mosquitto est léger, bien documenté et facile à prendre en main. Une configuration minimale pensée pour la production, avec TLS et authentification par mot de passe, ressemble à ceci :

# /etc/mosquitto/conf.d/production.conf
per_listener_settings true

listener 8883
certfile /etc/letsencrypt/live/mqtt.example.com/fullchain.pem
keyfile  /etc/letsencrypt/live/mqtt.example.com/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd

listener 8084
protocol websockets
certfile /etc/letsencrypt/live/mqtt.example.com/fullchain.pem
keyfile  /etc/letsencrypt/live/mqtt.example.com/privkey.pem
allow_anonymous false
password_file /etc/mosquitto/passwd

sudo apt install -y mosquitto mosquitto-clients
sudo mosquitto_passwd -c /etc/mosquitto/passwd device01
sudo systemctl restart mosquitto

Cela suffit pour démarrer. Ce que l'on sous-estime, c'est le travail continu : renouveler les certificats et recharger le broker, appliquer les mises à jour de sécurité de l'OS et du broker, surveiller le disque et la mémoire, augmenter les limites de descripteurs de fichiers, sauvegarder le fichier de mots de passe, gérer les tentatives de connexion par force brute et prévoir ce qui se passe quand l'unique serveur tombe en panne.

Avantages : contrôle total, faible coût direct, fonctionne hors ligne sur un réseau local. Inconvénients : c'est vous l'équipe d'astreinte ; un seul serveur est un point de défaillance unique ; la sécurité repose entièrement sur vous.

Option 2 : Kubernetes

Si votre organisation exploite déjà Kubernetes, y déployer un broker semble naturel. Vous bénéficiez d'une configuration déclarative, de mises à jour progressives (rolling updates) et d'une intégration avec la supervision existante.

Le piège, c'est que MQTT est un protocole à état reposant sur des connexions de longue durée, alors que Kubernetes excelle avec des services requête-réponse sans état. Il vous faut un équilibrage de charge TCP plutôt qu'un ingress HTTP, des pod disruption budgets soigneusement réglés pour que les rolling updates ne déconnectent pas tous les clients en même temps, des volumes persistants si vous voulez la persistance de session, et une bonne compréhension du comportement de votre broker quand les pods sont replanifiés. Notre guide broker MQTT sur Kubernetes détaille ces points.

Avantages : s'intègre à l'outillage de plateforme existant, infrastructure as code, contrôle total. Inconvénients : expertise opérationnelle importante requise ; il est facile de provoquer des tempêtes de reconnexions perturbatrices lors d'opérations de routine.

Option 3 : serverless managé

Un broker serverless est le moyen le plus rapide d'obtenir un endpoint sécurisé. Vous vous inscrivez, créez un broker et recevez un nom d'hôte, des ports et des identifiants. Le fournisseur exploite un cluster mutualisé multi-tenant et applique des quotas par plan pour isoler les clients entre eux.

Les plans Serverless de ConnectMQ en sont un exemple :

• Serverless (Free) : jusqu'à 25 connexions, QoS jusqu'à 1, messages de 256 Ko.
• Serverless (Paid) : jusqu'à 1 000 connexions, QoS 2, messages de 1 Mo, shared subscriptions.

Les deux prennent en charge MQTT 3.1.1 et 5.0 sur TCP 1883, TLS 8883, WebSocket 8083 et Secure WebSocket 8084 avec le chemin /mqtt, avec un certificat Let's Encrypt déjà en place. La connexion se fait comme avec n'importe quel broker :

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID \
  -t "acme/#" -v -V mqttv5

Avantages : démarrage en quelques minutes, aucun serveur, sécurité par défaut prise en charge, outils du portail inclus. Inconvénients : infrastructure partagée, limites de plan fixes, moins de contrôle sur l'emplacement et le réglage fin.

Pour en savoir plus, lisez broker MQTT serverless.

Option 4 : dédié managé

Un déploiement dédié vous fournit un cluster de broker isolé qu'aucun autre client n'utilise, toujours exploité par le fournisseur. Il convient aux systèmes de production où vous voulez des performances prévisibles, non affectées par d'autres clients, et dont la charge a dépassé les limites des plans mutualisés. Vous décrivez le nombre de connexions attendu, les débits de messages et la taille des payloads, et le déploiement est dimensionné en conséquence.

Avantages : isolation, exploitation assurée par le fournisseur, dimensionnement adapté à votre charge. Inconvénients : coût plus élevé que les plans mutualisés ; la mise en place prend plus de temps qu'une inscription en libre-service.

Consultez broker MQTT dédié pour les détails.

Option 5 : BYOC

Avec le modèle bring your own cloud, le broker tourne dans votre propre compte cloud, sous votre facturation, vos contrôles réseau et vos politiques de sécurité, tandis que le fournisseur le déploie et l'exploite. Ce modèle convient aux organisations soumises à des exigences strictes de contrôle des données ou disposant d'un vaste parc cloud où se trouvent déjà les consommateurs.

Avantages : votre infrastructure et votre chemin de données, exploitation assurée par le fournisseur, placement à côté de vos autres systèmes. Inconvénients : vous payez la facture cloud et devez accorder et encadrer l'accès du fournisseur ; davantage de coordination lors de la mise en place.

Notre article broker MQTT BYOC explique le modèle et la préparation du compte qu'il nécessite.

Ce qu'aucune option ne change

Quel que soit le modèle d'hébergement choisi, certaines choses restent de votre ressort :

• Le firmware des appareils, la logique de reconnexion et la mise en mémoire tampon locale.
• La conception de l'espace de noms des topics.
• Les formats de payload et leur validation.
• Le stockage de l'historique et l'intégration avec d'autres systèmes, généralement via un service abonné, Node-RED ou Telegraf connecté en tant que client MQTT.
• Le choix des niveaux de QoS par type de message.

Comme MQTT est un standard, passer d'un modèle d'hébergement à un autre revient surtout à changer un nom d'hôte et des identifiants sur vos clients, à condition d'éviter les extensions propriétaires.

Comment choisir : une checklist d'hébergement

Répondez à ces questions dans l'ordre. La première qui s'applique clairement détermine généralement le modèle d'hébergement.

1. S'agit-il d'un exercice d'apprentissage ou d'une démo ? Utilisez le serveur MQTT public gratuit et passez complètement l'étape de l'hébergement, en le réservant aux tests et jamais aux données de production.
2. Le broker doit-il fonctionner sur un réseau local sans Internet ? Auto-hébergez-le on-premise, ou envisagez une option entreprise auto-gérée.
3. Les données doivent-elles rester dans des comptes cloud qui vous appartiennent ? Choisissez BYOC.
4. Avez-vous besoin d'isolation vis-à-vis des autres clients ou d'un dimensionnement au-delà des plans mutualisés ? Choisissez un déploiement dédié.
5. Exploitez-vous déjà Kubernetes et voulez-vous le broker sur la même plateforme ? Auto-hébergez-le sur Kubernetes, en acceptant la charge opérationnelle.
6. Sinon : commencez avec du serverless managé, puis montez en gamme à mesure que les connexions et les exigences augmentent.

Évaluez aussi le coût total, pas seulement le prix mensuel. Le temps d'ingénierie consacré aux correctifs, au renouvellement des certificats, à la gestion des incidents et aux mises à jour est un coût réel des options auto-hébergées. Le coût total de possession d'un broker MQTT et broker MQTT auto-hébergé ou managé approfondissent cette comparaison, et le guide broker MQTT cloud en donne la vue d'ensemble.

La place de ConnectMQ

ConnectMQ couvre la partie managée de ce tableau : Serverless (Free et Paid) pour démarrer vite et accompagner des flottes en croissance, Dedicated pour des clusters isolés, BYOC pour des brokers dans votre propre compte cloud, et Self Managed Enterprise pour les organisations qui doivent l'exploiter elles-mêmes. Toutes ces offres parlent le même MQTT standard : vous pouvez donc commencer petit et évoluer d'une option à l'autre sans repenser vos appareils.

Hébergez votre broker MQTT sur ConnectMQ

Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, et connectez votre premier appareil en quelques minutes. Quand vous avez besoin d'isolation ou de maîtriser l'endroit où tourne le broker, parlez à l'équipe des offres Dedicated ou BYOC. Si vous préférez d'abord une introduction plus générale, lisez notre article sur le choix d'un broker MQTT managé.

Questions fréquentes

Quelle est la façon la moins chère d'héberger un broker MQTT ?

Un plan managé gratuit ou un petit serveur Mosquitto auto-hébergé représentent la dépense directe la plus faible. L'auto-hébergement ajoute votre propre temps pour les correctifs, les certificats et la supervision, ce qui dépasse souvent le coût du serveur.

Puis-je héberger Mosquitto sur un VPS en production ?

Oui, avec TLS, authentification, supervision et un plan pour les mises à jour et les pannes. De nombreuses équipes commencent ainsi et passent à un broker MQTT managé lorsque la charge opérationnelle augmente.

Kubernetes est-il un bon endroit pour exécuter un broker MQTT ?

Il peut l'être si votre équipe maîtrise déjà bien Kubernetes. Les connexions de longue durée de MQTT nécessitent un équilibrage de charge TCP et des rolling updates soignés pour éviter des reconnexions massives.

Quelle est la différence entre l'hébergement dédié et BYOC ?

Les deux vous offrent un broker isolé exploité par le fournisseur. Le dédié tourne sur l'infrastructure du fournisseur, tandis que BYOC tourne dans votre propre compte cloud.