Nasza strona używa cookies. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Jak łatwo wykonać testy obciążeniowe dla aplikacji serverless

Allen Helton Software Engineering Manager / Tyler Technologies
Sprawdź, jak w prosty sposób wykonać testy obciążeniowe dla aplikacji serverless, wykorzystując do tego Postman oraz AWS.
Jak łatwo wykonać testy obciążeniowe dla aplikacji serverless

Kiedy wspomnisz inżynierowi oprogramowania o testach obciążeniowych, to w zdecydowanej większości przypadków w odpowiedzi spotkasz się z grymasem z ich strony. Dlaczego tak jest? Ponieważ są one zazwyczaj bolesne. Tworzenie automatycznych skryptów testowych jest żmudne, programiści, pisząc początkową wersję, nie myśleli o wydajności potrzebnej przy większej skali i nikt nie wie, jak rozwiązać pojawiające się w rezultacie problemy. Brzmi jak katastrofa i bałagan, ale katastrofa  konieczna.

I tutaj pojawia się serverless. Jeśli budujesz swoją aplikację przy użyciu FaaS (Functions as a Service), to macie szczęście. Prawdopodobnie wiesz już o licznych zaletach AWS Lambda, ale możesz też dodać do listy łatwe testy obciążeniowe. Podstawową zasadą stojącą za aplikacjami serverless jest postawienie na API, co oznacza, że możesz w pełni korzystać z systemu za pośrednictwem punktów końcowych. Aby załadować test, wystarczy tylko połączyć te żądania w celu zbudowania skryptów testowych.

Gdy już je masz, to następnie będziesz potrzebować narzędzia, które może je uruchamiać na dużą skalę. I tutaj z pomocą przychodzi AWS. Na koniec musisz mieć możliwość monitorowania kondycji systemu podczas działania testu obciążeniowego. I tutaj też możemy podziękować AWS. 


Użyj Postmana, aby stworzyć swoje skrypty testowe

Postman będzie działał jako kreator skryptów. Jeśli masz już zestaw procesów biznesowych, które chcesz, aby działały pod obciążeniem, to Postman pomoże Ci to zaaranżować. Jeśli korzystasz już z programu Postman i masz zbudowane kolekcje, które sprawdzają procesy biznesowe, to dobrze, bo możesz ich używać bez dodatkowej konfiguracji.

Jeśli tego nie zrobiliście, to gorąco polecam zacząć używać Postman Interceptor i szybko przejść przez niektóre scenariusze w aplikacji. Interceptor zarejestruje wszystkie żądania wysyłane przez Twoją przeglądarkę, pozostawiając Ci kolekcję, która robi dokładnie to, co Twoja aplikacja.

Wszystko, co musisz zrobić później, to sparametryzować żądania (jeśli to konieczne), aby mogły one prawidłowo łączyć się ze sobą. Po skonfigurowaniu kolekcji zgodnie z własnymi upodobaniami wyeksportuj ją do formatu JSON jako kolekcję w wersji 2.1.



Konfigurowanie narzędzia do testów obciążeniowych

Będziemy tutaj używać mechanizmu testów obciążeniowych stworzonego przez AWS. Co prawda nie obsługuje on kolekcji Postmana jako takich, ale możemy go nieco zmodyfikować, by uruchomić kolekcje za pomocą CLI Postmana — Newman.

Aby uruchomić zestaw zasobów testów obciążeniowych na swoim koncie AWS, postępuj zgodnie z instrukcjami na stronie internetowej dotyczącymi deploymentu. W czasie, gdy poszczególne składniki się tworzą, możemy wprowadzić w kodzie zmiany potrzebne, aby prawidłowo obsłużyć Postmana.

Sklonuj to repozytorium GitHuba dla narzędzia do testów obciążeniowych AWS i przejdź do folderu. .\source\container. Następnie wykonaj następujące czynności:

  1. Wyeksportowany plik JSON kolekcji Postman dodaj do folderu
  2. Dodaj nowy plik o nazwie test.json z następującą zawartością:

