Que vous développiez une application naissante ou que vous exécutiez déjà un service à fort trafic, vous pouvez bénéficier des informations et des recommandations de ce guide sur la façon d'évoluer en douceur avec FCM. Ces concepts et pratiques peuvent vous aider à éviter les impacts négatifs lorsque vous devez envoyer de gros volumes de messages.
Termes et concepts clés
Demande de message : une demande de message FCM ; utilisé de manière interchangeable avec « requête », « message » ou « requête ».
Requêtes par seconde (RPS) : une métrique pour décrire le taux de requêtes entrantes vers FCM ; utilisé de manière interchangeable avec Requêtes par seconde (QPS).
Jetons de quota, compartiments de jetons et recharges : lors de l'envoi de messages vers l'API HTTP v1 FCM, chaque requête consomme un jeton de quota alloué dans une fenêtre de temps donnée. Cette fenêtre, appelée « Token Bucket », se remplit complètement à la fin de la fenêtre horaire. Par exemple : l'API HTTP v1 attribue 600 000 jetons de quota pour chaque seau de jetons d'une minute, qui se remplit complètement à la fin de chaque fenêtre d'une minute.
Limitation côté serveur : lorsque le volume de trafic dépasse la capacité du service FCM, les demandes au-delà de la capacité de service sont rejetées pour limiter le flux d'entrée. Des réponses d'erreur 429 avec des en-têtes retry-after peuvent être renvoyées pour indiquer que vous devez attendre une période de temps donnée avant de réessayer la demande.
Limitation côté client : lorsque les clients observent des échecs de requête, une latence élevée ou des erreurs 429 , ils doivent volontairement limiter le débit du flux de sortie pour éviter d'exacerber la congestion.
Interruption exponentielle : lorsque vous réessayez des erreurs, ajoutez des délais croissants de manière exponentielle. Par exemple : 1s, 2s, 4s, 8s, 16s, 32s.
Jittering : éviter de réessayer les requêtes à intervalles précis. Avec le jittering, vous faites varier les délais de nouvelle tentative selon un processus aléatoire pour les répartir uniformément dans le temps (par exemple : 0,9 s, 2,3 s, 4,1 s, 8,5 s, 17,9 s, 34,7 s).
Amplification des nouvelles tentatives : lorsque les demandes ayant échoué sont réessayées sans interruption/instabilité exponentielle, elles s'accumulent souvent et s'ajoutent à la charge de trafic en cours, potentiellement « amplifiant » et exacerbant 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 les principaux contributeurs à la congestion systémique, aux problèmes de latence et aux pannes.
Qu’est-ce qu’un trafic intense ?
Il existe plusieurs types de pics de trafic.
Pics horaires : FCM reçoit plus du double de trafic au cours des 30 premières secondes à 2 minutes de chaque heure. Des pics similaires, bien que moindres, sont également observés aux demi-heures et aux quarts d’heure (exemples : 00h15, 00h30, 00h45).
Amplification des nouvelles tentatives : les nouvelles tentatives de demandes ayant échoué ou expirées sans interruption exponentielle peuvent s'accumuler en vagues répétitives de trafic au-dessus des crêtes de trafic existantes.
Changements brusques de modèle de trafic : diriger du nouveau trafic vers FCM ou déplacer le trafic vers FCM entre régions sans facteurs de lissage tels qu'une montée en puissance progressive peut provoquer des pics.
Utilisation des jetons de quota à chargement frontal : épuiser tous les jetons de quota au début des fenêtres de quota au lieu de répartir les demandes uniformément sur les fenêtres de quota créera des oscillations marche-arrêt difficiles et coûteuses à équilibrer la charge.
Événements spéciaux : pics de trafic pendant les vacances (réveillon du Nouvel An) ou les événements sportifs ( Coupe du Monde de la FIFA ).
Remédier aux pics de trafic en « aplatissant la courbe »
Cette section décrit des stratégies pour atténuer les pics de trafic lorsque cela est possible – des stratégies pour « aplatir la courbe ».
Utilisez FCM uniquement pour les cas d'utilisation appropriés
Il existe certains cas d'utilisation dans lesquels l'utilisation de FCM pour envoyer une notification n'est pas nécessaire ou appropriée.
Par exemple, pour les notifications d'événements de calendrier, 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'applications. Limitez les messages FCM aux synchronisations de calendrier.
Évitez les pointes
Un anti-modèle de mise à l'échelle consiste à envoyer des notifications FCM aussi rapidement que les systèmes le permettent, au lieu d'appliquer une limitation côté serveur. Considérer ce qui suit:
- Tous vos clients doivent-ils recevoir la même notification dans un délai d'une minute ? Un délai de livraison de 5 minutes, par exemple, répondrait-il toujours aux besoins de votre entreprise ?
- Vos clients peuvent-ils être segmentés en fonction de leurs priorités pour atténuer les pics ?
- Vos notifications peuvent-elles être programmées à l'avance ?
Dans la mesure du possible : évitez les stratégies qui aboutissent à épuiser immédiatement votre quota d'envoi FCM, pour ensuite répéter le modèle dès que votre seau de jetons se remplit. Ce modèle d'accès crée des problèmes d'équilibrage de charge pour FCM et ses systèmes dépendants. Augmentez la circulation le plus progressivement possible. Au minimum, passez de 0 au RPS maximum sur une fenêtre de temps de 60 secondes. Préférez des fenêtres plus longues pour un RPS plus élevé.
Évitez le trafic « à l'heure »
Dans la mesure du possible : évitez d'envoyer des messages dans un intervalle de 2 minutes après chacune des marques :00, :15, :30 et :45 minutes.
Implémenter une limitation côté serveur
Implémentez une limitation côté serveur pour surveiller et gérer le flux de trafic vers FCM.
Gestion des tentatives
Bien que FCM s'efforce d'être hautement disponible, certaines demandes peuvent parfois expirer ou échouer. Bien que les raisons varient, les bonnes pratiques suivantes optimisent le comportement des nouvelles tentatives afin de transmettre les messages dès que possible tout en minimisant l'impact sur les embouteillages.
Délais d'attente
Définissez un délai d'attente d'au moins 10 secondes pour les demandes d'envoi avant de réessayer. La plupart des appels de procédure à distance internes de FCM utilisent un délai d'attente de 10 secondes.
les erreurs
- Pour les erreurs 400, 401, 403, 404 : abandonnez 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 de nouvelle tentative n’est défini, la valeur par défaut est 60 secondes.
- Pour 500 erreurs : réessayez avec un intervalle exponentiel.
Retard exponentiel
Pour éviter l'amplification des nouvelles tentatives, implémentez une interruption exponentielle avec instabilité pour les nouvelles tentatives de requêtes. Le SDK Firebase Admin, par exemple, implémente une interruption exponentielle.
Voici quelques paramètres supplémentaires recommandés :
- Intervalle minimum : ne réessayez pas immédiatement une demande ayant échoué avec FCM. Attendez au moins 10 secondes avant de réessayer une requête ayant échoué.
- Intervalle maximum : définissez un intervalle maximum pour supprimer les demandes qui ne sont plus opportunes, au lieu de réessayer indéfiniment.
Si une demande est continuellement réessayée avec un intervalle exponentiel et échoue toujours 60 minutes plus tard, soit elle est catégorisée à tort comme une erreur réessayable, soit FCM connaît une panne où les nouvelles tentatives peuvent aggraver la situation par inadvertance.
Créez des plans de déploiement et de restauration et apportez des modifications progressives
Lorsque vous effectuez des modifications de trafic à grande échelle, telles que l'augmentation du trafic vers FCM ou le déplacement du trafic entre régions ou réseaux, la conception d'un plan de déploiement/restauration et la mise en œuvre de changements progressifs protégeront vos utilisateurs, votre service et FCM.
- Un plan de déploiement aligne les attentes des parties prenantes. Dans certaines situations (abordées ci-dessous), vous souhaiterez peut-être partager votre plan de déploiement à l'avance avec l'équipe FCM pour éviter les surprises.
- Un plan de restauration vous permet de tenir compte des imprévus et de préparer des mécanismes pour récupérer rapidement et en toute sécurité après des pannes imprévues.
- Effectuer des changements progressifs comporte deux aspects :
- Montées en puissance « par étapes » : les étapes doivent être de 1 % -> 5 % -> 10 % -> 25 % -> 50 % -> 75 % -> 100 % ou plus. " Soak " (observer le comportement du système sous charge) chaque étape pendant 1 jour à 1 semaine. Cela vous permet de repérer les problèmes potentiels avant la prochaine « étape »
- Augmentation progressive du trafic : lorsque vous prenez chaque « étape » pour augmenter le trafic, lissez le trafic sur une période d'au moins une heure. Cela permet à l'infrastructure d'équilibrage de charge de FCM d'adapter de manière appropriée votre nouveau trafic tout en minimisant le potentiel de points d'accès et de congestion.
Voici un scénario hypothétique pour migrer 500 000 RPS à l’échelle mondiale depuis l’API HTTP héritée de FCM vers l’API HTTP v1 de FCM :
| Semaine | Étape | Stratégie de montée en puissance progressive |
|---|---|---|
| 0 | 1 % de montée en puissance | Montez en douceur de 0 à 5 000 RPS vers FCM HTTP v1 en une heure. |
| 1 | 5 % de montée en puissance | Montée en douceur de 5 000 à 25 000 RPS sur 2 heures. |
| 2 | 10 % de montée en puissance | Montée en puissance fluide de 25 000 à 50 000 RPS sur 2 heures |
| 3 | 25 % de montée en puissance | Montée en puissance de 50 000 à 125 000 RPS sur 3 heures |
| 4 | Montée en puissance de 50 % | Montée en puissance de 125 000 à 250 000 RPS sur 6 heures |
| 5 | 75 % de montée en puissance | Montée en puissance de 250 000 à 375 000 RPS sur 6 heures |
| 6 | Montée en puissance à 100 % | Montée en puissance de 375 000 à 500 000 RPS sur 6 heures |
Plan de restauration hypothétique :
- Si la latence du 95 centile augmente jusqu'à dépasser 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 à revenir aux é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 3 mois à une échelle de 100 000 RPS à l'échelle mondiale ou 30 000 RPS à l'échelle continentale.