Pick the autoscaling signal that does not just spend money

applied · 55 min · Objective 1.7

Task

Model a worker fleet whose real constraint is a downstream dependency, and show that scaling on CPU makes it worse while scaling on queue depth makes it better. This is the difference between an autoscaling policy that works and one that produces a larger bill and the same latency.

Steps

  1. Run a queue, three worker containers and a downstream service limited to a fixed low concurrency. Push a burst of messages and record throughput, queue depth, worker CPU and end-to-end latency in lab/scale.csv.
  2. Scale the workers to nine, simulating a CPU-triggered policy. Record the same four measures again, and note what happened to latency and to the downstream service's error rate.
  3. Return to three workers. Now raise the downstream service's concurrency limit instead, and record the four measures a third time.
  4. Write in lab/scale.md which of the three configurations had the best latency, which had the highest cost, and what the actual bottleneck was.
  5. State the signal you would attach a scaling policy to for this workload, and the one sentence explaining why CPU was the wrong choice.

Verify

awk -F, 'NR>1 && NF>=4 {n++} END {print n" measurement set(s)"}' lab/scale.csv
grep -Eci 'queue depth' lab/scale.md
grep -Eci 'bottleneck|constraint' lab/scale.md
grep -Eci 'cooldown|flap|oscillat' lab/scale.md

Three measurement sets, and the notes must identify the downstream service as the constraint. Concluding that nine workers were simply better means the downstream limit was not actually constraining.

This is an independent study companion for CompTIA Cloud+ CV0-004 and is not produced by or endorsed by CompTIA.