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 informacje 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 v1 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 koniec każdego 1-minutowego okna.
Ograniczanie na serwerze: 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 przesł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ść odpływu, 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, co może „wzmacniać” i pogłębiać 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 zwrotnego wykładniczego 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 okresie limitu spowoduje wahania obciążenia, które są trudne i drogie w zrównoważeniu.
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 problemu nagłych wzrostów ruchu przez „spłaszczenie krzywej”.
W tej sekcji opisujemy strategie, które mogą w jak największym stopniu wygładzić szczyty ruchu, czyli „spłaszczyć krzywą”.
Używaj FCM tylko w odpowiednich przypadkach.
W niektórych przypadkach użycie FCM do wysyłania powiadomień nie jest konieczne ani nie jest odpowiednie.
Na przykład w przypadku powiadomień o wydarzeniu w kalendarzu możesz zaplanować lokalne zadanie w aplikacji, aby wyświetlało powiadomienie w odpowiednich momentach, 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 ograniczenie 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 Twoi klienci mogą być podzieleni 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ę z 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 ustawia się 60 sekund.
- W przypadku błędów 500: podejmij ponowne próby ze wzrastającym czasem do ponowienia.
Wzrastający czas do ponownej próby
Aby uniknąć wzmocnienia prób, zastosuj wykładniczy czas do ponowienia z jitterem w przypadku prób. 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 próbuj ponownie od razu przesłać 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 nieskończonej liczby prób.
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 sklasyfikowane 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ę.
tworzyć plany wdrażania i przywracania oraz wprowadzać zmiany stopniowo.
W przypadku wprowadzania dużych zmian w ruchu, takich jak zwiększanie ruchu w FCM lub przenoszenie 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) warto wcześniej udostępnić plan wdrożenia zespołowi FCM, aby uniknąć niespodzianek.
- Plan wycofywania umożliwia uwzględnienie nieprzewidzianych sytuacji i przygotowanie mechanizmów do szybkiego i bezpiecznego przywracania po nieoczekiwanych awariach.
- Stopniowe wprowadzanie zmian ma 2 aspekty:
- „Stopniowe” rampy: kroki powinny wynosić 1% -> 5% -> 10% -> 25% -> 50% -> 75% -> 100% lub więcej. „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. Dzięki temu infrastruktura równoważenia obciążenia FCM może odpowiednio skalować nowy ruch, minimalizując przy tym potencjalne wąskie gardła i korki.
Oto hipotetyczny scenariusz migracji 500 tys. RPS na całym świecie z interfejsu FCM Legacy HTTP API na interfejs FCM HTTP w wersji 1:
| Tydzień | Step | Stopniowe zwiększanie udziału |
|---|---|---|
| 0 | 1% | stopniowo zwiększaj liczbę RPS-ów z 0 do 5000,aby dotrzeć do wersji 1 protokołu FCM HTTP w ciągu godziny; |
| 1 | Zwiększanie wyświetlania o 5% | 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. obrotów na sekundę w ciągu 6 godzin |
| 6 | 100% zwiększenia wyświetlania | Przyspieszanie z 375 tys. do 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 wystąpi któryś z tych problemów:
- 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.