Ya sea que esté desarrollando una aplicación incipiente o que ya esté ejecutando un servicio de alto tráfico, puede beneficiarse de los conocimientos y recomendaciones de esta guía sobre cómo escalar sin problemas con FCM. Estos conceptos y prácticas pueden ayudarle a evitar impactos negativos cuando necesite enviar grandes volúmenes de mensajes.
Términos y conceptos clave
Solicitud de mensaje : una solicitud de mensaje FCM; se usa indistintamente con "solicitud", "mensaje" o "consulta".
Solicitudes por segundo (RPS) : una métrica para describir la tasa de solicitudes entrantes a FCM; se utiliza indistintamente con consultas por segundo (QPS).
Tokens de cuota, depósitos de tokens y recargas : al enviar mensajes contra la API HTTP v1 de FCM, cada solicitud consume un token de cuota asignado en un período de tiempo determinado. Esta ventana, llamada " Token Bucket ", se llena por completo al final de la ventana de tiempo. Por ejemplo: la API HTTP v1 asigna 600.000 tokens de cuota por cada depósito de tokens de 1 minuto, que se recarga por completo al final de cada ventana de 1 minuto.
Limitación del lado del servidor : cuando el volumen de tráfico excede la capacidad del servicio FCM, las solicitudes que superan la capacidad de servicio se rechazan para limitar el flujo de entrada. Se pueden devolver respuestas de error 429 con encabezados retry-after para indicar que debe esperar un período de tiempo determinado antes de volver a intentar la solicitud.
Limitación del lado del cliente : cuando los clientes observan fallas en las solicitudes, alta latencia o errores 429 , deben limitar voluntariamente el flujo de salida para evitar exacerbar la congestión.
Retroceso exponencial : al reintentar errores, agregue retrasos de tiempo que aumenten exponencialmente. Por ejemplo: 1, 2, 4, 8, 16, 32.
Jittering : evitar reintentar solicitudes a intervalos exactos. Con el jittering, se varían los retrasos de reintento mediante un proceso aleatorio para distribuirlos uniformemente a lo largo del tiempo (por ejemplo: 0,9 s, 2,3 s, 4,1 s, 8,5 s, 17,9 s, 34,7 s).
Reintentar amplificación : cuando las solicitudes fallidas se reintentan sin retrocesos o fluctuaciones exponenciales, a menudo se acumulan y aumentan la carga de tráfico en curso, lo que potencialmente "amplifica" y exacerba los problemas de congestión del tráfico.
El problema: picos de tráfico
FCM procesa millones de solicitudes por segundo (RPS). El mayor contribuyente a la congestión sistémica, los problemas de latencia y las interrupciones son los picos de tráfico.
¿Qué es el tráfico puntiagudo?
Hay varios tipos diferentes de picos de tráfico.
Picos según la hora: FCM recibe más del doble de tráfico durante los primeros 30 segundos a 2 minutos de cada hora. También se observan picos similares, aunque menores, en las marcas de media hora y cuarto de hora (ejemplos: 00:15, 00:30, 00:45)
Amplificación de reintento : reintentar solicitudes fallidas o con tiempo de espera agotado sin un retroceso exponencial puede acumularse en oleadas repetidas de tráfico encima de los picos de tráfico existentes.
Cambios abruptos en los patrones de tráfico: dirigir el tráfico nuevo a FCM o mover el tráfico a FCM entre regiones sin factores de suavización, como un aumento gradual, puede provocar picos.
Uso de tokens de cuota de carga frontal: agotar todos los tokens de cuota al inicio de las ventanas de cuota en lugar de distribuir las solicitudes de manera uniforme entre las ventanas de cuota creará oscilaciones de encendido y apagado que son difíciles y costosas de equilibrar la carga.
Eventos especiales: picos de tráfico durante días festivos (Nochevieja) o eventos deportivos ( Copa Mundial de la FIFA ).
Remediar los picos de tráfico "aplanando la curva"
Esta sección describe estrategias para suavizar los picos de tráfico cuando sea posible: estrategias para "aplanar la curva".
Utilice FCM solo para casos de uso apropiados
Hay algunos casos de uso en los que no es necesario ni apropiado utilizar FCM para entregar una notificación.
Por ejemplo, para las notificaciones de eventos del calendario, puede programar una tarea local en su aplicación para mostrar una notificación en los momentos adecuados en lugar de enviarla desde el servidor de su aplicación. Limite los mensajes de FCM a las sincronizaciones del calendario.
Evite los picos
Un antipatrón de escalamiento es enviar notificaciones FCM tan rápido como lo permitan los sistemas, en lugar de aplicar limitación del lado del servidor. Considera lo siguiente:
- ¿Todos sus clientes necesitan recibir la misma notificación en un plazo de 1 minuto? ¿Un plazo de entrega de cinco minutos, por ejemplo, seguiría satisfaciendo las necesidades de su negocio?
- ¿Se pueden segmentar sus clientes según su prioridad para suavizar los picos?
- ¿Se pueden programar sus notificaciones con anticipación?
Siempre que sea posible : evite estrategias que resulten en agotar inmediatamente su cuota de envío de FCM, solo para repetir el patrón tan pronto como se recargue su depósito de tokens. Este patrón de acceso crea problemas de equilibrio de carga para FCM y sus sistemas dependientes. Aumente el tráfico lo más gradualmente posible. Como mínimo, aumente desde 0 hasta el RPS máximo en una ventana de tiempo de 60 segundos. Prefiera ventanas más largas para un RPS más alto.
Evite el tráfico "a la hora"
Siempre que sea posible : evite enviar mensajes dentro de un período de 2 minutos de cada una de las marcas de :00, :15, :30 y :45 minutos.
Implementar limitación del lado del servidor
Implemente limitación del lado del servidor para monitorear y administrar el flujo de tráfico hacia FCM.
Manejo de reintentos
Si bien FCM se esfuerza por tener una alta disponibilidad, en ocasiones algunas solicitudes caducan o fallan. Si bien los motivos varían, las siguientes prácticas recomendadas optimizan el comportamiento de reintento para entregar mensajes lo antes posible y al mismo tiempo minimizar el impacto en la congestión del tráfico.
Tiempos de espera
Establezca al menos un tiempo de espera de 10 segundos en las solicitudes de envío antes de volver a intentarlo. La mayoría de las llamadas a procedimientos remotos internos de FCM utilizan un tiempo de espera de 10 segundos.
Errores
- Para errores 400, 401, 403, 404: cancele y no vuelva a intentarlo.
- Para errores 429: vuelva a intentarlo después de esperar el tiempo establecido en el encabezado de reintento después. Si no se establece ningún encabezado de reintento posterior, el valor predeterminado es 60 segundos.
- Para errores 500: vuelva a intentarlo con retroceso exponencial.
Retroceso exponencial
Para evitar la amplificación de los reintentos, implemente un retroceso exponencial con fluctuaciones para las solicitudes de reintento. El SDK de Firebase Admin, por ejemplo, implementa un retroceso exponencial.
Aquí hay algunas configuraciones más recomendadas:
- Intervalo mínimo: no reintente inmediatamente una solicitud fallida con FCM. Espere al menos 10 segundos antes de volver a intentar una solicitud fallida.
- Intervalo máximo: establezca un intervalo máximo para descartar solicitudes que ya no sean oportunas, en lugar de reintentar indefinidamente.
Si una solicitud se reintenta continuamente con un retraso exponencial y sigue fallando 60 minutos después, se clasifica erróneamente como un error reintentable o FCM está experimentando una interrupción en la que los reintentos pueden exacerbar la situación sin darse cuenta.
Cree planes de implementación y reversión y realice cambios graduales
Al realizar cambios de tráfico a gran escala, como aumentar el tráfico a FCM o cambiar el tráfico entre regiones o redes, diseñar un plan de implementación/reversión e implementar cambios graduales protegerá a sus usuarios, su servicio y a FCM.
- Un plan de implementación alinea las expectativas de las partes interesadas. En determinadas situaciones (que se analizan a continuación), es posible que desee compartir su plan de implementación con anticipación con el equipo de FCM para evitar sorpresas.
- Un plan de reversión le permite tomar en cuenta las contingencias y preparar mecanismos para recuperarse de manera rápida y segura de fallas imprevistas.
- Hacer cambios graduales tiene dos aspectos:
- Aumentos "por pasos": Los pasos deben ser 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% o más finos. " Remojar " (observar el comportamiento del sistema bajo carga) en cada paso durante 1 día a 1 semana. Esto le permite detectar problemas potenciales antes del siguiente "paso a paso".
- Aumentos graduales del tráfico: al dar cada "paso" para aumentar el tráfico, suavice el tráfico en un lapso de al menos una hora. Esto permite que la infraestructura de equilibrio de carga de FCM escale adecuadamente su nuevo tráfico y al mismo tiempo minimice el potencial de puntos de acceso y congestión.
A continuación se muestra un escenario hipotético para migrar 500 000 RPS globalmente desde la API HTTP heredada de FCM a la API HTTP v1 de FCM:
| Semana | Paso | Estrategia de aumento gradual |
|---|---|---|
| 0 | 1% de aumento | Aumente sin problemas de 0 a 5000 RPS a FCM HTTP v1 en el transcurso de una hora. |
| 1 | 5% de aumento | Aumente suavemente de 5000 a 25 000 RPS en 2 horas. |
| 2 | 10% de aumento | Aumente suavemente de 25 000 a 50 000 RPS en 2 horas |
| 3 | 25% de aumento | Aumento de 50 000 a 125 000 RPS en 3 horas |
| 4 | 50% de aumento | Aumento de 125 000 a 250 000 RPS en 6 horas |
| 5 | 75% de aumento | Aumento de 250 000 a 375 000 RPS en 6 horas |
| 6 | 100% de aceleración | Aumento de 375 000 a 500 000 RPS en 6 horas |
Plan de reversión hipotético:
- Si la latencia del percentil 95 aumenta a más de 500 ms o si la tasa de error supera el 1 % durante más de una hora en cualquier paso, utilice la configuración dinámica para volver al paso anterior inmediatamente.
- Continúe retrocediendo a pasos anteriores hasta que la latencia y la tasa de error vuelvan a los niveles nominales.
Cuándo comunicarse con FCM
Comuníquese con FCM a través del soporte de Firebase si se aplica alguna de las siguientes situaciones:
- Las cuotas predeterminadas ya no cumplen con su caso de uso
- Está cambiando sus patrones de envío dentro de un período de 3 meses a una escala de 100 000 RPS a nivel mundial o 30 000 RPS a nivel continental.