Niezależnie od tego, czy rozwijasz nową aplikację, czy już prowadzisz usługę o dużym natężeniu ruchu, możesz skorzystać ze wskazówek i rekomendacji zawartych w tym przewodniku, aby płynnie skalować aplikację za pomocą FCM. Te pojęcia i praktyki mogą pomóc Ci uniknąć negatywnych skutków, gdy musisz wysłać dużą liczbę wiadomości.
Kluczowe terminy i pojęcia
Prośba o wiadomość: prośba o wiadomość FCM; używana zamiennie z „prośbą”, „wiadomością” lub „zapytaniem”.
Żądania na sekundę (RPS): dane opisujące liczbę żądań przychodzących do FCM. Są używane zamiennie z zapytaniami na sekundę (QPS).
Tokeny limitu, zasobniki tokenów i uzupełnienia: podczas wysyłania wiadomości do interfejsu FCM HTTP v1 API każde żądanie zużywa przydzielony token limitu w danym przedziale czasu. To okno, nazywane „zasobnikiem tokena”, napełnia się do pełna na koniec przedziału czasu. Na przykład interfejs HTTP v1 API przydziela 600 tys. tokenów limitu na każdy 1-minutowy zasobnik tokena, który jest uzupełniany do pełna na koniec każdego 1-minutowego okna.
Ograniczanie przepustowości po stronie serwera: gdy natężenie ruchu przekracza możliwości usługi FCM, żądania przekraczające możliwości obsługi są odrzucane, aby ograniczyć przepływ danych przychodzących. Odpowiedzi z błędem 429 z nagłówkami retry-after mogą być zwracane, aby wskazać, że przed ponownym wysłaniem żądania należy odczekać określony czas.
Ograniczanie po stronie klienta: gdy klienci zauważą błędy żądań, wysokie opóźnienie lub błędy 429, powinni dobrowolnie ograniczyć przepływ danych wychodzących, aby uniknąć pogorszenia przeciążenia.
Wzrastający czas do ponowienia: podczas ponawiania prób po wystąpieniu błędów dodawaj wykładniczo rosnące opóźnienia. Na przykład: 1 s, 2 s, 4 s, 8 s, 16 s, 32 s itd.
Wahania: unikanie ponawiania żądań w dokładnych odstępach czasu. W przypadku jitteringu opóźnienia ponownych prób są zmieniane w procesie losowym, 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).
Wzmocnienie ponownych prób: gdy nieudane żądania są ponawiane bez wzrastającego czasu do ponowienia lub jittera, często się kumulują i zwiększają bieżące obciążenie ruchem, co może „wzmocnić” i pogorszyć problemy z przeciążeniem ruchu.
Problem: skoki ruchu
FCM przetwarza miliony żądań na sekundę (RPS). Największym czynnikiem powodującym przeciążenie systemu, problemy z czasem oczekiwania i przerwy w działaniu są skoki natężenia ruchu.
Czym jest ruch o charakterze skokowym?
Istnieje kilka różnych typów skoków ruchu.
Skoki o pełnych godzinach: FCM otrzymuje ponad 2 razy większy ruch w ciągu pierwszych 30 sekund do 2 minut każdej godziny. Podobne, choć mniejsze skoki można zaobserwować również w połowie i na kwadrans przed pełną godziną (np. 00:15, 00:30, 00:45).
Wzmocnienie ponownych prób: ponawianie nieudanych żądań lub żądań, które przekroczyły limit czasu, bez wzrastającego czasu do ponowienia może powodować powtarzające się fale ruchu nakładające się na istniejące szczyty ruchu.
Nagłe zmiany wzorców ruchu: kierowanie nowego ruchu do FCM lub przenoszenie ruchu do FCM między regionami bez czynników wygładzających, takich jak stopniowe zwiększanie, może powodować skoki.
Wykorzystanie tokenów limitu na początku: wyczerpanie wszystkich tokenów limitu na początku okien limitu zamiast równomiernego rozłożenia żądań w oknach limitu spowoduje oscylacje, które są trudne i kosztowne do zrównoważenia.
Wydarzenia specjalne: gwałtowne wzrosty natężenia ruchu podczas świąt (Sylwester) lub wydarzeń sportowych (Mistrzostwa Świata w Piłce Nożnej FIFA).
Zmniejszanie skoków ruchu przez „spłaszczanie krzywej”
W tej sekcji opisano strategie, które pozwalają w miarę możliwości wygładzić skoki ruchu, czyli „spłaszczyć krzywą”.
Używaj FCM tylko w odpowiednich przypadkach
W niektórych przypadkach użycie FCM do dostarczenia powiadomienia nie jest konieczne ani odpowiednie.
Na przykład w przypadku powiadomień o wydarzeniach w kalendarzu możesz zaplanować zadanie lokalne w aplikacji, aby wyświetlać powiadomienia w odpowiednich momentach, zamiast wysyłać je z serwera aplikacji. Ogranicz wiadomości FCM do synchronizacji kalendarza.
Unikaj kolców
Jednym z antywzorców skalowania jest wysyłanie powiadomień FCM tak szybko, jak pozwalają na to systemy, zamiast stosowania ograniczania przepustowości po stronie serwera. Możesz na przykład:
- Czy wszyscy klienci muszą otrzymać to samo powiadomienie w ciągu 1 minuty? Czy na przykład 5-minutowe okno dostawy nadal spełniałoby potrzeby Twojej firmy?
- Czy można podzielić klientów na segmenty według priorytetu, aby wygładzić skoki?
- 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 wzorca, gdy tylko zasobnik tokena zostanie ponownie zapełniony. Ten wzorzec dostępu powoduje problemy z równoważeniem obciążenia w FCM i systemach zależnych. Zwiększaj ruch jak najwolniej. Minimalny wzrost od 0 do maksymalnej liczby żądań na sekundę w ciągu 60 sekund. W przypadku wyższej liczby żądań na sekundę preferowane są dłuższe okna.
Unikanie ruchu „o pełnej godzinie”
Jeśli to możliwe: unikaj wysyłania wiadomości w ciągu 2 minut od każdej z tych minut: :00, :15, :30 i :45.
Wdrażanie ograniczania przepustowości po stronie serwera
Zaimplementuj ograniczanie przepustowości po stronie serwera, aby monitorować ruch do FCM i nim zarządzać.
Obsługa ponownych prób
Chociaż FCM dąży do zapewnienia wysokiej dostępności, czasami niektóre żądania mogą zostać przekroczone lub nie powieść się. Przyczyny mogą być różne, ale te sprawdzone metody optymalizują ponawianie prób, aby dostarczać wiadomości jak najszybciej, jednocześnie minimalizując wpływ na przeciążenie ruchu.
Czasy oczekiwania
Przed ponowną próbą ustaw co najmniej 10-sekundowy limit czasu na wysyłanie żądań. Większość wewnętrznych zdalnych wywołań procedur FCM używa 10-sekundowego limitu czasu.
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 określonego w nagłówku retry-after. Jeśli nie ustawiono nagłówka retry-after, domyślny czas to 60 sekund.
- W przypadku błędów 500: ponów próbę ze wzrastającym czasem do ponowienia.
Wzrastający czas do ponowienia
Aby uniknąć wzmocnienia ponownych prób, zaimplementuj wykładnicze opóźnienie z jitterem w przypadku ponownych prób żądań. Na przykład pakiet Firebase Admin SDK implementuje wzrastający czas do ponowienia.
Oto kilka dodatkowych zalecanych ustawień:
- Minimalny odstęp: nie ponawiaj od razu nieudanej prośby 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 ponawiać próby w nieskończoność.
Jeśli żądanie jest stale ponawiane ze wzrastającym czasem do ponowienia i po 60 minutach nadal kończy się niepowodzeniem, oznacza to, że zostało błędnie zaklasyfikowane jako błąd, który można naprawić, lub że w FCM wystąpiła przerwa w działaniu, podczas której ponowne próby mogą nieumyślnie pogorszyć sytuację.
Tworzenie planów wdrażania i przywracania oraz wprowadzanie stopniowych zmian
Jeśli wprowadzasz zmiany w ruchu na dużą skalę, np. zwiększasz ruch do FCM lub przenosisz ruch między regionami lub sieciami, opracowanie planu wdrażania i wycofywania oraz wprowadzanie stopniowych zmian pomoże chronić użytkowników, Twoją usługę i FCM.
- Plan wdrażania pozwala uzgodnić oczekiwania interesariuszy. W niektórych sytuacjach (omówionych poniżej) warto wcześniej udostępnić plan wdrażania zespołowi FCM, aby uniknąć niespodzianek.
- Plan przywracania pozwala uwzględnić nieprzewidziane okoliczności i przygotować mechanizmy szybkiego i bezpiecznego przywracania po nieoczekiwanych awariach.
- Wprowadzanie stopniowych zmian ma 2 aspekty:
- Stopniowe zwiększanie: kroki powinny wynosić 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% lub mniej. „Obserwuj” (zachowanie systemu pod obciążeniem) każdy krok przez okres od 1 dnia do 1 tygodnia. Dzięki temu możesz wykryć potencjalne problemy przed kolejnym „skokiem”.
- Stopniowe zwiększanie ruchu: podczas każdego „kroku” zwiększania ruchu rozłóż go równomiernie na co najmniej godzinę. Dzięki temu infrastruktura równoważenia obciążenia FCM może odpowiednio skalować nowy ruch, minimalizując jednocześnie ryzyko wystąpienia hotspotów i przeciążeń.
Oto hipotetyczny scenariusz migracji 500 tys. żądań na sekundę na całym świecie ze starszej wersji interfejsu FCM HTTP API do interfejsu FCM HTTP v1 API:
| Tydzień | Step | Strategia stopniowego zwiększania liczby wysyłanych wiadomości |
|---|---|---|
| 0 | 1% – zwiększanie wyświetlania | W ciągu godziny płynnie zwiększaj liczbę żądań na sekundę do FCM HTTP v1 od 0 do 5000. |
| 1 | 5% wzrostu | Płynnie zwiększaj liczbę żądań na sekundę z 5000 do 25 000 w ciągu 2 godzin. |
| 2 | 10% – zwiększanie wyświetlania | Płynne zwiększanie liczby żądań na sekundę z 25 000 do 50 000 w ciągu 2 godzin |
| 3 | 25% wzrostu | Zwiększenie liczby żądań na sekundę z 50 000 do 125 000 w ciągu 3 godzin |
| 4 | 50% zwiększania wyświetlania | Zwiększenie liczby żądań na sekundę ze 125 000 do 250 000 w ciągu 6 godzin |
| 5 | 75% – zwiększanie wyświetlania | Zwiększenie liczby żądań na sekundę z 250 000 do 375 000 w ciągu 6 godzin |
| 6 | 100% wzrostu | Zwiększenie z 375 000 do 500 000 żądań na sekundę w ciągu 6 godzin |
Przykładowy plan przywrócenia:
- Jeśli na dowolnym etapie opóźnienie na poziomie 95 percentyla wzrośnie do ponad 500 ms lub współczynnik błędów przekroczy 1% przez ponad godzinę, użyj konfiguracji dynamicznej, aby natychmiast wrócić do poprzedniego etapu.
- Kontynuuj wycofywanie do wcześniejszych kroków, aż czas oczekiwania i odsetek błędów wrócą do wartości nominalnych.
Kiedy skontaktować się z FCM
Skontaktuj się z FCM przez zespół pomocy Firebase, jeśli:
- Domyślne limity nie odpowiadają już Twojemu przypadkowi użycia.
- Zmieniasz wzorce wysyłania w ciągu 3 miesięcy w skali 100 000 RPS globalnie lub 30 000 RPS na kontynencie.