Unabhängig davon, ob Sie eine neue App entwickeln oder bereits einen stark frequentierten Dienst betreiben, können Sie von den Erkenntnissen und Empfehlungen dieses Leitfadens für eine reibungslose Skalierung mit FCM profitieren. Diese Konzepte und Vorgehensweisen können Ihnen dabei helfen, negative Auswirkungen zu vermeiden, wenn Sie große Mengen an Nachrichten versenden müssen.
Schlüsselbegriffe und Konzepte
Nachrichtenanforderung : Eine FCM-Nachrichtenanforderung; wird austauschbar mit „Anfrage“, „Nachricht“ oder „Abfrage“ verwendet.
Anfragen pro Sekunde (RPS) : Eine Metrik zur Beschreibung der Rate eingehender Anfragen an FCM; wird austauschbar mit Abfragen pro Sekunde (QPS) verwendet.
Kontingent-Tokens, Token-Buckets und Auffüllungen : Beim Senden von Nachrichten über die FCM-HTTP-v1-API verbraucht jede Anfrage ein zugewiesenes Kontingent-Token in einem bestimmten Zeitfenster. Dieses Fenster, „ Token Bucket “ genannt, wird am Ende des Zeitfensters vollständig aufgefüllt . Beispiel: Die HTTP v1-API weist 600.000 Kontingent-Tokens für jeden 1-Minuten-Token-Bucket zu, der am Ende jedes 1-Minuten-Fensters vollständig aufgefüllt wird.
Serverseitige Drosselung : Wenn das Datenverkehrsvolumen die Kapazität des FCM-Dienstes überschreitet, werden Anfragen, die über die Bereitstellungskapazität hinausgehen, abgelehnt, um den Eingangsfluss zu begrenzen. Möglicherweise werden 429 Fehlerantworten mit retry-after Headern zurückgegeben, um darauf hinzuweisen, dass Sie einen bestimmten Zeitraum warten sollten, bevor Sie die Anforderung erneut versuchen.
Clientseitige Drosselung : Wenn Clients Anforderungsfehler, hohe Latenz oder 429 Fehler feststellen, sollten sie den Ausgangsfluss freiwillig begrenzen, um eine Verschärfung der Überlastung zu vermeiden.
Exponentieller Backoff : Fügen Sie bei der Wiederholung von Fehlern exponentiell zunehmende Zeitverzögerungen hinzu. Zum Beispiel: 1er, 2er, 4er, 8er, 16er, 32er.
Jittering : Vermeidung der Wiederholung von Anfragen in exakten Abständen. Beim Jitter variieren Sie die Wiederholungsverzögerungen durch einen zufälligen Prozess, 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 erneut versucht werden, häufen sie sich häufig an und erhöhen die laufende Verkehrslast, was möglicherweise zu einer „Verstärkung“ und Verschlimmerung von Verkehrsstauproblemen führt.
Das Problem: Verkehrsspitzen
FCM verarbeitet Millionen von Anfragen pro Sekunde (RPS). Der größte Faktor für systemische Überlastung, Latenzprobleme und Ausfälle sind Verkehrsspitzen.
Was ist Spitzenverkehr?
Es gibt verschiedene Arten von Verkehrsspitzen.
Zu jeder vollen Stunde auftretende Spitzen: FCM empfängt in den ersten 30 Sekunden bis 2 Minuten jeder Stunde mehr als das Doppelte des Datenverkehrs. Ähnliche, wenn auch geringere Spitzen werden auch bei den Halbstunden- und Viertelstundenmarken beobachtet (Beispiele: 00:15, 00:30, 00:45).
Wiederholungsverstärkung : Die Wiederholung fehlgeschlagener oder abgelaufener Anfragen ohne exponentiellen Backoff kann zu sich wiederholenden Datenverkehrswellen über bestehenden Datenverkehrsspitzen führen.
Abrupte Änderungen des Verkehrsmusters: Die Umleitung von neuem Verkehr zu FCM oder die Verlagerung des Verkehrs zu FCM über Regionen hinweg ohne Glättungsfaktoren wie eine allmähliche Steigerung kann zu Spitzen führen.
Vorgezogene Kontingent-Token-Nutzung: Die Erschöpfung aller Kontingent-Tokens zu Beginn der Kontingentfenster, anstatt die Anforderungen gleichmäßig über die Kontingentfenster zu verteilen, führt zu Ein-Aus-Schwankungen, deren Lastausgleich schwierig und teuer ist.
Besondere Ereignisse: Verkehrsspitzen an Feiertagen (Silvester) oder bei Sportveranstaltungen ( FIFA Fußballweltmeisterschaft ).
Beheben Sie Verkehrsspitzen, indem Sie die Kurve abflachen.
In diesem Abschnitt werden Strategien beschrieben, um Traffic-Spitzen nach Möglichkeit auszugleichen – Strategien zur „Abflachung der Kurve“.
Verwenden Sie FCM nur für entsprechende Anwendungsfälle
Es gibt einige Anwendungsfälle, in denen die Verwendung von FCM zur Übermittlung einer Benachrichtigung nicht notwendig oder angemessen ist.
Für Kalenderereignisbenachrichtigungen 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. Beschränken Sie FCM-Nachrichten auf Kalendersynchronisierungen.
Vermeiden Sie Spitzen
Ein Skalierungs-Anti-Pattern besteht darin, FCM-Benachrichtigungen so schnell zu senden, wie es die Systeme zulassen, anstatt eine serverseitige Drosselung anzuwenden. Folgendes berücksichtigen:
- Müssen alle Ihre Kunden innerhalb eines Zeitfensters von einer Minute die gleiche Benachrichtigung erhalten? Würde beispielsweise ein Lieferfenster von 5 Minuten immer noch Ihren Geschäftsanforderungen entsprechen?
- Können Ihre Kunden nach Priorität segmentiert werden, um Spitzen auszugleichen?
- Können Ihre Benachrichtigungen im Voraus geplant werden?
Wo immer möglich : Vermeiden Sie Strategien, die dazu führen, dass Ihr FCM-Sendekontingent sofort erschöpft ist, und wiederholen Sie das Muster, sobald Ihr Token-Bucket wieder aufgefüllt ist. Dieses Zugriffsmuster führt zu Lastausgleichsproblemen für FCM und seine abhängigen Systeme. Erhöhen Sie den Verkehr so langsam wie möglich. Steigen Sie mindestens über ein Zeitfenster von 60 Sekunden von 0 auf den maximalen RPS an. Bevorzugen Sie längere Fenster für höhere RPS.
Vermeiden Sie den Verkehr zu jeder vollen Stunde
Wenn möglich : Vermeiden Sie das Senden von Nachrichten innerhalb eines Zeitfensters von 2 Minuten nach den Minutenmarkierungen :00, :15, :30 und :45.
Implementieren Sie serverseitige Drosselung
Implementieren Sie eine serverseitige Drosselung, um den Datenverkehr zum FCM zu überwachen und zu verwalten.
Umgang mit Wiederholungsversuchen
Während FCM eine hohe Verfügbarkeit anstrebt, kann es bei einigen Anfragen zu Zeitüberschreitungen oder Fehlschlägen kommen. Obwohl die Gründe unterschiedlich sind, optimieren die folgenden Best Practices das Wiederholungsverhalten, um Nachrichten so schnell wie möglich zuzustellen und gleichzeitig die Auswirkungen auf Verkehrsstaus zu minimieren.
Auszeiten
Legen Sie für Sendeanfragen eine Zeitüberschreitung von mindestens 10 Sekunden fest, bevor Sie es erneut versuchen. Die meisten internen Remoteprozeduraufrufe von FCM verwenden ein Zeitlimit von 10 Sekunden.
Fehler
- Für 400, 401, 403, 404 Fehler: Abbrechen und nicht erneut versuchen.
- Bei 429-Fehlern: Versuchen Sie es erneut, nachdem Sie auf die im Retry-After-Header festgelegte Dauer gewartet haben. Wenn kein Retry-After-Header festgelegt ist, beträgt der Standardwert 60 Sekunden.
- Bei 500 Fehlern: Wiederholen Sie den Versuch mit exponentiellem Backoff.
Exponentieller Backoff
Um eine Wiederholungsverstärkung zu vermeiden, implementieren Sie ein exponentielles Backoff mit Jitter für Wiederholungsanfragen. Das Firebase Admin SDK implementiert beispielsweise einen exponentiellen Backoff.
Hier sind einige weitere empfohlene Einstellungen:
- Mindestintervall: Versuchen Sie eine fehlgeschlagene Anfrage nicht sofort mit FCM erneut. Warten Sie mindestens 10 Sekunden, bevor Sie eine fehlgeschlagene Anfrage erneut versuchen.
- Maximales Intervall: Legen Sie ein maximales Intervall für das Löschen von Anfragen fest, die nicht mehr zeitgemäß sind, anstatt es auf unbestimmte Zeit erneut zu versuchen.
Wenn eine Anfrage ständig mit exponentiellem Backoff wiederholt wird und 60 Minuten später immer noch fehlschlägt, wird sie entweder fälschlicherweise als wiederholbarer Fehler kategorisiert oder es liegt ein Ausfall von FCM vor, bei dem Wiederholungsversuche die Situation unbeabsichtigt verschlimmern können.
Erstellen Sie Rollout- und Rollback-Pläne und nehmen Sie schrittweise Änderungen vor
Wenn Sie umfangreiche Datenverkehrsänderungen vornehmen, wie z. B. die Erhöhung des Datenverkehrs zu FCM oder die Verlagerung des Datenverkehrs über Regionen oder Netzwerke hinweg, schützen Sie Ihre Benutzer, Ihren Dienst und FCM durch die Entwicklung eines Rollout-/Rollback-Plans und die Implementierung schrittweiser Änderungen.
- Ein Rollout-Plan bringt die Erwartungen der Stakeholder in Einklang. In bestimmten Situationen (siehe unten) möchten Sie Ihren Rollout-Plan möglicherweise vorab mit dem FCM-Team teilen, um Überraschungen zu vermeiden.
- Mit einem Rollback-Plan können Sie Eventualitäten berücksichtigen und Mechanismen für eine schnelle und sichere Wiederherstellung nach unvorhergesehenen Ausfällen vorbereiten.
- Schrittweise Änderungen vorzunehmen hat zwei Aspekte:
- „Schrittweise“ Hochläufe: Die Schritte sollten 1 % -> 5 % -> 10 % -> 25 % -> 50 % -> 75 % -> 100 % oder feiner sein. „ Soak “ (Systemverhalten unter Last beobachten) jeden Schritt für 1 Tag bis 1 Woche. Dadurch können Sie potenzielle Probleme erkennen, bevor Sie den nächsten Schritt unternehmen.
- Allmähliche Steigerung des Verkehrsaufkommens: Wenn Sie jeden „Schritt“ zur Steigerung des Verkehrs unternehmen, glätten Sie den Verkehr über einen Zeitraum von mindestens einer Stunde. Dadurch kann die Load-Balancing-Infrastruktur von FCM Ihren neuen Datenverkehr angemessen skalieren und gleichzeitig das Potenzial für Hotspots und Überlastungen minimieren.
Hier ist ein hypothetisches Szenario für die globale Migration von 500.000 RPS von der FCM Legacy HTTP API zur FCM HTTP v1 API:
| Woche | Schritt | Schrittweise Hochlaufstrategie |
|---|---|---|
| 0 | 1 % Steigerung | Steigern Sie innerhalb einer Stunde reibungslos von 0 auf 5.000 RPS auf FCM HTTP v1. |
| 1 | 5 % Steigerung | Steigern Sie innerhalb von 2 Stunden reibungslos von 5.000 auf 25.000 RPS. |
| 2 | 10 % Steigerung | Steigern Sie innerhalb von 2 Stunden reibungslos von 25.000 auf 50.000 RPS |
| 3 | 25 % Steigerung | Steigerung von 50.000 auf 125.000 RPS über 3 Stunden |
| 4 | 50 % Hochlauf | Anstieg von 125.000 auf 250.000 RPS über 6 Stunden |
| 5 | 75 % Hochlauf | Anstieg von 250.000 auf 375.000 RPS über 6 Stunden |
| 6 | 100 % Hochlauf | Anstieg von 375.000 auf 500.000 RPS über 6 Stunden |
Hypothetischer Rollback-Plan:
- Wenn die 95-Perzentil-Latenz auf mehr als 500 ms ansteigt oder die Fehlerquote bei einem Schritt länger als eine Stunde 1 % überschreitet, verwenden Sie die dynamische Konfiguration, um sofort zum vorherigen Schritt zurückzukehren.
- Setzen Sie die Rollbacks zu früheren Schritten fort, bis Latenz und Fehlerquote wieder auf das Nennniveau zurückkehren.
Wann Sie sich an FCM wenden sollten
Wenden Sie sich über den Firebase-Support an FCM, wenn einer der folgenden Punkte zutrifft:
- Standardkontingente entsprechen nicht mehr Ihrem Anwendungsfall
- Sie ändern Ihre Sendemuster innerhalb eines 3-Monats-Fensters in einer Größenordnung von 100.000 RPS weltweit oder 30.000 RPS kontinental.