Pourquoi le scaling MQTT est particulier
MQTT est centre sur des connexions longues. Un broker peut gerer des centaines de milliers de connexions, mais chaque connexion consomme des ressources.
Le scaling ne concerne pas seulement le debit, mais surtout le nombre de sessions, les retained et l’etat.
Commencer par le vertical
Un broker bien dimensionne sur une seule machine reste plus simple. Cela evite la complexite de la replication d’etat.
Optimisez limites de connexions, keep-alive et stockage retained avant de passer au cluster.
Strategies de clustering
Certains brokers utilisent le sharding, d’autres repliquent les sessions. Le choix influence latence et resilience.
Comprenez comment les subscriptions et retained sont partages entre noeuds, c’est souvent le goulot d’etranglement.
Persistance de session
Les sessions persistantes permettent aux clients de reprendre leurs subscriptions. En cluster, cela exige du stockage ou de la replication.
Tous les clients n’ont pas besoin de persistance. Faites le tri par criticite.
Bridging et sharding
Pour de grands deploiements, on peut shard par region ou client et relier via des bridges. Cela limite le blast radius.
Les bridges ajoutent latence et complexite. Utilisez-les pour l’isolation geo ou multi-tenant.
Observabilite
Surveillez le churn de connexions, le nombre de subscriptions, la taille des retained et le debit. Ces metriques prevoient la saturation.
Testez avec des comportements realistes, y compris des tempetes de reconnexion.
Modes de panne
Planifiez la panne d’un noeud. Que devient l’etat des sessions, les retained et les messages QoS 1/2 ?
Testez les procedures de failover et la capacite des clients a se reconnecter proprement.