Stopping Redis returns HTTP 000 rather than an error because the client waits on reconnect, and the pod keeps serving traffic because the redis health indicator is not in the readiness group even though /actuator/health returns 503. That is the mirror image of A-2, where Keycloak put its database check in readiness and the pods left the Service. Turning on AOF with config set created the appendonlydir and still lost everything on pod deletion, because /data was the container filesystem; adding a PVC makes the same setting work. Volume first, persistence setting second. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
B-5 — Redis 상실과 영속화 증거
2026-09-04 15:35–15:50 KST
해설: docs/experiment-b5-redis-loss-persistence.md
| 파일 | 무엇을 보여주는가 |
|---|---|
01-baseline.txt |
정지 전 — Redis 1키, PostgreSQL 1행, save/appendonly no, 외부 200 |
02-redis-down.txt |
정지 후 — /bff/token-boundary HTTP 000(멈춤), /actuator/health 503, 파드는 1/1 Ready 유지, Lettuce 재연결 스택 |
03-health-groups.txt |
핵심 — /actuator/health 503 인데 /actuator/health/readiness 는 {"status":"UP"}. Service 엔드포인트에 두 파드 모두 남아 있다 |
04-persistence.txt |
복구는 자동(재시작 0회) · AOF 를 켰는데 파드 삭제 후 dbsize 0 · PVC 를 붙인 뒤 written-on-pvc 생존 |
핵심 세 줄
- 파드가 Ready 를 유지한 채 계속 실패한다.
redis헬스 지표가 readiness 그룹에 없기 때문이며, A-2 에서 Keycloak 이 NotReady 가 된 것과 정반대다. - 오류가 아니라 멈춤이다.
HTTP 000— 빠른 실패가 안 되어 있어 사용자는 멈춘 화면을 본다. - 볼륨 없이 AOF 만 켜는 것은 장식이다.
appendonlydir까지 만들어지지만 컨테이너와 함께 사라진다.