Esteja você desenvolvendo um aplicativo nascente ou já executando um serviço de alto tráfego, você pode se beneficiar dos insights e recomendações deste guia sobre como escalar sem problemas com o FCM. Esses conceitos e práticas podem ajudar a evitar impactos negativos quando você precisar enviar grandes volumes de mensagens.
Termos e conceitos principais
Solicitação de mensagem : uma solicitação de mensagem FCM; usado de forma intercambiável com "solicitação", "mensagem" ou "consulta".
Solicitações por segundo (RPS) : uma métrica para descrever a taxa de solicitações recebidas ao FCM; usado de forma intercambiável com consultas por segundo (QPS).
Tokens de cota, buckets de token e recargas : ao enviar mensagens para a API FCM HTTP v1, cada solicitação consome um token de cota alocado em um determinado intervalo de tempo. Esta janela, chamada de " Token Bucket ", é totalmente preenchida no final da janela de tempo. Por exemplo: a API HTTP v1 atribui 600 mil tokens de cota para cada intervalo de token de 1 minuto, que é recarregado até ficar cheio no final de cada janela de 1 minuto.
Limitação do lado do servidor : quando o volume de tráfego excede a capacidade do serviço FCM, as solicitações além da capacidade de atendimento são rejeitadas para limitar a taxa de fluxo de entrada. 429 respostas de erro com cabeçalhos retry-after podem ser retornadas para indicar que você deve esperar um determinado período de tempo antes de tentar novamente a solicitação.
Limitação do lado do cliente : quando os clientes observam falhas de solicitação, alta latência ou erros 429 , eles devem limitar voluntariamente a taxa de fluxo de saída para evitar exacerbar o congestionamento.
Espera exponencial : ao tentar novamente erros, adicione atrasos de tempo crescentes exponencialmente. Por exemplo: 1s, 2s, 4s, 8s, 16s, 32s.
Tremulação : evitando novas tentativas de solicitações em intervalos exatos. Com o jitter, você varia os atrasos de repetição por meio de um processo aleatório para distribuí-los uniformemente ao longo do tempo (por exemplo: 0,9s, 2,3s, 4,1s, 8,5s, 17,9s, 34,7s).
Amplificação de novas tentativas : quando as solicitações com falha são repetidas sem espera/jittering exponencial, elas geralmente se acumulam e aumentam a carga de tráfego contínua, potencialmente "amplificando" e exacerbando os problemas de congestionamento de tráfego.
O problema: picos de tráfego
O FCM processa milhões de solicitações por segundo (RPS). O maior contribuinte para o congestionamento sistêmico, problemas de latência e interrupções são os picos de tráfego.
O que é tráfego intenso?
Existem vários tipos diferentes de picos de tráfego.
Picos durante a hora: o FCM recebe mais que o dobro do tráfego durante os primeiros 30 segundos a 2 minutos de cada hora. Picos semelhantes, embora menores, também são observados nas marcas de meia hora e quarto de hora (exemplos: 00h15, 00h30, 00h45)
Amplificação de nova tentativa : a repetição de solicitações com falha ou com tempo limite sem espera exponencial pode se acumular em ondas repetidas de tráfego além dos picos de tráfego existentes.
Mudanças abruptas no padrão de tráfego: direcionar novo tráfego para o FCM ou mover o tráfego para o FCM entre regiões sem fatores de suavização, como aumento gradual, pode causar picos.
Uso antecipado de tokens de cota: Esgotar todos os tokens de cota no início das janelas de cota, em vez de distribuir as solicitações uniformemente pelas janelas de cota, criará oscilações liga-desliga que são difíceis e caras de balancear a carga.
Eventos especiais: Picos de trânsito durante feriados (réveillon) ou eventos esportivos ( Copa do Mundo FIFA ).
Corrija os picos de tráfego "achatando a curva"
Esta seção descreve estratégias para suavizar picos de tráfego sempre que possível – estratégias para “achatar a curva”.
Use o FCM apenas para casos de uso apropriados
Existem alguns casos de uso em que o uso do FCM para entregar uma notificação não é necessário ou apropriado.
Por exemplo, para notificações de eventos de calendário, você pode agendar uma tarefa local no seu aplicativo para exibir uma notificação nos horários apropriados, em vez de enviá-la do servidor do seu aplicativo. Limite as mensagens do FCM às sincronizações do calendário.
Evite picos
Um antipadrão de escalonamento é enviar notificações FCM tão rapidamente quanto os sistemas permitirem, em vez de aplicar a limitação do lado do servidor. Considere o seguinte:
- Todos os seus clientes precisam receber a mesma notificação em um intervalo de 1 minuto? Uma janela de entrega de 5 minutos, por exemplo, ainda atenderia às necessidades do seu negócio?
- Seus clientes podem ser segmentados com base na prioridade para suavizar os picos?
- Suas notificações podem ser agendadas com antecedência?
Sempre que possível : evite estratégias que resultem no esgotamento imediato de sua cota de envio de FCM, apenas para repetir o padrão assim que seu token bucket for recarregado. Este padrão de acesso cria problemas de balanceamento de carga para o FCM e seus sistemas dependentes. Aumente o tráfego o mais gradualmente possível. No mínimo, aumente de 0 até o RPS máximo em uma janela de tempo de 60 segundos. Prefira janelas mais longas para RPS mais altos.
Evite o trânsito "de hora em hora"
Sempre que possível : evite enviar mensagens dentro de uma janela de 2 minutos de cada uma das marcas de :00, :15, :30 e :45 minutos.
Implementar limitação do lado do servidor
Implemente a otimização no lado do servidor para monitorar e gerenciar o fluxo de tráfego para o FCM.
Tratamento de novas tentativas
Embora o FCM se esforce para estar altamente disponível, às vezes algumas solicitações expiram ou falham. Embora os motivos variem, as práticas recomendadas a seguir otimizam o comportamento de novas tentativas para entregar mensagens o mais rápido possível, minimizando o impacto no congestionamento do tráfego.
Tempos limite
Defina um tempo limite de pelo menos 10 segundos para enviar solicitações antes de tentar novamente. A maioria das chamadas de procedimento remoto internas do FCM usam um tempo limite de 10 segundos.
Erros
- Para erros 400, 401, 403, 404: aborte e não tente novamente.
- Para erros 429: tente novamente após aguardar a duração definida no cabeçalho retry-after. Se nenhum cabeçalho de nova tentativa for definido, o padrão será 60 segundos.
- Para erros 500: tente novamente com espera exponencial.
Espera exponencial
Para evitar a amplificação de novas tentativas, implemente uma retirada exponencial com jitter para novas tentativas de solicitações. O Firebase Admin SDK, por exemplo, implementa espera exponencial.
Aqui estão mais algumas configurações recomendadas:
- Intervalo mínimo: não tente novamente imediatamente uma solicitação com falha com o FCM. Aguarde pelo menos 10 segundos antes de tentar novamente uma solicitação com falha.
- Intervalo Máximo: Defina um intervalo máximo para descartar solicitações que não são mais oportunas, em vez de tentar novamente indefinidamente.
Se uma solicitação for repetida continuamente com espera exponencial e ainda falhar 60 minutos depois, ela será categorizada incorretamente como um erro repetível ou o FCM estará enfrentando uma interrupção, onde as novas tentativas podem exacerbar inadvertidamente a situação.
Crie planos de implementação e reversão e faça mudanças graduais
Ao fazer alterações de tráfego em grande escala, como aumentar o tráfego para o FCM ou transferir o tráfego entre regiões ou redes, projetar um plano de implementação/reversão e implementar mudanças graduais protegerá seus usuários, seu serviço e o FCM.
- Um plano de implementação alinha as expectativas das partes interessadas. Em certas situações (discutidas abaixo), você pode compartilhar seu plano de implementação antecipadamente com a equipe do FCM para evitar surpresas.
- Um plano de reversão permite contabilizar contingências e preparar mecanismos para se recuperar de forma rápida e segura de falhas imprevistas.
- Fazer mudanças graduais tem dois aspectos:
- Aumentos "passo a passo": os passos devem ser de 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% ou mais fino. " Mergulhe " (observe o comportamento do sistema sob carga) em cada etapa por 1 dia a 1 semana. Isso permite que você identifique possíveis problemas antes da próxima "etapa"
- Aumentos graduais de tráfego: Ao dar cada "passo" para aumentar o tráfego, suavize-o ao longo de pelo menos uma hora. Isso permite que a infraestrutura de balanceamento de carga do FCM dimensione adequadamente seu novo tráfego, minimizando o potencial de hotspots e congestionamentos.
Aqui está um cenário hipotético para migrar 500.000 RPS globalmente da API HTTP legada do FCM para a API HTTP v1 do FCM:
| Semana | Etapa | Estratégia de aumento gradual |
|---|---|---|
| 0 | Aumento de 1% | Aumente suavemente de 0 a 5.000 RPS para FCM HTTP v1 ao longo de uma hora. |
| 1 | Aumento de 5% | Aumente suavemente de 5.000 a 25.000 RPS em 2 horas. |
| 2 | Aumento de 10% | Aumente suavemente de 25.000 para 50.000 RPS em 2 horas |
| 3 | Aumento de 25% | Aumente de 50.000 para 125.000 RPS em 3 horas |
| 4 | Aumento de 50% | Aumente de 125.000 para 250.000 RPS em 6 horas |
| 5 | Aumento de 75% | Aumente de 250.000 para 375.000 RPS em 6 horas |
| 6 | 100% de aceleração | Aumente de 375.000 para 500.000 RPS em 6 horas |
Plano de reversão hipotético:
- Se a latência do percentil 95 aumentar para mais de 500 ms ou se a taxa de erro exceder 1% por mais de uma hora em qualquer etapa, use a configuração dinâmica para reverter imediatamente para a etapa anterior.
- Continue reversões para etapas anteriores até que a latência e a taxa de erro retornem aos níveis nominais.
Quando entrar em contato com a FCM
Entre em contato com o FCM por meio do suporte do Firebase se alguma das seguintes situações se aplicar:
- As cotas padrão não atendem mais ao seu caso de uso
- Você está alterando seus padrões de envio dentro de um período de 3 meses em uma escala de 100.000 RPS globalmente ou 30.000 RPS continentalmente.