Niezależnie od tego, czy rozwijasz dopiero swoją aplikację, czy też masz już usługę o dużej liczbie użytkowników, znajdziesz w tym przewodniku przydatne statystyki i rekomendacje dotyczące płynnego skalowania za pomocą FCM. Te koncepcje i metody mogą pomóc Ci uniknąć negatywnych skutków, gdy musisz wysyłać duże ilości wiadomości.
Kluczowe terminy i pojęcia
Prośba o wiadomość: prośba o wiadomość FCM; używana zamiennie z terminami „prośba”, „wiadomość” lub „zapytanie”.
Żądania na sekundę (RPS): dane opisujące częstotliwość przychodzących żądań do FCM; używane zamiennie z danymi „Zapytania na sekundę (QPS)”.
Tokeny limitu, zbiory tokenów i ich uzupełnianie: podczas wysyłania wiadomości za pomocą interfejsu FCM HTTP w wersji 1 każde żądanie zużywa przydzielony token limitu w danym oknie czasowym. Okno to, nazywane pojemnikiem na tokeny, napełnia się do pełna pod koniec okna czasowego. Na przykład interfejs HTTP w wersji 1 przydziela 600 tys. tokenów limitu na każdy 1-minutowy koszyk tokenów, który napełnia się do pełna na końcu każdego 1-minutowego okna.
Ograniczanie przepustowości po stronie serwera: gdy natężenie ruchu przekracza pojemność usługi FCM, żądania przekraczające pojemność serwera są odrzucane, aby ograniczyć napływ danych. 429 odpowiedzi z błędem z nagłówkami retry-after, aby wskazać, że przed ponownym wysłaniem żądania należy odczekać określony czas.
Ograniczanie przepustowości po stronie klienta: gdy klienci odnotowują błędy 429, błędy związane z długim czasem oczekiwania lub błędy dotyczące żądań, powinni dobrowolnie ograniczyć przepustowość, aby uniknąć nasilenia zatorów.
Wzrost czasu do ponowienia: podczas ponownego próbowania w przypadku błędów należy dodawać wykładniczo zwiększające się opóźnienia czasowe. Na przykład: 1 s, 2 s, 4 s, 8 s, 16 s, 32 s itd.
Jitter: unikanie ponownego próbowania żądań w dokładnych odstępach. W przypadku jitteringu zmieniasz opóźnienia prób ponownego połączenia za pomocą losowego procesu, aby rozłożyć je równomiernie w czasie (np. 0,9 s, 2,3 s, 4,1 s, 8,5 s, 17,9 s, 34,7 s).
Ponowne próby: gdy nieudane żądania są powtarzane bez stosowania wzrastającego czasu do ponowienia lub ditheringu, często kumulują się i dodają do bieżącego obciążenia ruchu, potencjalnie „wzmacniając” i pogłębiając problemy z korkiem w ruchu.
Problem: skoki liczby wizyt
FCM przetwarza miliony żądań na sekundę (RPS). Największy wpływ na przeciążenia systemowe, problemy z opóźnieniami i przerwy w działaniu mają skoki ruchu.
Co to jest ruch o charakterze skumulowanym?
Wyróżniamy kilka różnych typów wzrostów liczby wizyt.
Szczyty godzinne: w pierwszych 30 sekundach do 2 minut każdej godziny FCM otrzymuje ponad dwukrotnie więcej ruchu niż w pozostałym czasie. Podobne, choć mniejsze, słupy są również widoczne w przypadku półgodzinnych i godzinnych wartości (np. 00:15, 00:30, 00:45).
Ponowne próby z wzmocnieniem: powtarzanie nieudanych żądań lub żądań, które osiągnęły limit czasu, bez zwrotnej funkcji wykładniczej może prowadzić do powtarzających się fal ruchu na szczytach dotychczasowych szczytów ruchu.
Nagłe zmiany w wzorze ruchu: kierowanie nowego ruchu do FCM lub przenoszenie ruchu do FCM w różnych regionach bez łagodnego zwiększania natężenia może powodować wzrosty.
Front-loading tokenów limitu: wykorzystanie wszystkich tokenów limitu na początku okresu limitu zamiast równomiernego rozłożenia żądań w całym okresie limitu spowoduje wahania obciążenia, które są trudne i drogie w wyrównaniu.
Wydarzenia specjalne: gwałtowne wzrosty ruchu w okresie świątecznym (sylwester) lub podczas wydarzeń sportowych (Mistrzostwa Świata w piłce nożnej FIFA).
Rozwiązywanie problemów z wzrostami ruchu przez „spłaszczenie krzywej”
W tej sekcji opisujemy strategie łagodzenia szczytów ruchu, o ile jest to możliwe – strategie „spłaszczania krzywej”.
Używaj FCM tylko w odpowiednich przypadkach.
W niektórych przypadkach użycie FCM do wysyłania powiadomień nie jest konieczne ani odpowiednie.
Na przykład w przypadku powiadomień o wydarzeniu w kalendarzu możesz zaplanować lokalne zadanie w aplikacji, aby wyświetlało powiadomienie o odpowiedniej porze, zamiast wysyłać je z serwera aplikacji. Ogranicz wiadomości FCM do synchronizacji z kalendarzem.
Unikaj nagłych wzrostów
Jednym ze sposobów na unikanie skalowania jest wysyłanie powiadomień FCM tak szybko, jak tylko systemy na to pozwalają, zamiast stosowania ograniczania przepustowości po stronie serwera. Zastanów się nad tymi kwestiami:
- Czy wszyscy klienci muszą otrzymać to samo powiadomienie w ciągu 1 minuty? Czy 5-minutowy przedział dostawy nadal odpowiada Twoim potrzebom biznesowym?
- Czy Twoich klientów można podzielić na segmenty według priorytetu, aby wygładzić wzrosty?
- Czy powiadomienia można zaplanować z wyprzedzeniem?
W miarę możliwości: unikaj strategii, które powodują natychmiastowe wyczerpanie limitu wysyłania FCM, a następnie powtarzanie tego wzoru, gdy tylko pula tokenów zostanie uzupełniona. Taki wzór dostępu powoduje problemy z balansem obciążenia w przypadku FCM i systemów, na których ono się opiera. Zwiększaj ruch stopniowo. Minimalnie zwiększaj liczbę żądań na sekundę od 0 do maksymalnej wartości w oknie czasowym 60 sekund. Wybieraj dłuższe okna, aby zwiększyć RPS.
Unikaj korków w godzinach szczytu.
W miarę możliwości: unikaj wysyłania wiadomości w ciągu 2 minut od każdej godziny, 15, 30 i 45 minut.
Wdrażanie ograniczania przepustowości po stronie serwera
Wdrożyć ograniczanie przepustowości po stronie serwera, aby monitorować przepływ ruchu do FCM i nim zarządzać.
Obsługa ponawiania prób
Chociaż usługa FCM dąży do zapewnienia wysokiej dostępności, czasami niektóre żądania mogą się nie powieść lub przekroczyć limit czasu. Poniżej znajdziesz sprawdzone metody optymalizacji zachowania ponownego próbowania, które umożliwiają jak najszybsze dostarczanie wiadomości przy jednoczesnym minimalizowaniu wpływu na natężenie ruchu.
Czasy oczekiwania
Ustaw limit czasu na wysyłanie żądań na co najmniej 10 sekund przed ponownym próbowaniem. Większość wywołań procedur zdalnych w FCM korzysta z czasu oczekiwania wynoszącego 10 sekund.
Błędy
- W przypadku błędów 400, 401, 403 i 404: przerwij i nie próbuj ponownie.
- W przypadku błędów 429: spróbuj ponownie po upływie czasu ustawionego w nagłówku retry-after. Jeśli nagłówek retry-after nie jest ustawiony, domyślnie ustawiona jest wartość 60 sekund.
- W przypadku błędów 500: podejmij ponowne próby ze wzrastającym czasem do ponowienia.
Wzrastający czas do ponowienia
Aby uniknąć wzmocnienia prób ponownego połączenia, w przypadku próśb o ponowne próby zastosuj wykładniczy czas do ponowienia z jitterem. Na przykład pakiet Firebase Admin SDK stosuje odstępowanie od prób w sposób wykładniczy.
Oto kilka zalecanych ustawień:
- Minimalny interwał: nie powtarzaj od razu nieudanego żądania za pomocą FCM. Zanim spróbujesz ponownie wysłać nieudane żądanie, odczekaj co najmniej 10 sekund.
- Maksymalny interwał: ustaw maksymalny interwał, po którym żądania, które nie są już aktualne, będą odrzucane zamiast być wielokrotnie ponownie wysyłane.
Jeśli żądanie jest stale powtarzane ze wzrastającym czasem do ponowienia i nadal nie udaje się go zrealizować po 60 minutach, oznacza to, że zostało ono nieprawidłowo zaklasyfikowane jako błąd, który można powtórzyć, lub że usługa FCM ma problemy, a powtarzanie prób może niepotrzebnie pogarszać sytuację.
Tworzenie planów wdrażania i przywracania oraz wprowadzanie zmian stopniowych
W przypadku wprowadzania dużych zmian w ruchu, np. zwiększania ruchu w FCM lub przekierowywania ruchu między regionami lub sieciami, opracowanie planu wdrażania/cofania oraz wdrażanie zmian stopniowo zapewni ochronę użytkowników, usługi i FCM.
- Plan wdrożenia pozwala dostosować oczekiwania interesariuszy. W niektórych sytuacjach (omówionych poniżej) możesz chcieć udostępnić zespół FCM swój plan wdrażania z wyprzedzeniem, aby uniknąć niespodzianek.
- Plan przywracania umożliwia uwzględnienie nieprzewidzianych sytuacji i przygotowanie mechanizmów szybkiego i bezpiecznego odtwarzania po nieoczekiwanych awariach.
- Wprowadzanie zmian stopniowych ma 2 aspekty:
- Ramp-up „schodkowy”: kroki powinny wynosić 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% lub dokładniej. „Soak” (obserwowanie zachowania systemu pod obciążeniem) na każdym kroku przez 1 dzień do 1 tygodnia. Dzięki temu możesz wykryć potencjalne problemy przed kolejnym „podniesieniem”.
- Stopniowe zwiększanie natężenia ruchu: gdy zwiększasz natężenie ruchu o krok, wygładzaj ruch w ciągu co najmniej godziny. Umożliwia to infrastrukturze równoważenia obciążenia FCM odpowiednie skalowanie nowego ruchu przy jednoczesnym minimalizowaniu potencjalnych wąskich gardeł i korków.
Oto hipotetyczny scenariusz globalnej migracji 500 tys. RPS z interfejsu FCM Legacy HTTP API do interfejsu FCM HTTP v1 API:
| Tydzień | Step | Stopniowe zwiększanie udziału |
|---|---|---|
| 0 | 1% | stopniowo zwiększać liczbę RPS-ów z 0 do 5000 w usłudze FCM HTTP w wersji 1 w ciągu godziny. |
| 1 | 5% zwiększenia wyświetlania | Płynnie zwiększaj liczbę RPS z 5000 do 25 tys. w ciągu 2 godzin. |
| 2 | 10% | stopniowe zwiększanie liczby RPS z 25 tys. do 50 tys. w ciągu 2 godzin; |
| 3 | 25% | Przyspieszanie z 50 tys. do 125 tys. RPS w ciągu 3 godzin |
| 4 | 50% zwiększenia wyświetlania | Przyspieszanie z 125 000 do 250 000 RPS w ciągu 6 godzin |
| 5 | 75% | Przyspieszanie z 250 tys. do 375 tys. obr./s w ciągu 6 godzin |
| 6 | 100% zwiększenia wyświetlania | Przyspieszanie z 375 tys. na 500 tys. RPS w ciągu 6 godzin |
Hipotetyczny plan przywrócenia:
- Jeśli czas oczekiwania w 95. procencie przypadków przekroczy 500 ms lub jeśli stosunek błędów przekroczy 1% przez ponad godzinę na dowolnym etapie, użyj konfiguracji dynamicznej, aby natychmiast wrócić do poprzedniego kroku.
- Kontynuuj cofanie do wcześniejszych kroków, aż czas oczekiwania i odsetek błędów powrócą do nominalnych wartości.
Kiedy kontaktować się z FCM
Skontaktuj się z zespołem pomocy Firebase Cloud Messaging (FCM) przez zespołem pomocy Firebase, jeśli:
- Domyślne limity nie spełniają już Twoich potrzeb
- zmieniasz wzorce wysyłania w ciągu 3 miesięcy na skalę 100 tys. RPS na całym świecie lub 30 tys. RPS na kontynencie.