{
    "execution": [
        {
            "executor": "newman",
            "iterations": 5000, 
            "scenario": "simple"
        }
    ],
    "scenarios": {
        "simple": {
            "script": "Collection.json", 
            "timeout": "5s",
            "think-time": "1s"
        }
    },
   "reporting":[
      {
         "module":"final-stats",
         "summary":true,
         "percentiles":true,
         "summary-labels":true,
         "test-duration":true,
         "dump-xml":"/tmp/artifacts/results.xml"
      }
   ]
}


Aby Twoja kolekcja została uruchomiona, możesz zmienić wartość w iteration w linii 5 na tyle razy, ile chcesz. Wartość script w linii 11. będzie nazwą Twojej wyeksportowanej z Postman kolekcji.

Następnie aktualizujemy plik Dockerfile, aby uwzględnić nowe pliki JSON:

FROM blazemeter/taurus
# taurus includes python and pip
RUN pip install --no-cache-dir awscli
# Taurus working directory = /bzt-configs
ADD ./load-test.sh /bzt-configs/

# Added json files for Postman support
ADD Collection.json .
ADD test.json .

RUN chmod 755 /bzt-configs/load-test.sh
ENTRYPOINT ["sh", "-c","./load-test.sh"]


W tym momencie kończymy edycję źródła. Teraz musimy wprowadzić nasze zmiany na ECS.


Aktualizacja testów obciążeniowych w AWS

Do tej pory cały stos powinien być gotowy do użycia. Możemy teraz przejść do usługi ECS oraz do linku do Amazon ECR Repositories po lewej stronie strony.


Wybierz repozytorium testów obciążeniowych z listy, aby wyświetlić listę obrazów.


W tym miejscu klikasz przycisk View push commands w prawym górnym rogu, aby uzyskać zestaw poleceń specyficznych dla twojego repozytorium. Mamy cztery polecenia, aby zaktualizować repozytorium naszymi zmianami. Na swoim komputerze otwórz wiersz poleceń i przejdź do folderu .\source\container. Skopiuj i wklej cztery polecenia podane przez AWS, aby zaktualizować obraz.


Uwaga: jeśli musisz wprowadzić wiele zmian w obrazie, pamiętaj o dodaniu „- no-cache” na końcu polecenia w kroku 2.

Po zakończeniu działania poleceń jesteśmy gotowi do uruchomienia testów.


Uruchamianie testów obciążeniowych

Gdy skończy się deployment całego stosu, AWS powinien wysłać email z nazwą użytkownika, hasłem i linkiem do dashboardu testów obciążeniowych. Znajdź ten e-mail, kliknij link na konsoli i zaloguj się przy użyciu podanych danych. Naciśnij przycisk Create Test na górze strony, aby przejść do konfiguracji testu. Wypełnij pola Name, Description oraz Task Count wartościami, które chcesz w nim zastosować.


Zmiany, które wprowadziliśmy w plikach Dockerfile i test.json sprawiły, że pola Concurrency, Ramp Up, Hold For i HTTP endpoint under tests nie będą używane, ale nadal są wymagane do przesłania formularza. Wypełnij pola dowolnymi wartościami — zostaną one zignorowane po naciśnięciu przycisku Submit.

W Task Count wpisz liczbę kontenerów w klastrze, na których ma zostać uruchomiona kolekcja. Fargate ma limit 100 kontenerów działających jednocześnie, ale limit formularza to 50. Jeśli chcesz zwiększyć przepustowość do 100, możesz otworzyć narzędzia developerskie przeglądarki i zmienić limit z 50 na 100.

Po naciśnięciu przycisku Submit wszystkie kontenery zostaną podniesione i rozpocznie się wykonywanie kolekcji Postmana.


Monitoring

