Maszyny wirtualne i przeglądarki chmurowe są rozliczane za czas, więc zadania wsadowe łatwo mogą wyczerpać limit. Warto oszacować zużycie, ustalić praktyczny pułap współbieżności i stosować właściwą kolejność działań naprawczych.
W przypadku zasobów rozliczanych za czas logika opłat jest prosta: czas działania razy liczba instancji. Limit jest twardą granicą. Po jej osiągnięciu zadania nie tylko zwalniają, lecz po prostu kończą się błędem: nie da się utworzyć nowych instancji, działające instancje mogą zostać odebrane, a interfejsy API zaczynają zwracać błędy ograniczenia. Wiedza o tym, ile zostało do limitu, jest bardziej użyteczna niż zwiększanie budżetu dopiero po problemie.
Najpierw oddziel niezbędne zużycie od zbędnego
Ten sam limit może dawać bardzo różne efekty zależnie od zadań, które go wykorzystują. Zacznij od przeglądu i podziel zadania według tego, czy naprawdę wymagają wykonania w czasie rzeczywistym.
Zadania działające stale należą do najłatwiejszych sposobów na wyczerpanie limitu. Mogą pracować przez całą dobę, mimo że faktycznie wykonują użyteczną pracę tylko przez kilka minut. Zastąpienie stałego monitoringu wyzwalaniem według harmonogramu często pozwala znacząco obniżyć zużycie bez zauważalnego wpływu na działalność. Zadania szczytowe skupione w konkretnych godzinach można przesunąć, a zadania jednorazowe uruchamiać tylko w razie potrzeby.
Następnie zadaj sobie pytanie: czy opóźnienie tego zadania o sześć godzin wpłynie na działalność? Jeśli tak, pozostaw je na ścieżce krytycznej i wykonuj w czasie rzeczywistym. Jeśli nie, przenieś je do niskopriorytetowego przetwarzania wsadowego i zaplanuj na okres z większym zapasem limitu. Zmiana monitorowania cen konkurencji z raz na godzinę na dwa razy dziennie w większości przypadków nie obniża istotnie wartości informacji.
Jak oszacować zużycie i ustalić współbieżność
Przy rozliczaniu za czas działania instancji całkowite zużycie partii zadań jest w przybliżeniu równe średniemu czasowi jednego zadania pomnożonemu przez liczbę zadań. Nie zależy ono od poziomu współbieżności; współbieżność określa tylko, jak szybko partia zostanie zakończona. Zależy od niej natomiast chwilowe obciążenie: im więcej instancji uruchamia się jednocześnie, tym łatwiej osiągnąć limit współbieżności puli zasobów albo ograniczenia po stronie platformy.
Dlatego zacznij od najmniejszej współbieżności. Najpierw uruchom jedno zadanie i sprawdź jego średni czas oraz wskaźnik powodzenia. Następnie stopniowo zwiększaj liczbę do kilku, a potem do kilkunastu, zapisując wskaźnik błędów i liczbę ponowień. Gdy po przekroczeniu pewnego poziomu liczba błędów wyraźnie rośnie, znalazłeś praktyczny limit. Dalsze zwiększanie współbieżności odda oszczędzony czas w postaci dodatkowych ponowień.
W szacunkach nie pomijaj ukrytego czasu: oczekiwania na logowanie, ładowania stron, etapów weryfikacji i ponowień po błędach. Często trwają one dłużej niż sam główny proces. Zostawienie marginesu na jedno zadanie jest bardziej przydatne niż wyliczanie wszystkiego co do minuty.
Jak wygląda wyczerpanie limitu
Wyczerpanie limitu bywa trudne do rozpoznania, ponieważ często przypomina inne problemy.
Jednym z objawów jest zatrzymanie zadania na etapie uruchamiania, gdy żądanie utworzenia środowiska lub instancji zostaje odrzucone, a w logu pozostaje jedynie niejasny błąd. Innym jest odebranie instancji w połowie pracy i utrata dotychczasowego postępu. Mogą też pojawiać się błędy ograniczenia, częściowe sukcesy przeplatane błędami albo coraz dłuższa kolejka, której nikt nie przetwarza.
Najłatwiej błędnie ocenić pozorne zawieszenie: instancja nadal istnieje i zadanie wygląda na aktywne, ale faktycznie utknęło w oczekiwaniu, podczas gdy limit nadal zużywa się wraz z upływem czasu. W takiej sytuacji najpierw sprawdź panel wykorzystania limitu, a potem osobno uruchom małe zadanie. Jeśli ono również nie startuje, przyczyny należy szukać w limicie lub uprawnieniach. Jeśli działa normalnie, problemem jest raczej współbieżność albo ponowne wykorzystywanie środowiska.
Kolejność działań naprawczych
Zacznij od działań, które nic nie kosztują.
Po pierwsze, zatrzymaj stałe zużycie o niskiej wartości i zmień zadania monitorujące na uruchamiane według harmonogramu. Po drugie, przenieś zadania tolerujące opóźnienie na okresy z większym zapasem limitu, aby spłaszczyć krzywą zużycia. Po trzecie, obniż limit współbieżności i dodaj kolejkę, aby zadania były pobierane zgodnie z dostępną pojemnością zamiast startować jednocześnie. Po czwarte, ogranicz marnotrawstwo: używaj pamięci podręcznej dla tych samych zasobów, pobieraj więcej danych w jednym żądaniu, jeśli ma to sens, szybko kończ żądania skazane na niepowodzenie i nie ponawiaj ich bez końca.
Dopiero po tych czterech krokach oceń, czy rzeczywiście potrzebujesz większego budżetu albo wyższego poziomu usługi. Często okaże się, że faktycznie potrzebny limit jest niższy niż początkowo zakładano. Zwiększenie budżetu na początku oznacza natomiast finansowanie także nieefektywnych nawyków.
Nie ściskaj warstwy środowiska razem z warstwą obliczeniową
Częstym błędem przy oszczędzaniu limitu jest współdzielenie jednego środowiska przeglądarki przez kilka zadań, z założeniem, że wystarczy uruchomić środowisko tylko raz.
Koszt pojawia się natychmiast: sesje nadpisują się nawzajem, stany logowania są wypychane, pamięci podręczne się mieszają, a awaria jednego zadania może pociągnąć za sobą pozostałe. Niewielka oszczędność czasu instancji wraca ze zwielokrotnioną siłą w postaci diagnostyki i ponownych uruchomień.
Te dwie warstwy należy rozpatrywać osobno. Warstwa obliczeniowa wykonuje logikę zadań, planuje pracę na żądanie i optymalizuje koszty. Warstwa środowiska odpowiada za tożsamość i izolację, zapewniając jedno niezależne środowisko na zadanie i optymalizując stabilność. Ściskanie warstwy środowiska tylko dlatego, że zasoby obliczeniowe są ograniczone, miesza dwa różne rodzaje kosztów. Masowe tworzenie i zwalnianie środowisk powinno być centralnie obsługiwane przez narzędzia tej warstwy. Gdy PurpleMark izoluje sesje i pamięci podręczne według środowiska, zadania i wykonawcy wyższej warstwy mogą być planowani swobodniej.
Na koniec: nie obniżaj kosztów przez łamanie zasad. Nie korzystaj z nieoficjalnych usług tylko po to, by oszczędzać limit, i nie próbuj wymuszać większej przepustowości przez zwiększanie częstotliwości żądań. Po uruchomieniu ograniczeń ponowienia zwykle zużywają więcej limitu niż praca w kontrolowanym tempie.
