CLO-1266

CloudOps 수집 및 티켓 발행 흐름

리소스 수집은 Temporal, CSP 이벤트 처리는 NATS JetStream을 사용합니다. 두 경로는 서로 다른 시작점과 실패 경계를 가집니다.

로컬 Temporal UI 열기 ↗

Temporal 수집 경로 계정 등록 → 별도 수집 시작 → 부모 실행 → 계정별 수집 → 후처리

WA 진단 항목은 티켓으로 동기화됩니다.

NATS 이벤트 경로 CSP 웹훅 → 정규화 → 알림 그룹화 → 티켓 반영

리소스 수집 Workflow와는 별도로 실행됩니다.

TEMPORAL WORKFLOW 시작점 전체 지도

최상위 실행을 만드는 업무 진입점은 다섯 종류입니다

수집 외에도 자격증명 변경과 계정 삭제가 Workflow를 시작합니다. 아래 카드는 시작 조건과 원 요청에 미치는 실패 영향을 비교합니다.

01 · 결과 대기

자격증명 검증

등록·수정·자격증명 갱신·root 연결 변경·일괄 검증/등록

조건: provider와 credential 준비
실패: 모든 원인을 DISCONNECTED로 정규화

02 · 비동기

수동 리소스 수집

POST /resources/collect가 계정 1–100개를 전달

조건: 검증 성공 계정이 1개 이상
실패: item·계정 상태를 failure로 보정

03 · 예약 실행

일일 전체 수집

core-scheduler가 매일 01:00 KST에 빈 입력으로 시작

조건: APScheduler job 활성·replica 1
실패: 로그 기록, 다음 cron 전 재시작 없음

04 · 10초 지연

계정 삭제 뒤 관계 정리

삭제 transaction commit 뒤 RelationshipExtractRun 시작

조건: GENERAL 계정 삭제
실패: 예외를 흡수하고 계정 삭제는 유지

05 · 15초 지연

계정 삭제 뒤 WA 재평가

남은 리소스를 기준으로 WellArchitectedRun 시작

조건: GENERAL · 삭제 리소스 1개 이상
실패: 예외를 흡수하고 계정 삭제는 유지

10초·15초 지연은 soft-delete 요청 transaction이 commit되기 전에 Worker가 읽는 race를 줄이기 위한 경계입니다. 최상위 실행은 원장 Activity가 성공하면 workflow_run에 기록되지만, 원장 실패는 업무 Workflow를 막지 않습니다.

상세 실행 시퀀스

계정 검증·수집·후처리·CSP 이벤트를 순서대로 보기

Temporal 경로는 Workflow·Activity handoff를, 이벤트 경로는 JetStream 전달을 보여 줍니다. DB 칩은 해당 시점에 바뀌는 물리 테이블과 연산입니다.

Temporal 수집 요약 6개 실행 주체의 전체 handoff 보기 반복되는 Workflow Task 반환은 생략한 방향 확인용 그림

시작 주체 Core API / Scheduler REST · APScheduler

오케스트레이션 Temporal Service gRPC :7233 · History

Workflow · Core Activity Core Worker core-collect

Provider Activity CSP Worker plugin-{provider}*

외부 시스템 AWS · Azure · GCP Cloud API

Core 영속 상태 Core DB / Secret account · resource · ticket

A 계정 등록 REST 정책 검증 후, 실제 CSP 연결에 성공해야 저장

Core API → Temporal 0 CredentialValidationWorkflow 실행·대기

Temporal → Core Worker 1 자격 증명 Workflow Task 전달

Core Worker → Temporal 2 validate_credential Activity 예약

Temporal → CSP Worker 3 validate_credential Activity 전달 plugin-{provider}-heartbeat queue

CSP Worker → CSP API 4 자격 증명으로 연결 확인

CSP API → CSP Worker 5 연결 성공·실패 응답

CSP Worker → Temporal 6 Activity 결과 반환

Temporal → Core API 7 credential 검증 결과 반환

Core API → Core DB / Secret 8 계정 저장 → secret 보관 → credential_ref 확정

B 별도의 리소스 수집 시작 계정 등록 완료와 자동으로 연결되지 않음

Core API / Scheduler → Temporal 9 ResourceCollectionRun 시작

Temporal → Core Worker 10 부모 Workflow Task 전달

