사용자에게는 한 번의 실행이어야 합니다
학습자가 에디터에서 실행 버튼을 누르는 순간에는 클러스터도, 큐도, 컨테이너도 보이지 않아야 합니다. 하지만 서버는 언어와 리소스 한도, 네트워크 정책, 작업 만료 시간을 모두 결정해야 합니다.
Reporch는 이 복잡도를 Control Plane과 Execution Plane 사이의 명확한 계약으로 감췄습니다. API는 실행 요청을 기록하고, 실제 코드는 별도의 실행 네임스페이스에서만 움직입니다.
동기 요청 대신 상태 머신을 선택한 이유
코드 실행은 네트워크와 이미지 준비, 스케줄링, 사용자 코드라는 여러 실패 지점을 가집니다. HTTP 요청 하나에 이 생명주기를 묶으면 타임아웃 이후의 상태를 설명하기 어려워집니다.
그래서 모든 실행을 ExecutionJob으로 만들고 queued, dispatched, running, succeeded 또는 failed 상태를 거치게 했습니다. 같은 결과가 두 번 도착해도 한 번만 반영되도록 작업을 설계했습니다.
- API와 실행기의 장애 범위를 분리합니다.
- 재시도와 중복 결과를 안전하게 처리합니다.
- 사용자는 WebSocket으로 진행 상태를 이어서 볼 수 있습니다.
queued → dispatched → running → succeeded
↘ failed → cleanup성능보다 먼저 지켜야 하는 것
사용자 코드는 신뢰할 수 없는 입력입니다. 실행 Pod는 non-root UID, read-only root filesystem, 제한된 tmpfs, capability drop, PID와 메모리 제한을 기본값으로 갖습니다.
빠른 실행을 위해 격리를 약화시키는 대신, 이미지 준비와 warm pool을 개선합니다. 안전 경계는 최적화 대상이 아니라 제품의 전제입니다.
다음 목표는 더 적은 대기, 같은 안전성
이 구조 덕분에 언어별 런타임과 프리뷰 라우터를 독립적으로 개선할 수 있게 됐습니다. 이제 우리는 실행 준비 시간을 줄이면서도 동일한 보안 정책과 관측 가능성을 유지하는 데 집중하고 있습니다.