Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Designüberlegungen

In diesem Abschnitt werden wichtige Entwurfsentscheidungen und Konfigurationsoptionen für die Lösung Distributed Load Testing on AWS beschrieben, einschließlich unterstützter Anwendungen, Testtypen, Planungsoptionen und Überlegungen zur Bereitstellung.

Unterstützte Anwendungen

Diese Lösung unterstützt das Testen von Cloud-basierten und lokalen Anwendungen, sofern Sie über eine Netzwerkverbindung zwischen Ihrem AWS-Konto und Ihrer Anwendung verfügen. Die Lösung unterstützt APIs, die HTTP- oder HTTPS-Protokolle verwenden.

Testtypen

Distributed Load Testing auf AWS unterstützt mehrere Testtypen: einfache HTTP-Endpunkttests, JMeter, k6 und Locust. Jeder Testtyp außer dem einfachen HTTP-Endpunkt kann in beiden Traffic-Shape-Modi ausgeführt werden. Weitere Informationen finden Sie unter Traffic-Shape-Modi.

Einfache HTTP-Endpunkttests

Die Webkonsole bietet eine HTTP-Endpunktkonfigurationsschnittstelle, mit der Sie jeden HTTP- oder HTTPS-Endpunkt testen können, ohne benutzerdefinierte Skripts schreiben zu müssen. Sie definieren die Endpunkt-URL, wählen die HTTP-Methode (GET, POST, PUT, DELETE usw.) aus einem Dropdownmenü aus und fügen optional benutzerdefinierte Anforderungsheader und Body-Payloads hinzu. Mit dieser Konfiguration können Sie APIs mit benutzerdefinierten Autorisierungstoken, Inhaltstypen oder anderen HTTP-Headern und Anforderungstexten testen, die für Ihre Anwendung erforderlich sind.

Wenn Sie einen HTTP-Endpunkt konfigurieren, konvertiert die Lösung Ihre Konfiguration in einen Testplan, der von der mitgelieferten Apache JMeter-Binärdatei über das Taurus-Framework ausgeführt wird. Einfache HTTP-Endpunkttests akzeptieren kein Testarchiv, sodass sie die mitgelieferte JMeter-Binärdatei oder -Plugins nicht überschreiben können. Wenn Sie HTTP-Endpunkttests mit einem gepatchten JMeter ausführen müssen, verwenden Sie stattdessen den JMeter-Tests JMeter-Testtyp. Informationen zu Sicherheitsüberlegungen finden Sie unter Apache JMeter.

Da die Lösung den Testplan für diesen Testtyp generiert, werden einfache HTTP-Endpunkttests nur im Standardmodus ausgeführt. Für den einheitlichen Modus ist ein Skript erforderlich, das Sie hochladen. Weitere Informationen finden Sie unter Traffic-Shape-Modi.

JMeter-Tests

Wenn Sie ein Testszenario mit der Webkonsole erstellen, können Sie ein JMeter-Testskript hochladen. Die Lösung lädt das Skript in den S3-Bucket der Szenarien hoch. Wenn Amazon ECS-Aufgaben ausgeführt werden, laden sie das JMeter-Skript von S3 herunter und führen den Test aus.

Wenn Sie JMeter-Eingabedateien haben, können Sie die Eingabedateien zusammen mit dem JMeter-Skript komprimieren. Sie können die Zip-Datei auswählen, wenn Sie ein Testszenario erstellen.

Wenn Sie Plugins hinzufügen möchten, werden alle Jar-Dateien, die in einem /plugins-Unterverzeichnis in der mitgelieferten Zip-Datei enthalten sind, in das JMeter-Erweiterungsverzeichnis kopiert und stehen für Lasttests zur Verfügung.

Wenn Sie JMeter-Plugins einbeziehen, müssen die JAR-Dateien in einem Unterverzeichnis namens /plugins im Stammverzeichnis der Zip-Datei gebündelt werden. Der Pfad zu den JAR-Dateien muss relativ zum Stammverzeichnis der ZIP-Datei lauten. /plugins/BUNDLED_PLUGIN.jar.

Weitere Informationen zur Verwendung von JMeter-Skripten finden Sie im JMeter-Benutzerhandbuch.

k6-Tests

Die Lösung unterstützt Tests, die auf dem K6-Framework basieren. Sie können die k6-Testdatei zusammen mit allen erforderlichen Eingabedateien in eine Archivdatei hochladen. Die Webkonsole zeigt eine Lizenzbestätigungsmeldung an, wenn Sie einen neuen k6-Test erstellen. Lizenz- und Sicherheitsdetails finden Sie unter Grafana k6. Grafana k6

Heuschrecken-Tests

