Break horizontal scaling with in-memory session state

short · 45 min · Objective 3.1

Task

Run a stateful application behind a load balancer and watch users lose their sessions, then fix it twice -- once with sticky sessions and once by moving state out -- and record what each fix costs.

Steps

  1. Run a small application that stores a counter in memory per session, behind a load balancer with three instances and round-robin distribution.
  2. Drive a client that makes 30 sequential requests with the same session cookie and writes one line per request with the counter value last on the line. Save it to lab/sessions-rr.txt. Round robin gives each instance its own counter, so the values climb in threes rather than from 1 to 30.
  3. Enable sticky sessions and repeat into lab/sessions-sticky.txt, killing the instance the client is pinned to after request 15. Record what happens to that user.
  4. Move session state to a shared store container. Repeat into lab/sessions-shared.txt, again killing an instance after request 15, and record whether the session survived.
  5. Write in lab/sessions.md the cost of each approach: what sticky sessions do to load distribution, and what dependency the shared store introduces.

Verify

for f in lab/sessions-rr.txt lab/sessions-sticky.txt lab/sessions-shared.txt; do
  awk -v f="$f" '{v=$NF+0} v==1{r++} v>m{m=v} END{print f": "r+0" fresh start(s), highest count "m+0}' "$f"
done
grep -Eci 'sticky' lab/sessions.md
grep -Eci 'shared store|external|survived' lab/sessions.md
grep -Eci 'uneven|distribution|dependency' lab/sessions.md

Round robin: 3 fresh starts, highest 10 -- three separate counters. Sticky: 2, because the kill at 15 starts the user over. Shared store: 1, highest 30, the kill invisible to the user. The notes must record a cost for BOTH fixes. Sticky sessions are a crutch with a price, and the shared store puts a new component on the critical path.

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