5

Moja aplikacja mocno opiera się na usługach AWS i szukam optymalnego rozwiązania opartego na nich. Aplikacja sieciowa uruchamia zaplanowane zadanie (zakładamy, że jest ono powtarzane w nieskończoność), co wymaga wykonania określonej ilości zasobów. Pojedynczy przebieg zadania zwykle zajmuje maksymalnie 1 minutę.Planowanie długotrwałych zadań za pomocą usług AWS

Obecnym pomysłem jest przekazywanie zadań za pośrednictwem SQS i odradzanie pracowników w instancjach EC2 w zależności od rozmiaru kolejki. (ta część jest mniej lub bardziej oczywista) Ale mam problem ze znalezieniem odpowiedniego rozwiązania dla faktycznego uruchamiania zadań w określonych odstępach czasu. Załóżmy, że mamy do czynienia z 10000 miejscami pracy. Tak więc, aby program uruchamiający 10k cronjobs (samo zadanie jest dość proste, tylko przekazywanie opisu zadań za pośrednictwem SQS) jednocześnie wydaje się szalonym pomysłem. Prawdziwe pytanie brzmi: jak przeprowadzić autoskalowanie samego programu planującego (biorąc pod uwagę scenariusze przy ponownym uruchomieniu programu planującego, tworzeniu nowej instancji itp.)? Czy program planujący jest nadmiarowy jako aplikacja i rozsądniej jest polegać na funkcjach AWS Lambda (lub innych usługach zapewniających planowanie)? Problem z używaniem funkcji Lambda jest pewnym ograniczeniem, a pamięć dostarczona 128mb dostarczona przez pojedynczą funkcję jest w rzeczywistości za duża (20mb wydaje się więcej niż wystarczająca).

Alternatywnie, sam pracownik może czekać przez pewien czas i powiadomić harmonogram, który powinien uruchomić zadanie jeszcze raz. Powiedzmy, jeśli częstotliwość jest 1 godzina:

1. Scheduler sends job to worker 1 
2. Worker 1 performs the job and after one hour sends it back to Scheduler 
3. Scheduler sends the job again 

Chodzi tu jednak jest możliwość tego pracownika będzie się skalować w

Bottom Line próbuję osiągnąć lekką planującego co. nie wymagają autoskalowania i służą jako koncentrator wyłącznie do przesyłania opisów zadań. I na pewno nie powinno być dławione po ponownym uruchomieniu usługi.

+1

„long-uruchamianie zadań” .. „zajmie maksymalnie 1 min”:/ –

Odpowiedz

5

Lambda jest do tego idealna. Masz wiele krótkich procesów (~ 1 minuta), a Lambda to krótkie procesy (do pięciu minut w dzisiejszych czasach). Bardzo ważne jest, aby wiedzieć, że szybkość procesora jest sprzężona z pamięcią RAM w sposób liniowy. Funkcja Lambda o pojemności 1 GB jest odpowiednikiem instancji t2.micro, jeśli dobrze pamiętam, a 1,5 GB RAM oznacza 1,5x większą szybkość procesora. Koszt tych funkcji jest tak niski, że można to po prostu wykonać. 128 MB RAM ma 1/8 prędkości procesora z mikro instancji, więc nie polecam ich używania.

Jako mechanizm kolejkowania możesz użyć S3 (tak, dobrze to przeczytałeś). Utwórz zasobnik i pozwól pracownikowi Lambda wywołać, gdy obiekt zostanie utworzony. Jeśli chcesz zaplanować pracę, umieść plik wewnątrz wiadra. Lambda uruchamia się i przetwarza natychmiast.

Teraz musisz przestrzegać pewnych ograniczeń. W ten sposób możesz mieć tylko 100 pracowników w tym samym czasie (całkowita liczba aktywnych instancji Lambda), ale możesz poprosić AWS o zwiększenie tego.

Koszty są następujące:

  • 0,005 za 1000 żądania PUT, więc 5 $ za milion wniosków Praca (to jest droższe niż SQS).
  • Środowisko wykonawcze Lambda. Zakładając normalną szybkość procesora t2.micro (1 GB RAM), kosztuje 0,0001 USD za zadanie (60 sekund, pierwsze 300 000 sekund to za darmo = 5000 miejsc pracy)
  • Żądania Lambda. 0,20 USD za milion wyzwalaczy (pierwszy milion jest bezpłatny)

Ta konfiguracja nie wymaga żadnych serwerów z Twojej strony. Nie może to zejść (tylko jeśli sam AWS).

(nie zapomnij usunąć pracę z S3, gdy skończysz)

+0

Dzięki za sugestię. Jeszcze jedno pytanie, co, jeśli zamiast tworzyć wiele funkcji lambda, robimy tylko kilka (powiedzmy, że tworzymy oddzielne funkcje działające co 5 minut, co godzinę, codziennie itp.). Każda z funkcji lambda pobierze zadania z s3 i przekaże je przez sqs. Coś, co może powodować problemy w tej architekturze? – Yerken

+0

Musisz pomyśleć o strukturze klawiszy s3 (nazw plików), więc funkcje lambda nie zawierają plików podwójnych (funkcja lambda nie wie o innych). Fajną rzeczą jest to, że możesz wyzwolić funkcję lambda na wydarzenie S3, więc nigdy nie masz tego problemu. Następnie możesz wysłać go do SQS (każda funkcja lambda ma jedno wywołanie SQS, to nie jest problem i zajmuje <1 sekundę). Ale jeśli możesz to zrobić, to dlaczego nie zdefiniować partii w 1 Bilet SQS i nie pomijać razem S3 i Lambda? –

+0

Czy mógłbyś wyjaśnić, co masz na myśli, definiując partię w 1 Bilet SQS? Dzięki – Yerken