scenario normal operation

평시 운영 시나리오

Factory telemetry가 수집되고, read model·Dashboard·알림·일일 보고서로 이어지는 현재 end-to-end 흐름을 시간 순서로 설명한다.

---

정상 상태

계층	정상 기준
Factory Spoke	K3s 핵심 노드/Pod가 정상이고 edge data-plane이 outbox를 처리한다
Telemetry	factory_state, infra_state가 IoT Core로 지속 publish된다
Data Pipeline	raw/processed 저장과 DynamoDB read model 갱신이 성공한다
Freshness	pipeline_status=normal, 최신 infra age가 60초 이하이다
Dashboard	Factory, Cloud Infra, 그래프, 보고서를 조회할 수 있고, image snapshot API/화면은 System 권한으로 접근된다
Alert	전송 조건이 없고, warning 확인/cooldown 상태가 불필요하게 생성되지 않는다
Report	reporting stack과 Scheduler가 배포된 기간에 00:30 KST 전일 Factory/Cloud Infra 보고서가 생성된다

Factory B/C는 VM 테스트베드의 synthetic dummy data다. 화면과 알림이 동일한 파이프라인을 사용하더라도 실제 생산 공장 사건으로 해석하지 않는다.

---

1. Factory telemetry 생성과 전송

factory-a
  Safe-Edge InfluxDB
  -> factory-a-log-adapter
  -> Longhorn outbox
  -> edge-iot-publisher

factory-b/c
  dummy-data-generator
  -> hostPath input
  -> edge-iot-publisher

공통
  -> MQTT over TLS
  -> aegis/{factory_id}/{source_type}
  -> AWS IoT Core

Publisher는 성공한 outbox 파일만 삭제한다. 실패한 파일은 남겨 재시도하므로 일시적인 MQTT/TLS 장애가 바로 데이터 폐기로 이어지지 않는다. 현재 publisher는 persistent MQTT 연결을 유지하고 QoS 1 ack 완료 뒤 파일을 삭제한다. AWS IoT Fleet Indexing connectivity가 운영 지표로 쓰이며, 상세 확인은 IoT Fleet 연결성을 따른다.

Factory A의 AI 이벤트 이미지는 별도 경로를 사용한다.

worker2 snapshot hostPath
  -> snapshot-uploader
  -> presigned S3 PUT: image_snapshot/
  -> outbox에 image_snapshot metadata 기록
  -> edge-iot-publisher
  -> IoT Core

이미지 binary는 IoT Core를 통과하지 않고 S3 참조 metadata만 publish된다.

---

2. Raw, processed, Risk 계산

각 Factory IoT Rule은 한 메시지를 두 경로로 전달한다.

IoT Core
  ├─> S3 raw/{factory_id}/{source_type}/...
  └─> DataProcessor Lambda
        -> schema 정규화
        -> Safety Score와 pipeline_status 계산
        -> DynamoDB LATEST / HISTORY#STATE
        -> S3 processed/{factory_id}/...

새 메시지가 없어도 EventBridge Scheduler가 1분마다 DataProcessor의 refresh_pipeline_status를 실행한다. 이 refresh는 마지막 관측값을 새 데이터처럼 복제하지 않고, 현재 시각 기준 freshness와 Risk만 다시 계산한다.

---

3. Read model 갱신

Read model	생성 주체	평시 용도
FACTORY#{id}/LATEST	DataProcessor	공장 카드, 최신 Risk, node/workload, 최신 이미지
HISTORY#STATE	DataProcessor/refresh	1시간 그래프와 상태 전환
GRAPH#5M	GraphAggregator5m	6/12/24시간 그래프
CLOUD#infra/LATEST	Fast/Slow Collector	Backend, pipeline, EKS, storage 상태
HISTORY#FAST/SLOW	Fast/Slow Collector	Cloud Infra 최근 추이
ALERT#	RiskAlertDispatcher	dedupe, warning 확인, cooldown

Fast Collector는 1분, Slow Collector는 5분 주기로 cloud-side 상태를 수집한다. Dashboard는 CloudWatch, EKS, Kubernetes API를 직접 조회하지 않고 이 read model을 읽는다.

---

4. Dashboard 반영

브라우저
  -> CloudFront + private S3 Web SPA
  -> Cognito 로그인
  -> ALB HTTPS
  -> ECS Fargate FastAPI Backend
      -> DynamoDB LATEST/HISTORY/GRAPH/CLOUD read
      -> S3 reports/image_snapshot read
      -> RDS RBAC metadata
      -> Redis/WebSocket

DynamoDB Streams의 변경은 notifier Lambda가 Redis Pub/Sub로 전달하고, Backend가 WebSocket으로 화면에 push한다. 연결이 끊기면 REST refresh가 정본 read path다.

Dashboard는 Control/Management VPC, Hub EKS, ArgoCD, Spoke K3s API 또는 Tailscale 관리망을 호출하지 않는다.

---

5. 정상 알림 상태

RiskAlertDispatcher는 Factory state snapshot과 Cloud Infra fast/slow snapshot의 S3 ObjectCreated 이벤트만 평가한다.

평시에는 다음 조건이 유지된다.

• Factory risk.level=safe, pipeline_status=normal
• Cloud specific error/throttle/unhealthy 원인 없음
• Slack 전송 없음
• 과거 cooldown item은 TTL에 따라 만료

일부 Cloud warning은 서로 다른 최신 snapshot 2회 확인 후에만 전송된다. 모든 danger/critical, Factory warning, throttle, collector error 등은 확인 대기 없이 cooldown/dedupe 규칙을 적용한다.

---

6. 일일 보고서

reporting stack 배포 시 00:30 KST EventBridge Scheduler
  -> Step Functions
  -> 전일 24시간 Factory/Cloud Infra processed data 집계
  -> report-context.json 생성
  -> Amazon Bedrock 운영자 검토용 초안
  -> 수치 표 렌더링과 불변값 검증
  -> S3 reports/daily/.../report.md
  -> Dashboard Reports API/Web 조회

보고서 문장은 운영 판단의 정본이 아니다. report-context.json, processed object와 집계 결과가 근거이며, 최종 Markdown은 운영자 검토용이다. 비용 절감을 위해 reporting stack은 검증 후 destroy될 수 있다. 이 경우 Dashboard는 이미 S3에 생성된 reports/daily/ 산출물만 읽고, 신규 일일 보고서는 Scheduler가 다시 배포될 때 생성된다.

---

7. Control plane의 평시 역할

Hub EKS의 ArgoCD와 Tailscale은 배포·운영 제어 경로다. GitOps 변경은 Hub ArgoCD가 각 Spoke에 반영하지만, telemetry 수집 경로는 Hub를 통과하지 않는다.

Git 변경
  -> CI build/test와 ECR push
  -> GitOps values/manifest 갱신
  -> Hub ArgoCD/ApplicationSet
  -> Tailscale 경유 Spoke rollout

따라서 Hub의 정상 여부와 Factory 데이터 수집의 정상 여부는 관련은 있지만 동일한 가용성 계층은 아니다.

---

관련 문서

• 데이터 Read Models
• Dashboard VPC 설계
• Alert 운영
• Daily Reporting Pipeline