DongHyeonkaandClaude Opus 5
dba0c3975c
Nine database round trips per login multiply the injected delay to 1.9 seconds, and connection pool queueing multiplies it again under twenty concurrent requests. The readiness probe joins the same queue and times out, so the node leaves the load balancer and pushes its load onto the one still standing. Two injections missed first: the guest interface is enp1s0 rather than eth0, and a filter on it can never match a pod IP because flannel has already encapsulated the packet. The delay has to go on flannel.1, before encapsulation. The predicted rise in optimistic lock conflicts did not happen, because logins insert new rows rather than contending for one. That belongs to B-3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.5 KiB
1.5 KiB
A-6 — 지연 주입 증거
2026-09-04 13:10–13:35 KST
해설: docs/experiment-a6-latency-injection.md
| 파일 | 무엇을 보여주는가 |
|---|---|
01-baseline.txt |
배치 설명(A/B 가 되는 이유), agroal_* 지표 목록, 기준선 70ms / 66ms |
02-delay-injected.txt |
첫 시도 실패 — Cannot find device "eth0" (Debian 은 enp1s0) |
03-flannel-injection.txt |
성공 — flannel.1 에 걸어야 파드 IP 가 보인다. netem Sent 150 pkt 로 검증. k0=41ms vs k1=1872ms |
04-pool-under-load.txt |
동시 20건 — 응답이 1.9초에서 22.2초까지 계단. blocking_time_max=20000ms, max_used_count=19, readiness 프로브 타임아웃 |
05-recovery.txt |
해제 즉시 43ms / 51ms 회복. 낙관적 락 충돌 0건(예측 빗나감) |
a6-connection-pool-blocking.png |
Grafana — agroal_blocking_time_max_milliseconds |
핵심 네 줄
- 200ms 가 1,872ms 가 된다. 로그인 트랜잭션의 왕복이 9번이라 지연이 곱해진다.
- 동시 부하에서 22초까지 늘어난다. 커넥션 풀 큐잉으로 한 번 더 곱해진다.
- 헬스체크도 같은 줄에 선다 — 프로브가 타임아웃되어 노드가 로드밸런서에서 빠지고, 남은 노드로 부하가 몰린다.
- 낙관적 락 충돌은 없었다. 로그인은 새 행을 만들 뿐 같은 행을 다투지 않는다 — B-3 의 영역.