본 문서는 Backend.AI 오픈소스 프로젝트 오프라인 미팅 내용을 리뷰한 내용입니다. (현재 작성중인 문서입니다.)

---

Backend.AI 저장소의 변화

• 구글 "소프트웨어 유지보수 주기가 5년을 넘어가면 히스토리, 외부 의존성을 관리하기 어렵다"
• 동일한 고민으로 meta-repository + 여러 하위 컴포넌트 저장소에서 mono-repository로 전환
• mono-repository를 편리하게 구성할 수 있도록 pants라는 도구를 사용

컴포넌트 소개

Manager

• API 서버 역할, 사용자 DB 관리, 스케쥴러, 사용자가 연산 세션을 요청하면 DB에 기록 후 판단해서 실행 가능한 agent를 선택하여 실행하는 등의 역할을 한다.
• 특정 Agent에 컨테이너를 띄우라는 명령은 RPC로 이루어진다.

Agent

• 각 연산 노드에 설치되어 실행되며, 연산노드를 관리하는 데몬이다.
• 연산 노드의 CPU, GPU, Memory 등의 상태 및 컨테이너 등의 이벤트를 인식하고 manager에 Redis를 통해 전달한다.
• Agent들이 Redis의 stream API를 통해 Redis stream에 메세지를 전달하고 Manager가 받아서 처리한다.

Web UI

• mono-repository에 포함되지 않았다.
• src/ai/backend/webui에서 npm run server:d 라는 명령어로 구동할 수 있다.
• Web UI가 Webserver를 바라보도록 설정해야 한다. (이 부분도 자동화 되어 있음)

Webserver

• Manager는 쿠키 등의 기능이 없으며 API Key를 HTTP Header에 삽입하여 인증을 한다.
• User ID 기반의 로그인을 지원하기 위해 Webserver를 Manager 앞 단에 둔다.
• 여기서 single-page application 형태로 서빙을 한다.
• API 요청을 그대로 translate해서 User ID와 Password로 로그인 하여 웹 쿠키 세션을 만들고 그 세션과 연결된 사용자 인증키를 통해 Manager가 이해할 수 있는 형태의 인증헤더를 붙여 보내준다.

Client SDK

• docker 명령어와 유사한 형태로 CLI에서 실행하는 인터페이스이다.

데이터베이스

• etcd, Postgres, Redis 3가지의 DB를 실행해야 컴포넌트간 통신이 가능하다.

버전관리 방법

• 연.월.버전 방식을 사용한다.
• YY.0M.micro 방식의 CalVer 형식을 따르고 있다.

OS 권장사항

• 우분투 환경을 권장한다.
• 복잡한 이유가 있다. (영상 참조)

컨트리뷰션

• git 관리의 핵심은 branch이다.
• upstream과 origin과 local
  • upstream(원본) 저장소를 fork한 것이 origin 저장소
  • origin을 clone하여 local에 다운로드 받은 것이 local 저장소
• upstream은 계속 변경이 일어나므로 origin에 main branch에 직접 push하는 경우 문제가 생길 수 있다.
• PR을 main에서 main으로 날리면 기존 base가 되는 branch를 찾을 수 없다.
• fork 후 새로운 branch를 만들어서 작업을 해야 한다.
• PR을 작업 중에 upstream의 main에 업데이트가 되면, 먼저 upstream을 fetch하고, 나의 local main에서 upstream main을 fast-forward로 merge(branch point 이동)하고, 이것을 다시 origin main에 push를 하면 main branch가 동기화 될 수 있다. 이럴 때는 merge conflict가 일어나지 않는다.
• main branch에 작업을 하게 되면 위와 같은 처리가 불가능하고 매번 merge가 일어나면서 히스토리가 지저분해진다.

PR 작성

• branch 네이밍
  • fix/, feature/, docs/, refactor/ 같은 prefix를 사용한다.
• 커밋 메세지
  • conventional commit style을 따른다. 브랜치 이름과 마찬가지로 fix:, refactor:, docs:, release:와 같은 접두어를 사용한다.
• 이슈 발견시 이슈(bug report, new feature)를 먼저 생성한다.
• 이슈 수정 후, PR을 생성한다.
  • PR 생성시 발생하는 번호에 대한 파일(572.fix.md)을 changes 폴더 안에 생성해야 한다.