CloudOps 실행 흐름 CLO-1266

CLO-1266

CloudOps 수집 및 티켓 발행 흐름

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

Temporal 수집 경로 계정 등록 → 별도 수집 시작 → 계정별 수집 → WA ∥ 관계→VPC ID→매핑

모든 계정의 리소스 저장이 끝나면 WA는 별도로 실행되고, 관계에서 VPC ID를 계산한 뒤 매핑을 시작합니다.

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

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

VPC ID 반영 시점

모든 계정의 리소스 저장이 끝난 뒤입니다

VPC를 CSP에서 다시 수집하는 단계가 아닙니다. 확정된 리소스 관계에서 각 리소스가 속한 VPC를 계산해 resource.vpc_id에 저장합니다.

모든 계정 저장 완료→ 계정별 관계 갱신→ 고객 관계 확정→ resource.vpc_id 저장→ 매핑 시작

WA는 첫 단계가 끝난 뒤 별도로 시작되어 이 경로와 병렬로 진행됩니다. 수집 부모는 VPC ID 저장까지 기다리지만 매핑 완료는 기다리지 않습니다.

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 WellArchitectedRun 시작 시작만 확인 · 평가와 티켓 완료는 기다리지 않음
Core Worker → Temporal 22 RelationshipExtractRun 실행·완료 대기 WA는 이 경로와 병렬로 계속 실행
Core Worker → Core DB 23 계정별 리소스 관계 갱신 같은 고객의 계정은 순서대로 resource_relationship 갱신
Core Worker → Core DB 24 고객 전체의 최종 관계 확정 고객의 모든 계정 관계 추출이 끝난 뒤 고객당 한 번 실행
Core Worker → Core DB 25 확정된 관계에서 resource.vpc_id 계산·저장 VPC 재수집이 아니라 containment 관계에서 소속 VPC를 파생
Core Worker → Temporal 26 MappingApplyRun 시작 관계·VPC ID 처리 종료 뒤 시작 · 매핑 완료는 기다리지 않음
독립 자식 Workflow → Core DB 27 WA 티켓 조정과 매핑 규칙 적용 수집 부모가 완료된 뒤에도 각각 계속 실행될 수 있음
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와 관계 후처리를 시작합니다

    모든 계정의 리소스 저장이 끝나면 WA를 별도로 시작합니다. 이어서 계정별 관계를 갱신하고 고객 관계를 확정한 뒤, 그 관계에서 각 리소스의 vpc_id를 계산·저장합니다. 수집 부모는 여기까지 기다린 후 매핑을 시작합니다.

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

세부 단계

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

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