scenario anomaly detection

이상 감지 시나리오

센서, AI, node/pod, 데이터 파이프라인, Cloud Infra 이상이 Safety Score, state snapshot, Slack, Dashboard에 반영되는 현재 흐름을 정리한다.

---

이상 영역

영역	예시	주 입력
Sensor	온도/습도/기압 임계 초과	factory_state
AI	fire/fall/bend score, abnormal sound	factory_state
Node/Pod/Device	NotReady node, unready workload, 장치 unavailable	infra_state
Pipeline	infra_state 지연 또는 단절	pipeline_status
Cloud	ECS/ALB, Lambda/DynamoDB, Redis/RDS, EKS/ArgoCD 이상	Cloud fast/slow snapshot

Factory A는 실제 Safe-Edge 관제 입력이다. Factory B/C는 VM 테스트베드의 synthetic dummy data이므로, 그 scope에서 발생한 anomaly와 Slack 메시지는 실제 현장 사고가 아니라 rule, multi-factory, freshness, UI 흐름 검증 이벤트다.

---

Factory 이상 흐름

Sensor/AI 또는 infra 상태 생성
  -> canonical JSON
  -> Edge IoT Publisher
  -> AWS IoT Core
  -> IoT Rule
      -> S3 raw
      -> Data Processor
          -> source_type별 normalize
          -> pipeline_status 계산
          -> Safety Score 계산
          -> DynamoDB FACTORY#{id}/LATEST
          -> DynamoDB HISTORY#STATE
          -> S3 processed/{factory_id}/state_snapshot
              -> RiskAlertDispatcher
              -> Slack

새 메시지가 없어도 1분 scheduler가 refresh_pipeline_status를 실행한다. 마지막 infra_state age를 다시 계산해 데이터 단절을 warning/critical로 바꾸고 새 state snapshot을 만든다. 과거 safe 값이 영구히 남는 것을 막는 경로다.

---

Safety Score와 Gate

현재 risk.score는 이름과 달리 높을수록 안전한 Safety Score다.

Level	Score	의미
safe	85~100	정상
warning	50~84	주의
danger	0~49	즉시 확인

factory_state + infra_state + pipeline_status
  -> 지표별 weighted contribution
  -> base_score = 100 - contribution 합계
  -> gate로 score 상한 적용
  -> score / level / top_causes

Weighted 지표에는 temperature, humidity, pressure, AI event, node/pod 상태, device availability, data freshness, storage pressure, network reachability가 포함된다.

Gate는 합산 점수가 높더라도 치명 조건을 강제로 반영한다.

Gate 예	결과
AI peak critical	danger cap
전체 node NotReady	score 0
전체 workload unready	danger cap
필수 device unavailable	warning 또는 danger cap
pipeline warning	warning cap
pipeline critical	danger cap
infra_state age 300초 초과	score 0

Dashboard와 Slack은 top_causes와 gates를 사용해 “왜 점수가 낮아졌는지”를 보여준다.

---

State Snapshot

Factory 상태 판단의 이벤트 단위 read model은 다음 S3 object다.

processed/{factory_id}/state_snapshot/yyyy=YYYY/mm=MM/dd=DD/hh=HH/{updated_at}.json

Snapshot에는 당시의 factory/infra 상태, pipeline status, Safety Score와 top causes가 함께 들어간다. RiskAlertDispatcher는 개별 risk_score object가 아니라 이 결합 snapshot을 평가한다.

sensor/AI 이상
  -> risk warning/danger alert

node/pod/device 이상
  -> gate 또는 top cause alert

pipeline freshness 이상
  -> pipeline_status alert

Pipeline freshness가 이미 alert 조건이면 같은 freshness cause/gate는 한 번 더 보내지 않는다. 단, 같은 snapshot의 독립적인 node/AI/device danger는 유지한다.

---

Cloud 이상 흐름

Fast Collector 1분
  -> backend/datastore/pipeline/factory freshness
  -> CLOUD#infra LATEST.fast
  -> S3 cloud fast snapshot

Slow Collector 5분
  -> EKS/Kubernetes/ArgoCD/storage freshness
  -> CLOUD#infra LATEST.slow
  -> S3 cloud slow snapshot

S3 ObjectCreated
  -> RiskAlertDispatcher
  -> specific rule / generic fallback
  -> confirmation / cooldown
  -> Cloud Slack channel

