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. Diese Konzepte und Praktiken können Ihnen helfen, negative Auswirkungen zu vermeiden, wenn Sie eine große Anzahl von Nachrichten senden müssen.
Wichtige Begriffe und Konzepte
Nachrichtenanfrage: Eine FCM-Nachrichtenanfrage, die synonym mit „Anfrage“, „Nachricht“ oder „Abfrage“ verwendet wird.
Anfragen pro Sekunde (Requests per Second, RPS): Ein Messwert, der die Rate eingehender Anfragen an FCM beschreibt. Wird synonym mit „Abfragen pro Sekunde (Queries per Second, QPS)“ verwendet.
Kontingent-Tokens, Token-Buckets und Aufladungen: Wenn Sie Nachrichten über die FCM HTTP v1 API senden, wird für jede Anfrage in einem bestimmten Zeitraum ein zugewiesenes Kontingent-Token verbraucht. Dieses Fenster, das als Token Bucket bezeichnet wird, wird am Ende des Zeitfensters wieder aufgefüllt. Beispiel: Für die HTTP v1 API werden 600.000 Kontingent-Tokens für jeden 1‑Minuten-Token-Bucket zugeteilt, der am Ende jedes 1‑Minuten-Zeitraums wieder vollständig aufgefüllt wird.
Serverseitige Drosselung: Wenn das Trafficvolumen die Kapazität des FCM-Dienstes überschreitet, werden Anfragen, die über die Verarbeitungskapazität hinausgehen, abgelehnt, um den eingehenden Datenfluss 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 bei Clients Anfragen fehlschlagen, die Latenz hoch ist oder 429-Fehler auftreten, sollten sie den ausgehenden Traffic freiwillig drosseln, um eine Überlastung zu vermeiden.
Exponentieller Backoff: Fügen Sie beim Wiederholen von Fehlern exponentiell ansteigende Zeitverzögerungen hinzu. Beispiele: 1 s, 2 s, 4 s, 8 s, 16 s, 32 s usw.
Jittering: Vermeiden von Wiederholungsversuchen in exakten Intervallen. Beim Jittering werden die Wiederholungsverzögerungen durch einen Zufallsprozess 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).
Verstärkung durch Wiederholungsversuche: Wenn fehlgeschlagene Anfragen ohne exponentiellen Backoff oder Jittering wiederholt werden, häufen sie sich oft an und erhöhen die aktuelle Traffic-Last. Dadurch können Probleme mit der Netzwerküberlastung verstärkt werden.
Das Problem: Trafficspitzen
FCM verarbeitet Millionen von Anfragen pro Sekunde (Requests per Second, RPS). Die größten Ursachen für systemische Überlastung, Latenzprobleme und Ausfälle sind Trafficspitzen.
Was sind Zugriffsspitzen?
Es gibt verschiedene Arten von Traffic-Spitzen.
Lastspitzen zu Beginn der Stunde: In den ersten 30 Sekunden bis 2 Minuten jeder Stunde empfängt FCM mehr als doppelt so viel Traffic. Ähnliche, wenn auch geringere Spitzen sind auch bei den Halb- und Viertelstundenmarken zu beobachten (Beispiele: 00:15, 00:30, 00:45).
Verstärkung durch Wiederholungsversuche:Wenn fehlgeschlagene oder abgelaufene Anfragen ohne exponentiellen Backoff wiederholt werden, kann dies zu wiederholten Traffic-Wellen zusätzlich zu bestehenden Traffic-Spitzen führen.
Plötzliche Änderungen des Traffic-Musters: Wenn neuer Traffic an FCM gesendet oder Traffic regionsübergreifend zu FCM verschoben wird, ohne dass Glättungsfaktoren wie ein schrittweiser Anstieg berücksichtigt werden, kann es zu Spitzen kommen.
Kontingent-Tokens im Voraus verwenden: Wenn Sie alle Kontingent-Tokens zu Beginn von Kontingentzeiträumen aufbrauchen, anstatt die Anfragen gleichmäßig über die Kontingentzeiträume zu verteilen, entstehen Ein-/Aus-Schwankungen, die schwer und teuer auszugleichen sind.
Besondere Ereignisse: Trafficspitzen an Feiertagen (Silvester) oder bei Sportveranstaltungen (FIFA-Weltmeisterschaft).
Trafficspitzen durch „Abflachen der Kurve“ abmildern
In diesem Abschnitt werden Strategien beschrieben, mit denen sich Trafficspitzen nach Möglichkeit abmildern lassen.
FCM nur für geeignete Anwendungsfälle verwenden
Es gibt einige Anwendungsfälle, in denen die Verwendung von FCM zum Zustellen einer Benachrichtigung nicht erforderlich oder angemessen ist.
Für Benachrichtigungen zu Kalenderterminen können Sie beispielsweise eine lokale Aufgabe in Ihrer App planen, um Benachrichtigungen zu den entsprechenden Zeiten anzuzeigen, anstatt sie von Ihrem App-Server zu senden. FCM-Nachrichten auf Kalendersynchronisierungen beschränken
Spitzen vermeiden
Ein Anti-Pattern für die Skalierung besteht darin, FCM-Benachrichtigungen so schnell wie möglich zu senden, anstatt serverseitige Drosselung anzuwenden. Berücksichtigen Sie Folgendes:
- Müssen alle Ihre Kunden dieselbe Benachrichtigung innerhalb von einer Minute erhalten? Würde ein 5-Minuten-Lieferzeitfenster beispielsweise Ihren geschäftlichen Anforderungen entsprechen?
- 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 Lastenausgleich für FCM und die zugehörigen Systeme. Steigern Sie den Traffic so langsam wie möglich. Die Anzahl der Anfragen pro Sekunde sollte innerhalb von 60 Sekunden von 0 auf den maximalen Wert ansteigen. Längere Zeitfenster sind für höhere RPS-Werte besser geeignet.
Traffic zu vollen Stunden vermeiden
Nach Möglichkeit: Senden Sie keine Nachrichten innerhalb von 2 Minuten vor oder nach den Zeitmarken :00, :15, :30 und :45.
Serverseitige Drosselung implementieren
Implementieren Sie die serverseitige Drosselung, um den Traffic zu FCM zu überwachen und zu verwalten.
Umgang mit Wiederholungsversuchen
FCM ist zwar bestrebt, eine hohe Verfügbarkeit zu bieten, aber manchmal treten Zeitüberschreitungen oder Fehler bei Anfragen auf. Die Gründe dafür sind vielfältig. Mit den folgenden Best Practices lässt sich das Verhalten bei Wiederholungsversuchen optimieren, um Nachrichten so schnell wie möglich zu senden und gleichzeitig die Auswirkungen auf die Überlastung des Datenverkehrs 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 Procedure Calls von FCM verwenden ein Zeitlimit von 10 Sekunden.
Fehler
- Bei den Fehlern 400, 401, 403 und 404 wird der Vorgang abgebrochen und nicht wiederholt.
- Bei 429-Fehlern: Versuchen Sie es noch einmal, 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: Versuchen Sie es mit exponentiellem Backoff noch einmal.
Exponentielle Backoffs
Um eine Verstärkung von Wiederholungsversuchen zu vermeiden, implementieren Sie exponentiellen Backoff mit Jittering für das Wiederholen von Anfragen. Das Firebase Admin SDK implementiert beispielsweise den exponentiellen Backoff.
Hier sind einige weitere empfohlene Einstellungen:
- Mindestintervall: Wiederholen Sie eine fehlgeschlagene Anfrage nicht sofort mit FCM. Warten Sie mindestens 10 Sekunden, bevor Sie eine fehlgeschlagene Anfrage wiederholen.
- Maximales Intervall: Legen Sie ein maximales Intervall für das Verwerfen von Anfragen fest, die nicht mehr rechtzeitig sind, anstatt sie unbegrenzt oft zu wiederholen.
Wenn eine Anfrage kontinuierlich mit exponentiellem Backoff wiederholt wird und nach 60 Minuten immer noch fehlschlägt, ist sie entweder fälschlicherweise als wiederholbarer Fehler kategorisiert oder es liegt ein Ausfall bei FCM vor, bei dem Wiederholungsversuche die Situation unbeabsichtigt verschlimmern können.
Rollout- 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 zwischen Regionen oder Netzwerken verschieben, sollten Sie einen Plan für die Einführung/das Rollback erstellen und schrittweise Änderungen vornehmen, um Ihre Nutzer, Ihren Dienst und FCM zu schützen.
- Ein Roll-out-Plan gleicht die Erwartungen der Stakeholder ab. In bestimmten Situationen (siehe unten) sollten Sie Ihren Roll-out-Plan vorab mit dem FCM-Team teilen, um Überraschungen zu vermeiden.
- Mit einem Rollback-Plan können Sie Unvorhergesehenes berücksichtigen und Mechanismen vorbereiten, um sich schnell und sicher von unerwarteten Fehlern zu erholen.
- Stufenweise Änderungen haben zwei Aspekte:
- Stufenweise Steigerung: Die Stufen sollten 1 % –> 5 % –> 10 % –> 25 % –> 50 % –> 75 % –> 100% oder feiner sein. Soak (Systemverhalten unter Last beobachten) für jeden Schritt für 1 Tag bis 1 Woche. So können Sie potenzielle Probleme vor dem nächsten „Step-up“ erkennen.
- Stufenweise Steigerung des Traffics: Wenn Sie den Traffic in einzelnen Schritten steigern, sollten Sie ihn über einen Zeitraum von mindestens einer Stunde verteilen. So kann die Lastverteilungsinfrastruktur von FCM Ihren neuen Traffic angemessen skalieren und gleichzeitig das Risiko von Hotspots und Überlastung 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 die schrittweise Einführung |
|---|---|---|
| 0 | 1% Ramp-up | Steigern Sie die Anzahl der Anfragen pro Sekunde (RPS) an die FCM HTTP v1 API im Laufe einer Stunde von 0 auf 5.000. |
| 1 | 5% Steigerung | Steigern Sie die RPS-Zahl innerhalb von 2 Stunden von 5.000 auf 25.000. |
| 2 | 10% Steigerung | Die RPS-Anzahl sollte innerhalb von 2 Stunden von 25.000 auf 50.000 gesteigert werden. |
| 3 | 25% Steigerung | Steigerung von 50.000 auf 125.000 RPS über 3 Stunden |
| 4 | 50% Steigerung | Ramp-up von 125.000 auf 250.000 RPS über 6 Stunden |
| 5 | 75% Steigerung | Ramp-up von 250.000 auf 375.000 RPS über 6 Stunden |
| 6 | 100% Ramp-up | Steigerung von 375.000 auf 500.000 RPS über 6 Stunden |
Beispiel für einen Rollback-Plan:
- Wenn die Latenz des 95. Perzentils in einem beliebigen Schritt auf mehr als 500 ms ansteigt oder das Fehlerverhältnis über 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 durch, bis Latenz und Fehlerrate wieder auf dem normalen Niveau sind.
Wann Sie sich an FCM wenden sollten
Wenden Sie sich über den Firebase-Support an FCM, wenn einer der folgenden Fälle zutrifft:
- Standardkontingente reichen für Ihren Anwendungsfall nicht mehr aus
- Sie ändern Ihre Sendemuster innerhalb eines Zeitraums von drei Monaten in einem Umfang von 100.000 RPS weltweit oder 30.000 RPS kontinental.