Unabhängig davon, ob Sie eine neue App entwickeln oder bereits einen Dienst mit hohem Traffic betreiben, können Sie von den Informationen und Empfehlungen in diesem Leitfaden profitieren, um mit FCM reibungslos zu skalieren. Mit diesen Konzepten und Praktiken können Sie negative Auswirkungen vermeiden, wenn Sie große Mengen an Nachrichten senden müssen.
Wichtige Begriffe und Konzepte
Nachrichtenanfrage: Eine FCM-Nachrichtenanfrage. Wird synonym mit „Anfrage“, „Nachricht“ oder „Abfrage“ verwendet.
Anfragen pro Sekunde (RPS): Ein Messwert, der die Rate der eingehenden Anfragen an FCM beschreibt. Wird synonym mit „Abfragen pro Sekunde“ (QPS) verwendet.
Kontingent-Tokens, Token-Buckets und Auffüllungen: Wenn Sie Nachrichten an die FCM HTTP v1 API senden, verbraucht jede Anfrage ein zugewiesenes Kontingent-Token in einem bestimmten Zeitfenster. Dieses Fenster, das als „Token Bucket“ bezeichnet wird, wird am Ende des Zeitfensters wieder vollständig aufgefüllt. Beispiel: Die HTTP v1 API weist 600.000 Kontingent-Tokens für jeden 1-minütigen Token-Bucket zu, der am Ende jedes 1-minütigen Zeitfensters vollständig aufgefüllt wird.
Serverseitige Drosselung: Wenn das Trafficvolumen die Kapazität des FCM-Dienstes überschreitet, werden Anfragen, die über die Bereitstellungskapazität hinausgehen, abgelehnt, um den eingehenden Datenfluss zu begrenzen. Möglicherweise werden 429-Fehlerantworten mit retry-after-Headern zurückgegeben, die darauf hinweisen, dass Sie einen bestimmten Zeitraum warten sollten, bevor Sie die Anfrage noch einmal senden.
Clientseitige Drosselung: Wenn Clients Anfragefehler, hohe Latenz oder 429-Fehler feststellen, sollten sie den ausgehenden Traffic freiwillig begrenzen, um eine Verschlimmerung der Überlastung zu vermeiden.
Exponentieller Backoff: Fügen Sie bei der Wiederholung von Fehlern exponentiell zunehmende Zeitverzögerungen hinzu. Beispiel: 1 s, 2 s, 4 s, 8 s, 16 s, 32 s usw.
Jittering: Vermeiden Sie es, Anfragen in exakten Intervallen zu wiederholen. Beim Jittering werden die Verzögerungen bei Wiederholungsversuchen durch einen zufälligen Prozess variiert, um sie gleichmäßig über die Zeit zu verteilen (z. B. 0,9 s, 2,3 s, 4,1 s, 8,5 s, 17,9 s, 34,7 s).
Wiederholungsverstärkung: Wenn fehlgeschlagene Anfragen ohne exponentiellen Backoff/Jitter wiederholt werden, häufen sie sich oft an und erhöhen die laufende Traffic-Last. Dadurch können Traffic-Überlastungsprobleme „verstärkt“ und verschlimmert werden.
Das Problem: Trafficspitzen
FCM verarbeitet Millionen von Anfragen pro Sekunde (RPS). Der größte Verursacher von systemischen Überlastungen, Latenzproblemen und Ausfällen sind Trafficspitzen.
Was ist Traffic mit Spitzen?
Es gibt verschiedene Arten von Traffic-Spitzen.
Spitzen zur vollen Stunde: FCM erhält in den ersten 30 Sekunden bis 2 Minuten jeder Stunde mehr als doppelt so viel Traffic. Ähnliche, wenn auch geringere Spitzen sind auch zur halben und viertel Stunde zu beobachten (Beispiele: 00:15, 00:30, 00:45).
Wiederholungsverstärkung: Wenn fehlgeschlagene oder abgelaufene Anfragen ohne exponentiellen Backoff wiederholt werden, kann sich dies zu wiederholten Traffic-Wellen zusätzlich zu bestehenden Traffic-Spitzen summieren.
Abrupte Änderungen des Traffic-Musters: Wenn neuer Traffic an FCM weitergeleitet oder Traffic über Regionen hinweg ohne Glättungsfaktoren wie schrittweise Erhöhung an FCM verschoben wird, kann dies zu Spitzen führen.
Front-Loading-Kontingenttoken-Nutzung: Wenn Sie alle Kontingenttoken zu Beginn der Kontingentfenster aufbrauchen, anstatt die Anfragen gleichmäßig über die Kontingentfenster zu verteilen, entstehen On-Off-Schwankungen, die sich nur schwer und mit hohem Aufwand ausgleichen lassen.
Besondere Ereignisse: Trafficspitzen an Feiertagen (Silvester) oder bei Sportereignissen (FIFA-Weltmeisterschaft).
Trafficspitzen durch „Abflachen der Kurve“ beheben
In diesem Abschnitt werden Strategien beschrieben, mit denen Sie Trafficspitzen nach Möglichkeit ausgleichen können, um die Kurve abzuflachen.
FCM nur für geeignete Anwendungsfälle verwenden
In einigen Anwendungsfällen ist die Verwendung von FCM zum Senden einer Benachrichtigung nicht erforderlich oder nicht angemessen.
Bei Benachrichtigungen zu Kalenderterminen können Sie beispielsweise eine lokale Aufgabe in Ihrer App planen, um eine Benachrichtigung zu den entsprechenden Zeiten anzuzeigen, anstatt sie von Ihrem App-Server zu senden. FCM-Nachrichten auf Kalendersynchronisierungen beschränken.
Spitzen vermeiden
Ein Anti-Pattern bei der Skalierung besteht darin, FCM-Benachrichtigungen so schnell wie möglich zu senden, anstatt serverseitiges Throttling anzuwenden. Berücksichtigen Sie Folgendes:
- Müssen alle Ihre Kunden dieselbe Benachrichtigung innerhalb eines Zeitfensters von einer Minute erhalten? Würde beispielsweise ein Lieferfenster von 5 Minuten Ihren geschäftlichen Anforderungen noch gerecht werden?
- Können Ihre Kunden nach Priorität segmentiert werden, um die Spitzen auszugleichen?
- Können Benachrichtigungen im Voraus geplant werden?
Nach Möglichkeit: Vermeiden Sie Strategien, die dazu führen, dass Ihr FCM-Sendekontingent sofort aufgebraucht wird, nur um das Muster zu wiederholen, sobald Ihr Token-Bucket wieder aufgefüllt ist. Dieses Zugriffsmuster führt zu Problemen beim Load Balancing für FCM und die davon abhängigen Systeme. Erhöhen Sie den Traffic so schrittweise wie möglich. Erhöhen Sie die Anzahl der Anfragen pro Sekunde (RPS) innerhalb von 60 Sekunden von 0 auf den maximalen Wert. Bevorzugen Sie längere Zeiträume für höhere RPS.
Traffic zur vollen Stunde vermeiden
Wenn möglich: Vermeiden Sie das Senden von Nachrichten innerhalb eines Zeitfensters von 2 Minuten um die Minutenmarken :00, :15, :30 und :45.
Serverseitige Drosselung implementieren
Implementieren Sie serverseitiges Throttling, um den Traffic zu FCM zu überwachen und zu verwalten.
Umgang mit Wiederholungsversuchen
FCM ist auf Hochverfügbarkeit ausgelegt, aber manchmal kommt es bei einigen Anfragen zu Zeitüberschreitungen oder Fehlern. Die Gründe dafür sind unterschiedlich. Mit den folgenden Best Practices können Sie das Wiederholungsverhalten optimieren, damit Nachrichten so schnell wie möglich zugestellt werden und die Auswirkungen auf die Überlastung des Traffics minimiert werden.
Zeitlimits
Legen Sie für Sendeanfragen ein Zeitlimit von mindestens 10 Sekunden fest, bevor Sie es noch einmal versuchen. Für die meisten internen Remote-Prozeduraufrufe von FCM gilt ein Zeitlimit von 10 Sekunden.
Fehler
- Bei den Fehlern 400, 401, 403 und 404: Brechen Sie den Vorgang ab und versuchen Sie es nicht noch einmal.
- Bei 429-Fehlern: Wiederholen Sie den Vorgang, nachdem Sie die im Header „retry-after“ festgelegte Zeit gewartet haben. Wenn kein „retry-after“-Header festgelegt ist, wird standardmäßig 60 Sekunden verwendet.
- Bei 500-Fehlern: Wiederholen Sie den Vorgang mit exponentiellem Backoff.
Exponentielle Backoffs
Um eine Wiederholungsverstärkung zu vermeiden, implementieren Sie einen exponentiellen Backoff mit Jitter für Wiederholungsanfragen. Das Firebase Admin SDK implementiert beispielsweise den exponentiellen Backoff.
Hier sind einige weitere empfohlene Einstellungen:
- Mindestintervall: Wiederholen Sie eine fehlgeschlagene Anfrage mit FCM nicht sofort. Warten Sie mindestens 10 Sekunden, bevor Sie eine fehlgeschlagene Anfrage wiederholen.
- Maximales Intervall: Legen Sie ein maximales Intervall fest, nach dem Anfragen, die nicht mehr zeitgerecht sind, verworfen werden, anstatt sie unbegrenzt zu wiederholen.
Wenn eine Anfrage mit exponentiellem Backoff kontinuierlich wiederholt wird und 60 Minuten später immer noch fehlschlägt, wurde sie entweder fälschlicherweise als wiederholbarer Fehler kategorisiert oder es liegt ein FCM-Ausfall vor, bei dem Wiederholungen die Situation möglicherweise unbeabsichtigt verschlimmern.
Roll-out- und Rollback-Pläne erstellen und schrittweise Änderungen vornehmen
Wenn Sie umfangreiche Änderungen am Traffic vornehmen, z. B. den Traffic zu FCM erhöhen oder Traffic über Regionen oder Netzwerke hinweg verschieben, sollten Sie einen Rollout-/Rollback-Plan entwerfen und schrittweise Änderungen implementieren, um Ihre Nutzer, Ihren Dienst und FCM zu schützen.
- Ein Roll-out-Plan sorgt dafür, dass die Erwartungen der Stakeholder aufeinander abgestimmt sind. In bestimmten Situationen (siehe unten) kann es sinnvoll sein, Ihren Roll-out-Plan vorab mit dem FCM-Team zu teilen, um Überraschungen zu vermeiden.
- Mit einem Rollback-Plan können Sie unvorhergesehene Ereignisse berücksichtigen und Mechanismen vorbereiten, um sich schnell und sicher von unerwarteten Fehlern zu erholen.
- Eine schrittweise Änderung hat zwei Aspekte:
- Schrittweise Erhöhung: Die Schritte sollten 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% oder feiner sein. Beobachten Sie das Systemverhalten unter Last bei jedem Schritt 1 Tag bis 1 Woche lang. So können Sie potenzielle Probleme vor dem nächsten „Step-up“ erkennen.
- Schrittweise Erhöhung des Traffics: Wenn Sie den Traffic schrittweise erhöhen, sollten Sie den Traffic über einen Zeitraum von mindestens einer Stunde verteilen. So kann die Load-Balancing-Infrastruktur von FCM den neuen Traffic entsprechend skalieren und gleichzeitig das Risiko von Hotspots und Überlastungen minimieren.
Hier ist ein hypothetisches Szenario für die Migration von 500.000 Anfragen pro Sekunde weltweit von der FCM Legacy HTTP API zur FCM HTTP v1 API:
| Woche | Step | Strategie für schrittweise Erhöhung |
|---|---|---|
| 0 | 1% Hochlauf | Steigern Sie die Anzahl der Anfragen pro Sekunde (RPS) an FCM HTTP v1 im Laufe einer Stunde schrittweise von 0 auf 5.000. |
| 1 | 5% Steigerung | Steigern Sie die Anfragen pro Sekunde innerhalb von 2 Stunden gleichmäßig von 5.000 auf 25.000. |
| 2 | 10% Erhöhung | Gleichmäßiger Anstieg von 25.000 auf 50.000 Anfragen pro Sekunde über 2 Stunden |
| 3 | 25% Prozentsatz erhöhen | Hochskalierung von 50.000 auf 125.000 Anfragen pro Sekunde über 3 Stunden |
| 4 | 50% Hochlauf | Hochskalierung von 125.000 auf 250.000 Anfragen pro Sekunde über 6 Stunden |
| 5 | 75% Hochlauf | Hochskalierung von 250.000 auf 375.000 Anfragen pro Sekunde über 6 Stunden |
| 6 | 100% Prozentsatz erhöhen | Hochskalierung von 375.000 auf 500.000 Anfragen pro Sekunde über 6 Stunden |
Hypothetischer Rollback-Plan:
- Wenn die 95-Perzentil-Latenz auf mehr als 500 ms ansteigt oder die Fehlerrate bei einem beliebigen Schritt länger als eine Stunde 1% überschreitet, verwenden Sie die dynamische Konfiguration, um sofort zum vorherigen Schritt zurückzukehren.
- Fahren Sie mit Rollbacks zu früheren Schritten fort, bis die Latenz und die Fehlerquote wieder auf ein normales Niveau zurückkehren.
Wann Sie sich an FCM wenden sollten
Wenden Sie sich in den folgenden Fällen über den Firebase-Support an FCM:
- Die Standardkontingente entsprechen nicht mehr Ihrem Anwendungsfall.
- Sie ändern Ihre Sendemuster innerhalb eines Zeitraums von 3 Monaten in einem Umfang von 100.000 RPS weltweit oder 30.000 RPS kontinental.