1. 환경분리와 배포
1.1 현업의개발 프로세스
Local
- 각자의 컴퓨터에서 개발
- 각자의 환경을 통일시키기위해 Docker등을 사용
Dev
- Local에서 개발한 기능을 테스트 할 수 있는 환경
- Test서버
Staging
- Production환경에 배포하기 전에 운영하거나 보안,성능 측정하는 환경
- Staging서버
Production
- 실제서비스를 운영하는 환경
- 운영서버
1.2 CI/CD
서버에 코드를 보내는 것과
반복적으로 진행할 Test를 어떻게 실행하는 방법은?
Dev Branch에 Merge되면 => Local에서 Git Pull & Test실행 후 코드배포(FTP로 파일 전송)
CI(Continuous Integration) 지속적 통합
Continuous Integration,지속적통합
- 새롭게 작성한 코드변경 사항이Build,Test진행한후 TestCase에 통과했는지 확인
- 지속적으로 코드품질관리
- 10명의 개발자가 코드를 수정했다면 모두 CI프로세스진행
CD(Continuous Deploy/Delivery) 지속적배포
ContinuousDeploy/Delivery,지속적배포
- 작성한 코드가 항상 신뢰가능한 상태가 되면 자동으로 배포될 수 있도록 하는 과정
- CI이후 CD를진행
- dev/staging/main브랜치에 Merge가 될 경우 코드가 자동으로 서버에 배포
요약
- CI:빌드,테스트자동화
- CD:배포자동화
1.3 모델배포에서 주의할점
Docker 이미지
모델 버저닝(model versionig)
모델 버저닝은 머신러닝(ML) 또는 AI 모델을 개발하고 개선해 나가는 과정에서 각 시점의 모델을 관리하는 방법
모델 아티팩트
모델이미지에 저장하는것 보다S3,오브젝트저장소(S3,CloudStorage)에 저장하는것을 권장
- 모델버전과 아티팩트의버전이 다른경우도 있으므로 메타정보를 확인해야 함
예) 이를 해결하기 위해 나온 도구:MLflow - 적합한 파일 권한 관리(VM인스턴스,Object Storage둘 다)
- VM인스턴스에서 pth파일을 읽지 못한다면 정상 실행 불가능
- Objectstorage에서 다른사용자가 버킷을 삭제하면 롤백 불가능(삭제권한 제어 필요)
2. Github Action
Github에서 출시한 기능으로,소프트웨어 Workflow 자동화를 도와주는 도구
2.1 Github Action 소개
Github Action-Workflow예시
(1) Test Code
(2) 배포
(3) 파이썬,쉘스크립트실행
(4) Github Tag,Release 자동으로 설정
다양한 workflow templates
Action Marketplace:https://github.com/marketplace?type=actions
Awesome GithubAction:https://github.com/sdras/awesome-actions
Github Action이 작동하는 방식
1) 코드작업
2) 코드작업후,Github Action으로 무엇을 할 것인지 생각
3) 사용할 Workflow 정의
4) Workflow정의후 정상 작동하는지 확인
2.2 Github Action Core
Workflow
- 여러 Job으로 구성되고 Event로 Trigger(실행)되는 자동화된 Process
- 최상위 개념
- Workflow파일은 YAML으로 작성되고,Github Repository의
.github/workflows폴더에 저장
Event
- Workflow를 Trigger하는 특정활동,규칙
- 특정 Branch로 Push하는 경우
- 특정 Branch로 PullRequest하는 경우
- 특정 시간대에 반복(Cron)
Jobs
Runner에서 실행되는 Steps의 조합
여러 Job이 있는 경우 병렬로실행하며,순차적으로 실행할 수 도 있음
Steps
- Step은 Job에서 실행되는 개별작업
- Action을 실행하거나 쉘커맨드실행
-하나의 Job에선 데이터를 공유할 수 있음
Actions
- Workflow의 제일작은단위
- Job을 생성하기 위해 여러 Step을 묶은개념
- 재사용이 가능한 Component
- 개인적으로 Action을 만들 수도 있고,Marketplace의 Action을 사용할 수 도 있음
Runner
- GithubAction도 일종의 서버에서 실행되는 개념
- Workflow가 실행될서버
- Github-hostedRunner:GithubAction의 서버를 사용하는 방법
- 성능:vCPU2,Memory7GB,Storage14GB
- Self-hostedRunner:직접서버를 호스팅해서 사용하는 방법
2.3 Github Action Hello World!
Githu Repository새로 생성
Add file-Create new file
hello-world.py를 생성한후,Commit
Github Repository에서 Action클릭
Python application검색 후 Setup this workflow클릭
템플릿으로 파일이 생성 Test with pytest만 수정!
커밋한 후,노란색동그라미 클릭!
GithubAction이실행중!Details클릭
초록색으로 바뀌면Success를 의미
재실행하는기능
정의한Step
클릭시 로그를 확인 할 수 있음
on: Event,언제Workflow가실행될것인가?
jobs: jobs정의,build는job의이름!
runs-on: ubuntu환경에서실행
uses: 사용할GithubAction
name: Step의이름
uses없는경우: run에작성된쉘커맨드실행
3. 모델이미지준비하기
3.1 Dockerfile 만들기
FROM python:3.9
WORKDIR /code
COPY ./requirements.txt /code/requirements.txt
RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt
COPY src /code/app
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "80"]3.2 DockerImage Registry만들기
Docker Image Registry란?
- 수많은 도커 이미지들을 저장하는 저장소
사용할 서비스: GoogleCloud Artifact Registry
- 1) Google Cloud에서 Artifact Registry API사용 설정
- 2) gcloud CLI설치:https://cloud.google.com/sdk/docs/install?hl=ko#mac 공식문서참고
- 3) Docker설치
- 4) 인증설정:gcloud auth configure-docker asia-northeast3-docker.pkg.dev
Artifact Registry에 DockerImage Push하는 과정
- 1) Docker Image Build
- 2) 태그설정
- 3) 이미지 Push
3.3 DockerImage Build&Push
로컬에서 Docker Image Build(-t를통해 model_deploy:test로 설정)
docker tag “기존이미지:태그” “새이미지이름:태그”
docker push “Artifact Registry/프로젝트/Repository/이미지이름:버전”
웹 콘솔에서 확인하면 Repository에 올라간 것을 확인할 수 있음
3.4 DockerImage Build&Push자동화
Github Action을 통해서 특정 조건에 Docker Image Build,Push자동화
ex)
main에 머지되면 DockerImage 새로 만들고,Registry에 Push
위작업을 하기위해 GoogleCloud Service Account설정
SHA(hash)값을 태그값으로 설정해서 매 커밋마다 이름이 겹치지 않도록
새로운 이미지 Build+Push
4. 배포하기
4.1 GoogleCloud Platform Compute Engine 세팅하기
4.2 VM Instance에 새이미지 배포하기
인스턴스를 띄울 때 DockerImage 기반으로 생성하면,이후 나온 Image를 기반으로 Container 업데이트가 가능
ComputeEngine는 이미지로 만들어진 인스턴스를 빠르게 업데이트 할 수 있는 기능을 CLI로 제공 gcloud compute instance supdate-container<서버이름>—container-image<컨테이너이미지>
4.3 배포 파이프라인 자동화
CI(ContinuousIntegration)을진행한후, GCE VMInstance에 변경사항 전파
needs필드를 통해 ci작업이 정상완료되어야 실행
업데이트 할인스턴스,존(영역)정보를 사용해 해당 인스턴스 업데이트
Github Action(Actions)에서 확인하면 ci가 완료된 후 cd가 실행
5. 참고사항
MLops
https://ml-ops.org/content/mlops-principles#automation