Die Lösung unterstützt Tests, die auf dem Locust-Framework basieren. Sie können die Locust-Testdatei zusammen mit allen erforderlichen Eingabedateien in eine Archivdatei hochladen.

Benennung von Testskripten

Wenn Sie eine einzelne .py Datei hochladen, speichert die Lösung sie unter der Test-ID und verweist direkt darauf, sodass die Datei einen beliebigen Namen haben kann. Wenn Sie ein .zip Archiv hochladen, durchsucht die Lösung das Archiv nach einer Datei mit dem Namenlocustfile.py. Wenn das Archiv ein Python-Skript unter einem anderen Namen enthält, schlägt der Test beim Starten des Containers mit der Meldung fehlNo test script (.py) in zip file.

Benutzerdefinierte Python-Abhängigkeiten

Der Container für Lasttests enthält Locust und seine Abhängigkeiten. Er enthält keine Python-Pakete von Drittanbietern. Wenn Ihr Locust-Skript ein Paket importiert, das nicht im Container vorhanden ist, schlägt der Test mit ModuleNotFoundError fehl. Um zusätzliche Pakete verfügbar zu machen, fügen Sie eine requirements.txt Datei in das Stammverzeichnis Ihres .zip Archivs ein. Der Container installiert die Pakete, die requirements.txt vor Beginn des Tests aufgeführt sind.

Sie können Abhängigkeiten auf eine von zwei Arten angeben:

Das folgende Beispiel zeigt das Archiv-Layout:

my-test.zip
├── locustfile.py         # Required — must use this name
├── requirements.txt      # Optional — packages to install
└── packages/             # Optional — wheels, for offline install only
    └── *.whl

Beide requirements.txt und das packages Unterverzeichnis müssen sich parallel locustfile.py im Stammverzeichnis des Archivs befinden. Lassen Sie beide weg, wenn Ihr Skript nur Pakete importiert, die der Container bereits bereitstellt. Das packages Unterverzeichnis wird nur zusammen mit einer requirements.txt Datei wirksam; für sich genommen wird es ignoriert und es werden keine Pakete installiert.

Räder für den Container vorbereiten

Auf dem Lasttestcontainer wird Linux auf der x86_64-Architektur mit Python 3.11 ausgeführt. Wheels, die für ein anderes Betriebssystem, eine andere Architektur oder eine andere Python-Version kompiliert wurden, werden nicht installiert. In reinem Python geschriebene Pakete werden als plattformunabhängige Räder verteilt und funktionieren überall, aber Pakete, die kompilierte Erweiterungen enthalten, benötigen ein Rad, das für die Plattform des Containers gebaut wurde. Da der Container keinen Compiler enthält, kann er beim Start der Aufgabe keine Quelldistribution erstellen.

Führen Sie den folgenden Befehl aus, um Räder herunterzuladen, die mit der Plattform des Containers kompatibel sind. Sie können diesen Befehl von jedem Betriebssystem aus ausführen, einschließlich macOS und Windows. Fügen Sie dann das resultierende packages Verzeichnis in Ihr Archiv ein:

pip download -r requirements.txt \
  --dest packages \
  --platform manylinux2014_x86_64 \
  --python-version 3.11 \
  --only-binary=:all:

Die --python-version Optionen --platform und zielen auf den Container ab, nicht auf den Computer, auf dem Sie den Befehl ausführen. Die --only-binary=:all: Option führt dazu, dass der Befehl fehlschlägt, anstatt stillschweigend auf eine Quelldistribution zurückzugreifen, die der Container nicht erstellen kann. Das manylinux2014 Tag spezifiziert ein Rad, das mit Glibc 2.17 und höher kompatibel ist und die Version des Containers beinhaltet.

Um ein Paket zu bündeln, das Sie selbst verwalten, bauen Sie ein Rad aus dem Quellverzeichnis Ihres Pakets mit pip wheel . --wheel-dir packages und fügen Sie dann den Paketnamen zu hinzu. requirements.txt

Shape-Modi für den Verkehr

Jeder Test wird in einem von zwei Traffic-Shape-Modi ausgeführt: Standard oder Nativ. Der Modus bestimmt drei Dinge: welche Seite die Last steuert, welches Container-Image die Fargate-Aufgaben verwenden und welche Ladeparameter die Lösung an das Testframework sendet. Eine Anleitung zur Auswahl eines Modus bei der Erstellung eines Tests finden Sie unter Traffic-Shape-Modi im Abschnitt Die Lösung verwenden.

Standardmodus

