ECS container HTTP latency

ECS container HTTP latency induces HTTP chaos on containers running in an Amazon ECS (Elastic Container Service) task. This fault introduces latency in the HTTP responses of containers of a specific service using a proxy server, simulating delays in network connectivity or slow responses from the dependent services. This experiment induces chaos within a container and depends on an EC2 instance. Typically, these are prefixed with "ECS container" and involve direct interaction with the EC2 instances hosting the ECS containers.

ECS Container HTTP Latency

Use cases

ECS container HTTP latency:

Modifies the HTTP responses of containers in a specified ECS service by starting a proxy server and redirecting traffic through the proxy server.
Simulates scenarios where containers experience delays in network connectivity or slow responses from dependent services, which may impact the behavior of your application.
Validates the behavior of your application and infrastructure during simulated HTTP latency, such as:
- Testing how your application handles delays in network connectivity from containers to dependent services.
- Verifying the resilience of your system when containers experience slow responses from dependent services.
- Evaluating the impact of HTTP latency on the performance and availability of your application.

Prerequisites

Kubernetes >= 1.17
ECS container metadata is enabled (disabled by default). To enable it, go to container metadata. If your task is currently running, restart it to get the metadata directory.
ECS cluster running with the desired tasks and containers and familiarity with ECS service update and deployment concepts.
Access to the ECS cluster instances with the necessary permissions to update the start and stop timeouts for containers. Go to systems manager documentation.
Backup and recovery mechanisms in place to handle potential failures during the testing process.
You and the ECS cluster instances have a role with the required AWS access to perform the SSM and ECS operations.
Kubernetes secret with AWS Access Key ID and secret access key credentials in the CHAOS_NAMESPACE. Below is the sample secret file:

apiVersion: v1
kind: Secret
metadata:
  name: cloud-secret
type: Opaque
stringData:
  cloud_config.yml: |-
    # Add the cloud AWS credentials respectively
    [default]
    aws_access_key_id = XXXXXXXXXXXXXXXXXXX
    aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

tip

HCE recommends that you use the same secret name, that is, cloud-secret. Otherwise, you will need to update the AWS_SHARED_CREDENTIALS_FILE environment variable in the fault template with the new secret name and you won't be able to use the default health check probes.

Below is an example AWS policy to execute the fault.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ssm:GetDocument",
                "ssm:DescribeDocument",
                "ssm:GetParameter",
                "ssm:GetParameters",
                "ssm:SendCommand",
                "ssm:CancelCommand",
                "ssm:CreateDocument",
                "ssm:DeleteDocument",
                "ssm:GetCommandInvocation",
                "ssm:UpdateInstanceInformation",
                "ssm:DescribeInstanceInformation"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2messages:AcknowledgeMessage",
                "ec2messages:DeleteMessage",
                "ec2messages:FailMessage",
                "ec2messages:GetEndpoint",
                "ec2messages:GetMessages",
                "ec2messages:SendReply"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstanceStatus",
                "ec2:DescribeInstances"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

note

You can pass the VM credentials as secrets or as a ChaosEngine environment variable.
The ECS task container should be in a healthy state before and after introducing chaos.
Refer to the superset permission or policy to execute all AWS faults.
Refer to the common attributes to tune the common tunables for all the faults.
Refer to AWS named profile for chaos to use a different profile for AWS faults.

Mandatory tunables

Tunable	Description	Notes
REGION	The AWS region ID where the ECS container has been created.	For example, `us-east-1`.
LATENCY	Provide latency to be added to request in milliseconds.	For example, 2000 ms. For more information, go to latency.
TARGET_SERVICE_PORT	Port of the service to target	Defaults to port 80. For more information, go to target service port.