operations dummy generator backtest

운영 — Dummy Generator Risk Coverage 백테스트

factory-b/c dummy generator가 Risk Score의 risk.top_causes를 더 다양하게 만들도록 profile을 개편한 뒤, VM 배포부터 AWS 저장까지 전 경로를 검증한 기록이다. 기준일 2026-06-04.

Risk 계산 로직(apps/data-processor/processor/risk.py)과 DynamoDB/S3 저장 계약은 바꾸지 않았다. 이 작업의 범위는 dummy generator 입력의 다양화와 그 결과 검증이다.

개편 설계

기존의 순수 확률 기반 anomaly를 제거하고 랜덤 간격 + round-robin 이벤트 타입 + 랜덤 값 구조로 바꿨다.

• baseline sensor jitter는 유지한다.
• AI event 기본 간격은 25~30분이며, 발생 시 fire_score/fall_score/bend_score 중 일부만 활성화한다.
• AI score 값은 0.5~1.0 범위의 0.1 단위 값이다.
• pipeline freshness 이벤트는 payload에 pipeline_status_*를 직접 넣지 않고, --loop에서 infra_state 생성을 skip해 만든다.

Profile별 Risk 커버리지

Factory	Profile	성격	AI	sensor	infra	freshness
factory-b	stable-lab	warning 중심	ai_warning (25~30분)	temperature/humidity/pressure_high, pressure_low (6~10분)	storage_warning, device_unavailable, pods_partial, nodes_partial (5~8분)	pipeline_warning_gap (75~105초 skip)
factory-c	noisy-vm	warning/critical/gate	ai_warning, ai_critical (25~30분)	*_critical, pressure_high/low_critical (4~7분)	pods_all_unready, nodes_all_not_ready, network_unreachable, device_unavailable, storage_critical (3~6분)	pipeline_critical_gap, pipeline_outage_gap (135180초 / 301330초 skip)

즉 factory-b는 warning 계열 top_causes 순환을, factory-c는 critical/gate 계열과 데이터 단절(pipeline_*_gap)을 검증하도록 분담한다.

검증 결과

Local test — python3 -m unittest discover -s apps/dummy-sensor/tests → 23 tests OK. AI score 범위/단위, baseline에서 매번 AI event가 나지 않는지, sensor spike가 threshold를 넘는지, infra event가 node/pod/device/storage/network 상태를 만드는지, node down이 explicit event에서만 발생하는지, write_outbox() idempotency를 확인했다.

No-write preview — 운영 outbox를 건드리지 않고 event interval override로 새 profile이 risk input을 만드는지 확인. factory-b는 temperature high(>32°C warning), storage warning(>75%); factory-c는 temperature critical(>38°C), CrashLoopBackOff/running=0 등 pods_all_unready gate를 만들 수 있음을 확인했다.

End-to-end 저장 경로 — VM systemd service active, factory_state ~3초·infra_state ~20초 주기로 outbox JSON 생성. edge-iot-publisher Pod Running, aegis/factory-{b,c}/{factory_state,infra_state} topic으로 publish. DynamoDB LATEST/HISTORY#STATE 갱신, S3 raw/·processed/risk_score/·processed/state_snapshot/에 최신 timestamp로 적재됨을 확인했다.

검증의 한계 — outbox backlog

배포 직후 LATEST.risk.top_causes는 정상 baseline factory_state에 빠르게 덮여 빈 배열인 경우가 많았다. 또한 양쪽 VM의 outbox에 1시간 이상 된 JSON이 6만 개 이상 backlog로 남아 있었다.

• publisher는 publish 성공 후 path.unlink()를 수행하는데도 backlog가 유지된 원인은 별도 운영 점검이 필요하다.
• 오래된 payload가 뒤늦게 publish되면 HISTORY/S3 processed에 기존 generator의 risk pattern이 섞여, 새 profile 효과와 backlog 효과가 혼재한다.
• 따라서 event 확인은 LATEST가 아니라 HISTORY#STATE와 S3 processed/risk_score 기준으로 봐야 한다.

권장 다음 단계

1. 운영 승인 후 outbox의 오래된 backlog를 정리한다.
2. 정리 직후 30~60분간 HISTORY#STATE와 S3 processed/risk_score를 관찰한다.
3. factory-b는 warning 계열, factory-c는 critical/gate 계열 top_causes가 순환하는지 확인한다.
4. freshness는 기본 간격상 시간이 걸리므로 pipeline_warning_gap/pipeline_critical_gap/pipeline_outage_gap 발생 시간대를 HISTORY 기준으로 확인한다.

관련 문서

• Dummy Sensor
• factory-b/c 테스트베드
• Safety Score 모델
• Data Pipeline 운영
• 이상 감지 시나리오