Ganz gleich, ob Sie eine neue App entwickeln oder bereits einen Dienst mit hohem Traffic betreiben – in diesem Leitfaden finden Sie Informationen und Empfehlungen dazu, wie Sie mit FCM reibungslos skalieren können. 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“ (Queries per second, QPS) verwendet.
Kontingent-Tokens, Token-Buckets und Aufstockungen: Beim Senden von Nachrichten an die FCM HTTP v1 API verbraucht jede Anfrage innerhalb eines bestimmten Zeitraums ein zugewiesenes Kontingent-Token. Dieses Fenster, das als Token Bucket bezeichnet wird, wird am Ende des Zeitfensters wieder aufgefüllt. Beispiel: Die HTTP v1 API weist jedem 1-Minuten-Token-Bucket 600.000 Kontingent-Tokens zu, die am Ende jedes 1-Minuten-Intervalls wieder aufgefüllt werden.
Serverseitige Drosselung: Wenn das Traffic-Volumen die Kapazität des FCM-Dienstes überschreitet, werden Anfragen, die die Bereitstellungskapazität überschreiten, abgelehnt, um den Eingangsfluss zu begrenzen. 429-Fehlerantworten mit retry-after-Headern können zurückgegeben werden, um anzugeben, dass Sie einen bestimmten Zeitraum warten sollten, bevor Sie die Anfrage noch einmal versuchen.
Clientseitige Drosselung: Wenn Clients Fehler bei Anfragen, hohe Latenz oder 429-Fehler feststellen, sollten sie den ausgehenden Traffic freiwillig begrenzen, um eine Verschärfung der Überlastung zu vermeiden.
Exponentieller Backoff: Beim Wiederholen von Fehlern werden exponentiell zunehmende Zeitverzögerungen hinzugefügt. Beispiel: 1 Sekunde, 2 Sekunden, 4 Sekunden, 8 Sekunden, 16 Sekunden, 32 Sekunden usw.
Jitter: Vermeidung von wiederholten Anfragen in genauen Intervallen. Beim Jittern werden die Verzögerungen für die Wiederholungen durch einen Zufallsvorgang variiert, um sie gleichmäßig über die Zeit zu verteilen (z. B. 0,9 Sekunden, 2,3 Sekunden, 4,1 Sekunden, 8,5 Sekunden, 17,9 Sekunden, 34,7 Sekunden).
Verstärkung durch Wiederholungsversuche: Wenn fehlgeschlagene Anfragen ohne exponentielles Backoff/Jitter wiederholt werden, summieren sie sich häufig und erhöhen die aktuelle Traffic-Last, was zu einer möglichen „Verstärkung“ und Verschlimmerung von Verkehrsüberlastungen führen kann.
Das Problem: Trafficspitzen
FCM verarbeitet Millionen von Anfragen pro Sekunde (RPS). Trafficspitzen sind der Hauptgrund für systemische Überlastungen, Latenzprobleme und Ausfälle.
Was sind Spitzen bei den Zugriffen?
Es gibt verschiedene Arten von Traffic-Spitzen.
Stündliche Spitzen: FCM erhält in den ersten 30 Sekunden bis 2 Minuten jeder Stunde mehr als doppelt so viel Traffic. Ähnliche, aber kleinere Spitzen sind auch zur halben und zur Viertelstunde zu beobachten (Beispiele: 00:15, 00:30, 00:45).
Wiederholte Versuche:Wenn fehlgeschlagene oder abgelaufene Anfragen ohne exponentielles Backoff wiederholt werden, kann es zu wiederholten Traffic-Wellen kommen, die sich auf bestehende Traffic-Spitzen auftürmen.
Plötzliche ��nderungen des Traffic-Musters: Wenn neuer Traffic an FCM weitergeleitet oder Traffic zwischen Regionen an FCM verschoben wird, ohne dass Faktoren wie eine schrittweise Steigerung berücksichtigt werden, kann es zu Spitzen kommen.
Vorzeitige Inanspruchnahme von Kontingenttokens: Wenn Sie alle Kontingenttokens zu Beginn des Kontingentzeitraums aufbrauchen, anstatt die Anfragen gleichmäßig auf die Kontingentzeiträume zu verteilen, kommt es zu Ein-/Aus-Schwankungen, die nur schwer und kostenintensiv auszugleichen sind.
Besondere Ereignisse: Trafficspitzen an Feiertagen (Silvester) oder bei Sportveranstaltungen (FIFA-Weltmeisterschaft).
Trafficspitzen beheben, indem die Kurve „abgeflacht“ wird
In diesem Abschnitt werden Strategien beschrieben, mit denen sich Traffic-Spitzen nach Möglichkeit abflachen lassen.
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 nicht angemessen ist.
Beispielsweise können Sie für Benachrichtigungen zu Kalenderereignissen eine lokale Aufgabe in Ihrer App planen, um eine Benachrichtigung zur richtigen Zeit anzuzeigen, anstatt sie von Ihrem App-Server zu senden. Begrenzen Sie FCM-Nachrichten auf Kalendersynchronisierungen.
Spitzen vermeiden
Ein Anti-Muster 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 Kunden innerhalb von einer Minute dieselbe Benachrichtigung erhalten? Würde ein Lieferfenster von 5 Minuten beispielsweise Ihren Geschäftsanforderungen gerecht werden?
- Können Ihre Kunden nach Priorität segmentiert werden, um die Spitzen abzufedern?
- Können Benachrichtigungen im Voraus geplant werden?
Nach Möglichkeit: Vermeiden Sie Strategien, die dazu führen, dass Ihr FCM-Sendelimit sofort ausgeschöpft wird, nur um das Muster zu wiederholen, sobald Ihr Token-Bucket wieder aufgefüllt ist. Dieses Zugriffsmuster führt zu Load Balancing-Problemen für FCM und die zugehörigen Systeme. Steigern Sie den Traffic so schrittweise wie möglich. Die Anzahl der Anfragen pro Sekunde muss innerhalb von 60 Sekunden von 0 auf die maximale Anzahl der Anfragen pro Sekunde ansteigen. Längere Zeitfenster eignen sich für eine höhere RPS.
Stoßzeiten vermeiden
Nach Möglichkeit: Senden Sie keine Nachrichten innerhalb von zwei Minuten nach den Minuten 00, 15, 30 und 45.
Serverseitige Drosselung implementieren
Implementieren Sie eine serverseitige Drosselung, um den Trafficfluss zu FCM zu überwachen und zu verwalten.
Wiederholungsversuche verarbeiten
FCM ist zwar bestrebt, eine hohe Verfügbarkeit zu bieten, aber manchmal kommt es zu Zeitüberschreitungen oder Fehlern bei Anfragen. Die Gründe dafür sind vielfältig. Mit den folgenden Best Practices lässt sich das Wiederholungsverhalten optimieren, um Nachrichten so schnell wie möglich zuzustellen und gleichzeitig die Auswirkungen auf die Verkehrsüberlastung zu minimieren.
Zeitlimits
Legen Sie für Sendeanfragen eine Zeitüberschreitung von mindestens 10 Sekunden fest, bevor Sie es noch einmal versuchen. Die meisten internen Remote Procedure Calls von FCM verwenden eine Zeitüberschreitung von 10 Sekunden.
Fehler
- Bei Fehlern 400, 401, 403 und 404: Abbrechen und nicht noch einmal versuchen.
- Bei 429-Fehlern: Wiederholen Sie den Vorgang, nachdem die in der Kopfzeile „retry-after“ angegebene Dauer abgelaufen ist. 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 Verstärkung von Wiederholungsversuchen zu vermeiden, implementieren Sie für Wiederholungsversuche einen exponentiellen Backoff mit Jitter. Das Firebase Admin SDK implementiert beispielsweise einen exponentiellen Backoff.
Hier sind einige weitere empfohlene Einstellungen:
- Mindestintervall: Eine fehlgeschlagene Anfrage darf nicht sofort noch einmal mit FCM versucht werden. Warten Sie mindestens 10 Sekunden, bevor Sie eine fehlgeschlagene Anfrage wiederholen.
- Maximalintervall: Legen Sie ein maximales Intervall für das Löschen von Anfragen fest, die nicht mehr aktuell sind, anstatt sie unbegrenzt zu wiederholen.
Wenn eine Anfrage wiederholt mit exponentiellem Backoff versucht wird und 60 Minuten später immer noch fehlschlägt, wurde sie entweder fälschlicherweise als wiederholbarer Fehler kategorisiert oder es liegt ein Ausfall bei FCM vor, bei dem Wiederholungen die Situation versehentlich verschlimmern können.
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 den Traffic auf Regionen oder Netzwerke verteilen, sollten Sie einen Roll-out-/Rollback-Plan erstellen und nach und nach Änderungen implementieren, um Ihre Nutzer, Ihren Dienst und FCM zu schützen.
- Ein Roll-out-Plan stimmt die Erwartungen der Stakeholder ab. In bestimmten Situationen (siehe unten) sollten Sie Ihren Roll-out-Plan vorab mit dem FCM-Team teilen, um unerwartete Probleme zu vermeiden.
- Mit einem Rollback-Plan können Sie auf unvorhergesehene Ereignisse reagieren und Mechanismen vorbereiten, um bei unerwarteten Fehlern schnell und sicher wiederherzustellen.
- Das hat zwei Aspekte:
- „Stufenweise“ Steigerung: Die Schritte sollten 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% oder feiner sein. Beobachten Sie das Systemverhalten unter Last für jeden Schritt für einen Tag bis eine Woche. So können Sie potenzielle Probleme vor der nächsten Stufe erkennen.
- Nach und nach mehr Traffic: Wenn Sie die Anzahl der Zugriffe schrittweise erhöhen, sollten Sie dies über einen Zeitraum von mindestens einer Stunde tun. So kann die Load Balancing-Infrastruktur von FCM den neuen Traffic angemessen skalieren und gleichzeitig das Risiko von Hotspots und Überlastungen minimieren.
Hier ist ein hypothetisches Szenario für die Migration von 500.000 RPS weltweit von der alten FCM HTTP API zur FCM HTTP v1 API:
| Woche | Step | Strategie für schrittweise Steigerung |
|---|---|---|
| 0 | 1% Steigerung | Steigern Sie die Anzahl der Anfragen pro Sekunde (RPS) innerhalb einer Stunde schrittweise von 0 auf 5.000 RPS für FCM HTTP v1. |
| 1 | 5% Steigerung | Eine stufenlose Steigerung von 5.000 RPS auf 25.000 RPS über einen Zeitraum von 2 Stunden. |
| 2 | 10% Steigerung | Nach zwei Stunden stufenweise von 25.000 auf 50.000 RPS hochfahren |
| 3 | 25% Steigerung | Steigerung von 50.000 auf 125.000 RPS über einen Zeitraum von 3 Stunden |
| 4 | 50% Steigerung | Steigerung von 125.000 auf 250.000 RPS über einen Zeitraum von 6 Stunden |
| 5 | 75% Steigerung | Steigerung von 250.000 auf 375.000 RPS über einen Zeitraum von 6 Stunden |
| 6 | 100% Steigerung | Steigerung von 375.000 auf 500.000 RPS über einen Zeitraum von 6 Stunden |
Hypothetischer Rollback-Plan:
- Wenn die Latenz des 95. Perzentils auf über 500 ms ansteigt oder die Fehlerquote bei einem beliebigen Schritt länger als eine Stunde lang 1% überschreitet, verwenden Sie die dynamische Konfiguration, um sofort zum vorherigen Schritt zurückzukehren.
- Führen Sie Rollbacks zu früheren Schritten so lange durch, bis Latenz und Fehlerquote wieder auf den Normalwert zurückgekehrt sind.
Wann Sie sich an FCM wenden sollten
Wenden Sie sich an den FCM-Support über den Firebase-Support, wenn einer der folgenden Punkte zutrifft:
- Die Standardkontingente erfüllen Ihren Anwendungsfall nicht mehr
- Sie ändern Ihre Versandmuster innerhalb eines Zeitraums von drei Monaten auf einer Skala von 100.000 RPS weltweit oder 30.000 RPS kontinental.