INCL의 구성

실험은 어떻게 돌아가나

INCL은 클라이언트, 백엔드, 작업 인스턴스 세 덩어리로 되어 있다. 클라이언트로 실험을 제출하고 추적하고, 백엔드는 요청을 처리하고 자원을 관리하고, 작업 인스턴스는 VM에서 실험을 실제로 돌린다. 여기서 "실험"과 "작업"은 같은 말이고, 모델 학습뿐 아니라 추론이나 스크립트 실행도 포함한다.

실험 하나가 실행되는 흐름

1. 작업 요청. 사용자가 스크립트와 필요한 자원을 정해서 백엔드로 보낸다.
2. 코드 업로드. 작업 디렉터리가 객체 스토리지로 동기화된다.
3. VM 프로비저닝. 백엔드가 요구 자원에 맞는 VM을 만들고 환경을 준비한다.
4. 코드 다운로드. VM이 객체 스토리지의 코드를 블록 스토리지로 복사한다.
5. 모델 학습, 추론. VM이 작업을 돌리고, 학습 데이터는 파일 스토리지(NFS)에서 읽는다.
6. 결과 동기화. 체크포인트와 출력을 객체 스토리지에 올린다.
7. 종료 보고. VM이 끝났다고 알리고 바로 자원을 반납한다.

구성요소

클라이언트

• CLI. Python Click 기반이라 터미널에서 쓰기 좋고 자동화하기도 편하다.
• 웹 UI. React, MobX, Material UI로 만들었고 실시간 그래프를 보여 준다.

클라이언트와 백엔드 사이

클라이언트는 REST API로 작업 제출, 상태 조회, 모델 관리 요청을 보낸다. API 서버는 객체 스토리지와 관계형 DB에 붙어 있고, 로깅 서버는 로그와 메트릭을 NoSQL DB에 저장한다.

백엔드

Kubernetes 클러스터 위에서 돌고, 이렇게 나뉜다.

• API 서버 (Django REST). 인증, 메타데이터 저장, 아티팩트 제공.
• 스케줄러. 작업 큐를 관리하고, 전체 할당량과 사용자별 할당량을 적용하고, 온디맨드와 스팟 중 뭘 쓸지 고른다.
• 작업 실행기 (Celery). VM 생성, 코드 복사, 의존성 설치, 오류 처리.
• 로깅 서버 (Gin). 동시에 쏟아지는 로그와 메트릭 수집.

API 서버, 스케줄러, 실행기, 작업 인스턴스 사이의 흐름

API 서버가 작업을 큐에 넣으면 스케줄러가 자원을 확인해서 실행기에 넘기고, 실행기가 VM에서 작업을 돌린다. 끝나면 VM이 실행기에 종료를 알리고 자원을 돌려준다. 중지 요청은 API 서버 → 실행기 → VM 순서로 전달된다.

실험의 수명주기

Gin 로깅 서버는 초당 수천 건의 로그와 메트릭을 받아서 실시간 모니터링을 받쳐 준다. 로깅을 따로 떼어 내서 API 서버 부담을 줄이고 확장성도 높였다.

작업 인스턴스

VM 안에는 작업 실행기, INCL Python SDK, 로그와 메트릭 수집기가 들어 있다. SDK로 구성, 메트릭, 아티팩트를 코드 몇 줄로 기록할 수 있다. 그리고 GPU 사용률이 기준치 아래로 떨어지면 VM이 알아서 꺼져서 돈이 새지 않는다.

스토리지는 용도별로

그래서 이렇게 나눠 쓴다

코드는 실행 전에 블록 스토리지로 복사해서 I/O 병목을 없애고, 작업이 끝나면 결과를 객체 스토리지로 옮겨서 비용을 아낀다. 학습 데이터는 파일 스토리지에 두고 여러 VM이 동시에 읽는다.