Podczas testu obciążeniowego warto jest monitorować wydajność swojej aplikacji. Istnieją dwa obszary, na które chcemy zwrócić uwagę w przypadku aplikacji serverless:

  • Jak skaluje się infrastruktura
  • Jak Twój kod obsługuje skalowanie.


Aby to zrobić, możemy stworzyć dwa wykresy CloudWatch do monitorowania w czasie rzeczywistym.


Skalowanie infrastruktury

Przyjrzymy się tutaj API Gateway i funkcjom Lambda. Jeśli nasza aplikacja nie radzi sobie za dobrze z obciążeniem, otrzymujemy zdarzenia związane z ograniczeniem przepustowości, a aplikacja stanie się powolna i nie będzie reagować.

W Cloudwatch przejdź do konsoli Metrics. Kliknij metryki Lambda> Across All Functions. Włącz ConcurrentExecutions, Durations, Errors, Invocations i Throttles.


Następnie chcemy zobaczyć metrykę ApiGateway> Across All APIs> Count. Kliknij kartę Graphed Metrics i zmień typ statystyki oraz okres, aby dopasować je do poniższego obrazu.


Jeśli chodzi o skalowanie infrastruktury, to takie podejście wystarczy dla większości aplikacji serverless. Jeśli korzystasz z innych usług AWS, możesz dodać inne metryki. Graf będzie aktualizowany w czasie rzeczywistym, aby pokazać wartości wszystkich statystyk.


Skalowanie aplikacji

Ważne jest też, aby sprawdzić, czy aplikacja generuje jakiekolwiek błędy podczas testu. Ze względu na to, że system jest testowany przez API Gateway, chcemy monitorować odpowiedzi naszych komunikatów API. Na nowym grafie CloudWatch chcemy wyświetlić wskaźniki 4XXError i 5XXError dla wszystkich API. Kliknij ApiGateway> By Api Name> filter for 4xx oraz select all results.


Usuń filtr i zrób to samo dla 5XX.

Jeśli trafisz na jakiekolwiek problemy z dławieniem usług AWS, z których korzystają Twoje funkcje lambda, to z pewnością pojawią się one jako odpowiedź 400 lub 500 za pośrednictwem API.

Te dwa wykresy pokazują stan Twojej aplikacji serverless podczas skalowania w czasie testu obciążeniowego. Jeśli zauważysz, że zaczynają pojawiać się błędy, możesz zmodyfikować grafy, aby pokazać określone funkcje lambda i zacząć wertować logi.


Podsumowanie

Testy obciążeniowe nie muszą być trudne. Sprawdzają one po prostu, czy Twoja aplikacja działa równie płynnie przy dużym obciążeniu, jak i bez obciążenia. Postman umożliwia nagrywanie i odtwarzanie sekwencji żądań za pośrednictwem przeglądarki. Jest to dokładna kopia tego, co ma być zrobione w terenie.

AWS umożliwia skalowanie odtwarzania i wysyłanie do aplikacji tysięcy żądań na minutę. Zapewnia również mechanizm wyświetlania kondycji aplikacji w miarę jej skalowania, aby dostosować się do obciążenia. Co więcej, testy obciążeniowe dają Ci dokładną informację na temat tego, jak kosztowne będzie uruchomienie aplikacji.

Jak już pisałem wcześniej, prognozowanie kosztów serverless może być trudne, ale można to uznać za źródło prawdy. Przetestuj system z obciążeniem produkcyjnym i zobacz zestawienie kosztów za pośrednictwem usługi rozliczeniowej AWS.

Nie pomijaj testów obciążeniowych. Musisz być pewny, że Twoja aplikacja będzie działać w momencie, gdy przetwarza najwięcej.

Miłego testowania!


Oryginał tekstu w języku angielskim możesz przeczytać tutaj.

Rozpocznij dyskusję

Lubisz dzielić się wiedzą i chcesz zostać autorem?

Podziel się wiedzą z 160 tysiącami naszych czytelników

Dowiedz się więcej