Le SLA d'un broker MQTT est l'engagement écrit d'un fournisseur sur la disponibilité, et les petites lignes comptent autant que le pourcentage affiché. Cet article traduit les objectifs de disponibilité courants en minutes d'arrêt réelles, explique ce que les SLA couvrent et excluent habituellement, et montre comment concevoir vos appareils et applications pour qu'ils encaissent sans dommage l'indisponibilité que tout SLA autorise malgré tout.
Ce qu'est un SLA, et ce qu'il n'est pas
Un accord de niveau de service (SLA) est un document contractuel. Il définit un objectif mesurable, généralement la disponibilité mensuelle, la manière dont cette disponibilité est mesurée et ce que le fournisseur vous doit si l'objectif n'est pas atteint. Trois termes voisins sont souvent confondus :
- SLI (service level indicator) : la valeur mesurée, comme le pourcentage de tentatives de connexion réussies.
- SLO (service level objective) : l'objectif interne visé par une équipe, souvent plus strict que le SLA.
- SLA (service level agreement) : la promesse externe et contractuelle, assortie de conséquences, généralement des crédits de service.
Le point essentiel : un SLA n'empêche pas les pannes. Il définit le niveau d'indisponibilité acceptable et la compensation lorsqu'il est dépassé. Votre système doit quand même gérer l'indisponibilité que le SLA autorise.
Pourcentages de disponibilité en minutes d'arrêt
Les écarts entre les « neufs » sont plus importants qu'il n'y paraît. Le tableau utilise un mois moyen d'environ 30,4 jours et une année de 365 jours.
| Disponibilité | Arrêt par mois | Arrêt par an |
|---|---|---|
| 99 % | environ 7 heures 18 minutes | environ 3 jours 15,6 heures |
| 99,5 % | environ 3 heures 39 minutes | environ 1 jour 19,8 heures |
| 99,9 % | environ 43,8 minutes | environ 8,8 heures |
| 99,95 % | environ 21,9 minutes | environ 4,4 heures |
| 99,99 % | environ 4,4 minutes | environ 52,6 minutes |
| 99,999 % | environ 26 secondes | environ 5,3 minutes |
Passer de 99,9 % à 99,99 % divise par dix l'indisponibilité autorisée. Y parvenir exige de la redondance entre domaines de défaillance, une bascule automatique et une gestion rigoureuse des changements, c'est pourquoi les niveaux supérieurs sont généralement liés à une infrastructure dédiée et à des contrats entreprise.
Vous pouvez calculer ces valeurs vous-même :
def allowed_downtime(availability_pct, period_minutes):
return period_minutes * (1 - availability_pct / 100)
MONTH = 30.44 * 24 * 60
YEAR = 365 * 24 * 60
for a in (99.0, 99.5, 99.9, 99.95, 99.99, 99.999):
print(f"{a}%: {allowed_downtime(a, MONTH):.1f} min/month, "
f"{allowed_downtime(a, YEAR) / 60:.2f} h/year")
Ce que couvre habituellement le SLA d'un broker MQTT
La définition de l'indisponibilité
Lisez comment l'« indisponibilité » est définie. Pour un broker, cela peut signifier que l'endpoint n'accepte plus de nouvelles connexions, qu'un certain pourcentage de tentatives de connexion échoue, ou que les messages ne sont pas livrés. Certains contrats ne comptent que les interruptions de plus de quelques minutes consécutives, ce qui signifie que les coupures brèves ne comptent pas du tout.
La méthode de mesure
Qui mesure, et depuis où ? La supervision côté fournisseur peut voir le broker en bonne santé alors que vos appareils sur un réseau donné ne parviennent pas à le joindre. Demandez si vous pouvez soumettre vos propres données de supervision lors d'une réclamation de crédits.
Le périmètre
Vérifiez quels composants sont couverts : endpoints de connexion, listeners TLS et WebSocket, portail de gestion, API utilisées pour le provisionnement. Les portails et les API sont souvent couverts différemment du plan de données, voire pas du tout.
Les crédits de service
Lorsque l'objectif n'est pas atteint, le recours habituel est un crédit : un pourcentage de la redevance mensuelle, souvent échelonné selon l'ampleur de la baisse de disponibilité. Les crédits doivent généralement être réclamés dans un délai donné, et ils sont rarement proportionnels à l'impact métier d'une panne. Voyez-les comme une incitation pour le fournisseur, pas comme une assurance pour vous.
Exclusions courantes
Presque tous les SLA excluent certains événements. Exclusions typiques :
- La maintenance planifiée annoncée à l'avance.
- Les problèmes causés par les propres appareils, réseaux ou erreurs de configuration du client.
- Le dépassement des limites du plan, comme les quotas de connexions ou de messages.
- Les cas de force majeure.
- Les offres gratuites, d'essai ou bêta.
- Les incidents sur les réseaux tiers entre vos appareils et le fournisseur.
Les offres gratuites en particulier s'accompagnent rarement d'un SLA contractuel. C'est raisonnable pour le développement et les pilotes, mais les engagements de production envers vos propres clients doivent reposer sur un plan aux conditions explicites.
Disponibilité composite : votre système est une chaîne
Votre disponibilité de bout en bout n'est pas celle du broker. Un message issu d'un capteur traverse l'appareil, le réseau local, l'opérateur mobile ou internet, le broker, votre backend et votre base de données. Quand des composants sont en série, leurs disponibilités se multiplient.
Par exemple, si le réseau des appareils est disponible à 99,5 %, le broker à 99,9 % et votre backend à 99,9 %, la chaîne atteint environ 0,995 x 0,999 x 0,999, soit environ 99,3 %. Le maillon le plus faible domine. Investir lourdement dans les neufs du broker alors que votre backend tourne sur un seul serveur rapporte peu. Pour les modèles d'architecture, consultez la haute disponibilité d'un broker MQTT.
Concevoir pour l'indisponibilité autorisée par le SLA
Même à 99,99 %, un broker sera parfois injoignable. Construisez des clients qui le tolèrent :
- Reconnectez-vous avec un backoff exponentiel et du jitter, pour que des milliers d'appareils ne se reconnectent pas au même instant.
- Mettez en mémoire tampon localement sur les appareils et les passerelles, puis publiez au retour de la connexion.
- Utilisez des sessions persistantes avec une expiration de session adaptée, afin que les messages QoS 1 et 2 destinés aux abonnés hors ligne soient mis en file.
- Utilisez des retained messages pour l'état, afin que les tableaux de bord voient la dernière valeur connue dès la reconnexion.
- Définissez un Last Will pour que votre backend sache quand un appareil a décroché de façon inattendue.
- Supervisez depuis l'extérieur avec un client synthétique qui publie et reçoit un heartbeat.
Le guide sur la panne d'un broker MQTT couvre la gestion des incidents, et la checklist de mise en production MQTT transforme ces points en tâches avant lancement.
La disponibilité n'est pas la durabilité
Un objectif de disponibilité indique si le broker accepte les connexions et route les messages. Il ne dit rien de la préservation de chaque message lors d'un incident. Demandez séparément comment se comportent les sessions, les messages en file et les retained messages lorsqu'un nœud du broker redémarre ou bascule, et concevez votre système en fonction de la réponse. Si la perte d'un message coûterait cher, gardez la source de vérité sur l'appareil ou dans votre backend et faites du broker un moyen de transport, pas un lieu de stockage. Les délais de réponse du support constituent un troisième engagement, distinct, qui mérite une lecture attentive.
Questions à poser avant de signer
| Question | Pourquoi c'est important |
|---|---|
| Comment la disponibilité est-elle mesurée, et par qui ? | Détermine ce qui compte comme indisponibilité |
| Quelle est la durée minimale d'interruption prise en compte ? | Les coupures courtes peuvent être exclues |
| La maintenance planifiée est-elle exclue, et avec quel préavis ? | Un arrêt planifié affecte quand même les appareils |
| Quels composants sont couverts ? | Le portail et les API peuvent différer des endpoints |
| Comment les crédits sont-ils calculés et réclamés ? | Des délais et des plafonds s'appliquent |
| Existe-t-il une page de statut et un historique des incidents ? | Montre l'historique réel |
| Quels délais de réponse du support s'appliquent ? | Disponibilité et support sont des engagements distincts |
Les SLA et ConnectMQ
ConnectMQ propose plusieurs plans, d'une offre Serverless gratuite sur un cluster mutualisé jusqu'aux clusters isolés Dedicated, au BYOC dans votre propre compte cloud géré par ConnectMQ, et à Self Managed Enterprise. Si votre projet nécessite des conditions de disponibilité contractuelles, discutez-en avec l'équipe ConnectMQ pour les options Dedicated, BYOC ou entreprise, et utilisez les questions ci-dessus pour examiner l'offre. Quelles que soient les conditions, ce sont les pratiques côté client décrites dans cet article qui maintiennent votre flotte en bonne santé lorsqu'un broker, quel qu'il soit, connaît un mauvais jour.
Démarrer avec ConnectMQ
Construisez et testez votre logique de reconnexion et de mise en mémoire tampon sur un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, ou expérimentez d'abord sur le serveur MQTT public gratuit, réservé aux tests et aux prototypes. Pour savoir ce qu'un broker MQTT managé vous épargne et comment se comparent les modèles d'hébergement, lisez le guide du broker MQTT cloud.
Questions fréquentes
Quelle indisponibilité un SLA à 99,9 % autorise-t-il ?
Environ 43,8 minutes par mois, soit environ 8,8 heures par an.
Un SLA garantit-il que mes appareils resteront connectés ?
Non. Il définit un objectif de disponibilité et la compensation s'il n'est pas atteint. Vos appareils ont toujours besoin d'une logique de reconnexion, d'une mémoire tampon et d'une supervision.
Les plans gratuits de broker MQTT incluent-ils un SLA ?
Les offres gratuites n'incluent généralement pas de SLA contractuel. Utilisez-les pour le développement et les pilotes, et choisissez un plan aux conditions explicites pour vos engagements de production.
99,99 % est-il toujours meilleur que 99,9 % ?
Ce niveau autorise dix fois moins d'indisponibilité, mais votre disponibilité de bout en bout dépend de chaque composant de la chaîne. Améliorez d'abord le maillon le plus faible.