Core Worker → Core DB 11 대상 계정 확정·pending 갱신 수동은 요청 입력, 스케줄은 active 계정 조회

Core Worker → Temporal 12 계정별 자식 Workflow 시작 명령 최대 20개 계정 동시 실행

Temporal → Core Worker 13 ResourceCollection 자식 Task 전달

C 계정별 리소스 수집 계정과 plan task 수만큼 반복

Core Worker → Temporal 14 make_plan → collect_resources 예약 Workflow 명령으로 Activity를 순서대로 등록

Temporal → CSP Worker 15 provider queue로 Activity Task 전달 plan queue 이후 collect queue

CSP Worker → CSP API 16 실제 Cloud API 호출

CSP API → CSP Worker 17 리소스·오류 응답

CSP Worker → Temporal 18 Activity 결과 반환·진행 상태 기록

Temporal → Core Worker 19 upsert_resources Activity 전달

Core Worker → Core DB 20 task 단위 저장·계정 최종 상태 반영

D 모든 계정 수집 종료 후 후처리 모든 계정별 자식 Workflow가 성공 또는 실패로 끝난 뒤 진입

Core Worker → Temporal 21 후처리 자식 Workflow 시작 WA 시작 → 관계 추출 완료 대기 → 매핑 시작

Temporal → Core Worker 22 평가·관계·매핑 Activity 전달

Core Worker → Core DB 23 WA 진단 티켓·관계·VPC·매핑 반영 기존 finding 티켓과 비교해 생성·갱신·해결

Temporal이 하는 일 업무 데이터를 직접 처리하는 것이 아니라 실행 이력, 대기, 재시도, timeout, task queue 전달과 parent-child 순서를 관리합니다. 반복되는 Worker polling과 Workflow Task 반환은 그림에서 생략했습니다.

수집 요청 1회 · 계정 N개 기준

무엇이 생성되고 어디에 기록되는가

위치	생성·변경되는 것	개수
Temporal	`ResourceCollectionRun` 부모 실행	1개
Temporal	`ResourceCollection` 계정별 자식 실행	N개
Core DB	`general_account` 기존 행의 수집 상태	N개 갱신
Core DB	`resource`·`resource_data` task별 UPSERT	수집 결과만큼
Core DB	`resource_change` 생성·변경 이력	unchanged 제외
Core DB	`workflow_run` 최상위 실행 원장	보통 1행
Core DB	`workflow_run_item`·`collection_job`·`collection_task`	0행 · writer 없음/폐기

코드의 job은 계정별 Workflow 입력 dict를 가리키는 이전 명칭입니다. Temporal의 별도 개념이나 DB row가 아닙니다. API 응답의 collection_job_id도 현재는 rc-{general_account_id} 형식의 식별 문자열이며 DB 기본 키가 아닙니다. workflow_run 기록은 업무 실행을 막지 않는 보조 원장이며, 계정별 자식은 현재 이 테이블에 각각 기록하지 않습니다.

시퀀스 보완 정보

단계별 운영 계약 확인

위 시퀀스가 순서와 handoff를 보여 준다면, 이 영역은 DB 기록, 중복 안전성, 실패 뒤 복구와 운영 확인 항목을 설명합니다.

TEMPORAL 수집 흐름

계정 등록과 리소스 수집 시작은 별도입니다

실선은 앞 단계의 완료를 기다리는 경로입니다. 점선은 시작만 확인한 뒤 부모와 별도로 실행되는 자식 워크플로를 뜻합니다.

등록 Temporal Core/DB 별도 실행 확인 필요

TEMPORAL 실행 구조

각 프로세스는 Temporal Frontend를 통해 작업을 주고받습니다

API, 스케줄러, 워커는 gRPC 7233으로 Temporal Frontend에 연결합니다. 브라우저는 별도의 HTTP 8233 포트로 Web UI에 접속합니다.

안전한 Pod 종료를 위한 조건 Pod grace > preStop + signal + drain + cleanup + margin

현재 워커 종료 대기 시간 30초와 Kubernetes 기본 종료 유예 시간 30초가 같아 추가 정리 시간을 확보할 수 없습니다. 운영 manifest의 실제 설정값은 아직 확인하지 못했습니다.

단계를 선택하세요

다음 단계 조건, DB 기록, 중복 안전성, 실패 동작과 운영 확인 항목을 이곳에서 확인할 수 있습니다.