component risk alert dispatcher

Risk Alert Dispatcher 컴포넌트

Factory 상태와 Cloud Infra snapshot을 S3 event로 받아 알림 규칙, 확인, cooldown을 적용한 뒤 scope별 Slack webhook으로 전달하는 Lambda다.

---

처리 흐름

S3 ObjectCreated (*.json)
  -> RiskAlertDispatcher
  -> S3 object read
  -> source/scope parse
  -> factory 또는 cloud rule 평가
  -> 필요한 warning 연속 관측 확인
  -> DynamoDB cooldown 예약
  -> scope별 Slack webhook 전송
  -> DynamoDB 전송 결과 기록

Terraform의 S3 notification은 다음 prefix를 명시적으로 등록한다.

processed/factory-a/state_snapshot/
processed/factory-b/state_snapshot/
processed/factory-c/state_snapshot/
processed/cloud_infra/fast/
processed/cloud_infra/slow/

그 밖의 processed object는 parser가 지원하지 않으며 알림 대상이 아니다.

---

Factory 규칙

Factory state_snapshot은 Safety Score 결과와 pipeline 상태를 함께 평가한다.

알림 조건:

• risk.level이 warning 또는 danger
• pipeline_status.status가 warning 또는 critical
• risk.top_causes[]에 danger 원인이 있음
• risk.gates[]에 danger gate가 있음

Pipeline freshness가 warning/critical이면 freshness weighted cause와 gate를 반복 전송하지 않고 pipeline_status 알림 하나로 합친다. 같은 snapshot에 node, pod, device, sensor, AI처럼 독립적인 원인이 있으면 별도 alert를 유지한다.

Factory 비-pipeline fingerprint는 현재 pipeline 상태와 분리된다.

warning#{reason}#state_snapshot
danger#{reason}#state_snapshot

warning#pipeline_status#warning
danger#pipeline_status#critical

따라서 동일한 node/AI/device 원인은 pipeline 상태가 바뀌어도 하나의 cooldown을 공유한다.

---

Cloud Fast 규칙

Cloud fast는 backend_runtime과 data_pipeline의 specific 원인을 먼저 찾는다.

Specific alert:

• Lambda errors_5m > 0
• Lambda throttles_5m > 0
• DynamoDB read/write throttle 발생
• ALB unhealthy host 발생
• collector error

Specific으로 설명할 수 없는 non-normal section만 generic fallback을 만든다.

실제 원인	생성	억제
Lambda error	data_pipeline_lambda_errors	data_pipeline_warning
Lambda throttle	data_pipeline_lambda_throttles	data_pipeline_warning
DynamoDB throttle	dynamodb_throttles	data_pipeline_warning
ALB unhealthy target	alb_unhealthy_hosts	backend_runtime_warning
원인 미식별 backend 이상	backend_runtime_{status}	없음

factory_freshness는 Cloud fast snapshot과 Dashboard에는 남지만 Cloud Slack 규칙은 평가하지 않는다. 같은 freshness 문제는 Factory snapshot의 pipeline alert가 담당한다.

Redis/RDS datastores section도 현재 generic Cloud alert 평가 대상은 아니다. Datastore collector 호출이 실패하면 통합 fast.errors[]를 통해 collector error가 생성될 수 있지만, Redis/RDS 상태 임계 초과만으로는 Slack alert가 만들어지지 않는다. Dashboard overall_status와 상세 card에서 먼저 관찰해야 하는 현재 규칙의 경계다.

---

Cloud Slow 규칙

Cloud slow는 다음 specific 원인을 평가한다.

• storage freshness non-normal
• EKS cluster 또는 nodegroup이 ACTIVE가 아님
• ASG healthy instance가 desired보다 적음
• Kubernetes nodes/pods 상태가 non-normal
• ArgoCD 상태가 non-normal
• collector error

nodes, pods, ArgoCD 등 specific 원인이 있으면 eks_management_* generic alert는 만들지 않는다. 서로 독립적인 nodes와 pods 문제가 동시에 있으면 둘 다 유지한다.

Collector 실패로 section이 unknown이 된 경우에는 파생 unknown alert를 억제하고 대표 collector error를 사용한다. Storage freshness처럼 독립적으로 판단 가능한 이상은 collector error와 함께 유지할 수 있다.

---

Warning 확인과 즉시 알림

Cloud infra metric은 일시적 fluctuation이 잦다. Lambda cold start, 일시적 CloudWatch 지연, EKS node heartbeat 간격 때문에 1회 snapshot만으로 판단하면 false positive Slack 메시지가 반복된다. 이를 막기 위해 일부 Cloud warning 규칙은 서로 다른 snapshot 2회 연속 관측을 확정 조건으로 쓴다. Factory alert와 모든 danger는 즉시 중요하므로 확인 대기 없이 전송한다.