Die Fargate-Aufgaben verwenden das Image, auf dem Taurus installiert ist. Taurus erhält von der Lösung die Anzahl der Aufgaben, die Parallelität, den Hochlauf und die Wartezeit. Es übersetzt diese Werte in die eigenen Laststeuerungen des zugrunde liegenden Frameworks. Taurus hat Vorrang vor der Last, die Ihr Skript deklariert. Es schreibt einen k6-Optionsblock, eine Locust LoadTestShape - oder eine JMeter-Threadgruppe um oder ignoriert sie. Die virtuellen Benutzer, die eine Region generiert, sind die Anzahl der Aufgaben multipliziert mit der Parallelität für jede Aufgabe. Diese Form ist für jedes Framework gleich. Auf diese Weise führte die Lösung jeden Test vor Version 4.3.0 aus.

Nativer Modus

Die Fargate-Aufgaben verwenden das dedizierte Image für das Testframework, das Taurus nicht beinhaltet. Anstatt eine Taurus-Konfiguration zu schreiben, ruft die Lösung das Framework direkt auf:jmeter -n -t, oder. k6 run locust --headless Sie übergibt keine Ladeparameter. Ihr Skript ist die alleinige Autorität für den Traffic, den es generiert.

Aus diesem Entwurf ergeben sich zwei Konsequenzen, und beide wirken sich auf die Größe eines Tests aus:

Planung von Tests

Die Lösung bietet drei Optionen zur Ausführungszeit für die Ausführung von Lasttests:

Wenn Sie „Einmal ausführen“ auswählen, geben Sie die Laufzeit im 24-Stunden-Format und das Ausführungsdatum an, an dem der Auslastungstest ausgeführt werden soll.

Wenn Sie Nach Zeitplan ausführen auswählen, können Sie entweder manuell einen Cron-Ausdruck eingeben oder aus gängigen Cron-Mustern auswählen (z. B. jede Stunde, täglich zu einer bestimmten Zeit, wochentags oder monatlich). Der Cron-Ausdruck verwendet ein feinkörniges Zeitplanformat mit Feldern für Minuten, Stunden, Monatstag, Monat, Wochentag und Jahr. Sie müssen auch ein Ablaufdatum angeben, das definiert, wann der geplante Test nicht mehr ausgeführt werden soll. Weitere Informationen zu Validierungsregeln für die Planung finden Sie im Abschnitt Einschränkungen bei der Planung in diesem Handbuch.

Gleichzeitige Tests

Jedes Mal, wenn ein Auslastungstest ausgeführt wird, erstellt die AWS-Lambda-Funktion des Task-Runners ein CloudWatch Amazon-Dashboard, das EcsLoadTesting-<testId>-<region> in jeder Region benannt ist, in der der Test ausgeführt wird. Das CloudWatch Dashboard zeigt die kombinierte Ausgabe aller Aufgaben, die im Amazon ECS-Cluster ausgeführt werden, in Echtzeit an: durchschnittliche Antwortzeit, Anzahl gleichzeitiger Benutzer, Anzahl erfolgreicher Anfragen und Anzahl fehlgeschlagener Anfragen. Die Lösung aggregiert jede Metrik sekundengenau und aktualisiert das Dashboard jede Minute.

Bei nachfolgenden Durchläufen desselben Testszenarios wird dasselbe Dashboard aktualisiert, sodass Ihr Konto ein Dashboard für jedes Testszenario in jeder Region enthält. Diese Dashboards verbleiben nach Abschluss der Tests in Ihrem Konto. Für sie fällt eine monatliche Gebühr an, bis Sie sie löschen. Die Lösung löscht die Dashboards eines Szenarios, wenn Sie das Testszenario löschen (z. B. über die Webkonsole). Die Dashboards werden nicht gelöscht, wenn Sie die Stapel der Lösung löschen. CloudFormation Weitere Informationen finden Sie im Abschnitt Kosten und im Abschnitt Manuelles Löschen einbehaltener Ressourcen in diesem Handbuch.

Benutzerverwaltung

Bei der Erstkonfiguration geben Sie einen Benutzernamen und eine E-Mail-Adresse an, die Amazon Cognito verwendet, um Ihnen Zugriff auf die Webkonsole der Lösung zu gewähren. Die Konsole bietet keine Benutzerverwaltung. Um weitere Benutzer hinzuzufügen, müssen Sie die Amazon Cognito-Konsole verwenden. Weitere Informationen finden Sie im Amazon Cognito-Entwicklerhandbuch unter Benutzer in Benutzerpools verwalten.

Informationen zur Migration vorhandener Benutzer zu Amazon Cognito-Benutzerpools finden Sie im AWS-Blog Approaches for migrating users to Amazon Cognito-Benutzerpools.

Identitätsanbieterverbund

