시뮬레이션 런 한 번의 일생
사용자가 "실행" 버튼을 누르면, 그 뒤에서 꽤 긴 여정이 펼쳐집니다. RuntimeConfig라는 주문서 하나가 큐를 지나, 워커에 잡히고, 러너가 Isaac을 띄우고, 물리가 돌고, 마침내 영상과 KPI가 나옵니다. 이 한 바퀴를 따라가 봅니다.
제출에서 산출까지
도식 렌더링 중…
- 제출 — API(POST /runs)로 RuntimeConfig를 보냅니다. 런이 DB에
requested로 기록됩니다. - 큐 — 오케스트레이터가 대기열에 올려둡니다. 아직 GPU는 안 씁니다.
- claim — 워커가 자기 GPU 노드가 비면 런을 집어(claim)
running으로 바꿉니다. - 러너 — Isaac Sim을 부팅하고, 환경·로봇을 스폰하고, 물리를 step합니다.
- 산출 — 매 틱 궤적을 기록하고, HLS로 영상을 녹화하며, KPI를 집계합니다.
- 정리 — 끝나면 verdict(판정)를 매기고, 영상을 mp4로 묶고, 리소스를 정리(teardown)합니다.
각 단계의 의미
이 분업에는 이유가 있습니다.
💡 큐와 실행의 분리 — 제출(가벼움)과 실행(무거운 GPU)을 분리하면, 수백 개를 한꺼번에 제출해도 GPU가 감당하는 만큼만 차례로 돕니다. "제출 = 즉시 실행"이 아니라 "제출 = 대기열 등록"이라, 배치 수천 건도 안전하게 흘려보낼 수 있습니다.
⚠️ claim 단계가 조용히 막히면 위험 — 런이
requested에서 안 넘어가면, 워커가 claim을 못 하는 것입니다. 추측성 게이트가 막거나, 노드 연결이 죽었거나. 이 단계의 실패는 에러 없이 조용하기 쉬워, 끝단(노드 연결·게이트)부터 의심해야 합니다.
산출물은 어디서 오나
런이 끝나면 output/runs/{run_id}/ 아래에 — 카메라별 mp4, 궤적 로그, KPI, 이벤트 로그, AAR(사후 분석)이 쌓입니다. 영상은 HLS 스트리밍 파이프라인이 라이브로 만든 세그먼트를 teardown 때 mp4로 합친 것입니다. 그래서 런이 정상 종료(teardown)에 도달해야 영상이 완성됩니다 — 중간에 하드킬되면 세그먼트만 남고 mp4가 안 묶입니다.
한 줄 정리
📌 런의 일생은 **제출(API) → 큐(requested) → 워커 claim(running) → 러너(Isaac 부팅·물리 step) → 산출(궤적·KPI·영상) → verdict·정리(teardown)**다. 제출과 실행을 분리해 배치를 안전하게 흘리고, 영상은 teardown에서 완성되며,
requested에서 멎으면 claim 단계(게이트·노드 연결)를 의심한다.