diff --git a/docs/experiment-plan.md b/docs/experiment-plan.md new file mode 100644 index 0000000..66a2169 --- /dev/null +++ b/docs/experiment-plan.md @@ -0,0 +1,795 @@ +# 실험 실행 계획 — 구조 · 주입 지점 · 확인 항목 + +[`session-store-lab-roadmap.md`](session-store-lab-roadmap.md)가 **무엇을 할지**의 +지도라면, 이 문서는 **각 실험을 어떤 구조에서 어디를 건드려 무엇을 볼지**를 +미리 확정해둔 것이다. + +**실험 전에 예측을 적어둔다.** 결과를 보고 나서 "그럴 줄 알았다"고 쓰면 +아무것도 배우지 못한다. 예측이 빗나갔을 때가 배울 거리다. + +맥락이 안 잡히면 [`session-lab-prerequisites.md`](session-lab-prerequisites.md) +먼저. + +--- + +## 1. 기준 구조 — 모든 실험이 여기서 출발한다 + +``` + [개발 노트북] 브라우저 · kubectl · Playwright + │ + │ https (tailnet 100.x, split DNS) + ▼ + ┌──────────────────────────────────────────────────────────────┐ + │ test-server Arch Linux · 12GB RAM · WiFi only │ + │ │ + │ nginx :443 ← TLS 종료 (Let's Encrypt, DNS-01) │ + │ auth.hyeonworks.com / app1 / app2 │ + └───────────────────────────┬───────────────────────────────────┘ + │ http, libvirt NAT (virbr0) + ┌───────────────┴────────────────┐ + ▼ ▼ + ┌───────────────────────┐ ┌───────────────────────┐ + │ kc-lab-1 5120MB │ │ kc-lab-2 4096MB │ + │ k3s server │ │ k3s agent │ + │ 10.42.0.0/24 │ │ 10.42.1.0/24 │ + │ │ │ │ + │ traefik ← 진입점 │ │ │ + │ coredns │ │ │ + │ metrics-server │ │ │ + │ local-path-prov. │ │ │ + │ │◀ 7800 ▶│ │ + │ keycloak-1 │ JGroups│ keycloak-0 │ + │ │ │ postgres (PVC) │ + │ prometheus (PVC) │ │ │ + │ grafana │ │ │ + └───────────────────────┘ └───────────────────────┘ + ▲ ▲ + │ 관측 스택은 여기 고정 │ 장애 주입은 여기 + │ (nodeSelector 로 못박음) │ +``` + +### 배치 규칙 — 왜 이렇게 두었는가 + +| 규칙 | 이유 | +|---|---| +| 관측 스택은 **kc-lab-1 고정** | 관측 시스템이 관측 대상과 같이 죽으면 기록이 없다 | +| 장애 주입은 **kc-lab-2** | server 를 죽이면 노드 상실이 아니라 **컨트롤 플레인 상실**이다 | +| postgres 는 **kc-lab-2** | DB 손실과 노드 손실을 한 실험에서 겹쳐 볼 수 있다 | +| PVC 는 노드에 못박힘 | `local-path` 프로비저너. **결함이 아니라 조건** | + +### 공통 관측 지점 + +이후 모든 실험에서 이 표의 것들을 본다. + +| 무엇 | 어디서 | 값의 뜻 | +|---|---|---| +| **`up`** | Prometheus | **0이라는 값으로 남는다.** 죽은 시각을 사후에 특정할 수 있는 유일한 지표 | +| `vendor_statistics_approximate_entries_unique{cache="sessions"}` | KC :9000 | 노드별 세션 캐시 보유량 | +| `vendor_jgroups_fd_sock2_get_num_suspected_members` | KC :9000 | **상대를 의심하기 시작한 순간** | +| `vendor_jgroups_merge3_get_views` | KC :9000 | split brain 후 재병합 | +| `ISPN000094` | `kubectl logs` | 새 클러스터 뷰(멤버 명단) | +| `JGROUPS_PING` 테이블 | PostgreSQL | 디스커버리 등록 상태 | +| `offline_user_session` (`offline_flag='0'`) | PostgreSQL | **온라인 세션의 진실** | +| `node_load1`, `node_memory_*` | node-exporter | 기계가 죽었나 프로세스가 죽었나 | + +--- + +## 2. 전체 목록 + +| # | 실험 | 답하는 실무 질문 | 상태 | 선행 | +|---|---|---|---|---| +| **A-0** | 세션 복제 확인 | 정상일 때 세션은 어디 있나 | ✅ | — | +| **A-1** | TCP 7800 차단 | 노드 간 통신이 끊기면? | 다음 | A-0 | +| **A-2** | DB 정상 정지 | **DB가 죽으면?** | | A-0 | +| **A-3** | DB 강제 종료 | 복구 시 무엇을 잃나 (RPO) | | A-2 | +| **A-4** | 노드 전원 차단 | **Keycloak 한 대가 죽으면?** | | A-0 | +| **A-5** | 비대칭 파티션 | 한쪽만 안 들리면? (split brain) | | A-1 | +| **A-6** | 지연 주입 (netem) | 느려지기만 하면? | | A-1 | +| **A-7** | volatile 모드 비교 | 옛 방식(KC≤24)은 뭐가 다른가 | | A-1·A-2·A-4 | +| **A-8** | 롤링 재시작 | 배포하면 로그아웃되나 | | A-0 | +| **B-1** | BFF + Redis 저장소 | Redis vs JDBC 어느 쪽인가 → **Q3** | | 배포 필요 | +| **B-2** | BFF 다중 인스턴스 | 인스턴스 늘리면? → **Q1** | | B-1 | +| **B-3** | Refresh 토큰 경쟁 | 동시 갱신하면? → **Q2** | | B-1 | +| **B-4** | Edge 인가 범위 | 인가를 Edge에 얼마나? → **Q4** | | B-1 | +| **B-5** | Redis 상실 | Redis가 죽으면? | | B-1 | +| **B-6** | Redis 영속화 비교 | AOF/RDB 유무 차이 | | B-5 | +| **C-1** | 다중 앱 SSO | **SSO 붙이면 뭐가 달라지나** | | B-1 | +| **C-2** | 백채널 로그아웃 | 로그아웃이 전 앱에 퍼지나 | | C-1 | +| **D-1** | 백업·복구 리허설 | **복구해본 적 있나** | | A-2 | +| **D-2** | 버전 업그레이드 | 올릴 때 세션·스키마는? | | D-1 | +| **D-3** | 비밀 관리 | Secret은 정말 감춰지나 | | — | +| **D-4** | 인증서 갱신 | 갱신 중 무중단인가 | | — | + +--- + +# A층 — Keycloak 자체 + +## A-1. TCP 7800 차단 + +### 답하려는 질문 +> 노드 사이 네트워크가 끊기면 로그인한 사용자는 어떻게 되는가? + +**이 실험이 A-0 다음인 이유** — 통념과 측정이 정면으로 어긋나 있다. +둘 중 하나는 틀렸고, 이 실험이 판정한다. + +| | | +|---|---| +| **통념** (KC 24 이전 자료) | 세션은 7800으로 복제된다 → **막으면 세션 공유가 깨진다** | +| **A-0 측정** | 세션은 DB로 공유된다 → **막아도 안 깨진다** | + +### 구조 — 주입 지점 + +``` + kc-lab-1 kc-lab-2 + ┌────────────────┐ ┌────────────────┐ + │ keycloak-1 │ ✂✂✂ 7800 차단 ✂✂✂ │ keycloak-0 │ + │ │ (NetworkPolicy) │ │ + └───────┬────────┘ └───────┬────────┘ + │ │ + │ 둘 다 DB 는 그대로 본다 │ + └──────────────┬──────────────────────┘ + ▼ + ┌───────────────┐ + │ postgres │ ← 여기는 안 건드린다 + │ JGROUPS_PING │ 디스커버리는 계속 된다 + │ 세션 테이블 │ + └───────────────┘ +``` + +**핵심**: 디스커버리(DB)는 살리고 **트랜스포트(7800)만** 끊는다. +그래서 "DB엔 서로 등록되는데 클러스터는 안 붙는" 상태가 만들어진다. +**단일 노드에서는 재현 불가능한 고장**이며, 이 실험대를 2노드로 만든 이유다. + +### 주입 방법 + +```yaml +# NetworkPolicy 로 파드 간 7800 만 막는다. IP 가 아니라 라벨로 지정한다 +# (파드 IP 는 재시작마다 바뀐다 — 2홉 실험에서 확인) +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: { name: block-jgroups, namespace: keycloak-lab } +spec: + podSelector: { matchLabels: { app: keycloak } } + policyTypes: [Ingress] + ingress: + - from: [{ podSelector: { matchLabels: { app: keycloak } } }] + ports: [{ port: 7800, protocol: TCP }] # ← 이 규칙을 뺀 채 적용하면 차단 +``` + +### 확인할 것 + +| 관측 | 예상 | +|---|---| +| `fd_sock2_get_num_suspected_members` | **0 → 1** (가장 먼저 움직일 것) | +| `ISPN000094` 로그 | 각자 **멤버 1개짜리 뷰** 발행 (split brain) | +| `JGROUPS_PING` 테이블 | **양쪽 다 남아 있다** (디스커버리는 살아 있으므로) | +| **교차 노드 refresh** | **200 유지** ← 이게 판정의 핵심 | +| 로그아웃 전파 | **?** — DB 삭제로 되면 유지, 클러스터 메시지면 깨진다 | +| `sessions` 캐시 엔트리 | 변화 없음 | + +### 예측 + +``` +세션 공유 안 깨진다 (A-0 근거: 세션은 7800 으로 안 다닌다) +로그아웃 안 깨진다 (DB 행 삭제로 전파되므로) +realm 설정 변경 전파 깨진다 (work 캐시는 클러스터 메시지를 쓴다) +로그인 실패 횟수 집계 깨진다 (loginFailures 캐시) +``` + +### 판정 기준 + +| 결과 | 뜻 | +|---|---| +| 교차 refresh 가 **200** | A-0 모델이 맞다. 통념이 틀렸다 | +| 교차 refresh 가 **400/401** | **A-0 해석이 틀렸다.** 무엇을 놓쳤는지 다시 판다 | + +### 복구 +```bash +kubectl -n keycloak-lab delete networkpolicy block-jgroups +# MERGE3 가 뷰를 다시 합치는지 확인 — merge3_get_views 증가 +``` + +--- + +## A-2. DB 정상 정지 + +### 답하려는 질문 +> **PostgreSQL이 죽으면 어떻게 되는가?** 로그인한 사람은? 새 로그인은? + +### 구조 + +``` + kc-lab-1 kc-lab-2 + ┌────────────────┐ ┌────────────────┐ + │ keycloak-1 │◀────── 7800 ──────▶│ keycloak-0 │ + │ 캐시: 세션 N개 │ (살아 있다) │ 캐시: 세션 M개 │ + └───────┬────────┘ └───────┬────────┘ + │ │ + └──────────────┬──────────────────────┘ + ▼ + ┌───────────────┐ + │ postgres ✗ │ ← replicas=0 으로 정지 + └───────────────┘ + + 질문: 캐시에 세션을 들고 있는 노드는 그 세션을 계속 쓸 수 있는가? +``` + +**A-0에서 얻은 예측의 시험대다.** DB가 진실의 원천이라면, **캐시에 있어도 +못 쓴다**는 것이 논리적 귀결이다. 하지만 룩어사이드 캐시라면 읽기는 될 +수도 있다 — **이게 갈리는 지점**이다. + +### 주입 방법 +```bash +kubectl -n keycloak-lab scale deployment/postgres --replicas=0 +``` + +### 확인할 것 — **세 가지 경로를 구분해서 본다** + +| 경로 | 무엇을 보는가 | 예상 | +|---|---|---| +| **① 캐시 있는 노드에서 refresh** | 캐시가 DB를 대신할 수 있나 | **실패** (쓰기가 필요) | +| **② 캐시 없는 노드에서 refresh** | 완전히 DB 의존 | **실패** | +| **③ 새 로그인** | 쓰기 경로 | **실패** | +| ④ 이미 발급된 access token 검증 | 서명만 보면 되는 경로 | **성공** (60초 동안) | + +**④가 중요하다.** DB가 죽어도 **access token 수명 동안은 리소스 서버가 +정상 동작한다.** 이게 "짧은 access token + 긴 refresh token" 구조가 +장애에 주는 유예 시간이다. + +| 관측 | 예상 | +|---|---| +| `up{job="keycloak"}` | **1 유지** — 프로세스는 살아 있다 | +| KC `/health/ready` | **DOWN** 으로 바뀌는가? | +| KC 로그 | 커넥션 풀 고갈 / `FATAL: the database system is shutting down` | +| 에러 응답 코드 | 500? 503? — **클라이언트가 재시도할지 결정하는 값** | + +### 예측 +``` +로그인 실패 +refresh 실패 (캐시 유무 무관) +기존 access token 검증 성공 — 만료까지 +KC 프로세스 살아 있음 (up=1) — 헬스체크만 DOWN +``` + +### 판정 기준 +`up=1`인데 기능은 전멸 → **"프로세스 살아 있음"이 헬스체크로 부족하다는 증명.** +`/health/ready`가 DB를 보는지 여부가 롤링 배포 안전성을 좌우한다. + +### 복구 +```bash +kubectl -n keycloak-lab scale deployment/postgres --replicas=1 +# 자동 복구되는가, Keycloak 재시작이 필요한가 ← 이것도 측정 대상 +``` + +--- + +## A-3. DB 강제 종료 — 무엇을 잃는가 (RPO) + +### 답하려는 질문 +> 정상 종료가 아니라 **전원이 나가면** 무엇을 잃는가? + +**A-0에서 발견한 `SET LOCAL synchronous_commit TO OFF`의 시험대다.** + +```sql +update OFFLINE_USER_SESSION set LAST_SESSION_REFRESH=$1, VERSION=$2 where ... +SET LOCAL synchronous_commit TO OFF ← WAL 플러시를 기다리지 않고 커밋 +COMMIT +``` + +### 구조 + +``` + ┌────────────────┐ + │ keycloak-0 │ refresh 를 초당 여러 번 날린다 + └───────┬────────┘ + │ UPDATE LAST_SESSION_REFRESH + ▼ + ┌───────────────────────────────┐ + │ postgres │ + │ 메모리 (WAL 버퍼) ← 여기까지만 쓰고 COMMIT 응답 │ + │ ↓ 아직 안 내려감 │ + │ 디스크 (WAL) │ ✗ SIGKILL + └───────────────────────────────┘ + 이 사이의 갱신이 사라진다 +``` + +### 주입 방법 +```bash +# 정상 종료가 아니라 강제 종료. 컨테이너에 SIGKILL +kubectl -n keycloak-lab delete pod -l app=postgres --grace-period=0 --force +``` + +### 확인할 것 + +| 절차 | 무엇을 보는가 | +|---|---| +| 1. refresh 를 반복하며 매번 `LAST_SESSION_REFRESH` 를 기록 | 기준값 | +| 2. 마지막 성공 시각을 클라이언트 쪽에 남긴다 | **클라이언트가 믿는 값** | +| 3. 강제 종료 → 재기동 | | +| 4. DB의 `LAST_SESSION_REFRESH` 를 다시 읽는다 | **2와 4의 차이 = 잃은 것** | +| 5. postgres 로그의 crash recovery 메시지 | `database system was not properly shut down` | + +### 예측 +``` +잃는 양 수백 밀리초 분량의 LAST_SESSION_REFRESH 갱신 +잃지 않는 것 로그인·로그아웃 자체 (다른 트랜잭션일 가능성 — 확인 필요) +crash recovery 자동 실행되고 성공 +``` + +**"COMMIT 응답을 받았는데 없어졌다"를 실제로 관측하는 것이 목표다.** +이건 버그가 아니라 **의도된 트레이드오프**이며, 그걸 눈으로 봐야 +"세션 갱신은 잃어도 되는 쓰기"라는 설계 판단을 체감할 수 있다. + +--- + +## A-4. 노드 전원 차단 + +### 답하려는 질문 +> **Keycloak 한 대가 통째로 죽으면** 그 노드가 처리하던 사용자는 어떻게 되는가? + +### 구조 + +``` + kc-lab-1 (살아 있다) kc-lab-2 ✗ 전원 차단 + ┌────────────────────┐ ┌────────────────────┐ + │ traefik ← 진입점 │ │ keycloak-0 │ + │ coredns │ │ 캐시 세션 M개 ✗ │ + │ keycloak-1 │ │ postgres ✗ │ ← 같이 죽는다 + │ prometheus │ │ │ + └────────────────────┘ └────────────────────┘ + + ⚠ postgres 가 kc-lab-2 에 있으므로 이 실험은 A-2 와 겹친다. + 순수한 "노드 상실"을 보려면 postgres 를 먼저 kc-lab-1 로 옮긴다. +``` + +**중요** — `virsh destroy`는 프로세스 kill이 아니라 **전원 차단**이다. +게스트에 종료 신호가 가지 않으므로 진짜 노드 상실이다. + +### 두 판본으로 나눠 실행한다 + +| 판본 | 배치 | 보는 것 | +|---|---|---| +| **4a. 순수 노드 상실** | postgres 를 kc-lab-1 로 옮긴 뒤 | Keycloak 한 대만 잃었을 때 | +| **4b. 복합 장애** | 현재 배치 그대로 | **노드 + DB 동시 상실** — 더 현실적 | + +### 주입 방법 +```bash +virsh destroy kc-lab-2 # ACPI 종료가 아니라 전원 차단 +``` + +### 확인할 것 + +| 관측 | 예상 (4a) | +|---|---| +| `up{node="kc-lab-2"}` | **0** — 언제 죽었는지 기록됨 | +| 죽은 노드의 마지막 샘플 | node-exporter 가 DaemonSet 인 이유 | +| kubectl 노드 상태 | `Ready` → `NotReady` (기본 40초 후) | +| **죽은 노드가 만든 세션의 refresh** | **성공** ← 판정 핵심. DB 에 있으므로 | +| `ISPN000094` | 남은 노드가 멤버 1개 뷰 발행 | +| `JGROUPS_PING` | 죽은 노드 행이 **남아 있다** (지울 주체가 없다) | +| 파드 재배치 | PVC 때문에 postgres 는 **재배치 못 한다** | + +### 예측 +``` +4a 세션 살아남는다. 남은 노드가 DB 에서 읽어 계속 서비스한다 +4b 전면 장애 — DB 가 같이 죽었으므로 A-2 와 같아진다 +``` + +### 복구 +```bash +virsh start kc-lab-2 +# JGROUPS_PING 의 유령 행이 어떻게 정리되는지 관찰 — 자동인가 수동인가 +``` + +--- + +## A-5. 비대칭 파티션 (split brain) + +### 답하려는 질문 +> **한쪽 방향만** 끊기면? 서로 상대가 죽었다고 생각하면? + +가장 고약한 장애다. 완전 단절보다 **부분 단절**이 훨씬 흔하고 진단이 어렵다. + +### 구조 + +``` + kc-lab-1 kc-lab-2 + ┌────────────────┐ ──────────▶ ┌────────────────┐ + │ keycloak-1 │ 나가는 건 됨 │ keycloak-0 │ + │ │ │ │ + │ │ ◀━━✗━━━━━━ │ │ + │ │ 들어오는 건 막힘 │ │ + └────────────────┘ └────────────────┘ + + kc-lab-1 → "상대가 응답이 없네, 죽었나보다" + kc-lab-2 → "나는 잘 보내고 있는데?" +``` + +### 주입 방법 +```bash +# 게스트 안에서 nftables 로 인바운드만 차단 (커널이 분리돼 있어 가능) +ssh kc-lab-2 'sudo nft add rule inet filter input tcp dport 7800 drop' +``` + +### 확인할 것 + +| 관측 | 보는 이유 | +|---|---| +| 양쪽의 `ISPN000094` 뷰 | **서로 다른 명단을 갖는가** | +| `coord` 컬럼 | **양쪽 다 코디네이터가 되는가** (진짜 split brain) | +| `fd_sock2_suspected` | 어느 쪽이 먼저 의심하는가 | +| 세션 동작 | DB 는 멀쩡하므로 **영향 없어야 한다** | +| 복구 후 `merge3_get_views` | MERGE3 가 합치는가, 재시작이 필요한가 | + +--- + +## A-6. 지연 주입 (tc netem) + +### 답하려는 질문 +> **끊기지 않고 느려지기만** 하면? — 실제 장애의 대부분이 이 모양이다 + +### 구조 + +``` + keycloak ──▶ [ tc netem: +200ms ] ──▶ postgres + 지연만 넣는다 +``` + +### 주입 방법 +```bash +ssh kc-lab-2 'sudo tc qdisc add dev eth0 root netem delay 200ms' +``` + +### 확인할 것 + +| 관측 | 왜 | +|---|---| +| refresh 응답 시간 분포 | 200ms 가 그대로 더해지는가, 증폭되는가 | +| **DB 커넥션 풀 사용률** | 느려지면 커넥션이 반환 안 돼 **고갈된다** | +| 타임아웃 발생 지점 | 어느 계층이 먼저 포기하는가 | +| **낙관적 락 충돌 증가** | 트랜잭션이 길어져 `VERSION` 충돌이 늘어야 한다 | + +**여기서 A-0의 낙관적 락 발견이 다시 쓰인다** — 지연이 길수록 읽고 쓰는 +사이가 벌어지므로 충돌 확률이 오른다. + +--- + +## A-7. volatile 모드 비교 — 옛 방식은 뭐가 다른가 + +### 답하려는 질문 +> Keycloak 24 이전 방식(메모리가 진실의 원천)이었다면 지금까지의 결론이 +> 어떻게 달라지는가? + +**A-0의 모든 결론이 "26 기본값"이라는 전제 위에 있다.** +전제를 뒤집어 확인하는 것이 이 실험이다. + +### 구조 + +``` + 현재 (persistent, KC 26 기본) 비교군 (volatile) + ┌────────────────┐ ┌────────────────┐ + │ keycloak │ │ keycloak │ + │ 캐시(로컬) │ │ 캐시 ←──────┼── 진실의 원천 + └───────┬────────┘ └───────┬────────┘ + │ 진실의 원천 │ ✗ 세션 저장 안 함 + ▼ ▼ + [ PostgreSQL ] [ PostgreSQL ] + (realm 설정만) +``` + +### 설정 변경 +```yaml +args: ["start", "--features-disabled=persistent-user-sessions"] +``` + +### 확인할 것 — **A-0부터 A-4를 전부 다시 돌린다** + +| 실험 | persistent (측정 완료) | volatile (예측) | +|---|---|---| +| A-0 캐시 위치 | 각자 자기 것만 | **양쪽에 복제되어야 한다** | +| **A-1 7800 차단** | 안 깨짐 | **치명적** — 정반대 | +| A-2 DB 정지 | 전면 장애 | **세션은 살아남음** | +| A-4 노드 상실 | 세션 생존 | 복제됐다면 생존 | +| A-8 롤링 재시작 | 세션 유지 | **전부 로그아웃** | + +**A-1이 정반대로 뒤집히는 것을 보는 게 이 실험의 목적이다.** +같은 주입, 같은 관측, 정반대 결과 — 그래야 "버전 확인이 1순위"라는 교훈이 +말이 아니라 데이터가 된다. + +--- + +## A-8. 롤링 재시작 — 배포하면 로그아웃되는가 + +### 답하려는 질문 +> **운영에서 가장 자주 겪는 것.** 배포할 때마다 사용자가 로그아웃되는가? + +### 구조 + +``` + 시각 → + keycloak-0 ████████──✗ 재시작 ──████████ + keycloak-1 ████████████████──✗ 재시작 ──████ + + 사용자 세션 ────────────────────────────────▶ 유지되는가? +``` + +### 주입 방법 +```bash +kubectl -n keycloak-lab rollout restart statefulset/keycloak +``` + +### 확인할 것 +| 관측 | 예상 (persistent) | +|---|---| +| 재시작 전후 `sid` | **동일** | +| 재시작 중 refresh | 일시 실패 후 성공 (파드 전환 시점) | +| 재시작 후 캐시 엔트리 | **0에서 다시 시작** — 캐시는 사라진다 | +| 브라우저 SSO 쿠키 | 유지 | + +**A-7과 짝이다.** volatile 이었다면 여기서 전원 로그아웃된다. +이게 **persistent 를 켜는 진짜 이유**다. + +--- + +# B층 — 애플리케이션 세션 (Redis) + +**선행: 배포가 필요하다.** 현재 실험대에 BFF도 Redis도 없다. + +``` + 지금 B층 실험에 필요한 것 + ┌──────────────┐ ┌──────────────────────────┐ + │ keycloak x2 │ │ keycloak x2 │ + │ postgres │ │ postgres │ + │ echo (헤더용) │ + │ bff x2 ← 새로 배포 │ + │ │ │ redis ← 새로 배포 │ + │ │ │ resource-server │ + └──────────────┘ └──────────────────────────┘ +``` + +BFF 구현은 `develop-keycloak-pattern3`에 있으므로 가져온다. +```bash +git checkout develop-keycloak-pattern3 -- bff/ +``` + +**자원 예산 확인 필요** — 호스트 12GB 중 현재 여유 약 4GB. +Redis(~64Mi) + BFF 2개(~512Mi) 정도면 들어가지만, **A층 실험을 마친 뒤** +배포하는 편이 안전하다. + +## B-1. BFF 저장소 결정 → Q3 + +### 구조 + +``` + 브라우저 ──쿠키(SESSION)──▶ ┌─────────┐ ┌──────────────┐ + │ bff-0 │─────────▶│ │ + ├─────────┤ │ Redis │ + │ bff-1 │─────────▶│ │ + └─────────┘ └──────────────┘ + │ 두 가지가 들어간다 + │ ① Application Session + │ ② OAuth2AuthorizedClient + ▼ + [ Keycloak ] +``` + +### 확인할 것 — **조회 키가 다르다는 것이 핵심** + +| 상태 | 조회 키 | 결과 | +|---|---|---| +| Application Session | **session ID** | 브라우저마다 별개 | +| OAuth2AuthorizedClient | **registration + principal name** | **같은 사용자의 여러 브라우저가 공유** | + +5단계 — 로그인 유지·재시작 복구 / **refresh token 이 평문으로 저장되는가** / +**session TTL ≠ token 만료** / logout 후 잔여 항목 / 저장소 끊김 시 오류 형태 + +## B-2. 다중 인스턴스 운영 → Q1 + +### 구조 +``` + nginx ip_hash 주석 → 스티키 유무를 같은 구성에서 비교 + │ + ├──▶ bff-0 ──┐ + └──▶ bff-1 ──┴──▶ Redis +``` + +**확인 핵심** — **authorized client 덮어쓰기.** "Redis만 붙이면 해결"이라는 +착각을 깨는 항목이다. 조회 키에 session ID가 없어서 생긴다. + +## B-3. Refresh Token 경쟁 → Q2 + +### 구조 +``` + access token 만료 직후, 동시에 두 요청 + │ │ + ▼ ▼ + bff-0 bff-1 + │ │ + └────── 같은 refresh token ──────▶ Keycloak + │ + 한쪽만 성공, 다른 쪽은? +``` + +**★ B-1 이후여야 재현된다.** 저장소가 process-local이면 두 replica가 같은 +항목을 보지 않아 **경쟁 자체가 성립하지 않는다.** + +**A-0에서 낙관적 락(`VERSION`)과 `SKIP LOCKED`를 이미 확인했다.** +Keycloak 쪽 동작을 알고 시작하므로, BFF 쪽 재시도 설계에 집중한다. + +판정 기준 — *실패가 사용자에게 노출되면 lock, 노출 안 되면 재시도.* + +## B-4. Edge 인가 범위 → Q4 + +### 구조 +``` + 브라우저 ──▶ nginx ──▶ [auth_request] ──▶ BFF + │ │ + │◀── X-Auth-Request-Roles ──┘ + │ + └──▶ Resource Server ← 헤더만 믿는가? +``` + +**2홉 실험의 교훈이 여기서 결정적이다** — 헤더 위조가 통하면 +그것은 쿠키 속성이 아니라 **신원 위조**다. NetworkPolicy 패턴을 재사용한다. + +확인 — 다중 값 구분자·escaping / 헤더 크기 상한 / role 변경 반영 시점 / +upstream 이 값과 service identity 까지 보는가 + +## B-5 · B-6. Redis 상실과 영속화 + +``` + B-5 Redis 파드 정지 → 세션 전멸? 로그인 화면? + B-6 appendonly yes/no 비교 → 재시작 후 무엇이 남는가 +``` + +**A-2·A-3의 Redis 판본이다.** 같은 질문을 다른 저장소에 던진다. + +--- + +# C층 — SSO + +## C-1. 다중 앱 SSO + +### 답하려는 질문 +> **당신 원래 질문**: "SSO를 추가하면 어떻게 달라지는가" + +### 구조 + +``` + ┌──────────────────────────┐ + │ Keycloak SSO 세션 │ + │ 쿠키 KEYCLOAK_IDENTITY │ + └────────┬─────────────────┘ + │ + ┌──────────────┴──────────────┐ + ▼ ▼ + ┌──────────────┐ ┌──────────────┐ + │ app1 │ │ app2 │ + │ (BFF 세션) │ │ (BFF 세션) │ + └──────────────┘ └──────────────┘ + + app1 로그인 → app2 는 로그인 화면 없이 통과 + Keycloak 세션 소멸 → 양쪽 다 재로그인 +``` + +### 확인할 것 +| 항목 | 보는 것 | +|---|---| +| app1 로그인 후 app2 접속 | 로그인 화면 없이 통과하는가 | +| **A-2(DB 정지)를 겹친다** | **장애 반경이 앱 하나에서 전체로 커지는가** | +| SSO 세션 vs 앱 세션 수명 | 어긋나면 무슨 일이 생기는가 | +| 노드 상실 중 SSO | 새 앱 진입이 되는가 | + +**이게 SSO의 대가다** — 편의를 얻는 대신 **단일 장애점이 하나 늘어난다.** + +## C-2. 백채널 로그아웃 + +``` + Keycloak ──logout token(sid)──▶ app1 /backchannel-logout + └─────────────────────▶ app2 /backchannel-logout +``` + +**A-0에서 확인한 `sid`가 여기서 쓰인다.** 토큰·DB·관리 API에서 같았던 그 +문자열이 로그아웃 전파의 키다. + +확인 — 한 앱이 응답 안 하면? 부분 실패 시 재시도는? 역인덱스는 어디에? + +--- + +# D층 — 운영 역량 + +## D-1. 백업과 복구 리허설 + +> **"백업이 있다"와 "복구해봤다"는 완전히 다르다.** + +``` + 1. pg_dump 로 전체 덤프 + 2. 일부러 파괴 (PVC 삭제 또는 DROP DATABASE) + 3. 덤프에서 복구 + 4. 로그인이 되는가 / 기존 세션이 살아나는가 + 5. 걸린 시간 = RTO, 잃은 데이터 = RPO +``` + +**A-3에서 측정한 RPO와 합쳐진다.** `synchronous_commit OFF` 때문에 +백업 시점 이후뿐 아니라 **크래시 직전 수백 ms도 잃는다.** + +## D-2. 버전 업그레이드 + +``` + 26.7.0 → 다음 마이너 + │ + ├── DB 스키마 자동 마이그레이션 ← 실패하면 되돌리기 어렵다 + ├── 롤링 중 세션 유지되는가 ← A-8 과 연결 + └── 롤백 가능한가 ← 스키마가 바뀐 뒤에는 구버전이 못 뜬다 +``` + +**D-1이 선행이어야 한다.** 백업 없이 스키마 마이그레이션을 돌리지 않는다. + +## D-3. 비밀 관리 +`kubectl get secret -o yaml` → base64 디코드가 한 줄로 되는 것을 **직접 본다.** +"Secret은 암호화가 아니다"를 문장이 아니라 화면으로. + +## D-4. 인증서 갱신 +```bash +sudo certbot renew --force-renewal # 90일을 안 기다린다 +``` +nginx reload 중 **진행 중이던 요청**은 어떻게 되는가. + +--- + +## 실행 순서와 의존 관계 + +``` + A-0 ✅ + │ + ├─▶ A-1 (7800) ─────┬─▶ A-5 (비대칭) + │ └─▶ A-6 (지연) + │ + ├─▶ A-2 (DB 정지) ──▶ A-3 (강제 종료) ──▶ D-1 (백업/복구) ──▶ D-2 (업그레이드) + │ + ├─▶ A-4 (노드 상실) + │ + ├─▶ A-8 (롤링 재시작) + │ + └─▶ A-7 (volatile 비교) ← A-1·A-2·A-4·A-8 을 다 한 뒤 전부 재실행 + │ + ▼ + [ BFF + Redis 배포 ] + │ + ├─▶ B-1 (저장소) ──┬─▶ B-2 (다중 인스턴스) + │ ├─▶ B-3 (refresh 경쟁) + │ ├─▶ B-4 (edge 인가) + │ └─▶ B-5 (Redis 상실) ─▶ B-6 (영속화) + │ + └─▶ C-1 (SSO) ─▶ C-2 (백채널 로그아웃) + + D-3 (비밀), D-4 (인증서) 는 언제든 독립적으로 +``` + +**A-7(volatile)을 A층 마지막에 두는 이유** — 앞의 실험들을 전부 마친 뒤 +설정 하나만 바꿔 재실행하면, **같은 주입에 대한 정반대 결과**를 한 벌로 +얻는다. 이게 이 실험대에서 가장 값진 산출물이 될 가능성이 높다. + +--- + +## 공통 판정 규칙 + +A-0에서 비싸게 배운 것들. 모든 실험에 적용한다. + +| 규칙 | 왜 | +|---|---| +| **대조군을 먼저 잰다** | 반대편 응답은 발급 노드 응답과 나란히 놓기 전엔 의미 없다 | +| **개수가 아니라 식별자로 추적** | 실험 도구 자신이 만든 잡음에 오염된다 | +| **저장소를 실제로 건드리는 탐침** | userinfo 는 세션을 몰라도 통과한다 | +| **계측 코드가 자기 실패를 말하게** | 스냅샷이 비면 델타가 조용히 0이 된다 | +| **예측을 먼저 적는다** | 사후에 "그럴 줄 알았다"는 아무것도 아니다 | +| **증거는 원본 그대로** | 터미널 출력과 브라우저 스크린샷. 재구성하지 않는다 | + +### 실험마다 남기는 것 + +``` +docs/experiment-NN-<이름>.md 해설 · 예측 · 결과 · 개념 · 함정 +docs/evidence/<이름>/README.md 파일별 무엇을 보여주는지 +docs/evidence/<이름>/*.txt 터미널 원문 +docs/evidence/<이름>/*.png 브라우저 스크린샷 (Grafana / 관리 콘솔) +deploy/lab/scripts/experiment-*.sh 재현 스크립트 +``` diff --git a/docs/session-store-lab-roadmap.md b/docs/session-store-lab-roadmap.md index 4c14e55..1766fbe 100644 --- a/docs/session-store-lab-roadmap.md +++ b/docs/session-store-lab-roadmap.md @@ -59,7 +59,9 @@ if [ "$expected_count" -ne 39 ]; then 12. 인증서 갱신 실측 ``` -**순서 근거는 [`open-questions-coverage.md`](open-questions-coverage.md)에 있다.** +**각 실험의 구조·주입 지점·확인 항목은 +[`experiment-plan.md`](experiment-plan.md)에 미리 확정해두었다.** +순서 근거는 [`open-questions-coverage.md`](open-questions-coverage.md)에 있다. 특히 5번(refresh 경쟁)은 3번(저장소 공유) 이후여야 **재현 자체가 성립한다.** ### ✅ 완료 — 환경 구축 @@ -378,6 +380,9 @@ sudo certbot renew --force-renewal | 문서 | 내용 | |---|---| +| [`experiment-plan.md`](experiment-plan.md) | **실험 20개의 구조도·주입 방법·관측 지점·예측** | +| [`session-lab-prerequisites.md`](session-lab-prerequisites.md) | 이 실험을 이해하기 위한 선수 지식 | +| [`experiment-00-session-replication.md`](experiment-00-session-replication.md) | A-0 결과 — 세션 공유의 실체 | | [`open-questions-coverage.md`](open-questions-coverage.md) | 공개 열린 질문 4개와의 대조, 순서 근거 | | [`session-lab-concepts.md`](session-lab-concepts.md) | 등장 개념 전체 (가상화·네트워크·k3s·TLS·패키지) | | [`session-lab-operations.md`](session-lab-operations.md) | 관측 도구 · 자주 쓰는 명령 · 훈련 · 자원 예산 |