This content originally appeared on Level Up Coding - Medium and was authored by Richard Kang
The reliability of a site requires continuous monitoring to ensure system performance does not deviate from the non-functional requirements because the performance of a system could be affected by new releases or the growth of data.
One way of measuring the performance is using a client with the capability of simulating the key business activities, and with capabilities to measure the key indicators such as response time or request per second. Gatling is one of the popular libraries commonly used for this purpose.
Gatling is a SCALA library that leverages the flexible syntax of SCALA to offer Domain Specific Language (DSL) on load testing with key metrics for performance measurement. Gatling uses AKKA for the distributed load agents which offer better resource utilization compare to plain Java threading.
This article examines three important concepts related to testing: reliability, repeatability, and reproducibility. It then shows you how to use Gatling to set up a performance testing infrastructure using AWS’s Cloud Development Kit (CDK), and gives you pointers to consider when running performance testing against systems of your own.
Reliability of the tests
In any monitoring and measurement, we need true positive results that we can trust. For example, when the test tool reported a connectivity issue to the web services, we want the result to be true positive that the web service is unavailable and not false positive due to misconfigured of the bad host that is running the tool.
Therefore, leveraging serverless architecture to run the testing tool is ideal to ensure the reliability of the execution of the tool.
Reproducibility of the tests
When issues are reported from the testing, we want to be able to replicate the results to facilitate troubleshooting, or experiment with different factors to reduce any uncertainty. For example, when the QA team found an issue reported by the testing tool, the same result can be replicated by the development team to troubleshooting the same issue reported.
Automate the building and containerize the testing framework allows us to freeze the code change and pre-defined the library dependencies of the testing framework. With the dockerized image, the same testing can be replicated across teams and environments.
Repeatability of the tests
We want to run the tests repeatedly when triggered by an event such as before a new release is being deployed, or when triggered by a clock event such as every end of the month to measure the system performance against the Service Level Objectives.
In order to run the testings over and over, we need to automate the build of the container image for reproducibility purposes and bring up the infrastructure when triggered, and tear-down when not needed, and repeat again in the next trigger.
To achieve this objective, AWS Cloud Development Kit (AWS CDK) offers the functionalities that we can leverage to build the docker image and to provision the necessary infrastructure to achieve the reliability of the testing.
Creation of AWS Resources using AWS Cloud Development Kit (AWS CDK)
The repository for the CDK and the Gatling can be found in https://github.com/kangks/distributed_gatling.
The structure of the repository consists of 2 main folders, cdk/ and gatling/.
cdk/bin/app.ts is the CDK application written in TypeScript. When invoked with command cdk deploy ecsLoadTestTask, it will create the Stack DistributedECSTaskStack from cdk/lib/ecsTaskStack.ts.
The Stack uses the AWS CDK Docker Image Assets API, which builds the Docker image locally with the gatling/Dockerfile, and deploy the Docker image to ECR. The Stack will then proceed to provision the AWS Fargate resources along with the other essential infrastructure such as NAT Gateway.
The deployed architecture will be as below:
In sdk/lib/ecsTaskStack.ts, the Stack DistributedECSTaskStack creates the FargateService with ContainerDefinition that builds the image locally using the API ContainerImage.fromAsset():
const containerDef = new ecs.ContainerDefinition(this, 'containerDef', {[...]
image: ecs.ContainerImage.fromAsset(path.resolve(__dirname, '../../gatling'), {file: "Dockerfile"}),[...]
})
The gatling container uses gatling.sh which is the wrapper script to run the Gatling Highcharts.
const containerDef = new ecs.ContainerDefinition(this, 'containerDef', {[...]
command: [ "gatling.sh", "-sf", "/tests/test", "-s", "perfTest.simulations.WebServiceSimulation" ],
[...]
})
The flag -sf tells the Gatling where to find the simulation class, which is /tests/test as built in the Dockerfile, and the simulation to run with flag -s .
For the Gatling container, it also needs the endpoint of the service to be tested, which is defined as web.baseUrl and passed in via JAVA_OPTS :
const containerDef = new ecs.ContainerDefinition(this, 'containerDef', {[...]
environment: {"GATLING_CONF": "/tests/test/resources",
"JAVA_OPTS": "-Dweb.baseUrl=http://simpl-simpl-1tvem419lsgf7-18442615.us-west-1.elb.amazonaws.com"
},
[...]
})
Gatling
A typical Gatling simulation consists of one or many scenarios, and each scenarios invokes one or many requests.
For example, a simulation to load test a shopping cart service might contain two scenarios, one scenario to search product, and another scenario to add-to-cart.
For the search product scenario, the request will be to POST a search string into the search service and validate the response from the search service.
The add-to-cart scenario might require multiple requests. One request to invoke the authentication service, and store the JWT token in the session. Another request will retrieve the product ID from the search result and the JWT token from the session, and POST to the add-to-cart service, and validate the response. Finally, a validation requests to validate that the product has been added into the cart with a GET call to the cart service.
Therefore, in this example, we separated the concerns into individual folders, namely,
- gatling/src/test/simulations for all the simulations that setup the scenarios with a load profile
- gatling/src/test/scenarios for all the scenarios by use cases, such as product search
- gatling/src/test/requests for the actual requests, such as authentication request
When gatling.sh is invoked, it will look in the folder specified with the flag -sf for classes that extend io.gatling.core.scenario.Simulation . If there are more than one simulations found in the folder, and no simulation class specified with the flag -s , gatling.sh will prompt for the selection of which simulation class to run.
In order to parameterize the execution of the gatling from the Fargate Tasks, the custom configurator perfTest.config.Configurations will first read the config value from System properties, and if not found, read value from the configuration file defaulted to application.conf in theGATLING_CONF folder.
The 3 parameters that can be configured through JAVA_OPTS are:
- web.baseUrl which is the endpoint to the system to be tested;
- load.rps which is the concurrent users to simulate the scenario;
- load.durationInSeconds is the duration of the whole simulation.
Running the Gatling against a simple web service
An example web service using Docker image amazon/amazon-ecs-sample will be used as the system under test.
The CDK application contains the example web service SimpleFargateWebServicewhich can be deployed with the command cdk deploy simpleWebFargate.
The stack will be deployed as below:
Once the stack is created, get the URL from the CloudFormation out using AWS CLI
% aws cloudformation describe-stacks --stack-name simpleWebFargate --query "Stacks[0].Outputs[?OutputKey=='SvcUrl'].OutputValue" --output text
simpl-simpl-1TVEM419LSGF7-18442615.us-west-1.elb.amazonaws.com
The stack-name was defined in the CDK application new SimpleFargateWebService(app, ‘simpleWebFargate’), and the return value will be the endpoint to the Application Load Balancer.
Next, we will update the endpoint of the simpleWebFargate, in cdk/lib/ecsTaskStack.ts as the web.basedUrl :
export class DistributedECSTaskStack extends cdk.Stack {constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {[...]
const containerDef = new ecs.ContainerDefinition(this, 'containerDef', {[...]
environment: {[...]
"JAVA_OPTS": "-Dweb.baseUrl=http://simpl-simpl-1tvem419lsgf7-18442615.us-west-1.elb.amazonaws.com"
},
[...]
})
[...]
}
}
With the web.baseUrl updated according to the output of the simpleWebFargate stack, we can deploy the stack using the command cdk deploy ecsLoadTestTask to deploy the DistributedECSTaskStack.
Once the stack ecsLoadTestTask is deployed, the Fargate Task will run. The log output from the Gatling will be available in the CloudWatch log.
To inspect the Gatling output, we can use the AWS CLI to tail the LogGroup perfTest , which was defined when creating the ECS AWSLogDriver:
const logging = new ecs.AwsLogDriver({[...]
logGroup: new log.LogGroup(this, 'gatlingLogGroup', {logGroupName: 'perfTest',
[...]
})
})
The AWS CLI to run is aws logs tail perfTest . If the execution was successful, you should be able to see that the assertion was passing:
2021-04-03T15:06:43.886000+00:00 gatling/containerDef/8b703ac477474209b0b1ef076c90fd56 Global: percentage of successful events is greater than 99.0 : true
2021-04-03T15:06:43.886000+00:00 gatling/containerDef/8b703ac477474209b0b1ef076c90fd56 Global: max of response time is less than 5000.0 : true
The assertions in the Gatling simulation are
package perfTest.simulations
[...]
class WebServiceSimulation extends Simulation {[...]
setUp(
[...]
)
.assertions(
global.successfulRequests.percent.gt(99),
global.responseTime.max.lt(5000),
)
[...]
}
Site Reliability using AWS Fargate with CDK and Gatling was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Richard Kang
Richard Kang | Sciencx (2021-04-05T12:51:18+00:00) Site Reliability using AWS Fargate with CDK and Gatling. Retrieved from https://www.scien.cx/2021/04/05/site-reliability-using-aws-fargate-with-cdk-and-gatling/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.