모델과 코드 배포

seung·2025년 1월 3일
Product Servinggit-hub

Product Serving

목록 보기
7/8

현업에서의 개발 프로세스

  • Local
    각자의 컴퓨터에서 개발한다.
    각자의 환경을 통일 시키기 위해 Docker, poetry등을 사용한다.

  • Dev
    개발 환경인데 local에서 개발한 기능을 테스트 하는 환경이다.
    test 서버를 띄우고 개발한다.

  • Staging
    Production 환경에 배포하기 전에 운영하거나 보안 성능 축적하는 환경

  • Production
    실제 서비스를 운영하는 환경(운영 서버)

개발 환경을 나누는 이유는 실제 운영중인 서비스에서 장애가 나면 안되기 때문에 환경을 나누어 개발하게 된다.
Dev = Staging= Production인 경우 소스 코드를 저장 하면 바로 반영되기 때문에 조심해야 한다.

개인 프로젝트 시에는 서버 비용이 많이 들기 때문에 Local에서 개발 후에 바로 main으로 가는 과정을 거치기도 한다.

현업 개발 git flow

[main] < - [staging] < - [Dev] < - [feature / 기능, 이름]

feature에서 완성하면 Dev에서 pull request를 하고 Dev에서 review를 하는 단계를 거친다.

개발 프로세스를 위와 같이 구성하게 되는데 (staging이 없을 수도 있다.)

main 은 production server와 연결되고
staging은 staging server, dev는 dev server, feature는 대부분 local에서 개발하게 된다.

dev brench에서 feature를 merge하게 되면
로컬(dev server)에서 git pull & 코드 베포를 수동적으로 해줘야된다. (FTP or SCP)
굉장히 번거로운 일이다.. 한번에 자동적으로 되겠끔 할 수 없을까?

CI/CD

Continuous Integration, 지속적 통합

  • 새롭게 작성한 코드 변경 사항이 Build, Test 진행한 후 Test Case에 통과 했는지 확인
  • 지속적으로 코드 품질 관리
  • 10명의 개발자가 코드를 수정했다면 모두 CI 프로세스 진행

Continuous Deploy/Delivery, 지속적 배포

  • 작성한 코드가 항상 신뢰 가능한 상태가 되면 자동으로 배포될 수 있도록 하는 과정
  • CI 이후 CD를 진행
  • dev/staging/main 브랜치에 Merge가 될 경우 코드가 자동으로 서버에 배포

큰 개념으로 CI는 빌드, 테스트 자동화이고, CD는 배포 자동화이다!

모델 배포시 주의할점

  1. Docker 이미지

    • 사이즈가 보통 큰 편이라서 관리가 필요하다.
    • 호스트 머신의 디스크 용량 관리가 필요하다.
    • (로그를 주기적으로 삭제하거나 클라우드로 보내기)

  2. 모델 버저닝

    • 어떤 버전의 모델이 현재 배포 중이고, 과거에는 어떤 버전으로 배포 되었는지
    • 롤백이 필요하다면 어떤 버전으로 재배포해야 하는지
    • 모델의 버전 별 특징을 쉽게 볼 수 있어야 한다.

  3. 모델 아티팩트(모델의 핵심 결과물)

    • 모델 이미지에 저장하는 것보다 S3,오브젝트저장소
      (S3,CloudStorage)에 저장 하는 것을 권장
    • 모델 버전과 아티팩트의 버전이 다른 경우도 있기 때문에 메타 정보 를 잘 확인해야 한다.(이때 MLflow 활용)
    • 적합한 파일 권한 관리 (VM 인스턴스, Object Storage 둘 다)

Github action

배포하는 과정에서 사용되는 github action에 대해 알아보자
회사에서도, 개인 개발에서도 사용될 수 있다!

github action은 소프트웨어 workflow 자동화를 도와주는 기구이다.

workflow 사용 예시)
1. Test code
특정 함수의 return값이 어떻게 나오는지 확인하는 test code
Unit Test, End to End Test

  1. 배포
    Prod, Staging, Dev 서버에 코드 배포 (파일을 서버에 보내는 일)
    FTP로 파일 전송할 수도 있고, Docker Image를 Push하는 방법 등
    Node.js등 다양한 언어 배포도 지원

  2. 파이썬, 쉘 스크립트 진행
    github repo에 저장된 스크립트를 일정 주기를 가지고 진행할 수 있다.

  3. Github Tag, Release 자동으로 설정
    ex) Main 브랜치에 Merge될 경우에 특정 작업 실행,
    기존 버전에서 버전 Up 하기

이렇게 다양한 workflow를 이용할 수 있고 사용자가 만들어서 workflow 템플릿을 공유하기도 한다.

public repo : 무료
private repo : 조건부 무료

github action도 제약 조건이 있다.

github action 사용하는 방식

1) 코드 작업
2) 코드 작업 후,GithubAction으로무엇을할것인지생각
3) 사용할 Workflow 정의
4) Workflow 정의 후 정상 작동하는지 확인

Github Action Core

Workflow

최상위 개념으로
여러 Job으로 구성되고 Event로 Trigger(실행)되는 자동화된 Process이다.

Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows폴더에저장

Event

Workflow를 Trigger하는 특정 활동, 규칙

jobs

