Que vous développiez une application naissante ou que vous exploitiez déjà un service à fort trafic, vous pouvez bénéficier des insights et des recommandations de ce guide pour faire évoluer votre application 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
Message Request (Demande de message) : demande de message FCM, utilisée de manière interchangeable avec "request" (requête), "message" (message) ou "query" (requête).
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, se remplit à la fin de la période. 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 du débit côté client: lorsque les clients observent 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'aggraver 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, etc.
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 intervalle exponentiel entre les tentatives/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: 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 du jeton de quota en premier: si vous utilisez tous les jetons de quota au début des périodes de quota au lieu de répartir les requêtes de manière uniforme sur les périodes de quota, vous créerez des oscillations de mise en marche et d'arrêt qui sont difficiles et coûteuses à équilibrer.
Événements spéciaux: pics de trafic pendant les fêtes (réveillon du Nouvel An) 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 de mise à l'échelle 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 ?
- Les notifications peuvent-elles être planifiées à l'avance ?
Dans la mesure du possible: évitez les stratégies qui épuisent immédiatement votre quota d'envoi FCM, puis qui répètent 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 dépendants. 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'être hautement disponible, il arrive que certaines requêtes expirent ou échouent. Les raisons peuvent varier, mais les bonnes pratiques suivantes optimisent le comportement de nouvelle tentative pour envoyer les messages dès que possible, tout en limitant l'impact sur la congestion du trafic.
Délais avant expiration
Définissez un délai avant 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 avant expiration 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 Firebase Admin, par exemple, implémente l'intervalle exponentiel entre les tentatives.
Voici d'autres paramètres recommandés:
- Intervalle minimum: 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 soit classée à tort comme une erreur pouvant être réessayée, soit 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 apportez des modifications de trafic à grande échelle, comme augmenter le trafic vers FCM ou déplacer le trafic entre des régions ou des réseaux, concevoir un plan de déploiement/de rollback et implémenter des modifications progressives protégera vos utilisateurs, votre service et FCM.
- Un plan de déploiement aligne 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 prendre en compte les aléas et de préparer des mécanismes pour récupérer rapidement et en toute sécurité en cas de défaillances imprévues.
- L'apport de changements progressifs comporte 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 pouvez 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 manière appropriée, tout en minimisant le risque de points chauds et de congestion.
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 | 1% d'activation progressive | 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 | Augmentation progressive de 25 000 à 50 000 RPS sur deux heures |
| 3 | Accélération de 25 % | Accélération de 50 000 à 125 000 RPS sur trois heures |
| 4 | Accélération de 50 % | Accélération de 125 000 à 250 000 RPS sur six heures |
| 5 | Accélération de 75 % | Accélération de 250 000 à 375 000 RPS sur six 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 à annuler les étapes précédentes jusqu'à ce que la latence et le ratio d'erreur reviennent à des 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.