Chaos Engineering Part 2: How to

Induce Chaos at scale

Previously

Previously we saw what chaos engineering is and why it is required to chaos test your service at scale. In this next chapter, we will talk about ways to chaos test your service at scale. We will see how we can leverage AWS Fault Injection Simulator (FIS) to inject network issues. In another example, we will see how we can use Litmus to induce chaos by hogging CPU resources.

Types of Chaos

Some common chaos testing techniques at scale include:

1. Network Issues: Injecting network faults like high latency, packet loss, disconnections to test network resilience.
2. Resource Constraints: Starving services of CPU, memory, disk space to test handling of resource saturation.
3. Service Impairment: Simulating partial outages or degraded performance of services the system depends on (databases, message queues, caches, etc.)
4. Node Failures: Randomly terminating instances, containers or processes to test failover and self-healing.

AWS FIS (Fault Injection Simulator)

We can use AWS Fault Injection Simulator (FIS) to increase network latency between the application components, such as between a web server and a database. FIS is a fully managed service that enables you to perform fault injection experiments on Amazon EC2 instances, Amazon Elastic Container Service…