test: 노드 장애 및 PostgreSQL 자동 전환 검증

[move-hoon]

계층

운영 검증 — 실제 VM과 PostgreSQL primary 장애에서 사용자 서비스가 회복하는지 측정하는 작업입니다.

배경 및 목적

Kubernetes replica와 PostgreSQL standby가 있어도 실제 장애 때 자동으로 동작하는지는 별도 문제입니다. 스케줄러가 남은 노드에서 Pod를 실행할 공간이 없거나, CNPG 승격 뒤 애플리케이션 연결이 회복되지 않을 수 있습니다.

가비아 콘솔에서 노드를 강제로 정지하고 사용자 관점의 오류와 쓰기 중단 시간을 측정합니다.

현재 상태

노드 운영과 PostgreSQL failover Runbook만 있으며 실제 RTO와 자동 회복 기록은 없습니다.

작업 흐름

기준 트래픽 시작 → primary 노드 확인 → VM 강제 정지 → Pod 재배치·standby 승격 → 쓰기 회복 측정 → redundancy 복구

구현 방향

1. 시험 전 etcd snapshot, PostgreSQL 백업, 현재 primary와 Pod 배치를 기록합니다.
2. 일정한 읽기·쓰기 요청을 보내고 성공률과 latency 기준선을 잡습니다.
3. CNPG primary가 있는 VM 한 대를 가비아 콘솔에서 정지합니다.
4. Traefik, API, 필수 Pod의 재배치와 Pending 상태를 관찰합니다.
5. CNPG standby 승격과 rw Service의 쓰기 회복 시간을 측정합니다.
6. 정지 노드를 복구한 뒤 새 standby가 만들어지고 복제가 따라잡는지 확인합니다.
7. 오류 수, RTO, 수동 개입과 예상과 달랐던 점을 이슈에 남깁니다.

완료 조건

• 필수 Pod Pending이 0입니다.
• 사용자 서비스가 사람 개입 없이 회복합니다.
• PostgreSQL Write RTO가 측정되며 목표 60초 이내입니다.
• 복구 뒤 primary와 standby 두 인스턴스가 정상입니다.
• 시험 시각과 오류 수, RTO와 수동 개입 기록이 있습니다.

하지 않는 일

• 운영 시간대에 승인 없이 장애를 발생시키지 않습니다.
• readiness와 실제 쓰기 확인 없이 복구 완료로 보지 않습니다.

참고 자료

• 노드 운영
• PostgreSQL 복구
• 상위 이슈

위험 확인

• 관리망(management_network) 또는 방화벽(firewall) 순서에 영향을 줍니다.
• ESO/SecretStore 경로를 변경합니다.
• 시크릿·자격증명이 포함되지 않았음을 확인했습니다.

[move-hoon]

2026-08-15 v8 drill 기준: 이 이슈은 Drill A(non-primary node loss)와 Drill B(CNPG primary loss)의 실제 evidence를 요구합니다. VM hard power-off, external HTTPS, write RTO≤60s, actual RPO, single promotion/no split brain, cleanup을 Git 외부 evidence로 기록해야 합니다.

현재 validator/NOT_EXECUTED artifact만 있으므로 열어 둡니다.