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. # Einzelheiten zur Architektur Einzelheiten zur Architektur In diesem Abschnitt werden die Komponenten und [AWS-Services beschrieben, aus denen diese Lösung besteht](#aws-services-in-this-solution), sowie die Architekturdetails dazu, wie diese Komponenten zusammenarbeiten. Die Lösung Distributed Load Testing on AWS besteht aus drei Komponenten auf hoher Ebene: einem [Frontend](front-end.md), einem [Backend](back-end.md) und einem optionalen [MCP-Server](MCP-Server.md). # Frontend Das Frontend bietet die Schnittstellen für die Interaktion mit der Lösung und umfasst: + Eine Lasttest-API für den programmatischen Zugriff + Eine Webkonsole zum Erstellen, Planen und Ausführen von Leistungstests + Ein optionaler MCP-Server für die KI-gestützte Analyse von Testergebnissen und Fehlern ## Belastungstest-API Distributed Load Testing auf AWS konfiguriert Amazon API Gateway so, dass es die RESTful API der Lösung hostet. Benutzer können über die mitgelieferte Webkonsole, RESTful API und den optionalen MCP-Server sicher mit dem Lasttestsystem interagieren. Die API fungiert als „Eingangstür“ für den Zugriff auf Testdaten, die in Amazon DynamoDB gespeichert sind. Sie können die auch verwenden APIs , um auf alle erweiterten Funktionen zuzugreifen, die Sie in die Lösung integriert haben. Diese Lösung nutzt die Benutzerauthentifizierungsfunktionen der Amazon Cognito Cognito-Benutzerpools. Nach erfolgreicher Authentifizierung eines Benutzers gibt Amazon Cognito ein JSON-Web-Token aus, mit dem die Konsole Anfragen an die Lösung APIs (Amazon API Gateway Gateway-Endpunkte) senden kann. HTTPS-Anfragen werden von der Konsole APIs mit dem Autorisierungsheader, der das Token enthält, an die Konsole gesendet. Basierend auf der Anfrage ruft API Gateway die entsprechende AWS Lambda Lambda-Funktion auf, um die erforderlichen Aufgaben mit den in den DynamoDB-Tabellen gespeicherten Daten auszuführen, Testszenarien als JSON-Objekte in Amazon S3 zu speichern, Amazon CloudWatch Metrics-Bilder abzurufen und Testszenarien an die AWS Step Functions Functions-Zustandsmaschine zu senden. Weitere Informationen zur API der Lösung finden Sie im Abschnitt [Distributed Load Testing API](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/distributed-load-testing-api.html) in diesem Handbuch. ## Web-Konsole Diese Lösung umfasst eine Webkonsole, mit der Sie Tests konfigurieren und ausführen, laufende Tests überwachen und detaillierte Testergebnisse anzeigen können. Die Konsole ist eine ReactJS-Anwendung, die mit [Cloudscape](https://cloudscape.design/), einem Open-Source-Designsystem für die Erstellung intuitiver Webanwendungen, erstellt wurde. Die Konsole wird in Amazon S3 gehostet und der Zugriff erfolgt über Amazon CloudFront. Die Anwendung nutzt AWS Amplify zur Integration mit Amazon Cognito, um Benutzer zu authentifizieren. Die Webkonsole enthält auch eine Option zum Anzeigen von Live-Daten für einen laufenden Test, in dem sie das entsprechende Thema in AWS IoT Core abonniert. Die URL der Webkonsole ist der Name der CloudFront Distributionsdomain, der in den CloudFormation Ausgaben als **Konsole** zu finden ist. Nachdem Sie die CloudFormation Vorlage gestartet haben, erhalten Sie außerdem eine E-Mail mit der URL der Webkonsole und dem Einmalkennwort für die Anmeldung. ## MCP-Server (optional) Der optionale Model Context Protocol (MCP) -Server bietet eine zusätzliche Schnittstelle für KI-Entwicklungstools, um über Interaktionen in natürlicher Sprache auf Lasttestdaten zuzugreifen und diese zu analysieren. Diese Komponente wird nur bereitgestellt, wenn Sie bei der Bereitstellung der Lösung die Option MCP-Server auswählen. Mit dem MCP Server können KI-Agenten mithilfe von Tools wie Amazon Q, Claude und anderen MCP-kompatiblen KI-Assistenten Testergebnisse abfragen, Leistungskennzahlen analysieren und Einblicke in Ihre Lasttestdaten gewinnen. Ausführliche Informationen zur Architektur und Konfiguration des MCP-Servers finden Sie in diesem Abschnitt unter [MCP](MCP-Server.md) Server. # Backend Das Backend besteht aus einer Container-Image-Pipeline und einer Load-Test-Engine, mit der Sie die Last für die Tests generieren. Sie interagieren mit dem Backend über das Frontend. Darüber hinaus werden die für jeden Test gestarteten Aufgaben von Amazon ECS auf AWS Fargate mit einer eindeutigen Test-ID (ID) gekennzeichnet. Diese Test-ID-Tags können Ihnen helfen, die Kosten für diese Lösung zu überwachen. Weitere Informationen finden Sie unter [Benutzerdefinierte Cost Allocation Tags](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) im *AWS Billing and Cost Management-Benutzerhandbuch*. ## Pipeline für Container-Images Diese Lösung verwendet ein mit [Amazon Linux 2023](https://aws.amazon.com/linux/amazon-linux-2023/) erstelltes Container-Image als Basis-Image, auf dem das [Taurus](https://gettaurus.org/) Load Testing Framework installiert ist. Taurus ist ein Open-Source-Framework zur Testautomatisierung, das K6 JMeter, Locust und andere Testtools unterstützt. AWS hostet dieses Image in einem öffentlichen Repository von Amazon Elastic Container Registry (Amazon ECR). Die Lösung verwendet dieses Image, um Aufgaben im Amazon ECS on AWS Fargate-Cluster auszuführen. Weitere Informationen finden Sie im Abschnitt zur [Anpassung von Container-Images](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/container-image.html) in diesem Handbuch. ## Infrastruktur testen Zusätzlich zur CloudFormation Hauptvorlage bietet die Lösung eine regionale Vorlage, mit der die erforderlichen Ressourcen für die Durchführung von Tests in mehreren Regionen bereitgestellt werden können. Die Lösung speichert diese Vorlage in Amazon S3 und stellt in der Webkonsole einen Link dazu bereit. Jeder regionale Stack umfasst eine VPC, einen AWS Fargate-Cluster und eine Lambda-Funktion für die Verarbeitung von Live-Daten. Weitere Informationen zur Bereitstellung der Testinfrastruktur in weiteren Regionen finden Sie im Abschnitt [Bereitstellung in mehreren Regionen dieses Handbuchs](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/multi-region-deployment.html). ## Test-Engine auslasten Die Distributed Load Testing-Lösung verwendet Amazon Elastic Container Service (Amazon ECS) und AWS Fargate, um Tausende von gleichzeitigen Benutzern in mehreren Regionen zu simulieren und HTTP-Anfragen mit kontinuierlicher Geschwindigkeit zu generieren. Sie definieren die Testparameter mithilfe der mitgelieferten Webkonsole. Die Lösung verwendet diese Parameter, um ein JSON-Testszenario zu generieren und es in Amazon S3 zu speichern. Weitere Informationen zu Testskripten und Testparametern finden Sie unter [Testtypen](design-considerations.md#test-types) in diesem Abschnitt. Eine AWS Step Functions Functions-Zustandsmaschine führt Amazon ECS-Aufgaben in einem AWS Fargate-Cluster aus und überwacht sie. Die AWS Step Functions Functions-Zustandsmaschine umfasst eine AWS-Lambda-Funktion mit ecr-checker, eine AWS-Lambda-Funktion, eine task-status-checker AWS-Lambda-Funktion für Task-Runner, eine AWS-Lambda-Funktion zum Abbrechen von Aufgaben und eine AWS-Lambda-Funktion zum Analysieren von Ergebnissen. [Weitere Informationen zum Workflow finden Sie im Abschnitt „Workflow testen“ dieses Handbuchs.](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-workflow.html) Weitere Informationen zu Testergebnissen finden Sie im Abschnitt [Testergebnisse](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-results.html) dieses Handbuchs. Weitere Informationen zum Ablauf der Teststornierung finden Sie im Abschnitt zum [Ablauf der Teststornierung](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-cancel-workflow.html) in diesem Handbuch. Wenn Sie Live-Daten auswählen, initiiert die Lösung in jeder Region eine real-time-data-publisher Lambda-Funktion anhand der CloudWatch Protokolle, die den Fargate-Aufgaben in dieser Region entsprechen. Die Lösung verarbeitet und veröffentlicht dann die Daten zu einem Thema in AWS IoT Core in der Region, in der Sie den Haupt-Stack gestartet haben. Weitere Informationen finden Sie im Abschnitt [Live-Daten](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/live-data.html) dieses Handbuchs. # MCP-Server Die optionale Serverintegration des Model Context Protocol (MCP) ermöglicht es KI-Agenten, über Interaktionen in natürlicher Sprache programmgesteuert auf Ihre Lasttestdaten zuzugreifen und diese zu analysieren. Diese Komponente wird nur bereitgestellt, wenn Sie bei der Bereitstellung der Lösung die Option MCP-Server auswählen. Der MCP-Server fungiert als Brücke zwischen KI-Entwicklungstools und Ihrer DLT-Bereitstellung und bietet eine standardisierte Schnittstelle für die intelligente Analyse der Ergebnisse von Leistungstests. Die Architektur integriert mehrere AWS-Services, um eine sichere, skalierbare Schnittstelle für Interaktionen mit KI-Agenten zu schaffen: ## AgentCore AWS-Gateway AWS AgentCore Gateway ist ein vollständig verwalteter Service, der standardisiertes Hosting und Protokollmanagement für MCP-Server bietet. In dieser Lösung dient AgentCore Gateway als öffentlicher Endpunkt, mit dem KI-Agenten eine Verbindung herstellen, wenn sie Zugriff auf Ihre Lasttestdaten anfordern. Der Service wickelt die gesamte MCP-Protokollkommunikation ab, einschließlich der Erkennung von Tools, der Validierung von Authentifizierungstoken und der Weiterleitung von Anfragen. AgentCore Gateway arbeitet als Mehrmandantendienst mit integrierten Sicherheitsvorkehrungen gegen allgemeine Bedrohungen für öffentliche Endgeräte und validiert gleichzeitig die Signaturen und Ansprüche von Cognito-Tokens für jede Anfrage. ## DLT MCP Server Lambda Die DLT MCP Server Lambda-Funktion ist eine benutzerdefinierte serverlose Komponente, die MCP-Anfragen von AI-Agenten verarbeitet und sie in Abfragen für Ihre DLT-Ressourcen übersetzt. Diese Lambda-Funktion fungiert als Informationsebene der MCP-Integration. Sie ruft Testergebnisse aus DynamoDB-Tabellen ab, greift auf Leistungsartefakte zu, die in S3-Buckets gespeichert sind, und fragt CloudWatch Logs nach detaillierten Ausführungsinformationen ab. Die Lambda-Funktion implementiert schreibgeschützte Zugriffsmuster und wandelt DLT-Rohdaten in strukturierte, KI-freundliche Formate um, die Agenten einfach interpretieren und analysieren können. ## Integration der Authentifizierung Das Authentifizierungssystem nutzt Ihre bestehende Cognito-Benutzerpool-Infrastruktur, um konsistente Zugriffskontrollen sowohl für die Webkonsole als auch für die MCP-Serverschnittstellen aufrechtzuerhalten. Diese Integration verwendet die tokenbasierte OAuth 2.0-Authentifizierung. Benutzer authentifizieren sich einmal über den Cognito-Anmeldevorgang und erhalten Token, die sowohl für Benutzeroberflächeninteraktionen als auch für den MCP-Serverzugriff funktionieren. Das System behält dieselben Berechtigungsgrenzen und Zugriffskontrollen wie die Weboberfläche bei und stellt so sicher, dass Benutzer nur über KI-Agenten auf dieselben Lasttestdaten zugreifen können, auf die sie über die Konsole zugreifen können. ## AWS-Services in dieser Lösung Die folgenden AWS-Services sind in dieser Lösung enthalten: | AWS Service | Description | | --- | --- | | [Amazon API Gateway](https://aws.amazon.com/api-gateway/) | **Kern.** Hostet REST-API-Endpunkte in der Lösung. | | [AWS CloudFormation](https://aws.amazon.com/cloudformation/) | **Kern.** Verwaltet Bereitstellungen für die Lösungsinfrastruktur. | | [Amazon CloudFront](https://aws.amazon.com/cloudfront/) | **Kern.** Stellt die in Amazon S3 gehosteten Webinhalte bereit. | | [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) | **Kern.** Speichert die Lösungsprotokolle und Metriken. | | [Amazon Cognito](https://aws.amazon.com/cognito/) | **Kern.** Verwaltet die Benutzerverwaltung und Authentifizierung für die API. | | [Amazon-DynamoDB](https://aws.amazon.com/dynamodb/) | **Kern.** Speichert Bereitstellungsinformationen und testet Szenariodetails und Ergebnisse. | | [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) | **Kern.** Stellt unabhängige Amazon ECS-Aufgaben auf AWS Fargate-Containern bereit und verwaltet sie. | | [AWS Fargate](https://aws.amazon.com/fargate/) | **Kern.** Hostet die Amazon ECS-Container der Lösung | | [AWS Identity and Access Management](https://aws.amazon.com/iam/) | **Kern.** Kümmert sich um die Verwaltung von Benutzerrollen und Berechtigungen. | | [AWS Lambda](https://aws.amazon.com/lambda/) | **Kern.** Stellt Logik für die APIs Implementierung, das Analysieren von Testergebnissen und das Starten von workers/leader Aufgaben bereit. | | [AWS Step Functions](https://aws.amazon.com/step-functions/) | **Kern.** Orchestriert die Bereitstellung von Amazon ECS-Containern für AWS Fargate-Aufgaben in den angegebenen Regionen | | [AWS Amplify](https://aws.amazon.com/amplify/) | **Unterstützend.** Stellt eine von [AWS Amplify](https://aws.amazon.com/amplify) betriebene Webkonsole bereit. | | [ CloudWatch Amazon-Veranstaltungen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) | **Unterstützend**. Plant Tests so, dass sie automatisch an einem bestimmten Datum oder an wiederkehrenden Terminen beginnen. | | [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) | **Unterstützend**. Hostet das Container-Image in einem öffentlichen ECR-Repository. | | [AWS IoT Core](https://aws.amazon.com/iot-core/) | **Unterstützend.** Ermöglicht die Anzeige von Live-Daten für einen laufenden Test, indem Sie das entsprechende Thema in AWS IoT Core abonnieren. | | [AWS Systems Manager](https://aws.amazon.com/systems-manager/) | **Unterstützend.** Ermöglicht die Überwachung von Ressourcen auf Anwendungsebene und die Visualisierung von Ressourcenoperationen und Kostendaten. | | [Amazon S3](https://aws.amazon.com/s3/) | **Unterstützend.** Hostet die statischen Webinhalte, Protokolle, Metriken und Testdaten. | | [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/) | **Unterstützend.** Enthält die Amazon ECS-Container der Lösung, die auf AWS Fargate ausgeführt werden. | | [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) | **Unterstützend, optional.** Hostet den optionalen Remote Model Context Protocol (MCP) -Server der Lösung für die Integration von KI-Agenten mit der API. | # So funktioniert Distributed Load Testing auf AWS Die folgende detaillierte Aufschlüsselung zeigt die Schritte, die zur Ausführung eines Testszenarios erforderlich sind. **Test-Arbeitsablauf** ![\[image3\]](http://docs.aws.amazon.com/de_de/solutions/latest/distributed-load-testing-on-aws/images/image3.png) 1. Sie verwenden die Webkonsole, um ein Testszenario mit den Konfigurationsdetails an die API der Lösung zu senden. 1. Die Konfiguration des Testszenarios wird als JSON-Datei () in den Amazon Simple Storage Service (Amazon S3`s3:///test-scenarios/<$TEST_ID>/<$TEST_ID>.json`) hochgeladen. 1. Ein AWS Step Functions Functions-Zustandsmaschine wird mit der Test-ID, der Anzahl der Aufgaben, dem Testtyp und dem Dateityp als Eingabe für die AWS Step Functions Functions-Zustandsmaschine ausgeführt. Wenn der Test geplant ist, erstellt er zunächst eine CloudWatch Ereignisregel, die AWS Step Functions am angegebenen Datum auslöst. Weitere Informationen zum Planungs-Workflow finden Sie im Abschnitt [Test-Scheduling-Workflow](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-scheduling-workflow.html) in diesem Handbuch. 1. Konfigurationsdetails werden in der Amazon DynamoDB-Szenario-Tabelle gespeichert. 1. Im Task Runner-Workflow von AWS Step Functions prüft die task-status-checker AWS Lambda Lambda-Funktion, ob Amazon Elastic Container Service (Amazon ECS) -Aufgaben bereits für dieselbe Test-ID ausgeführt werden. Wenn festgestellt wird, dass Aufgaben mit derselben Test-ID ausgeführt werden, führt dies zu einem Fehler. Wenn im AWS Fargate-Cluster keine Amazon ECS-Aufgaben ausgeführt werden, gibt die Funktion die Test-ID, die Anzahl der Aufgaben und den Testtyp zurück. 1. Die Task-Runner-Funktion AWS Lambda ruft die Aufgabendetails aus dem vorherigen Schritt ab und führt die Amazon ECS-Worker-Aufgaben im AWS Fargate-Cluster aus. Die Amazon ECS-API verwendet die RunTask Aktion, um die Worker-Aufgaben auszuführen. Diese Worker-Aufgaben werden gestartet und warten dann auf eine Startnachricht von der Leader-Aufgabe, um mit dem Test zu beginnen. Die RunTask Aktion ist auf 10 Aufgaben pro Definition begrenzt. Wenn die Anzahl Ihrer Aufgaben mehr als 10 beträgt, wird die Aufgabendefinition mehrmals ausgeführt, bis alle Worker-Aufgaben gestartet wurden. Die Funktion generiert auch ein Präfix, um den aktuellen Test in der AWS Lambda Lambda-Funktion zur Ergebnisanalyse zu unterscheiden. 1. Die task-status-checker AWS Lambda Lambda-Funktion prüft, ob alle Amazon ECS-Worker-Aufgaben mit derselben Test-ID ausgeführt werden. Wenn die Aufgaben noch bereitgestellt werden, wartet sie eine Minute und prüft erneut. Sobald alle Amazon ECS-Aufgaben ausgeführt werden, gibt es die Test-ID, die Anzahl der Aufgaben, den Testtyp, alle Aufgaben und das Präfix zurück IDs und übergibt sie an die Task-Runner-Funktion. 1. Die Task-Runner-Funktion AWS Lambda wird erneut ausgeführt. Diesmal wird eine einzelne Amazon ECS-Task gestartet, die als Leader-Knoten fungiert. Diese ECS-Aufgabe sendet eine Starttestnachricht an jede der Worker-Aufgaben, damit die Tests gleichzeitig gestartet werden können. 1. Die task-status-checker AWS Lambda Lambda-Funktion überprüft erneut, ob Amazon ECS-Aufgaben mit derselben Test-ID ausgeführt werden. Wenn Aufgaben noch ausgeführt werden, wartet sie eine Minute und prüft erneut. Sobald keine Amazon ECS-Aufgaben ausgeführt werden, werden die Test-ID, die Anzahl der Aufgaben, der Testtyp und das Präfix zurückgegeben. 1. Wenn die Task-Runner-Funktion AWS Lambda die Amazon ECS-Aufgaben im AWS Fargate-Cluster ausführt, lädt jede Aufgabe die Testkonfiguration von Amazon S3 herunter und startet den Test. 1. Sobald die Tests ausgeführt werden, werden die durchschnittliche Antwortzeit, die Anzahl der gleichzeitigen Benutzer, die Anzahl der erfolgreichen Anfragen und die Anzahl der fehlgeschlagenen Anfragen für jede Aufgabe in Amazon protokolliert CloudWatch und können in einem CloudWatch Dashboard eingesehen werden. 1. Wenn Sie Live-Daten in den Test aufgenommen haben, filtert die Lösung Echtzeit-Testergebnisse CloudWatch mithilfe eines Abonnementfilters. Dann übergibt die Lösung die Daten an eine Lambda-Funktion. 1. Die Lambda-Funktion strukturiert dann die empfangenen Daten und veröffentlicht sie in einem AWS IoT Core Core-Thema. 1. Die Webkonsole abonniert das AWS IoT Core Core-Thema für den Test und empfängt die zum Thema veröffentlichten Daten, um die Echtzeitdaten während der Ausführung des Tests grafisch darzustellen. 1. Wenn der Test abgeschlossen ist, exportieren die Container-Images einen detaillierten Bericht als XML-Datei nach Amazon S3. Jede Datei erhält eine UUID für den Dateinamen. *Zum Beispiel s3://dlte-bucket/test-scenarios/ *<\$1TEST\$1ID> /results/ <\$1UUID> .json*.* 1. Wenn die XML-Dateien auf Amazon S3 hochgeladen werden, liest die AWS Lambda Lambda-Funktion für Ergebnisanalyse die Ergebnisse in den XML-Dateien, beginnend mit dem Präfix, analysiert und aggregiert alle Ergebnisse zu einem zusammengefassten Ergebnis. 1. Die AWS Lambda Lambda-Funktion für Ergebnisanalyse schreibt das Gesamtergebnis in eine Amazon DynamoDB-Tabelle. ## MCP-Server-Workflow (optional) Wenn Sie die optionale MCP-Serverintegration einsetzen, können KI-Agenten über den folgenden Workflow auf Ihre Lasttestdaten zugreifen und diese analysieren: **MCP-Serverarchitektur** ![\[Die MCP-Serverarchitektur zeigt die Integration mit DLT-Komponenten\]](http://docs.aws.amazon.com/de_de/solutions/latest/distributed-load-testing-on-aws/images/mcp-server-architecture.png) 1. **Kundeninteraktion** — Der Kunde interagiert mit dem MCP von DLT über den MCP-Endpunkt, der von AWS Gateway gehostet wird. AgentCore KI-Agenten stellen eine Verbindung zu diesem Endpunkt her, um Zugriff auf Belastungstestdaten anzufordern. 1. **Autorisierung** — AgentCore Gateway übernimmt die Autorisierung für den Solution Cognito-Benutzerpool-Anwendungsclient. Das Gateway validiert das Cognito-Token des Benutzers, um sicherzustellen, dass er berechtigt ist, auf den DLT-MCP-Server zuzugreifen. Autorisierten Benutzern wird Zugriff gewährt, wobei der Zugriff auf das Agententool auf schreibgeschützte Operationen beschränkt ist. 1. **Toolspezifikation** — AgentCore Gateway stellt eine Verbindung zur DLT MCP Server Lambda-Funktion her. Eine Toolspezifikation definiert die verfügbaren Tools, mit denen KI-Agenten mit Ihren Lasttestdaten interagieren können. 1. **Schreibgeschützter API-Zugriff** — Die Lambda-Funktion ist auf den schreibgeschützten API-Zugriff über die vorhandenen DLT API Gateway Gateway-Endpunkte beschränkt. Die Funktion bietet vier Hauptoperationen: + **Szenarien auflisten** — Ruft eine Liste von Testszenarien aus der DynamoDB-Szenariatabelle ab + **Szenario-Testergebnisse abrufen** — Greifen Sie auf detaillierte Testergebnisse für bestimmte Szenarien von DynamoDB und S3 zu + **Holen Sie sich Fargate-Load-Test-Runner** — Informationen zur Ausführung von Fargate-Aufgaben im ECS-Cluster abfragen + **Verfügbare regionale Stacks abrufen — Rufen Sie** Informationen über die bereitgestellte regionale Infrastruktur ab von CloudFormation Die MCP-Serverintegration nutzt die bestehende DLT-Infrastruktur (API Gateway, Cognito, DynamoDB, S3), um sicheren, schreibgeschützten Zugriff auf Testdaten für KI-gestützte Analysen und Erkenntnisse zu ermöglichen. # Designüberlegungen In diesem Abschnitt werden wichtige Designentscheidungen und Konfigurationsoptionen für die Distributed Load Testing on AWS-Lösung beschrieben, einschließlich unterstützter Anwendungen, Testtypen, Planungsoptionen und Überlegungen zur Bereitstellung. ## Unterstützte Anwendungen Diese Lösung unterstützt das Testen von cloudbasierten Anwendungen und lokalen Anwendungen, sofern Sie über eine Netzwerkverbindung zwischen Ihrem AWS-Konto und Ihrer Anwendung verfügen. Die Lösung unterstützt APIs die Verwendung von HTTP- oder HTTPS-Protokollen. ## Testtypen Distributed Load Testing auf AWS unterstützt mehrere Testtypen: einfache HTTP-Endpunkttests JMeter, K6 und Locust. ### Einfache HTTP-Endpunkttests Die Webkonsole bietet eine Schnittstelle zur Konfiguration von HTTP-Endpunkten, 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. Diese Konfiguration ermöglicht es Ihnen, APIs mit benutzerdefinierten Autorisierungstoken, Inhaltstypen oder anderen HTTP-Headern und Anforderungstexten zu testen, die für Ihre Anwendung erforderlich sind. ### 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 des Szenarios hoch. Wenn Amazon ECS-Aufgaben ausgeführt werden, laden sie das JMeter Skript von S3 herunter und führen den Test aus. **Wichtig** Ihr JMeter Skript kann zwar Parallelität (virtuelle Benutzer), Transaktionsraten (TPS), Anlaufzeiten und andere Ladeparameter definieren, aber die Lösung überschreibt diese Konfigurationen mit den Werten, die Sie während der Testerstellung auf dem Traffic Shape-Bildschirm angeben. Die Traffic Shape-Konfiguration steuert die Anzahl der Aufgaben, die Parallelität (virtuelle Benutzer pro Aufgabe), die Dauer des Hochlaufs und die Haltedauer für die Testausführung. Wenn Sie über JMeter Eingabedateien verfügen, können Sie die Eingabedateien zusammen mit dem Skript komprimieren. JMeter Sie können die ZIP-Datei auswählen, wenn Sie ein Testszenario erstellen. Wenn Sie Plugins einbeziehen möchten, werden alle .jar-Dateien, die in einem /plugins-Unterverzeichnis der mitgelieferten ZIP-Datei enthalten sind, in das JMeter Erweiterungsverzeichnis kopiert und stehen dort für Auslastungstests zur Verfügung. **Anmerkung** Wenn Sie Ihrer JMeter Skriptdatei JMeter Eingabedateien hinzufügen, müssen Sie den relativen Pfad der Eingabedateien in Ihrer Skriptdatei angeben. JMeter Außerdem müssen sich die Eingabedateien im relativen Pfad befinden. Wenn sich Ihre JMeter Eingabedateien und die Skriptdatei beispielsweise stattdessen im Verzeichnis/home/user directory and you refer to the input files in the JMeter script file, the path of input files must be ./INPUT\$1FILES. If you use /home/user/INPUT\$1FILES befinden, schlägt der Test fehl, da die Eingabedateien nicht gefunden werden können. Wenn Sie JMeter Plugins einbeziehen, müssen die .jar-Dateien in einem Unterverzeichnis namens /plugins im Stammverzeichnis der ZIP-Datei gebündelt werden. Relativ zum Stammverzeichnis der ZIP-Datei muss der Pfad zu den JAR-Dateien sein. /Plugins/Bundled\$1Plugin.jar. [Weitere Informationen zur Verwendung von Skripten finden Sie im Benutzerhandbuch. JMeter JMeter ](https://jmeter.apache.org/usermanual/index.html) ### K6-Tests Die Lösung unterstützt Tests auf Basis des K6-Frameworks. [K6 ist unter der AGPL-3.0-Lizenz veröffentlicht.](https://github.com/grafana/k6/blob/master/LICENSE.md) Die Lösung zeigt bei der Erstellung eines neuen K6-Tests eine Lizenzbestätigungsmeldung an. Sie können die K6-Testdatei zusammen mit allen erforderlichen Eingabedateien in eine Archivdatei hochladen. **Wichtig** Ihr K6-Skript kann zwar Parallelität (virtuelle Benutzer), Stufen, Schwellenwerte und andere Ladeparameter definieren, aber die Lösung überschreibt diese Konfigurationen mit den Werten, die Sie bei der Testerstellung im Traffic Shape-Bildschirm angeben. Die Traffic Shape-Konfiguration steuert die Anzahl der Aufgaben, die Parallelität (virtuelle Benutzer pro Aufgabe), die Dauer des Hochlaufs und die Haltedauer für die Testausführung. ### Locust testet Die Lösung unterstützt Tests auf Basis des Locust Frameworks. Sie können die Locust-Testdatei zusammen mit allen erforderlichen Eingabedateien in eine Archivdatei hochladen. **Wichtig** Ihr Locust-Skript kann zwar Parallelität (Benutzeranzahl), Spawn-Rate und andere Ladeparameter definieren, aber die Lösung überschreibt diese Konfigurationen mit den Werten, die Sie während der Testerstellung im Traffic Shape-Bildschirm angeben. Die Traffic Shape-Konfiguration steuert die Anzahl der Aufgaben, die Parallelität (virtuelle Benutzer pro Aufgabe), die Dauer des Hochlaufs und die Haltedauer für die Testausführung. ## Planung von Tests Die Lösung bietet drei Optionen zum Ausführungszeitpunkt für die Ausführung von Lasttests: + **Jetzt ausführen** — Führt den Belastungstest unmittelbar nach der Erstellung aus + **Einmal ausführen** — Führen Sie den Test an einem bestimmten Datum und zu einer bestimmten Uhrzeit in der future aus + Nach **einem Zeitplan ausführen** — Erstellen Sie wiederkehrende Tests mithilfe von Cron-Ausdrücken, um den Zeitplan zu definieren Wenn Sie **Einmal ausführen** auswählen, geben Sie die Laufzeit im 24-Stunden-Format und das Ausführungsdatum an, an dem der Belastungstest 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 wählen (z. B. stündlich, täglich zu einer bestimmten Zeit, wochentags oder monatlich). Der Cron-Ausdruck verwendet ein detailliertes Zeitplanformat mit Feldern für Minuten, Stunden, Monatstag, Monat, Wochentag und Jahr. Sie müssen auch ein Ablaufdatum angeben, das festlegt, wann der geplante Test nicht mehr ausgeführt werden soll. Weitere Informationen zur Funktionsweise der Planung finden Sie im Abschnitt zum [Ablauf der Testplanung](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-scheduling-workflow.html) in diesem Handbuch. **Anmerkung** Testdauer: Berücksichtigen Sie bei der Planung die Gesamtdauer der Tests. Ein Test mit einer Anlaufzeit von 10 Minuten und einer Haltezeit von 40 Minuten dauert beispielsweise etwa 80 Minuten. Mindestintervall: Stellen Sie sicher, dass das Intervall zwischen den geplanten Tests länger ist als die geschätzte Testdauer. Wenn der Test beispielsweise etwa 80 Minuten dauert, sollten Sie ihn so planen, dass er nicht häufiger als alle 3 Stunden ausgeführt wird. Stündliche Begrenzung: Das System erlaubt es nicht, Tests mit einem Unterschied von nur einer Stunde zu planen, selbst wenn die geschätzte Testdauer weniger als eine Stunde beträgt. ## Gleichzeitige Tests Diese Lösung erstellt für jeden Test ein CloudWatch Amazon-Dashboard, das die kombinierte Ausgabe aller im Amazon ECS-Cluster ausgeführten Aufgaben in Echtzeit anzeigt. Das CloudWatch Dashboard zeigt die durchschnittliche Antwortzeit, die Anzahl der gleichzeitigen Benutzer, die Anzahl der erfolgreichen Anfragen und die Anzahl der fehlgeschlagenen Anfragen. Die Lösung aggregiert jede Metrik sekundengenau und aktualisiert das Dashboard jede Minute. ## 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 Cognito-Konsole verwenden. Weitere Informationen finden Sie unter [Managing Users in User Pools](https://docs.aws.amazon.com/cognito/latest/developerguide/managing-users.html) im *Amazon Cognito Developer Guide*. Informationen zur Migration vorhandener Benutzer zu Amazon Cognito-Benutzerpools finden Sie im AWS-Blog [Approaches for migration users to Amazon Cognito](https://aws.amazon.com/blogs/security/approaches-for-migrating-users-to-amazon-cognito-user-pools) user pools. ## 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](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).