Dashboard는 전체 Cloud read model과 factory freshness를 표시한다. 최신 collector 코드의 overall_status도 factory freshness와 Redis/RDS datastore 상태를 포함한다. 반면 Cloud Slack은 factory freshness와 datastore section 상태 자체를 generic 평가하지 않는다. Factory freshness는 Factory pipeline alert가 담당하고, datastore 상태는 현재 Dashboard 관찰 항목이다. 단, datastore 수집 실패가 fast.errors[]에 기록되면 collector error 알림은 생성될 수 있다.

---

Slack 판단

Factory warning/danger와 Cloud danger는 한 snapshot으로 확인된다. 일부 일시적 Cloud warning은 서로 다른 최신 snapshot 2회가 필요하다.

첫 warning snapshot
  -> OBSERVATION# 상태 갱신
  -> awaiting_confirmation

window 안의 더 최신 두 번째 snapshot
  -> confirmation 완료
  -> ALERT# cooldown 예약
  -> Slack 전송

Cloud는 구체적인 원인이 있으면 포괄적인 section alert를 억제한다.

Lambda error
  -> data_pipeline_lambda_errors
  X  data_pipeline_warning

Pod warning
  -> pods_warning
  X  eks_management_warning

ALERT#와 OBSERVATION# item은 전송 제어 상태이며 기본 7일 TTL을 갖는다. 장기 사고 이력으로 사용하지 않는다.

---

Dashboard 확인

Factory 화면

운영자는 다음 순서로 본다.

1. Factory card의 Safety Score와 level
2. pipeline_status와 stale badge
3. top_causes와 gate
4. sensor/AI/node/workload/device 상세
5. timeline에서 상태 전환 시각
6. history chart와 S3/report 근거

새 snapshot을 받으면 WebSocket 갱신 신호가 UI에 전달되며, REST latest/history가 최종 read model이다. Timeline은 현재 상태와 history를 합쳐 sensor, risk, pipeline 전환을 보여준다.

Cloud Infra 화면

Cloud 화면은 다음을 함께 표시한다.

• overall_status
• Fast/Slow 마지막 갱신 시각과 stale badge
• backend runtime, datastore, data pipeline
• factory freshness
• EKS/node/pod/ArgoCD
• storage freshness
• Fast/Slow history strip
• collector reasons[]와 errors[]

Backend는 Fast 180초, Slow 900초 초과를 stale로 판정한다. Collector가 죽으면 마지막 정상 snapshot만 남기 때문에, read 시점에 해당 section을 unknown으로 바꾸고 overall normal을 warning으로 올린다.

---

운영 해석 예

Sensor + Node 복합 이상

temperature critical
+ 일부 node NotReady
  -> weighted penalty
  -> warning gate
  -> Safety Score 하락
  -> state snapshot
  -> reason별 Factory Slack
  -> Dashboard timeline

Pipeline 단절

infra_state 미수신
  -> 1분 freshness refresh
  -> pipeline warning/critical
  -> Safety Score cap
  -> pipeline_status alert 1건
  -> Dashboard stale/pipeline 표시

Cloud Lambda 오류

Fast Collector가 errors_5m 감지
  -> Cloud snapshot data_pipeline=warning
  -> 서로 다른 snapshot 2회 확인
  -> data_pipeline_lambda_errors Slack
  -> generic data_pipeline_warning 억제

EKS 즉시 위험

cluster/nodegroup not ACTIVE 또는 ASG healthy 부족
  -> Slow snapshot
  -> danger specific alert
  -> 확인 대기 없이 cooldown 예약
  -> Cloud Slack

---

사고 판정 주의

• Slack은 이상 조건 감지 신호이며 원인 확정이나 자동 복구 완료를 의미하지 않는다.
• Dashboard의 stale은 수집 지연을 뜻하며 대상 시스템 자체 장애와 구분해야 한다.
• Collector error로 생긴 unknown과 실제 service critical을 구분한다.
• Factory B/C dummy anomaly는 테스트 시나리오이며 실제 산업 현장 사고 통계나 사고 보고로 집계하지 않는다.
• 최종 판단은 원본 S3 key, CloudWatch Logs, DynamoDB latest/history, Dashboard timeline을 함께 확인한다.

---

관련 문서

• Safety Score 모델
• Data Processor
• Cloud Infra Collector
• Risk Alert Dispatcher
• Alert 운영