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'effectuer un scaling fluide 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
Requête de message : requête de message FCM. Ce terme est utilisé de manière interchangeable avec "requête", "message" ou "demande".
Requêtes par seconde (RPS) : métrique décrivant le taux de requêtes entrantes vers FCM. Ce terme est utilisé de manière interchangeable avec "demandes par seconde (QPS)".
Jetons de quota, buckets de jetons et recharges : lorsque vous envoyez des messages à l'aide de l' API FCM HTTP v1, chaque requête consomme un jeton de quota alloué dans une fenêtre temporelle donnée. Cette fenêtre, appelée "bucket de jetons", est rechargée complètement à la fin de la fenêtre temporelle. Par exemple, l'API HTTP v1 alloue 600 000 jetons de quota pour chaque bucket de jetons d'une minute, qui est rechargé 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 requêtes au-delà de la capacité de traitement sont rejetées pour limiter le flux entrant. 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 donnée avant de réessayer la requête.
Limitation côté client : lorsque les clients observent des échecs de requêtes, une latence élevée,
ou 429 erreurs, ils doivent limiter volontairement le flux sortant pour éviter d'aggraver la
congestion.
Intervalle exponentiel entre les tentatives: lorsque vous réessayez après des erreurs, ajoutez des délais qui augmentent de manière exponentielle. Par exemple : 1 s, 2 s, 4 s, 8 s, 16 s, 32 s, etc.
Gigue : évitez de réessayer les requêtes à intervalles exacts. Avec la gigue, vous variez les délais de nouvelle tentative via 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 requêtes ayant échoué sont réessayées sans intervalle exponentiel entre les tentatives ni gigue, elles s'accumulent souvent et s'ajoutent à 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 la principale cause de congestion systémique, de problèmes de latence et d'interruptions.
Qu'est-ce qu'un pic de trafic ?
Il existe plusieurs types de pics de trafic.
Pics à l'heure : 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 moins importants, sont également observés à la demi-heure et au quart d'heure (par exemple : 00:15, 00:30, 00:45).
**Amplification des nouvelles tentatives**: réessayer les requêtes ayant échoué ou ayant expiré sans intervalle exponentiel entre les tentatives peut entraîner des vagues de trafic répétées en plus des pics de trafic existants.
Modifications soudaines des schémas de trafic : diriger un nouveau trafic vers FCM ou déplacer du trafic vers FCM entre les régions sans facteurs de lissage tels qu'une augmentation progressive peut entraîner des pics.
Utilisation anticipée des jetons de quota : épuiser tous les jetons de quota au début des fenêtres de quota au lieu de répartir les requêtes de manière uniforme sur les fenêtres de quota crée des oscillations marche/arrêt 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).
Remédier aux pics de trafic en "aplatissant la courbe"
Cette section décrit des stratégies permettant de lisser les pics de trafic lorsque cela est possible, c'est-à-dire des stratégies pour "aplatir la courbe".
N'utilisez FCM que pour les cas d'utilisation appropriés
Dans certains cas d'utilisation, il n'est pas nécessaire ni approprié d'utiliser FCM pour diffuser une notification.
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 moments appropriés au lieu de l'envoyer depuis votre serveur d'applications. Limitez les messages FCM aux synchronisations d'agenda.
Éviter les pics
Un anti-schéma de scaling consiste à envoyer des notifications FCM aussi rapidement que les systèmes le permettent, au lieu d'appliquer une limitation côté serveur. Tenez compte des points suivants :
- Tous vos clients doivent-ils recevoir la même notification dans une fenêtre d'une minute ? Une fenêtre de diffusion de cinq minutes, par exemple, répondrait-elle toujours à vos besoins commerciaux ?
- Vos clients peuvent-ils être segmentés en fonction de la priorité pour lisser les pics ?
- Vos notifications peuvent-elles être planifiées à l'avance ?
Dans la mesure du possible : évitez les stratégies qui entraînent l'épuisement immédiat de votre quota d'envoi FCM, pour ensuite répéter le schéma dès que votre bucket de jetons est rechargé. Ce schéma 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, passez de 0 au nombre maximal de RPS sur une fenêtre temporelle de 60 secondes. Préférez des fenêtres plus longues pour un nombre de RPS plus élevé.
Éviter le trafic "à l'heure"
Dans la mesure du possible : évitez d'envoyer des messages dans une fenêtre de deux minutes pour chaque marque de temps :00, :15, :30 et :45.
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.
Gérer les nouvelles tentatives
Bien que FCM s'efforce d'être hautement disponible, certaines requêtes expirent ou échouent parfois. Bien que les raisons varient, les bonnes pratiques suivantes optimisent le comportement de nouvelle tentative pour diffuser 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 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 : 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 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 gigue pour réessayer les requêtes. Le SDK Firebase Admin, par exemple, implémente un intervalle exponentiel entre les tentatives.
Voici d'autres paramètres recommandés :
- Intervalle minimal : ne réessayez pas immédiatement une requête ayant échoué avec FCM. Attendez au moins 10 secondes avant de réessayer une requête ayant échoué.
- Intervalle maximal : définissez un intervalle maximal pour supprimer les requêtes qui ne sont plus opportunes, au lieu de réessayer indéfiniment.
Si une requête est réessayée en continu avec un intervalle exponentiel entre les tentatives et qu'elle échoue toujours 60 minutes plus tard, elle est soit mal classée comme erreur pouvant être réessayée, soit FCM subit une interruption où les nouvelles tentatives peuvent aggraver la situation par inadvertance.
Créer des plans de déploiement et de rollback, et apporter des modifications progressives
Lorsque vous apportez des modifications de trafic à grande échelle, par exemple en augmentant le trafic vers FCM ou en déplaçant le trafic entre les régions ou les réseaux, la conception d'un plan de déploiement/rollback et l'implémentation de modifications progressives protégeront vos utilisateurs, votre service et FCM.
- Un plan de déploiement aligne les attentes des partenaires. Dans certaines situations (abordées 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 récupérer rapidement et en toute sécurité après des échecs imprévus.
- Apporter des modifications progressives comporte deux aspects :
- Augmentations "par étapes" : les étapes doivent être de 1 % -> 5 % -> 10 % -> 25 % -> 50 % -> 75 % -> 100 % ou plus précises. "Imprégnez" (observez le comportement du système sous charge) chaque étape pendant un jour à une semaine. Cela vous permet de détecter les problèmes potentiels avant la prochaine "étape".
- Augmentations progressives du trafic : lorsque vous effectuez 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 de mettre à l'échelle de manière appropriée votre nouveau trafic tout en minimisant le potentiel de points chauds et de congestion.
Voici un scénario hypothétique pour migrer 500 000 RPS à l'échelle mondiale de l'API HTTP héritée de FCM vers l'API HTTP v1 de FCM :
| Semaine | Étape | Stratégie d'augmentation progressive |
|---|---|---|
| 0 | Augmentation de 1 % | Augmentez progressivement de 0 à 5 000 RPS vers l'API HTTP v1 de FCM sur une période d'une heure. |
| 1 | Augmentation de 5 % | Augmentez progressivement de 5 000 à 25 000 RPS sur deux heures. |
| 2 | Augmentation de 10 % | Augmentez progressivement de 25 000 à 50 000 RPS sur deux heures. |
| 3 | Augmentation de 25 % | Augmentez de 50 000 à 125 000 RPS sur trois heures. |
| 4 | Augmentation de 50 % | Augmentez de 125 000 à 250 000 RPS sur six heures. |
| 5 | Augmentation de 75 % | Augmentez de 250 000 à 375 000 RPS sur six heures. |
| 6 | Augmentation de 100 % | Augmentez de 375 000 à 500 000 RPS sur six heures. |
Plan de rollback hypothétique :
- Si la latence du 95e centile augmente à plus de 500 ms ou si le taux d'erreur dépasse 1 % pendant plus d'une heure à une étape quelconque, 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 à des niveaux nominaux.
Quand contacter FCM ?
Contactez FCM via l'assistance Firebase si l'une des conditions suivantes s'applique :
- Les quotas par défaut ne correspondent plus à votre cas d'utilisation.
- Vous modifiez vos schémas d'envoi dans une fenêtre de trois mois à une échelle de 100 000 RPS à l'échelle mondiale ou de 30 000 RPS à l'échelle continentale.