Che tu stia sviluppando un'app nascente o gestendo già un servizio ad alto traffico, puoi trarre vantaggio dagli approfondimenti e dai consigli di questa guida su come scalare senza problemi con FCM. Questi concetti e pratiche possono aiutarti a evitare impatti negativi quando devi inviare grandi volumi di messaggi.
Termini e concetti chiave
Richiesta di messaggio : una richiesta di messaggio FCM; usato in modo intercambiabile con "richiesta", "messaggio" o "query".
Richieste al secondo (RPS) : una metrica per descrivere la velocità delle richieste in entrata in FCM; utilizzato in modo intercambiabile con Query al secondo (QPS).
Token di quota, bucket di token e ricariche : quando si inviano messaggi all'API HTTP v1 di FCM, ogni richiesta consuma un token di quota assegnato in un determinato intervallo di tempo. Questa finestra, chiamata " Token Bucket ", si riempie completamente alla fine della finestra temporale. Ad esempio: l'API HTTP v1 assegna 600.000 token di quota per ogni bucket di token da 1 minuto, che si riempie completamente alla fine di ogni finestra di 1 minuto.
Limitazione lato server : quando il volume del traffico supera la capacità del servizio FCM, le richieste oltre la capacità di servizio vengono rifiutate per limitare la velocità del flusso in entrata. Potrebbero essere restituite risposte di errore 429 con intestazioni retry-after per indicare che è necessario attendere un determinato periodo di tempo prima di ritentare la richiesta.
Limitazione lato client : quando i client osservano richieste non riuscite, latenza elevata o errori 429 , dovrebbero limitare volontariamente la velocità del flusso in uscita per evitare di esacerbare la congestione.
Backoff esponenziale : quando si riprovano gli errori, aggiungere ritardi di tempo in aumento esponenziale. Ad esempio: 1, 2, 4, 8, 16, 32.
Jittering : evitare di riprovare le richieste a intervalli esatti. Con il jittering, puoi variare i ritardi tra i nuovi tentativi attraverso un processo casuale per distribuirli uniformemente nel tempo (ad esempio: 0,9 s, 2,3 s, 4,1 s, 8,5 s, 17,9 s, 34,7 s).
Amplificazione dei tentativi : quando le richieste non riuscite vengono ritentate senza backoff/jittering esponenziale, spesso si accumulano e si aggiungono al carico di traffico in corso, potenzialmente "amplificando" ed esacerbando i problemi di congestione del traffico.
Il problema: i picchi di traffico
FCM elabora milioni di richieste al secondo (RPS). Il principale contributo alla congestione sistemica, ai problemi di latenza e alle interruzioni sono i picchi di traffico.
Cos'è il traffico intenso?
Esistono diversi tipi di picchi di traffico.
Picchi orari: FCM riceve più del doppio del traffico durante i primi 30 secondi fino a 2 minuti di ogni ora. Picchi simili, anche se minori, si osservano anche ai segni delle mezz'ore e dei quarti d'ora (esempi: 00:15, 00:30, 00:45)
Amplificazione dei nuovi tentativi : i nuovi tentativi di richieste non riuscite o scadute senza backoff esponenziale possono accumularsi in ondate di traffico ripetute oltre ai picchi di traffico esistenti.
Cambiamenti improvvisi del modello di traffico: indirizzare nuovo traffico verso FCM o spostare il traffico verso FCM tra regioni senza fattori di livellamento come l'aumento graduale può causare picchi.
Utilizzo dei token di quota con caricamento anticipato: l'esaurimento di tutti i token di quota all'inizio delle finestre di quota invece di distribuire uniformemente le richieste tra le finestre di quota creerà oscillazioni on-off difficili e costose da bilanciare il carico.
Eventi speciali: picchi di traffico durante le vacanze (Capodanno) o eventi sportivi ( Coppa del Mondo FIFA ).
Risolvere i picchi di traffico "appiattendo la curva"
Questa sezione descrive le strategie per attenuare i picchi di traffico ove possibile: strategie per "appiattire la curva".
Utilizzare FCM solo per casi d'uso appropriati
Esistono alcuni casi d'uso in cui l'utilizzo di FCM per inviare una notifica non è necessario o appropriato.
Ad esempio, per le notifiche degli eventi del calendario, puoi pianificare un'attività locale nella tua app per visualizzare una notifica negli orari appropriati invece di inviarla dal server dell'app. Limita i messaggi FCM alle sincronizzazioni del calendario.
Evitare picchi
Un anti-modello di ridimensionamento consiste nell'inviare notifiche FCM con la rapidità consentita dai sistemi, invece di applicare la limitazione sul lato server. Considera quanto segue:
- Tutti i tuoi clienti devono ricevere la stessa notifica entro un intervallo di 1 minuto? Una finestra di consegna di 5 minuti, ad esempio, soddisferebbe comunque le tue esigenze aziendali?
- I tuoi clienti possono essere segmentati in base alla priorità per attenuare i picchi?
- È possibile programmare in anticipo le notifiche?
Ove possibile : evita strategie che portino all'esaurimento immediato della tua quota di invio FCM, per poi ripetere lo schema non appena il bucket di token si riempie. Questo modello di accesso crea problemi di bilanciamento del carico per FCM e i suoi sistemi dipendenti. Aumentare il traffico il più gradualmente possibile. Come minimo, aumenta da 0 all'RPS massimo in una finestra temporale di 60 secondi. Preferisci finestre più lunghe per un RPS più elevato.
Evita il traffico "ogni ora".
Ove possibile : evitare di inviare messaggi entro una finestra di 2 minuti dopo ciascuno dei minuti: 00,: 15,: 30 e: 45.
Implementare la limitazione lato server
Implementa la limitazione lato server per monitorare e gestire il flusso di traffico verso FCM.
Gestione dei tentativi
Sebbene FCM si impegni a garantire un'elevata disponibilità, a volte alcune richieste scadono o falliscono. Anche se i motivi variano, le seguenti best practice ottimizzano il comportamento dei nuovi tentativi per recapitare i messaggi il prima possibile riducendo al minimo l'impatto sulla congestione del traffico.
Timeout
Impostare almeno un timeout di 10 secondi per le richieste di invio prima di riprovare. La maggior parte delle chiamate di procedura remota interne di FCM utilizzano un timeout di 10 secondi.
Errori
- Per errori 400, 401, 403, 404: interrompere e non riprovare.
- Per errori 429: riprova dopo aver atteso la durata impostata nell'intestazione retry-after. Se non è impostata alcuna intestazione riprova dopo, il valore predefinito è 60 secondi.
- Per 500 errori: riprovare con backoff esponenziale.
Backoff esponenziale
Per evitare l'amplificazione dei tentativi, implementare il backoff esponenziale con jitter per i tentativi di richiesta. Firebase Admin SDK, ad esempio, implementa il backoff esponenziale.
Ecco alcune altre impostazioni consigliate:
- Intervallo minimo: non ritentare immediatamente una richiesta non riuscita con FCM. Attendere almeno 10 secondi prima di ritentare una richiesta non riuscita.
- Intervallo massimo: imposta un intervallo massimo per eliminare le richieste che non sono più tempestive, invece di riprovare all'infinito.
Se una richiesta viene ripetuta continuamente con backoff esponenziale e continua a fallire 60 minuti dopo, viene erroneamente classificata come errore riproducibile oppure FCM sta riscontrando un'interruzione in cui i nuovi tentativi potrebbero inavvertitamente esacerbare la situazione.
Crea piani di implementazione e rollback e apporta modifiche graduali
Quando si apportano modifiche al traffico su larga scala, come l'aumento del traffico verso FCM o lo spostamento del traffico tra regioni o reti, la progettazione di un piano di implementazione/rollback e l'implementazione di modifiche graduali proteggerà i tuoi utenti, il tuo servizio e FCM.
- Un piano di implementazione allinea le aspettative per le parti interessate. In alcune situazioni (discusse di seguito), potresti voler condividere in anticipo il tuo piano di implementazione con il team FCM per evitare sorprese.
- Un piano di rollback consente di tenere conto degli imprevisti e di preparare meccanismi per il ripristino rapido e sicuro da guasti imprevisti.
- Apportare cambiamenti graduali ha due aspetti:
- Aumenti "per gradi": i passaggi dovrebbero essere 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% o più fini. " Immergere " (osservare il comportamento del sistema sotto carico) ogni passaggio per 1 giorno o 1 settimana. Ciò consente di individuare potenziali problemi prima del successivo "step-up"
- Aumento graduale del traffico: quando si esegue ogni "passo" per aumentare il traffico, livellarlo nell'arco di almeno un'ora. Ciò consente all'infrastruttura di bilanciamento del carico di FCM di dimensionare adeguatamente il nuovo traffico riducendo al minimo il rischio di hotspot e congestione.
Ecco uno scenario ipotetico per la migrazione di 500.000 RPS a livello globale dall'API HTTP legacy di FCM all'API HTTP v1 di FCM:
| Settimana | Fare un passo | Strategia di accelerazione graduale |
|---|---|---|
| 0 | Aumento dell'1%. | Aumenta senza problemi da 0 a 5.000 RPS a FCM HTTP v1 nel corso di un'ora. |
| 1 | Aumento del 5%. | Aumenta gradualmente da 5.000 a 25.000 RPS in 2 ore. |
| 2 | Aumento del 10%. | Aumenta gradualmente da 25.000 a 50.000 RPS in 2 ore |
| 3 | Aumento del 25%. | Aumento da 50.000 a 125.000 RPS in 3 ore |
| 4 | Aumento del 50%. | Aumento da 125.000 a 250.000 RPS in 6 ore |
| 5 | Aumento del 75%. | Aumento da 250.000 a 375.000 RPS in 6 ore |
| 6 | Accelerazione al 100%. | Aumento da 375.000 a 500.000 RPS in 6 ore |
Piano di rollback ipotetico:
- Se la latenza del 95 percentile aumenta fino a superare i 500 ms o se il rapporto di errore supera l'1% per più di un'ora in qualsiasi passaggio, utilizzare la configurazione dinamica per tornare immediatamente al passaggio precedente.
- Continuare i rollback ai passaggi precedenti finché la latenza e il rapporto di errore non ritornano ai livelli nominali.
Quando rivolgersi a FCM
Contatta FCM tramite il supporto Firebase se si verifica una delle seguenti condizioni:
- Le quote predefinite non soddisfano più il tuo caso d'uso
- Stai modificando i tuoi modelli di invio entro un periodo di 3 mesi su una scala di 100.000 RPS a livello globale o 30.000 RPS a livello continentale.