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 große Mengen an Nachrichten senden müssen.
Wichtige Begriffe und Konzepte
Nachrichtenanfrage: Eine FCM-Nachrichtenanfrage, die synonym mit „Anfrage“, „Nachricht“ oder „Abfrage“ verwendet wird.
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 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 für jeden 1-Minuten-Token-Bucket 600.000 Kontingent-Tokens zugewiesen, die am Ende jedes 1-Minuten-Zeitraums wieder vollständig aufgefüllt werden.
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. 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 Anfragenfehler, hohe Latenz oder 429-Fehler feststellen, sollten sie den ausgehenden Datenfluss freiwillig drosseln, um eine Überlastung zu vermeiden.
Exponentieller Backoff: Fügen Sie beim Wiederholen von Fehlern exponentiell ansteigende 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 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 Trafficlast. Dadurch können Probleme mit der Trafficüberlastung verstärkt werden.
Problem: Trafficspitzen
FCM verarbeitet Millionen von Anfragen pro Sekunde (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.
Spitzen zu Beginn der 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 bei den Halb- und Viertelstundenmarken zu beobachten (Beispiele: 00:15, 00:30, 00:45).
Wiederholungsversuche:Wenn fehlgeschlagene oder abgelaufene Anfragen ohne exponentiellen Backoff wiederholt werden, kann dies zu wiederholten Trafficwellen zusätzlich zu bestehenden Trafficspitzen führen.
Abrupte Änderungen des Traffics: Wenn Sie neuen Traffic an FCM weiterleiten oder Traffic regionsübergreifend zu FCM verschieben, ohne dass es glättende Faktoren wie einen schrittweisen Anstieg gibt, kann es zu Spitzen kommen.
Vorzeitige Nutzung von Kontingent-Tokens: Wenn alle Kontingent-Tokens zu Beginn von Kontingentzeiträumen aufgebraucht werden, 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 Verkehrsspitzen nach Möglichkeit abmildern lassen.
FCM nur für geeignete Anwendungsfälle verwenden
Es gibt einige Anwendungsfälle, in denen die Zustellung einer Benachrichtigung über FCM nicht erforderlich oder angemessen ist.
Für Benachrichtigungen zu Kalenderereignissen können Sie beispielsweise eine lokale Aufgabe in Ihrer App planen, um zu den entsprechenden Zeiten eine Benachrichtigung 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-minütiges Zeitfenster für die Lieferung 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 und sich das Muster wiederholt, sobald Ihr Token-Bucket wieder aufgefüllt ist. Dieses Zugriffsmuster führt zu Load-Balancing-Problemen für FCM und die zugehörigen Systeme. Erhöhen Sie den Traffic so schrittweise wie möglich. Die Anzahl der Anfragen pro Sekunde sollte innerhalb von 60 Sekunden von 0 auf den maximalen Wert ansteigen. Bei einem höheren RPS sollten Sie längere Zeiträume verwenden.
Traffic zu vollen Stunden vermeiden
Wenn möglich: Senden Sie keine Nachrichten innerhalb von 2 Minuten vor oder nach den Zeitmarken :00, :15, :30 und :45.
Serverseitige Drosselung implementieren
Implementieren Sie serverseitige Drosselung, um den Trafficfluss zu FCM zu überwachen und zu verwalten.
Wiederholungsversuche verarbeiten
FCM ist zwar darauf ausgelegt, hochverfügbar zu sein, aber manchmal kommt es zu Zeitüberschreitungen oder Fehlern bei Anfragen. Die Gründe dafür sind vielfältig. Mit den folgenden Best Practices können Sie 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 vor dem Wiederholen mindestens ein Zeitlimit von 10 Sekunden fest. Die meisten internen Remote Procedure Calls von FCM verwenden ein Zeitlimit von 10 Sekunden.
Fehler
- Bei den Fehlern 400, 401, 403 und 404: Abbrechen und nicht wiederholen.
- Bei 429-Fehlern: Wiederholen Sie den Vorgang, nachdem Sie die im Header „retry-after“ angegebene Zeit gewartet haben. Wenn kein „retry-after“-Header festgelegt ist, wird standardmäßig ein Wert von 60 Sekunden verwendet.
- Bei 500-Fehlern: Wiederholen Sie den Vorgang mit exponentiellem Backoff.
Exponentielle Backoffs
Um eine Verstärkung von Wiederholungsversuchen zu vermeiden, sollten Sie für das Wiederholen von Anfragen einen exponentiellen Backoff mit Jittering implementieren. Das Firebase Admin SDK implementiert beispielsweise 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 noch einmal senden.
- 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 60 Minuten später immer noch fehlschlägt, ist sie entweder fälschlicherweise als wiederholbarer Fehler kategorisiert oder es liegt ein Ausfall von FCM vor, bei dem Wiederholungen 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 Schritte 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 Schritt erkennen.
- Stufenweise Steigerung des Traffics: Wenn Sie den Traffic in einzelnen Schritten steigern, sollten Sie den Traffic über einen Zeitraum von mindestens einer Stunde gleichmäßig verteilen. So kann die Load-Balancing-Infrastruktur 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% Steigerung | Steigern Sie die RPS für FCM HTTP v1 innerhalb einer Stunde von 0 auf 5.000. |
| 1 | 5% Steigerung | Steigern Sie die RPS über 2 Stunden hinweg langsam von 5.000 auf 25.000. |
| 2 | 10% Steigerung | Ramp-up von 25.000 auf 50.000 RPS über 2 Stunden |
| 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 | Steigerung 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 |
Hypothetischer Rollback-Plan:
- Wenn die Latenz des 95. Perzentils auf mehr als 500 ms ansteigt oder das Fehlerverhältnis in einem beliebigen Schritt länger als eine Stunde 1% überschreitet, verwenden Sie die dynamische Konfiguration, um sofort zum vorherigen Schritt zurückzukehren.
- Führen Sie weiterhin Rollbacks zu früheren Schritten durch, bis Latenz und Fehlerrate wieder auf dem normalen Niveau sind.
Wann sollten Sie sich an FCM wenden?
Wenden Sie sich über den Firebase-Support an FCM, wenn einer der folgenden Fälle zutrifft:
- Standardkontingente entsprechen nicht mehr Ihrem Anwendungsfall
- Sie ändern Ihre Sendemuster innerhalb von drei Monaten in einem Umfang von 100.000 RPS weltweit oder 30.000 RPS kontinental.