CloudOps 실행 흐름 CLO-1266

CLO-1266

CloudOps 수집 및 티켓 발행 흐름

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

Temporal 수집 경로 계정 등록 → 별도 수집 시작 → 계정별 수집 → 두 후속 경로

수집이 끝나면 WA 진단·티켓과 관계·VPC·매핑이 서로 독립적으로 진행됩니다.

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

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

TEMPORAL WORKFLOW 시작점 전체 지도

Temporal Workflow는 다음 다섯 경우에 시작됩니다

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

01 · 결과 대기

자격증명 검증

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

조건
provider와 credential 준비
실패
모든 원인을 DISCONNECTED로 정규화
02 · 비동기

수동 리소스 수집

요청자가 POST /resources/collect 본문에 수집할 계정 1–100개를 지정

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

일일 전체 수집

매일 01:00 KST에 계정 목록 없이 시작하고, 부모 Workflow가 활성 계정을 DB에서 조회

조건
APScheduler job 활성·replica 1
실패
로그 기록, 다음 cron 전 재시작 없음
04 · 삭제 후 관계 재계산

계정 삭제 뒤 관계 정리

삭제 전 상태를 읽는 경쟁을 줄이기 위해 예약 시점에서 10초 뒤 RelationshipExtractRun 시작

조건
GENERAL 계정 삭제
실패
예외를 흡수하고 계정 삭제는 유지
05 · 삭제 후 WA 재평가

계정 삭제 뒤 WA 재평가

삭제 리소스가 있을 때 예약 시점에서 15초 뒤 WellArchitectedRun 시작

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

계정과 리소스의 soft-delete는 요청 트랜잭션 안에서 실행되고, DB commit은 요청이 끝날 때 일어납니다. Worker가 commit 전 데이터를 읽는 경쟁을 줄이기 위해 관계 재계산은 10초 뒤, WA 재평가는 15초 뒤 시작하도록 각각 예약합니다. 두 지연은 순서대로 25초를 기다리는 과정이 아니며, WA 재평가는 관계 재계산 완료를 기다리지 않습니다.

상세 실행 시퀀스

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

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

상세 시퀀스 구간을 열면 실행 주체·queue·대기 조건과 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. 1
    계정을 등록합니다

    자격 증명을 확인한 뒤 계정과 Secret 참조를 저장합니다. 등록만으로 수집이 시작되지는 않습니다.

  2. 2
    수집을 별도로 시작합니다

    수동 API는 선택한 계정 1~100개를, 일일 Scheduler는 실행 시점의 활성 계정 전체를 대상으로 삼습니다.

  3. 3
    부모 Workflow가 계정별 실행을 관리합니다

    대상을 pending으로 바꾸고 계정별 자식 Workflow를 최대 20개까지 동시에 실행합니다.

  4. 4
    각 계정의 리소스를 수집하고 저장합니다

    계획이 성공하면 running으로 바꾸고, 작업별로 수집한 결과를 즉시 저장한 뒤 최종 상태를 결정합니다.

  5. 5
    모든 계정 수집 뒤 후처리를 시작합니다

    WA 진단·티켓과 관계·VPC 계산은 병렬로 진행될 수 있으며, 관계 계산 뒤에는 매핑을 시작합니다.

수집 부모 Workflow 완료의 의미 수집 부모가 기다리는 계정별 수집과 관계·VPC 경로는 종료됐지만, 별도로 실행되는 WA 진단·티켓과 매핑은 아직 진행 중일 수 있습니다.

세부 단계

계정 등록·수집·후처리의 세부 조건

단계를 누르면 오른쪽에서 실행 주체, 다음 단계로 넘어가는 조건, DB 기록과 실패 동작을 확인할 수 있습니다.