Der Amazon Cognito-Benutzerpool der Lösung unterstützt den Verbund mit externen Identitätsanbietern (IdPs) mithilfe der Protokolle SAML 2.0 oder OpenID Connect (OIDC). Der Verbund ermöglicht es Benutzern, sich an der Webkonsole mit ihren vorhandenen Unternehmens- oder Organisationsanmeldedaten anstelle von Anmeldeinformationen anzumelden. Cognito-native Verbundbenutzer erhalten dieselben Zugriffsberechtigungen wie Benutzer, die direkt im Cognito-Benutzerpool erstellt wurden.

Die Lösung stellt bereits den Cognito-Benutzerpool, die Domain, den App-Client und die gehostete Benutzeroberfläche bereit. Um den Verbund zu aktivieren, müssen Sie nur Ihren Identitätsanbieter registrieren und ihn auf dem vorhandenen App-Client aktivieren.

Wenn Sie die optionale MCP Server-Integration bereitstellen, können Verbundbenutzer auch mit denselben Anmeldeinformationen für den Cognito-Benutzerpool auf den MCP-Server zugreifen.

Voraussetzungen

Bevor Sie den Verbund konfigurieren, benötigen Sie Folgendes:

Schritt 1: Konfigurieren Sie Ihren Identitätsanbieter

Konfigurieren Sie Ihren externen Identitätsanbieter mit den folgenden Werten, damit er mit dem Cognito-Benutzerpool der Lösung kommunizieren kann.

Für SAML-Identitätsanbieter:

Für OIDC-Identitätsanbieter:

Einzelheiten zu den Anforderungen Ihres IdP finden Sie unter Hinzufügen von SAML-Identitätsanbietern zu einem Benutzerpool oder Hinzufügen von OIDC-Identitätsanbietern zu einem Benutzerpool im Amazon Cognito-Entwicklerhandbuch.

Schritt 2: Registrieren Sie den Identitätsanbieter in Cognito

Fügen Sie Ihren externen Identitätsanbieter mithilfe der Amazon Cognito-Konsole zum vorhandenen Cognito-Benutzerpool der Lösung hinzu.

Eine schrittweise Anleitung finden Sie unter Hinzufügen einer Benutzerpool-Anmeldung über einen Drittanbieter im Amazon Cognito-Entwicklerhandbuch.

Schritt 3: Attributzuordnungen konfigurieren

Konfigurieren Sie Attributzuordnungen zwischen den Ansprüchen Ihres Identitätsanbieters und den Cognito-Benutzerpool-Attributen. Ordnen Sie mindestens den E-Mail-Anspruch des Benutzers vom externen Anbieter dem Cognito-Attribut zu. email Erwägen Sie auch, sie name zuzuordnen oder nickname ob Ihr Identitätsanbieter sie bereitstellt.

Eine Anleitung dazu finden Sie im Amazon Cognito-Entwicklerhandbuch unter Spezifizieren von Attributzuordnungen für Identitätsanbieter für Ihren Benutzerpool.

Schritt 4: Aktivieren Sie den Identitätsanbieter im App-Client

Suchen Sie in der Amazon Cognito-Konsole nach dem App-Client, der von der Lösung erstellt wurde, und aktivieren Sie Ihren neuen Identitätsanbieter in den Einstellungen für die gehostete Benutzeroberfläche.

Eine Anleitung finden Sie im Amazon Cognito Developer Guide unter Konfiguration eines App-Clients für Benutzerpools.

Den Cognito-Standardbenutzer deaktivieren oder löschen

Nachdem Sie den Verbund konfiguriert haben, möchten Sie möglicherweise den Standardbenutzer, der während der Stack-Bereitstellung erstellt wurde, deaktivieren oder löschen. Dies ist optional — der Standardbenutzer arbeitet weiterhin zusammen mit der Verbundanmeldung.

Um einen Benutzer zu deaktivieren, navigieren Sie in der Amazon Cognito-Konsole zum Cognito-Benutzerpool der Lösung, wählen Sie den Tab Benutzer aus, und wählen Sie Benutzerzugriff deaktivieren aus. Um einen Benutzer zu löschen, müssen Sie ihn zuerst deaktivieren und dann Benutzer löschen auswählen. Wenn du einen Benutzer deaktivierst, werden seine Tokens gesperrt und die Anmeldung verhindert, während das Konto erhalten bleibt. Durch das Löschen wird es dauerhaft entfernt.

Weitere Informationen finden Sie unter Benutzerkonten verwalten und suchen im Amazon Cognito Developer Guide.

Regionale Bereitstellung

Diese Lösung verwendet Amazon Cognito, das nur in bestimmten AWS-Regionen verfügbar ist. Daher müssen Sie diese Lösung in einer Region bereitstellen, in der Amazon Cognito verfügbar ist. Die aktuelle Serviceverfügbarkeit nach Regionen finden Sie in der regionalen AWS-Serviceliste.