Bez względu na to, czy rozwijasz nową aplikację, czy zarządzasz usługą o dużym natężeniu ruchu, ten przewodnik pomoże Ci płynnie skalować się za pomocą FCM. Te pojęcia i sprawdzone metody mogą pomóc Ci uniknąć negatywnych skutków, gdy musisz wysłać dużą liczbę wiadomości.
Kluczowe terminy i pojęcia
Żądanie wiadomości: żądanie wiadomości FCM; używane zamiennie z terminami "żądanie", "wiadomość" lub "zapytanie".
Żądania na sekundę (RPS): wskaźnik opisujący szybkość przychodzących żądań do FCM; używany zamiennie z terminem „zapytania na sekundę (QPS)”.
Tokeny limitu, zasobniki tokenów i doładowania: podczas wysyłania wiadomości za pomocą interfejsu FCM HTTP v1 API każde żądanie zużywa przydzielony token limitu w danym przedziale czasu. Ten przedział czasu, nazywany „_zasobnikiem tokenów_”, _doładowuje się_ do pełna na końcu przedziału czasu. Na przykład interfejs HTTP v1 API przydziela 600 tys. tokenów limitu na każdy 1-minutowy zasobnik tokenów, który doładowuje się do pełna na końcu każdego 1-minutowego przedziału czasu.
Ograniczanie po stronie serwera: gdy natężenie ruchu przekracza możliwości usługi FCM's
capacity, żądania przekraczające możliwości obsługi są odrzucane, aby ograniczyć przepustowość ruchu przychodzącego
flow. Odpowiedzi na błędy 429 z nagłówkami retry-after mogą wskazywać, że przed ponowieniem próby żądania należy odczekać określony czas.
Ograniczanie po stronie klienta: gdy klienci zauważą nieudane żądania, duże opóźnienia,
lub błędy 429, powinni dobrowolnie ograniczyć przepustowość ruchu wychodzącego, aby nie pogorszyć
zatorów.
Wzrastający czas do ponowienia: podczas ponawiania prób w przypadku błędów dodaj wykładniczo rosnące opóźnienia. Na przykład: 1 s, 2 s, 4 s, 8 s, 16 s, 32 s itd.
Jittering: unikanie ponawiania prób żądań w dokładnych odstępach czasu. Dzięki jitteringowi możesz zmieniać opóźnienia ponawiania prób za pomocą procesu losowego, aby równomiernie rozłożyć je w czasie (np. 0,9 s, 2,3 s, 4,1 s, 8,5 s, 17,9 s, 34,7 s).
Wzmocnienie ponawiania prób: gdy nieudane żądania są ponawiane bez wzrastającego czasu do ponowienia lub jitteringu, często się kumulują i zwiększają bieżące obciążenie ruchem, co może "wzmocnić" i pogorszyć problemy z zatorami.
Problem: skoki natężenia ruchu
FCM przetwarza miliony żądań na sekundę (RPS). Największym czynnikiem przyczyniającym się do zatorów systemowych, problemów z opóźnieniami i awarii są skoki natężenia ruchu.
Co to jest skok natężenia ruchu?
Istnieje kilka różnych rodzajów skoków natężenia ruchu.
Skoki o pełnej godzinie: FCM otrzymuje ponad 2 razy więcej ruchu w pierwszych 30 sekundach do 2 minut każdej godziny. Podobne, choć mniejsze, skoki obserwuje się też o pół godziny i kwadrans (np. 00:15, 00:30, 00:45).
Wzmocnienie ponawiania prób: ponawianie prób nieudanych lub przekraczających limit czasu żądań bez wzrastającego czasu do ponowienia może powodować powtarzające się fale ruchu, które nakładają się na istniejące szczyty natężenia ruchu.
Nagłe zmiany wzorca 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 natężenia ruchu.
Wykorzystanie tokenów limitu z wyprzedzeniem: wyczerpanie wszystkich tokenów limitu na początku okien limitu zamiast równomiernego rozłożenia żądań w oknach limitu spowoduje oscylacje włączania i wyłączania, które są trudne i kosztowne do równoważenia obciążenia.
Wydarzenia specjalne: skoki natężenia ruchu podczas świąt (Sylwester) lub wydarzeń sportowych (Mistrzostwa Świata w Piłce Nożnej FIFA).
Zapobieganie skokom natężenia ruchu przez „spłaszczenie krzywej”
W tej sekcji opisujemy strategie wygładzania skoków natężenia ruchu, czyli „spłaszczania krzywej”.
Używaj FCM tylko w odpowiednich przypadkach
W niektórych przypadkach używanie FCM do dostarczania powiadomień nie jest konieczne ani odpowiednie.
Na przykład w przypadku powiadomień o wydarzeniach w kalendarzu możesz zaplanować lokalne zadanie w aplikacji, aby wyświetlać powiadomienia w odpowiednich momentach, zamiast wysyłać je z serwera aplikacji. Ogranicz wiadomości FCM do synchronizacji kalendarza.
Unikaj skoków natężenia ruchu
Jednym z anty-wzorców skalowania jest wysyłanie powiadomień FCM tak szybko, jak pozwalają na to systemy, zamiast stosowania ograniczania po stronie serwera. Zastanów się nad tym:
- Czy wszyscy Twoi klienci muszą otrzymać to samo powiadomienie w ciągu 1 minuty? Czy na przykład 5-minutowe okno dostawy nadal będzie spełniać Twoje potrzeby biznesowe?
- Czy można podzielić klientów na segmenty według priorytetu, aby wygładzić skoki natężenia ruchu?
- Czy powiadomienia można zaplanować z wyprzedzeniem?
Jeśli to możliwe: unikaj strategii, które powodują natychmiastowe wyczerpanie limitu wysyłania FCM, a następnie powtarzanie tego wzorca, gdy tylko zasobnik tokenów się doładuje. Ten wzorzec dostępu powoduje problemy z równoważeniem obciążenia w FCM i jego systemach zależnych. Zwiększaj natężenie ruchu tak stopniowo, jak to możliwe. Zwiększaj natężenie ruchu od 0 do maksymalnego RPS w ciągu 60 sekund. W przypadku wyższego RPS preferuj dłuższe okna.
Unikaj ruchu o pełnej godzinie
Jeśli to możliwe: unikaj wysyłania wiadomości w ciągu 2 minut od każdej z godzin: 00:00, 00:15, 00:30 i 00:45.
Wdrażanie ograniczania po stronie serwera
Wdróż ograniczanie po stronie serwera, aby monitorować ruch do FCM i nim zarządzać.
Obsługa ponawiania prób
Chociaż FCM stara się być wysoce dostępny, czasami niektóre żądania przekraczają limit czasu lub kończą się niepowodzeniem. Przyczyny mogą być różne, ale te sprawdzone metody optymalizują zachowanie ponawiania prób, aby dostarczać wiadomości tak szybko, jak to możliwe, przy jednoczesnym minimalizowaniu wpływu na zatory.
Czasy oczekiwania
Przed ponowieniem próby ustaw co najmniej 10-sekundowy limit czasu oczekiwania na żądania wysyłania. Większość wewnętrznych zdalnych wywołań procedur FCM używa 10-sekundowego limitu czasu oczekiwania.
Błędy
- W przypadku błędów 400, 401, 403 i 404: przerwij i nie ponawiaj próby.
- W przypadku błędów 429: ponów próbę po odczekaniu czasu ustawionego w nagłówku retry-after. Jeśli nie ustawiono nagłówka retry-after, domyślnie przyjmuje się 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 ponawiania prób, wdróż wzrastający czas do ponowienia z jitteringiem. Na przykład pakiet Firebase Admin SDK implementuje wzrastający czas do ponowienia.
Oto kilka dodatkowych zalecanych ustawień:
- Minimalny odstęp czasu: nie ponawiaj od razu nieudanego żądania w FCM. Przed ponowieniem próby nieudanego żądania odczekaj co najmniej 10 sekund.
- Maksymalny interwał: ustaw maksymalny interwał, aby odrzucać żądania, które nie są już aktualne, zamiast ponawiać próby w nieskończoność.
Jeśli żądanie jest ciągle ponawiane ze wzrastającym czasem do ponowienia i nadal kończy się niepowodzeniem po 60 minutach, oznacza to, że jest ono błędnie sklasyfikowane jako błąd, który można ponowić, lub że FCM ma awarię, w której ponawianie prób może nieumyślnie pogorszyć sytuację.
Tworzenie planów wdrożenia i wycofania oraz wprowadzanie stopniowych zmian
W przypadku wprowadzania zmian w ruchu na dużą skalę, takich jak zwiększanie ruchu do FCM lub przenoszenie ruchu między regionami lub sieciami, opracowanie planu wdrożenia lub wycofania oraz wprowadzanie stopniowych zmian ochroni Twoich użytkowników, Twoją usługę i FCM.
- Plan wdrożenia dostosowuje oczekiwania zainteresowanych stron. W niektórych sytuacjach (opisanych poniżej) warto wcześniej udostępnić plan wdrożenia zespołowi FCM, aby uniknąć niespodzianek.
- Plan wycofania pozwala uwzględnić nieprzewidziane sytuacje i przygotować mechanizmy szybkiego i bezpiecznego przywracania systemu po nieoczekiwanych awariach.
- Wprowadzanie stopniowych zmian ma 2 aspekty:
- Stopniowe zwiększanie: kroki powinny wynosić 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% lub więcej. "Przetestuj" (obserwuj zachowanie systemu pod obciążeniem) każdy krok przez 1 dzień do 1 tygodnia. Pozwoli Ci to wykryć potencjalne problemy przed kolejnym „krokiem”.
- Stopniowe zwiększanie natężenia ruchu: podczas każdego „kroku” zwiększania natężenia ruchu wygładź ruch w ciągu co najmniej godziny. Pozwoli to infrastrukturze równoważenia obciążenia FCM odpowiednio skalować nowy ruch przy jednoczesnym minimalizowaniu potencjalnych punktów krytycznych i zatorów.
Oto hipotetyczny scenariusz migracji 500 tys. RPS na całym świecie z interfejsu FCM Legacy HTTP API do interfejsu FCM HTTP v1 API:
| Tydzień | Krok | Strategia stopniowego zwiększania |
|---|---|---|
| 0 | Zwiększenie o 1% | Stopniowo zwiększaj natężenie ruchu od 0 do 5 tys. RPS do interfejsu FCM HTTP v1 API w ciągu godziny. |
| 1 | Zwiększenie o 5% | Stopniowo zwiększaj natężenie ruchu od 5 tys. do 25 tys. RPS w ciągu 2 godzin. |
| 2 | Zwiększenie o 10% | Stopniowo zwiększaj natężenie ruchu od 25 tys. do 50 tys. RPS w ciągu 2 godzin. |
| 3 | Zwiększenie o 25% | Zwiększaj natężenie ruchu od 50 tys. do 125 tys. RPS w ciągu 3 godzin. |
| 4 | Zwiększenie o 50% | Zwiększaj natężenie ruchu od 125 tys. do 250 tys. RPS w ciągu 6 godzin. |
| 5 | Zwiększenie o 75% | Zwiększaj natężenie ruchu od 250 tys. do 375 tys. RPS w ciągu 6 godzin. |
| 6 | Zwiększenie o 100% | Zwiększaj natężenie ruchu od 375 tys. do 500 tys. RPS w ciągu 6 godzin. |
Hipotetyczny plan wycofania:
- Jeśli opóźnienie na poziomie 95 percentyla wzrośnie do ponad 500 ms lub jeśli współczynnik błędów przekroczy 1% przez ponad godzinę na dowolnym etapie, użyj konfiguracji dynamicznej, aby natychmiast wycofać się do poprzedniego kroku.
- Kontynuuj wycofywanie do wcześniejszych kroków, aż opóźnienie i współczynnik błędów wrócą do normalnych poziomów.
Kiedy skontaktować się z FCM
Skontaktuj się z FCM za pomocą zespołu pomocy Firebase jeśli spełniony jest któryś z tych warunków:
- Domyślne limity nie są już odpowiednie dla Twojego przypadku użycia.
- W ciągu 3 miesięcy zmieniasz wzorce wysyłania na skalę 100 tys. RPS na całym świecie lub 30 tys. RPS na kontynencie.