Runner에서 실행되는 Steps의 조합
여러 Job이 있는 경우 병렬로 실행하며, 순차적으로 실행할 수도 있음

  • 다른 Job에 의존관계를 가질수도 있다.

steps

Step은 Job에서 실행 되는 개별 작업(하나의 Job에선 데이터를 공유할 수 있다.)
Action을 실행하거나 쉘 커맨드 실행

actions

Workflow의 제일 작은 단위
Actions는 워크플로(Workflow)에서 하나의 단계(Step)를 수행합니다.
재사용이 가능하고 , 개인적으로 action을 만들수도 있고, marketplace의 action을 사용할 수 있다.

Runner

Github Action도 일종의 서버에서 실행되는 개념이어서
workflow가 실행되는 서버를 의미한다.

github-hosted server : github action의 서버를 사용하는 방법
self-hosted server : 직접 서버를 호스팅해서 사용하는 방법

github action 실습

  1. github repository 생성 및 파일 생성
    레포지토리를 생성한 후
    새로운 파일 hello-world.py를 생성한 후, Commit

  2. github repository에서 action 클릭 및 workflow 클릭
    Python application 검색 후 Setup this workflow클릭

  3. 템플릿으로 파일이 생성되면 test 쪽을 수정해보기
    Test with pytest에서 run에 python hello-world.py로 수정

  4. 실행되는지 확인
    노란색 동그라미 표시가 뜨면 실행중인것이고, 초록색으로 바뀌면 작업이 성공적으로 끝난것을 의미한다.

재실행하는 기능을 이용해 재실행 할수도 있다.

yaml 파일 분석

  • ON : Event, 언제 Workflow가 실행될 것인가?
  • jobs : jobs 정의, build는 job의 이름!
  • runs-on : ubuntu 환경에서 실행
  • uses : 사용할 Github Action
  • name : Step의 이름
  • uses 없는 경우 : run에 작성된 쉘 커맨드 실행

모델 이미지 준비

  1. docker file 생성
    사전준비
    -서빙할모델코드
    -OnlineServing을위한APIEndpoint정의코드
    -컨테이너화를위한의존성정의(requirements.txt)

  2. docker image repository 만들기

    Docker Image Registry란?
    수많은 도커 이미지들을 저장하는 저장소
    자체적으로 이미지의 이름과 버전 등을 저장하고 불러옴

    Docker 공식 저장소(예:Dockerhub)
    또는 클라우드의 저장소를 사용

    예를 들어 Google Cloud Artifact Registry를 사용한다고 하면

    Artifact Registry에 Docker Image Push하는 과정
    -1) Docker Image Build
    -2) 태그 설정
    -3) 이미지 Push

  1. Docker Image Build & Push
    로컬에서 Docker Image Build (-t를 통해 model_deploy : test로 설정)
    docker tag “기존이미지:태그”“새이미지이름:태그”
    docker push “ArtifactRegistry/프로젝트/Repository/이미지이름:버전”

    이후 웹 콘솔에서 확인하면 레포지토리에 올라간것을 확인할 수 있다.

    올라간 이미지를 pull하고 싶다면
    docker pull asia-northeast3-docker.pkg.dev/boostcamp-ai-tech-serving/model-deploy/v1:latest

  2. Docker Image Build & Push 자동화
    Github Action을 통해서 특정 조건에 Docker Image Build, Push 자동화

예시:
main에 머지 되면 Docker Image 새로 만들고, Registry에 Push

위 작업을 하기 위해 Google Cloud Service Account 설정

  • SHA(hash)값을 태그값으로
    설정해서 매 커밋마다 이름이 겹치지 않도록
    새로운 이미지 Build+Push

배포하기

배포하는 방법을 학습해보겠다.
Google Cloud Platform을 이용하여 해볼것이다.

GCP computer engine 세팅하기

인스턴스 생성하기
이름은 자유롭게 생성하고, 지역은 서울로 한다.

생성이 완료되면 ip 주소를 확인할 수 있다.

VM Instance에 새 이미지 배포하기

새롭게 생성한 인스턴스에서 업데이트를 어떻게 할까?

방법은 간단하다.

인스턴스를 띄울 때 Docker Image기반으로 생성하면, 이후 나온 Image를 기반으로 Container 업데이트가 가능하다.
(몰론 클라우드마다 기능이 다르지만 이미지가 바뀌면 새롭게 업데이트하는 기능이 존재한다.)

만약 docker기반이 아니라 그냥 띄운다면 새로운 코드를 pull하고 재실행하는 과정을 거쳐주어야 된다.

computer engine에서는 이미지로 만들어진 인스턴스를 더 빠르게 업데이트 할 수 있는 기능을 CLI로 제공한다.

배포 파이프라인 자동화

앞에 CI 작업이 있다면 CI가 진행된 후에 VM instance에 변경 사항을 전파해야 한다.

needs라는 필드를 통해 ci 작업이 정상완료 되어야 실행되도록 설정
그리고 업데이트 할 인스턴스, 존(영역)정보를 사용해 해당 인스턴스 업데이트를 한다.

다 저장하고 merge하고 나서 github action에서 확인하면 ci가 완료된후에 cd가 실행되는 것을 알 수 있다.

profile
seung
이전 포스트

클라우드 서비스

다음 포스트

모델관리(with MLflow) 및 평가

0개의 댓글