DongHyeonkaandClaude Opus 5
74c9b3cea7
The audit found ~80 placeholders, and the damaging ones were where the measuring apparatus itself was prose rather than a command: a6 "( curl ... ) & 를 20개 띄우고 wait" — the 22.2s headline came from this a3 "<로그인 반복, sid 를 /tmp/sids 에>" — the whole RPO measurement a3 "<sid 목록>" — the control it is compared against a5 "<수신 파드IP>" — the injection a8 writes /tmp/tok, reads /tmp/rt — self-inconsistent, sent an empty token b3 $KC / $RT / $NEW never assigned c2 bare kcadm.sh with no kubectl exec a1 conntrack tuples written by hand, though the direction flips per restart Each is now a shell-expandable form: pod IPs from jsonpath, the admin password from the secret, ids from kcadm --format csv, conntrack tuples derived from "conntrack -L" with awk rather than transcribed. Then the rewritten commands were executed against the live cluster, and one of them failed — the 20-way load generator, written as "kubectl run --rm -i", lost its output stream twice in a row. That is a trap this series already hit once, and the rewrite reintroduced it. A-6 now uses a resident probe pod that collects into a file and is cat-ed once; verified 20/20 lines. Evidence: docs/evidence/followup/05-command-reproducibility.txt Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
279 lines
9.7 KiB
Markdown
279 lines
9.7 KiB
Markdown
# B-5 — Redis 가 죽으면, 그리고 재시작하면 무엇이 남는가
|
||
|
||
브랜치 `feature/keycloak-b5-redis-loss-persistence` ·
|
||
증거 [`docs/evidence/b5-redis-loss/`](evidence/b5-redis-loss/) ·
|
||
2026-09-04 15:35–15:50 KST
|
||
|
||
선행: [`B-2`](experiment-b2-multi-instance-session.md) — 세션(Redis)과 토큰(PostgreSQL)이 나뉘어 있어야 각각 죽여볼 수 있다
|
||
|
||
---
|
||
|
||
## 구조
|
||
|
||
|
||
|
||
> 다이어그램 규약은 [`diagrams/_style.md`](diagrams/_style.md).
|
||
> 실험대 전체 구조는 [`diagrams/lab-topology.svg`](diagrams/lab-topology.svg).
|
||
|
||
---
|
||
|
||
## 0. 결론부터
|
||
|
||
| | 결과 |
|
||
|---|---|
|
||
| Redis 정지 시 요청 | **오류가 아니라 멈춘다** (`HTTP 000`) |
|
||
| `/actuator/health` | **503** |
|
||
| **파드 readiness** | **★ `UP` 유지 — 트래픽을 계속 받으며 계속 실패한다** |
|
||
| 복구 | 자동. **BFF 재시작 0회** |
|
||
| **AOF 를 켰는데 재시작 후 전부 소실** | **볼륨이 없었다.** 영속화 설정만으로는 아무것도 안 남는다 |
|
||
| PVC 를 붙인 뒤 | **살아남는다** |
|
||
|
||
**A-2(Keycloak DB 상실)와 정반대의 실패 모양이다.** 거기서는 헬스체크가
|
||
파드를 트래픽에서 빼줬는데, 여기서는 안 빼준다.
|
||
|
||
---
|
||
|
||
## 1. Redis 정지 — 오류가 아니라 정지다
|
||
|
||
```bash
|
||
kubectl -n keycloak-lab scale deployment/redis --replicas=0
|
||
```
|
||
|
||
```
|
||
/ HTTP 200 ← permitAll 정적 페이지
|
||
/bff/token-boundary HTTP 000 ← ★ 응답이 없다
|
||
/actuator/health HTTP 503
|
||
```
|
||
|
||
`000` 은 curl 이 응답을 못 받았다는 뜻이다. **오류를 돌려주는 것이 아니라
|
||
매달려 있다.** Lettuce 가 재연결을 시도하며 타임아웃을 기다리기 때문이다.
|
||
|
||
```
|
||
io.netty.channel.socket.nio.NioSocketChannel.doFinishConnect
|
||
java.base/sun.nio.ch.Net.pollConnect
|
||
```
|
||
|
||
> **"빨리 실패하기(fail fast)"가 안 되어 있다.** 사용자는 오류 화면 대신
|
||
> **멈춘 화면**을 본다. 이것이 A-6(지연 주입)에서 본 것과 같은 문제다 —
|
||
> **느린 실패가 빠른 실패보다 나쁘다.**
|
||
|
||
---
|
||
|
||
## 2. 그런데 파드는 Ready 를 유지한다 — 가장 중요한 발견
|
||
|
||
```
|
||
/actuator/health HTTP 503
|
||
/actuator/health/readiness HTTP 200 {"status":"UP"}
|
||
/actuator/health/liveness HTTP 200
|
||
|
||
Service ready: [10.42.0.52 10.42.1.124] ← 둘 다 트래픽을 받는다
|
||
```
|
||
|
||
### 개념 — health group
|
||
|
||
Spring Boot 는 헬스 지표를 **그룹**으로 나눈다.
|
||
|
||
```
|
||
/actuator/health 모든 지표의 합 ← redis 지표가 여기 있다
|
||
/actuator/health/readiness readiness 그룹 ← 기본값은 readinessState 뿐
|
||
/actuator/health/liveness liveness 그룹
|
||
```
|
||
|
||
**`redis` 헬스 지표는 자동으로 readiness 그룹에 들어가지 않는다.**
|
||
그래서 전체 상태는 `DOWN` 인데 readiness 는 `UP` 이다.
|
||
|
||
kubelet 은 `/actuator/health/readiness` 를 보므로 **파드를 빼지 않는다.**
|
||
|
||
### A-2 와의 대비
|
||
|
||
| | A-2 (Keycloak · DB 상실) | **B-5 (BFF · Redis 상실)** |
|
||
|---|---|---|
|
||
| 의존 대상 헬스 지표 | **readiness 에 포함** | **포함 안 됨** |
|
||
| 파드 상태 | **NotReady** | **Ready 유지** |
|
||
| Service 엔드포인트 | **비었다** | 둘 다 남는다 |
|
||
| 외부 응답 | **503** (즉시, 명확) | **000** (멈춤) |
|
||
|
||
**Keycloak 은 자기 의존성을 readiness 에 넣었고, 이 BFF 는 안 넣었다.**
|
||
어느 쪽이 옳은지는 상황에 달렸다.
|
||
|
||
| readiness 에 넣으면 | 넣지 않으면 |
|
||
|---|---|
|
||
| 의존 대상이 죽으면 **전 파드가 빠진다** → 전면 장애 | 파드가 남아 **실패를 계속 서빙한다** |
|
||
| 부분 기능이라도 살릴 수 없다 | 부분 기능(정적 페이지 등)은 살아 있다 |
|
||
| A-2 처럼 **명확한 503** | **멈춤** — 진단이 어렵다 |
|
||
|
||
**의도적으로 골라야 하는 설정이며, 기본값에 맡기면 후자가 된다.**
|
||
|
||
```yaml
|
||
management:
|
||
endpoint:
|
||
health:
|
||
group:
|
||
readiness:
|
||
include: readinessState, redis # 넣으려면 명시해야 한다
|
||
```
|
||
|
||
---
|
||
|
||
## 3. 복구는 자동이다
|
||
|
||
```
|
||
/actuator/health HTTP 200
|
||
/bff/token-boundary HTTP 302 (세션이 사라져 로그인으로 보냄)
|
||
BFF 재시작: 0, 0 회
|
||
```
|
||
|
||
**Lettuce 가 스스로 재연결했다.** A-2 에서 Keycloak 의 커넥션 풀이 그랬던
|
||
것과 같다. **liveness 를 Redis 에 걸었다면 파드가 재시작됐을 것**이고,
|
||
회복이 더 늦어졌을 것이다.
|
||
|
||
`302` 는 세션이 사라졌기 때문이다 — Redis 가 비었으므로 로그인 상태가 없다.
|
||
**사용자는 로그아웃된다.**
|
||
|
||
---
|
||
|
||
## 4. 영속화 — 설정만으로는 아무것도 안 남는다
|
||
|
||
### 시도 ① AOF 를 켜고 파드를 지운다
|
||
|
||
```bash
|
||
kubectl -n keycloak-lab exec deploy/redis -- redis-cli config set appendonly yes
|
||
kubectl -n keycloak-lab exec deploy/redis -- redis-cli set b5:aof "written-with-aof"
|
||
```
|
||
|
||
```
|
||
appendonly yes
|
||
/data 내용: appendonlydir ← 파일이 실제로 만들어졌다
|
||
```
|
||
|
||
파드를 지운 뒤
|
||
|
||
```
|
||
dbsize: 0
|
||
b5:probe (없음)
|
||
b5:aof (없음)
|
||
appendonly no ← 설정도 되돌아갔다
|
||
```
|
||
|
||
**전부 사라졌다.**
|
||
|
||
| 왜 | |
|
||
|---|---|
|
||
| `/data` 가 **컨테이너 파일시스템** | 볼륨이 없으므로 컨테이너와 함께 사라진다 |
|
||
| `CONFIG SET` 은 **런타임 전용** | 재기동하면 매니페스트의 `args` 가 이긴다 |
|
||
|
||
> **쿠버네티스에서 영속화 설정만 켜는 것은 장식이다.**
|
||
> `appendonly yes` 를 켜고 안심하는 것이 가장 위험하다 — **파일은 만들어지고
|
||
> 로그도 정상이며, 사라지는 것은 재시작 순간뿐**이다.
|
||
|
||
### 시도 ② PVC 를 붙인다
|
||
|
||
```yaml
|
||
volumeMounts:
|
||
- name: data
|
||
mountPath: /data
|
||
volumes:
|
||
- name: data
|
||
persistentVolumeClaim:
|
||
claimName: redis-data
|
||
args: ["redis-server", "--appendonly", "yes", "--dir", "/data"]
|
||
```
|
||
|
||
```
|
||
appendonly yes
|
||
키 심음: written-on-pvc
|
||
--- 파드 삭제 후 ---
|
||
dbsize: 1
|
||
b5:pvc written-on-pvc ← 살아남았다
|
||
```
|
||
|
||
### 비교
|
||
|
||
| 구성 | 파드 삭제 후 |
|
||
|---|---|
|
||
| AOF **끔**, 볼륨 없음 | 전부 소실 |
|
||
| AOF **켬**, 볼륨 없음 | **전부 소실** (설정은 켰는데) |
|
||
| AOF **켬**, **PVC** | **생존** |
|
||
|
||
**순서가 있다 — 볼륨이 먼저고 설정이 나중이다.**
|
||
|
||
### `appendfsync` 는 여전히 트레이드오프다
|
||
|
||
```
|
||
appendfsync everysec ← 기본값
|
||
```
|
||
|
||
**1초 분량을 잃을 수 있다.** A-3 에서 본 PostgreSQL 의
|
||
`synchronous_commit OFF` 와 **같은 모양의 맞바꿈**이다.
|
||
|
||
| 설정 | 잃는 양 | 비용 |
|
||
|---|---|---|
|
||
| `always` | 없음 | 쓰기마다 fsync — 느리다 |
|
||
| **`everysec`** | **최대 1초** | 기본값 |
|
||
| `no` | OS 에 맡김 | 가장 빠름 |
|
||
|
||
**세션 저장소에서 1초를 잃는다는 것은 그 사이 로그인한 사용자가
|
||
다시 로그인해야 한다는 뜻이다.** A-3 에서 Keycloak 이 같은 판단을 했다.
|
||
|
||
### PVC 도 노드에 못박힌다
|
||
|
||
`local-path` PVC 이므로 **A-4 에서 본 것과 같다** — 노드가 죽으면
|
||
볼륨도 함께 접근 불가가 된다. **영속화는 재시작을 견디게 하지만
|
||
노드 상실을 견디게 하지는 않는다.**
|
||
|
||
---
|
||
|
||
---
|
||
|
||
## 증거 파일
|
||
|
||
**증거 수집 시각: 2026-09-04 14:24 – 14:28 KST** (파일 mtime 기준. 문서 상단의 시각 표기는 작성 시점이라 다를 수 있다.)
|
||
|
||
| 파일 | 종류 |
|
||
|---|---|
|
||
| [`01-baseline.txt`](evidence/b5-redis-loss/01-baseline.txt) | 터미널 원문 |
|
||
| [`02-redis-down.txt`](evidence/b5-redis-loss/02-redis-down.txt) | 터미널 원문 |
|
||
| [`03-health-groups.txt`](evidence/b5-redis-loss/03-health-groups.txt) | 터미널 원문 |
|
||
| [`04-persistence.txt`](evidence/b5-redis-loss/04-persistence.txt) | 터미널 원문 |
|
||
|
||
파일별 상세는 [`evidence/b5-redis-loss/README.md`](evidence/b5-redis-loss/README.md).
|
||
|
||
## 5. 재현 절차 (명령어)
|
||
|
||
```bash
|
||
# ① 정지
|
||
kubectl -n keycloak-lab scale deployment/redis --replicas=0
|
||
curl -s -o /dev/null -w '%{http_code}\n' https://app1.hyeonworks.com/bff/token-boundary # 000
|
||
|
||
# ② 왜 파드가 안 빠지는가 — 그룹별로 본다
|
||
kubectl -n keycloak-lab exec $(kubectl -n keycloak-lab get pod -l app=bff --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}') -- wget -qO- http://localhost:8083/actuator/health
|
||
kubectl -n keycloak-lab exec $(kubectl -n keycloak-lab get pod -l app=bff --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}') -- wget -qO- http://localhost:8083/actuator/health/readiness
|
||
kubectl -n keycloak-lab get endpoints bff -o jsonpath='{.subsets[*].addresses[*].ip}'
|
||
|
||
# ③ 복구
|
||
kubectl -n keycloak-lab scale deployment/redis --replicas=1
|
||
|
||
# ④ 영속화 — 볼륨 없이 AOF 만 켜본다
|
||
kubectl -n keycloak-lab exec deploy/redis -- redis-cli config set appendonly yes
|
||
kubectl -n keycloak-lab exec deploy/redis -- redis-cli set k v
|
||
kubectl -n keycloak-lab delete pod -l app=redis
|
||
kubectl -n keycloak-lab exec deploy/redis -- redis-cli dbsize # 0
|
||
|
||
# ⑤ PVC 를 붙이고 다시
|
||
kubectl apply -f deploy/lab/k8s/bff-redis.yaml
|
||
kubectl -n keycloak-lab exec deploy/redis -- redis-cli set k v
|
||
kubectl -n keycloak-lab delete pod -l app=redis
|
||
kubectl -n keycloak-lab exec deploy/redis -- redis-cli get k # v
|
||
```
|
||
|
||
---
|
||
|
||
## 6. 다음 실험에 남기는 것
|
||
|
||
| 실험 | 이 실험이 준 것 |
|
||
|---|---|
|
||
| **B-6** 암호화 key 교체 | Redis 가 이제 영속적이므로 **key 를 바꾸면 옛 데이터가 남아 있다** |
|
||
| **D-1** 백업·복구 | `local-path` PVC 는 **노드에 묶여 있다** — 노드가 안 돌아오면 백업뿐 |
|
||
| 구성 | **readiness 그룹에 무엇을 넣을지 명시적으로 정한다** |
|
||
| 구성 | Redis 클라이언트에 **타임아웃**을 걸어 빠르게 실패시킨다 |
|