scenario failover recovery

Failover와 복구 시나리오

장애를 Factory A workload, 데이터 freshness, Hub control plane, Dashboard runtime 계층으로 나누어 설명한다. Factory A failover 성공을 전체 시스템 HA로 일반화하지 않는다.

---

장애 계층

계층	대표 장애	복구 주체
Factory A workload	worker2 전원/LAN/k3s-agent 장애	K3s scheduler + master OS cron
Factory data path	publish 중단, outbox 적체, freshness 증가	publisher 재시도 + cloud refresh
Hub control plane	EKS/ArgoCD 삭제 또는 재생성	Hub build/reconnect 절차
Dashboard runtime	ECS/ALB/RDS/Redis 장애	Data/Dashboard VPC 운영 절차
Snapshot upload	worker2/uploader/outbox 장애	현재 수동 확인, worker1 HA는 비범위

---

1. Factory A worker2 장애

Factory A의 AI, audio, BME280 workload는 worker2를 선호하고 worker1로 failover할 수 있다.

worker2 장애
  -> Node NotReady
  -> tolerationSeconds 30초 이후 eviction/re-schedule
  -> AI/audio/BME280가 worker1에서 Running
  -> InfluxDB write 재개

AI snapshot mount를 Longhorn RWO PVC에서 node-local hostPath로 바꾼 뒤 AI Pod는 stale VolumeAttachment에 막히지 않았다. 이는 AI workload 재기동 검증이며 snapshot upload HA를 의미하지 않는다.

실측 결과

docs/ops/09_failover_failback_test_results.md에 기록된 범위:

시험	관측 결과
전원 제거	장애 관찰부터 worker1 전체 Running까지 약 74초
전원 복구	복구 관찰부터 worker2 전체 Running까지 약 2분 11초
Longhorn	전원 복구 관찰부터 healthy까지 약 2분 22초
hostPath 적용 후 물리 LAN 제거 test_09	제거 후 약 2분 3초에 worker2 NotReady와 worker1 workload Running 확인
hostPath 적용 후	AI/audio/BME failover·failback 성공, snapshot PVC Multi-Attach 재발 없음

시험마다 Node heartbeat와 관찰 간격이 달라 LAN 제거 시간을 하나의 고정 SLA로 보지 않는다.

---

2. Data gap과 freshness

최종 물리 LAN 제거 검증의 10초 bucket 기준 InfluxDB 공백은 다음 범위였다.

Measurement	최대 0-count 구간
environment_data	약 70초
ai_detection	약 80초
acoustic_detection	약 80초

1초 bucket은 약 83~90초였으나 BME 수집 주기 때문에 운영 판단은 10초 bucket을 우선한다. 전원 제거 시험의 failback 공백은 각 measurement 최대 약 2초였다.

Cloud read model은 데이터가 멈춘 사실을 별도로 반영한다.

마지막 infra 관측 age <= 60초
  -> pipeline_status normal

age > 60초
  -> warning
  -> Dashboard 데이터 지연 표시

age > 120초
  -> critical
  -> Safety Score danger gate 가능
  -> Factory alert 즉시 평가

DataProcessor refresh가 1분마다 실행되므로 새 telemetry가 없어도 과거 safe 상태가 무기한 남지 않는다. processed_agg의 빈 bucket은 source_count=0, 빈 sensor/infra와 freshness Risk를 기록한다.

---

3. Worker2 복구와 failback

worker2 Ready 복귀
  -> master OS cron
  -> /usr/local/sbin/safe-edge-failback.sh
  -> 대상 Pod가 이미 worker2면 SKIP
  -> worker1에 있으면 순차 삭제
  -> worker2 preferred affinity로 재스케줄
  -> InfluxDB/Longhorn 상태 확인

Failback은 Kubernetes CronJob이 아니다. OS cron과 Kubernetes API에 의존하므로 /var/log/safe-edge-failback.log도 복구 검증 대상이다.

---

4. Snapshot uploader 제약

현재 Factory A snapshot 경로는 worker2 단일 배치를 전제로 한다.

snapshot source: worker2 hostPath
snapshot-uploader: worker2 단일 Deployment
edge-iot-publisher/outbox: Longhorn RWO PVC

worker2 장애 시 AI workload는 worker1에서 재기동할 수 있지만 다음은 현재 보장하지 않는다.

• worker1에서 생성된 snapshot의 자동 S3 upload
• worker2 로컬 backlog의 worker1 인계
• uploader/outbox multi-writer
• worker별 state 병합과 중복 방지

따라서 Factory workload failover 성공과 image snapshot pipeline의 연속성은 별도 상태로 표시해야 한다.

---

5. Hub-only rebuild 중 데이터 지속성

Hub EKS/ArgoCD는 control plane이며 IoT data path의 중간 hop이 아니다.

Spoke publisher
  -> IoT Core
  -> IoT Rule/DataProcessor
  -> DynamoDB/S3
  -> ECS Dashboard

Hub만 삭제·재생성할 때 data-pipeline, ECS Backend, Factory publisher와 dummy generator를 유지하면 telemetry와 cloud-side 처리는 계속된다.

복구 순서:

build-hub.sh
  -> build-admin-ui-after-ns.sh
  -> HUB_ONLY_RECONNECT=true register-spoke-factory-a/b/c.sh
  -> publisher 중복/rollout 안전성 확인

HUB_ONLY_RECONNECT=true는 기존 Spoke workload의 불필요한 sync/restart를 기본적으로 생략한다. Hub 재생성 뒤 Slow Collector의 새 EKS access binding은 build 과정에서 복구한다.

이 연속성은 data-pipeline과 Spoke가 유지된 Hub-only 조건에만 해당한다. foundation, IoT, data-pipeline까지 삭제한 전체 rebuild에는 적용되지 않는다.

---

6. Dashboard/ECS 장애는 별도 계층

Dashboard 장애는 Factory A K3s failover로 복구되지 않는다.

ECS/ALB 장애
  -> 사용자 화면/API/WebSocket 영향
  -> IoT Core, DataProcessor, DynamoDB/S3 적재는 계속 가능
  -> Fast Collector가 backend_runtime 상태 갱신
  -> Cloud alert 규칙 평가

반대로 Factory A worker2 장애 중에도 ECS Backend가 정상이라면 Dashboard는 마지막 상태와 freshness warning/critical을 계속 보여줄 수 있다. RDS/Redis는 현재 Single-AZ/single-node 구성이라 전체 Dashboard HA로 간주하지 않는다.

---

복구 완료 기준

• AI/audio/BME workload가 기대 노드에서 Running
• InfluxDB write와 IoT publish가 재개
• LATEST.pipeline_status가 새 telemetry로 normal 복귀
• Dashboard에서 stale 표시가 해제
• Longhorn이 healthy 복귀
• failback log와 alert/cooldown 결과 확인
• snapshot uploader가 worker2에서 동작하고 backlog/state를 처리

---

관련 문서

• 모범사례와 실패사례
• AI Snapshot hostPath ADR
• Failback OS cron ADR
• Hub 재생성 운영
• Image Snapshot Pipeline