Que vous développiez une application naissante ou que vous exécutiez déjà un service à trafic élevé, vous pouvez bénéficier des informations et des recommandations de ce guide pour évoluer en douceur avec FCM. Ces concepts et pratiques peuvent vous aider à éviter les impacts négatifs lorsque vous devez envoyer de grands volumes de messages.
Termes et concepts clés
Demande de message: demande de message FCM, utilisée de manière interchangeable avec "request", "message" ou "query".
Requêtes par seconde (RPS): métrique permettant de décrire le taux de requêtes entrantes vers FCM. Utilisée de manière interchangeable avec les requêtes par seconde (QPS).
Jetons de quota, buckets de jetons et recharges : lorsque vous envoyez des messages à l'aide de l'API HTTP v1 de FCM, chaque requête consomme un jeton de quota alloué dans un intervalle de temps donné. Cette fenêtre, appelée Token Bucket (seau à jetons), recharge entièrement à la fin de celle-ci. Par exemple, l'API HTTP v1 alloue 600 000 jetons de quota pour chaque bucket de jetons de 1 minute, qui se remplit à nouveau à la fin de chaque période de 1 minute.
Limitation côté serveur : lorsque le volume de trafic dépasse la capacité du service FCM, les requêtes dépassant la capacité de diffusion sont refusées pour limiter le débit entrant. Des réponses d'erreur 429 avec des en-têtes retry-after peuvent être renvoyées pour indiquer que vous devez attendre un certain temps avant de réessayer la requête.
Limitation côté client: lorsque les clients constatent des échecs de requêtes, une latence élevée ou des erreurs 429, ils doivent volontairement limiter le débit de sortie pour éviter d'exacerber la congestion.
Intervalle exponentiel entre les tentatives : lors des nouvelles tentatives d'erreurs, ajoutez des délais de plus en plus longs. Par exemple: 1 s, 2 s, 4 s, 8 s, 16 s, 32 s.
Jittering : évitez de relancer les requêtes à des intervalles exacts. Avec le jittering, vous modifiez les délais de nouvelle tentative via un processus aléatoire pour les répartir uniformément au fil du temps (par exemple : 0,9 s, 2,3 s, 4,1 s, 8,5 s, 17,9 s, 34,7 s).
Amplification des tentatives: lorsque les requêtes échouées sont réessayées sans délai exponentiel entre les tentatives ni jitter, elles s'accumulent souvent et augmentent la charge de trafic en cours, ce qui peut "amplifier" et aggraver les problèmes de congestion du trafic.
Le problème: les pics de trafic
FCM traite des millions de requêtes par seconde (RPS). Les pics de trafic sont le principal facteur de congestion systémique, de problèmes de latence et d'indisponibilités.
Qu'est-ce que le trafic à pics ?
Il existe plusieurs types de pics de trafic.
Pics à l'heure : FCM reçoit plus du double du trafic pendant les 30 premières secondes à deux minutes de chaque heure. Des pics similaires, mais moins importants, sont également observés aux demi-heures et aux quarts d'heure (par exemple, 00:15, 00:30 et 00:45).
Amplification des tentatives:la réitération des requêtes ayant échoué ou expirées sans intervalle exponentiel entre les tentatives peut entraîner l'accumulation de vagues de trafic répétées sur les pics de trafic existants.
Changements brusques de schémas de trafic : rediriger le nouveau trafic vers FCM ou le déplacer vers FCM entre les régions sans facteurs d'atténuation tels que l'augmentation progressive peut entraîner des pics.
Utilisation anticipée des jetons: l'épuisement de tous les jetons de quota au début des fenêtres de quota au lieu de répartir les requêtes uniformément entre les quotas entraîne des oscillations d'activation et de désactivation difficiles et coûteuses à équilibrer.
Événements spéciaux: pics de trafic pendant les fêtes (Saint-Sylvestre) ou les événements sportifs (Coupe du monde de la FIFA).
Atténuer les pics de trafic en "aplatissant la courbe"
Cette section décrit des stratégies visant à lisser les pics de trafic dans la mesure du possible, c'est-à-dire à "aplatir la courbe".
Utiliser FCM uniquement pour les cas d'utilisation appropriés
Dans certains cas d'utilisation, l'utilisation de FCM pour envoyer une notification n'est pas nécessaire ni appropriée.
Par exemple, pour les notifications d'événements d'agenda, vous pouvez planifier une tâche locale dans votre application pour afficher une notification aux heures appropriées au lieu de l'envoyer depuis votre serveur d'application. Limitez les messages FCM aux synchronisations d'agenda.
Éviter les pics
Un anti-modèle d'ajustement consiste à envoyer des notifications FCM aussi rapidement que possible, au lieu d'appliquer un débit limité côté serveur. Réfléchissez aux éléments suivants :
- Tous vos clients doivent-ils recevoir la même notification dans un délai d'une minute ? Par exemple, un délai de livraison de cinq minutes répondrait-il toujours à vos besoins ?
- Est-il possible de segmenter vos clients en fonction de leur priorité pour atténuer les pics ?
- Pouvez-vous programmer vos notifications à l'avance ?
Dans la mesure du possible: évitez les stratégies qui épuisent immédiatement votre quota d'envoi FCM, puis répétez le schéma dès que votre bucket de jetons est rempli. Ce modèle d'accès crée des problèmes d'équilibrage de charge pour FCM et ses systèmes qui en dépendent. Augmentez le trafic aussi progressivement que possible. Au minimum, augmentez de 0 à la valeur maximale de RPS sur une période de 60 secondes. Préférez des périodes plus longues pour un RPS plus élevé.
Éviter les embouteillages aux heures de pointe
Dans la mesure du possible: évitez d'envoyer des messages dans un délai de deux minutes avant ou après les minutes :00, :15, :30 et :45.
Implémenter le débit limité côté serveur
Implémentez le débit limité côté serveur pour surveiller et gérer le flux de trafic vers FCM.
Gérer les nouvelles tentatives
Bien que FCM s'efforce d'assurer une disponibilité élevée, il arrive que certaines requêtes expirent ou échouent. Bien que les raisons varient, les bonnes pratiques suivantes optimisent le comportement des nouvelles tentatives afin de distribuer les messages dès que possible tout en minimisant l'impact sur la congestion du trafic.
Délais avant expiration
Définissez un délai d'expiration d'au moins 10 secondes pour les requêtes d'envoi avant de réessayer. La plupart des appels de procédure à distance internes de FCM utilisent un délai d'inactivité de 10 secondes.
Erreurs
- Pour les erreurs 400, 401, 403 et 404: arrêtez et ne réessayez pas.
- Pour les erreurs 429: réessayez après avoir attendu la durée définie dans l'en-tête "retry-after". Si aucun en-tête "retry-after" n'est défini, la valeur par défaut est de 60 secondes.
- Pour les erreurs 500: réessayez avec un intervalle exponentiel entre les tentatives.
Intervalle exponentiel entre les tentatives
Pour éviter l'amplification des nouvelles tentatives, implémentez un intervalle exponentiel entre les tentatives avec une gigue pour les nouvelles tentatives. Le SDK Admin Firebase, par exemple, implémente l'intervalle exponentiel entre les tentatives.
Voici d'autres paramètres recommandés:
- Intervalle minimal: ne relancez pas immédiatement une requête ayant échoué avec FCM. Attendez au moins 10 secondes avant de relancer une requête ayant échoué.
- Intervalle maximal : définissez un intervalle maximal pour abandonner les requêtes qui ne sont plus à jour, au lieu de réessayer indéfiniment.
Si une requête est constamment relancée avec un intervalle exponentiel entre les tentatives et qu'elle échoue toujours 60 minutes plus tard, elle est mal classée en tant qu'erreur pouvant être réessayée, ou FCM connaît une panne où les nouvelles tentatives peuvent aggraver la situation par inadvertance.
Créer des plans de déploiement et de rollback, et effectuer des modifications progressives
Lorsque vous effectuez des modifications de trafic à grande échelle, telles que l'augmentation du trafic vers FCM ou le transfert du trafic entre des régions ou des réseaux, la conception d'un plan de déploiement/de rollback et l'implémentation de modifications progressives protègent vos utilisateurs, votre service et FCM.
- Un plan de déploiement permet d'aligner les attentes des partenaires. Dans certaines situations (décrites ci-dessous), vous pouvez partager votre plan de déploiement à l'avance avec l'équipe FCM pour éviter les surprises.
- Un plan de rollback vous permet de tenir compte des imprévus et de préparer des mécanismes pour une récupération rapide et sécurisée après des défaillances imprévues.
- Les modifications progressives présentent deux aspects :
- Augmentations "par étapes" : les étapes doivent être de 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% ou plus précises. "Soak" (observer le comportement du système sous charge) chaque étape pendant une à une semaine. Vous pourrez ainsi repérer les problèmes potentiels avant le prochain "passage à l'étape supérieure".
- Augmentation progressive du trafic: lorsque vous augmentez le trafic à chaque étape, lissez-le sur une période d'au moins une heure. L'infrastructure d'équilibrage de charge de FCM peut ainsi adapter votre nouveau trafic de façon appropriée, tout en réduisant les risques de hotspots et d'encombrement.
Voici un scénario hypothétique pour migrer 500 000 RPS dans le monde entier de l'ancienne API HTTP FCM vers l'API HTTP v1 FCM :
| Semaine | Step | Stratégie d'activation progressive |
|---|---|---|
| 0 | Augmentation de 1 % | Augmentez progressivement de 0 à 5 000 appels par seconde vers FCM HTTP v1 sur une heure. |
| 1 | Augmentation de 5 % | Augmentez progressivement de 5 000 à 25 000 RPS sur deux heures. |
| 2 | 10 % d'augmentation | Montée en douceur de 25 000 à 50 000 RPS en deux heures |
| 3 | Augmentation de 25 % | Passage de 50 000 à 125 000 RPS en trois heures |
| 4 | Accélération de 50 % | Accélération de 125 000 à 250 000 RPS sur six heures |
| 5 | Augmentation de 75 % | Passage de 250 000 à 375 000 RPS en 6 heures |
| 6 | Accélération à 100 % | Augmentation de 375 000 à 500 000 RPS sur six heures |
Plan de rollback hypothétique :
- Si la latence du 95e centile dépasse 500 ms ou si le taux d'erreur dépasse 1% pendant plus d'une heure à n'importe quelle étape, utilisez la configuration dynamique pour revenir immédiatement à l'étape précédente.
- Continuez les rollbacks vers les étapes précédentes jusqu'à ce que la latence et le taux d'erreur reviennent aux niveaux nominaux.
Quand contacter FCM
Contactez FCM via l'assistance Firebase si l'un des cas suivants s'applique :
- Les quotas par défaut ne répondent plus à votre cas d'utilisation
- Vous modifiez vos modèles d'envoi dans un délai de trois mois à une échelle de 100 000 RPS au niveau mondial ou de 30 000 RPS par continent.