Die digitale Kommunikation ist heute in Firmen Alltag. Administratoren müssen die hierfür passenden Plattformen bereitstellen. Welche Möglichkeiten sich ... (mehr)

Loadtest durchführen

Um nun loslegen zu können, müssen Sie einen AWS-Account verwenden, der die nötigen Rechte besitzt. Dies sind nicht nur diverse Rollen für den eigentlichen Serverless-Dienst AWS Lambda, sondern auch für den Storage-Service S3, Cloudformation und einige mehr. Fehlen diese, bekommen Sie im Deploy-Schritt eine Fehlermeldung wie die folgende:

 

{ ServerlessError: ServerlessError: User: arn:aws:iam::587383870225:user/kops is not authorized to perform: cloudformation:DescribeStacks on resource: arn:aws:cloudformation:us-east-1:587383870225:stack/serverless-artillery-H1613rs2f-dev/*

Die einfachste Lösung ist natürlich, einen Account mit vollen AWS-Admin-Rechten zu verwenden, aber davon raten wir aus Sicherheitsgründen ab. Die Alternative ist, genau die Rollen zu vergeben, die das Serverless-Framework voraussetzt. Eine Diskussion dazu findet sich auf der Github-Seite von Serverless, wo auch ein Generator-Skript für die nötige IAM-Policy verlinkt ist [4]. Nun starten Sie mit dem folgenden Aufruf das Deployment der JavaScript-Files auf AWS Lambda:

$ slsart deploy

Klappt alles, sehen Sie eine Meldung wie im Bild. Die Meldung "Deploy complete" erscheint seltsamerweise auch, wenn es einen Fehler gibt, aber dann ist darüber meist noch ein Stacktrace zu sehen.

Die Funktionen von Serverless Artillery wurden in AWS Lambda installiert.

Mit einem Aufruf von »slsart invoke« starten Sie nun einen Lauf von Artillery. Ohne weiteres Zutun verwendet Artillery ein Default-File, das die grundlegende Funktion testet. Für eigene Loadtests müssen Sie eine Konfigurationsdatei im Artillery-Format schreiben, das im Einzelnen festlegt, wie das Trafficprofil aussieht, das simuliert werden soll.

Um das Schreiben der Konfiguration zu vereinfachen, bietet Serverless Artillery einen Befehl, der das Grundgerüst einer Datei erzeugt: »slsart script« . Nach dem Aufruf finden Sie im aktuellen Verzeichnis die Datei "script.yml", die Sie für Ihre Testszenarien anpassen können. Es ist auch möglich, schon beim Aufruf des »script« -Befehls einige Parameter anzugeben, die in die Datei wandern: "-e" gibt den "Endpoint" an, also die getestete URL, "-d" die Dauer des Tests, "-r" die anfängliche Request-Rate und "-t" die nach der Ramp-up-Time erreichte Request-Rate.

Befindet sich während des Invoke-Schritts eine Datei namens "script.yml" oder "script.json" im aktuellen Verzeichnis, verwendet Serverless Artillery diese für seine Tests. Alternativ geben Sie über den Schalter "-p" den Pfad zu Ihrer Konfigurationsdatei an. Es ist auch möglich, das Testskript direkt auf der Commandline hinter "-d" anzugeben. Weitere Anpassungen sind über »slsart configure« möglich, das die verwendeten Files im aktuellen Verzeichnis speichert, wo Sie sie vor dem Deployment ändern können.

Um Fehler auf einer Website zu finden, ohne die entsprechende URL mit tausenden von Hits zu belasten, rufen Sie »slsart invoke -a« auf, das nach einem Durchlauf abbricht und das Ergebnis ausgibt. Ein Beispiel für die Konfiguration eines Loadtests mit (Serverless) Artillery ist im Listingkasten zu sehen. Das Tool ist flexibel und ermöglicht viele Testszenarien, aber es ist zum Ersten das Studium der Dokumentation nötig und zum anderen ein bisschen Trial-and-Error, um komplexere Konstrukte wie Schleifen zu verstehen.

Listing: Artillery-Test



config:
    target: "https://staging1.local"
    phases:
       - duration: 60
         arrivalRate: 5
       - duration: 120
         arrivalRate: 5
         rampTo: 50
       - duration: 600
         arrivalRate: 50
    payload:
       path: "keywords.csv"
       fields:
         - "keywords"
scenarios:
    - name: "Search and buy"
      flow:
         - post:
               url: "/search"
               body: "kw={{ keywords }}"
               capture:
                  json: "$.results[0].id"
                  as: "id"
         - get:
               url: "/details/{{ id }}"
         - think: 3
         - post:
               url: "/cart"
               json:
                  productId: "{{ id }}"

Fazit

Die Serverless-Version des Loadtesting-Tools Artillery ermöglicht es, Loadtests für Webserver durchzuführen, ohne dafür eigene Server oder VMs zu starten. Ansonsten lässt sich das serverlose Artillery wie die normale Version bedienen und auf vielfältige Weise für Tests von Websites einsetzen. Zudem ist es ein brauchbares Projekt für alle, die sich mit der Serverless-Technologie beschäftigen möchten.

Link-Codes

[1] Serverless Artillery: https://github.com/Nordstrom/serverless-artillery/

[2] Artillery: https://artillery.io/

[3] Serverless: https://serverless.com/

[4] IAM-Rollen für Serverless: https://github.com/serverless/serverless/issues/1439/

comments powered by Disqus
Mehr zum Thema

Buchbesprechung

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2020