대부분의 alert는 한 snapshot으로 확정한다. 일시적 흔들림이 잦은 일부 Cloud warning만 서로 다른 최신 snapshot 2회가 필요하다.

Rule	확인 정책
Fast backend_runtime_warning	90초 안에 2회
Fast data_pipeline_warning	90초 안에 2회
Fast data_pipeline_lambda_errors	90초 안에 2회
Slow eks_management_warning	450초 안에 2회
Slow pods_warning	450초 안에 2회

첫 관측은 awaiting_confirmation으로 끝난다. 같은 window 안에 더 최신 source_updated_at을 가진 두 번째 snapshot이 와야 확정된다. 같은 snapshot 재처리는 확인 횟수를 올리지 않는다.

다음 조건은 확인 대기 없이 즉시 cooldown 예약과 전송으로 진행한다.

• 모든 danger/critical
• Factory warning
• ALB unhealthy host
• Lambda/DynamoDB throttle
• collector error
• storage, node, ArgoCD 등 위 표에 없는 warning

즉시 전송도 dedupe/cooldown은 적용된다.

---

Dedupe와 Cooldown

전송 제어 상태는 AEGIS-DynamoDB-FactoryStatus에 저장한다.

pk = ALERT#{scope}
sk = {severity}#{reason}#{fingerprint_status}

기본 cooldown:

Source	Warning	Danger
Factory snapshot	900초	300초
Cloud fast	900초	300초
Cloud slow	900초	300초

예약 조건은 두 가지다.

1. 이전 last_source_updated_at보다 최신 snapshot이다.
2. cooldown_until이 현재 시각 이하이거나 아직 없다.

예약되면 last_slack_status=pending을 먼저 기록하고 전송 후 sent 또는 failed로 바꾼다. Slack 전송이 실패해도 예약된 cooldown은 남으므로, 운영자는 실패 상태와 cooldown 시각을 함께 확인해야 한다.

---

ALERT#와 OBSERVATION#

확인용 item은 cooldown item과 분리된다.

pk = ALERT#cloud-infra
sk = OBSERVATION#{severity}#{reason}#{status}

두 item 종류 모두 기본 TTL은 604800초, 즉 7일이다.

Item	목적
일반 ALERT# item	마지막 전송, cooldown, source, Slack 결과 제어
OBSERVATION# item	warning 연속 관측 횟수와 window 제어

이 key들은 감사용 장기 알림 이력이 아니다. 같은 fingerprint를 update하고 TTL로 만료되는 운영 상태다. 사고 이력은 원본 S3 snapshot, CloudWatch Logs, Dashboard timeline/report와 함께 해석해야 한다.

---

Slack Routing

Dispatcher는 alert scope로 webhook secret을 고른다.

Scope	Lambda 환경 변수
cloud-infra	SLACK_WEBHOOK_SECRET_CLOUD
factory-a	SLACK_WEBHOOK_SECRET_FACTORY_A
factory-b	SLACK_WEBHOOK_SECRET_FACTORY_B
factory-c	SLACK_WEBHOOK_SECRET_FACTORY_C
그 밖의 scope	SLACK_WEBHOOK_SECRET_ID fallback

Secret 값은 Secrets Manager에서 실행 시 읽는다. 선택된 secret은 plain URL 또는 url/webhook_url JSON 필드를 지원한다. SSM SecureString fallback도 코드에 있지만 기본 Terraform 경로는 Secrets Manager다.

Slack 메시지는 scope, severity, source, 상태, Safety Score, reason, top cause/gate, 원본 S3 key를 제공한다.

Factory B/C는 VM 테스트베드의 synthetic dummy data다. 이 scope의 warning/danger 메시지는 실제 공장 사고를 확정한 것이 아니라 alert pipeline과 위험 시나리오를 검증하는 테스트 이벤트로 해석해야 한다.

---

Dashboard와의 차이

Dashboard는 DynamoDB LATEST와 history를 조회해 현재 상태, stale badge, timeline을 보여준다. Dispatcher는 S3 ObjectCreated 시점의 snapshot을 event 단위로 평가한다.

같은 read model
  -> Dashboard: 전체 상태와 시간 흐름을 관찰
  -> Dispatcher: 전송할 원인만 선택하고 noise policy 적용

따라서 Cloud 화면이 warning이라고 해서 항상 Slack이 즉시 오지는 않는다. specific rule 대상이 아니거나 확인 대기 중이거나 cooldown 중일 수 있다.

---

관련 문서

• Cloud Infra Collector
• Alert 운영
• Safety Score 모델
• 이상 감지 시나리오