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. Diese Konzepte und Best Practices können Ihnen helfen, negative Auswirkungen zu 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 wieder 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. Es können 429-Fehlerantworten mit retry-after-Headern zurückgegeben werden, 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 zwischen den 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 unregelmäßiger Traffic?
Es gibt verschiedene Arten von Traffic-Spitzen.
Spitzen zur vollen Stunde: FCM empfängt 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 Sie neuen Traffic an FCM weiterleiten oder Traffic über Regionen hinweg ohne Glättungsfaktoren wie schrittweises Hochfahren an FCM verschieben, kann dies zu Spitzen führen.
Front-Loading-Kontingent-Token-Nutzung: Wenn Sie alle Kontingent-Tokens zu Beginn der Kontingentfenster aufbrauchen, anstatt die Anfragen gleichmäßig über die Kontingentfenster zu verteilen, entstehen Ein-Aus-Schwankungen, die sich nur schwer und mit hohem Aufwand ausgleichen lassen.
Besondere Ereignisse: Traffic-Spitzen während Feiertagen (Silvester) oder Sportereignissen (FIFA-Weltmeisterschaft).
Trafficspitzen durch „Abflachen der Kurve“ beheben
In diesem Abschnitt werden Strategien beschrieben, mit denen Sie Trafficspitzen nach Möglichkeit glätten können, um die Kurve abzuflachen.
FCM nur für geeignete Anwendungsfälle verwenden
Es gibt einige Anwendungsfälle, in denen die Verwendung von FCM zum Senden einer Benachrichtigung nicht erforderlich oder angemessen ist.
Beispielsweise können Sie für Benachrichtigungen zu Kalenderterminen 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 eine serverseitige Drosselung 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-Sende-Kontingent sofort aufgebraucht wird, nur um das Muster zu wiederholen, sobald Ihr Token-Bucket wieder aufgefüllt ist. Dieses Zugriffsmuster verursacht Probleme 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 RPS mindestens über einen Zeitraum von 60 Sekunden von 0 auf den maximalen Wert. Längere Zeiträume für höhere RPS bevorzugen.
Traffic zur vollen Stunde vermeiden
Nach Möglichkeit: Vermeide es, Nachrichten innerhalb von 2 Minuten nach den Minutenmarken :00, :15, :30 und :45 zu senden.
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, um Nachrichten so schnell wie möglich zuzustellen und gleichzeitig die Auswirkungen auf die Überlastung des Traffics zu minimieren.
Zeitlimits
Legen Sie für Sendeanfragen ein Zeitlimit von mindestens 10 Sekunden fest, bevor Sie es noch einmal versuchen. Die meisten internen Remote-Prozeduraufrufe von FCM haben 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, beträgt der Standardwert 60 Sekunden.
- Bei 500-Fehlern: Versuchen Sie es mit exponentiellem Backoff erneut.
Exponentielle Backoffs
Um eine Wiederholungsverstärkung zu vermeiden, implementieren Sie einen exponentiellen Backoff mit Jitter für Wiederholungsversuche. 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 aktuell sind, verworfen werden, anstatt sie unbegrenzt zu wiederholen.
Wenn eine Anfrage kontinuierlich mit exponentiellem Backoff 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 erstellen 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 kleiner sein. Beobachten Sie das Systemverhalten unter Last bei jedem Schritt für einen Tag bis eine Woche. So kannst du 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 über 2 Stunden hinweg 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 in 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 Fehlerrate 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 sind für Ihren Anwendungsfall nicht mehr ausreichend.
- Sie ändern Ihre Sendemuster innerhalb eines Zeitraums von 3 Monaten in einem Umfang von 100.000 RPS weltweit oder 30.000 RPS kontinental.