View a markdown version of this page

Übersicht über die Architektur - Verteilte Lasttests auf AWS
Architekturdiagramm

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.

Übersicht über die Architektur

Architekturdiagramm

Wenn Sie diese Lösung mit den Standardparametern bereitstellen, werden die folgenden Komponenten in Ihrem AWS-Konto bereitgestellt.

Verteilte Lasttests auf der AWS-Architektur

Verteilte Lasttests auf der AWS-Architektur
Anmerkung

CloudFormation AWS-Ressourcen werden aus Konstrukten des AWS Cloud Development Kit (AWS CDK) erstellt.

Der allgemeine Prozessablauf für die mit der CloudFormation AWS-Vorlage bereitgestellten Lösungskomponenten sieht wie folgt aus:

  1. (CloudFront + S3-Hosting-Bereitstellungsoption) Der Konsolenbenutzer greift über Amazon auf die Webkonsole zu CloudFront, die die in einem Amazon Simple Storage Service (Amazon S3) -Bucket gehostete AWS Amplify-Anwendung bereitstellt.

  2. (ALB + ECS Fargate-Hosting-Bereitstellungsoption) Der Konsolenbenutzer greift über einen Application Load Balancer auf die Webkonsole zu, der den Datenverkehr an die AWS Amplify-Anwendung weiterleitet, die auf Amazon Elastic Container Service (Amazon ECS) auf AWS Fargate innerhalb einer Amazon Virtual Private Cloud (Amazon VPC) ausgeführt wird.

  3. (Headless-Bereitstellungsoption) Es wird kein öffentliches Frontend bereitgestellt. Die Lösung stellt die Webkonsole als herunterladbare ZIP-Datei in einem privaten Amazon S3-Bucket bereit. Der Konsolenbenutzer kann von einem selbst gehosteten Webserver aus auf die Konsole zugreifen.

  4. Bei der Erstkonfiguration erstellt die Lösung einen Standard-Administratorbenutzer im Amazon Cognito-Benutzerpool und sendet eine E-Mail zur Kontoerstellung an die von Ihnen angegebene E-Mail-Adresse. Der Cognito-Benutzerpool verwaltet den Benutzerzugriff auf die Webkonsole, die REST-API, die CLI und den MCP-Server.

  5. Amazon API Gateway ruft AWS Lambda-Microservices auf, die die Geschäftslogik für die Verwaltung der Testdaten und die Ausführung der Tests bereitstellen.

  6. Die Microservices interagieren mit Amazon S3, Amazon DynamoDB und Amazon, um Details zu Testszenarien EventBridge zu speichern und Testpläne zu verwalten. Wenn Sie einen Test so planen, dass er zu einem späteren Zeitpunkt oder in einem wiederkehrenden Intervall ausgeführt wird, erstellen die Microservices einen EventBridge Scheduler-Zeitplan, der den Microservice zum geplanten Zeitpunkt aufruft.

  7. Um einen Test auszuführen, rufen die Microservices AWS Step Functions auf, die die Testausführung orchestrieren.

  8. EventBridge Regeln leiten Amazon ECS-Aufgaben- und Step Functions-Fehlerereignisse an eine Lambda-Funktion für den Failure-Handler weiter.

  9. Step Functions startet Amazon Elastic Container Service (Amazon ECS) -Aufgaben auf AWS Fargate in jeder AWS-Region, die Sie ausgewählt haben.

  10. Jede Aufgabe wird in einer Amazon Virtual Private Cloud (Amazon VPC) in der ausgewählten Region ausgeführt.

  11. Container für Lasttests verwenden ein Amazon Linux 2023-Basis-Image, und welches Image eine Aufgabe verwendet, hängt vom Traffic-Shape-Modus des Tests ab. Im Standardmodus ist auf dem Image das https://gettaurus.org/ Taurus-Testautomatisierungsframework installiert. Taurus führt Ihren JMeter-, k6-, Locust- oder Simple HTTP Endpoint-Test mithilfe der Ladeparameter aus, die Sie in der Konsole festgelegt haben. Im nativen Modus führt ein dediziertes Image für jedes Framework dieses Framework direkt mit Ihrem Skript aus, ohne Taurus und ohne Ladeparameter aus der Lösung. Einzelheiten zu den Modi finden Sie unter Traffic-Shape-Modi. Informationen zur Bereitstellung der einzelnen Testframeworks finden Sie unter Bereitstellung von Testframeworks. Die Option ALB + ECS verwendet den Webhost-Container. Die Container-Images werden von AWS in einem öffentlichen Repository von Amazon Elastic Container Registry (Amazon ECR) gehostet.

  12. Jede Fargate-Aufgabe schreibt ihre regionsspezifischen Testergebnisse in Amazon S3 und sendet Protokolle an Amazon. CloudWatch Wenn alle Regionen abgeschlossen sind, aggregieren die Microservices die Ergebnisse in DynamoDB.

  13. Wenn Sie die Live-Datenoption aktivieren, empfängt eine Lambda-Funktion während des Tests CloudWatch Protokolle von Fargate-Aufgaben.

  14. Die Lambda-Funktion veröffentlicht die Protokolle zu einem Thema in AWS IoT Core in der Region, in der der Haupt-Stack bereitgestellt wird. Die Webkonsole abonniert das Thema, um während der Testausführung Echtzeit-Metriken anzuzeigen.

  15. (Optionaler CLI-Zugriff) Benutzer können die DLT-Befehlszeilenschnittstelle (CLI) lokal installieren, um von ihrem Terminal aus mit der Lösung zu interagieren. Die CLI authentifiziert sich über Cognito und ruft die REST-API direkt auf, was eine skriptgestützte Automatisierung und Integration ermöglicht. CI/CD

    Anmerkung

    Die folgenden Schritte beschreiben die optionale MCP Server-Integration für AI-assisted die Analyse von Lasttests. Diese Komponente wird nur bereitgestellt, wenn Sie bei der Bereitstellung der Lösung die Option MCP Server auswählen.

  16. Ein MCP-Client (KI-Entwicklungstool) stellt eine Verbindung zum Amazon Bedrock AgentCore Gateway-Endpunkt her, um über das Model Context Protocol auf die Daten der Distributed Load Testing-Lösung zuzugreifen. AgentCore Gateway validiert das Amazon Cognito-Authentifizierungstoken des Benutzers, um den autorisierten Zugriff auf den MCP-Server zu verifizieren.

  17. Nach erfolgreicher Authentifizierung leitet AgentCore Gateway die MCP-Tool-Anfrage an die DLT MCP Server Lambda-Funktion weiter.

  18. Die Lambda-Funktion ruft die vorhandene DLT-REST-API auf, um die angeforderten Lasttestdaten abzurufen. Anschließend sendet sie die strukturierten Daten an AgentCore Gateway zurück, das sie zur AI-assisted Analyse und für Erkenntnisse an den MCP-Client zurücksendet.