처음에는 한 대면 충분했습니다
제품의 가설을 확인할 때는 단순한 구조가 가장 빠릅니다. API, 작업 큐, 실행기가 가까이 있으면 배포와 디버깅이 쉽습니다. 문제는 사용자 코드의 자원 사용량이 제품 API와 같은 장애 범위를 공유한다는 점이었습니다.
확장보다 장애 범위를 먼저 나눴습니다
전환의 핵심은 서버 수가 아니라 책임의 분리였습니다. 인증과 결제, 문제 데이터는 Control Plane에 남기고, 빌드와 실행, 정리는 Execution Plane으로 옮겼습니다.
reporch-control
api · celery · beat
reporch-executor
runner · cleaner · runtime pods한 번에 갈아엎지 않는 전환
새 실행 경로를 기능 플래그 뒤에 두고 기존 요청과 같은 결과를 내는지 비교했습니다. 큐와 상태 계약을 먼저 고정한 덕분에 오케스트레이터를 바꾸면서도 API와 사용자 화면은 그대로 유지할 수 있었습니다.
운영 명령도 아키텍처의 일부입니다
배포와 장애 대응 기준을 단일 VM 셸에서 Kubernetes 네임스페이스와 롤링 업데이트 중심으로 바꿨습니다. 구조가 달라졌다면 운영자의 기본 동작도 함께 달라져야 합니다.