CI/CD 파이프라인을 통한 모델 배포
CI/CD 기본 개념
CI(Continuous Integration)는 개발 과정에서 코드 변경 사항을 주기적으로 통합하는 것을 말하며, CD(Continuous Deployment 또는 Continuous Delivery)는 통합된 코드를 자동으로 테스트하고 배포하는 과정을 의미한다. 이러한 프로세스를 통해 소프트웨어 개발의 효율성을 높이고 오류 가능성을 줄일 수 있다.
머신러닝 모델 배포의 특징
머신 러닝 모델 배포는 전통적인 소프트웨어 배포와 달리, 모델의 성능 검증, 데이터 의존성 관리, 모델 버전 관리 등 여러 가지 특수한 과제를 포함한다. 이러한 것들을 일일이 관리하기에는 시간과 노력이 많이 소요되며, 종종 실수를 불러일으킬 수도 있기 때문에 이를 자동화하는 것은 현업에서 매우 중요하다.
CI/CD 파이프라인 구축
1. 깃허브 레포지토리 설정
머신러닝 프로젝트를 위한 깃허브 레포지토리를 설정하고, 모델 코드와 종속성 파일을 관리하는 단계이다. 깃헙 액션(GitHub Actions)을 통해서 코드 push가 이루어질 때마다(on으로 관리 가능) 자동으로 실행되도록 workflow를 작성할 수 있으며, 이는 .github 폴더 아래 workflow 디렉터리 내 yaml 파일로 관리된다. 이 두 개의 폴더명은 깃허브에서 지정한 special name이므로 지켜줘야 한다.
아래는 예시로, secerets로 관리되는 키들은 깃허브 설정에서 만들 수 있다.
name: Deploy Movie Recommendation to AWS ECS
on:
push:
branches:
- main
jobs:
deploy:
name: Deploy
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ${{ secrets.AWS_REGION }}
- name: Login to Amazon ECR
uses: aws-actions/amazon-ecr-login@v1
- name: Build, tag, and push image to Amazon ECR
env:
ECR_REGISTRY: ${{ secrets.ECR_REGISTRY }}
ECR_REPOSITORY: ${{ secrets.ECR_REPOSITORY }}
IMAGE_TAG: ${{ github.sha }}
run: |
docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG movie_recommendation_part1
docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
- name: Fill in the new image ID in the ECS task definition
id: task-def
uses: aws-actions/amazon-ecs-render-task-definition@v1
with:
task-definition: movie_recommendation_part1/deploy/task-definition.json
container-name: web
image: ${{ secrets.ECR_REGISTRY }}/${{ secrets.ECR_REPOSITORY }}:${{ github.sha }}
- name: Deploy Amazon ECS task definition
uses: aws-actions/amazon-ecs-deploy-task-definition@v1
with:
service: fast-campus-service-with-alb
cluster: fast-campus-cluster
task-definition: ${{ steps.task-def.outputs.task-definition }}
2. 자동 테스트 및 검증
모델 코드에 변경 사항이 발생할 때마다 자동으로 테스트를 실행하여 모델의 성능을 검증한다. 이를 통해 코드의 안정성을 보장하고 모델의 버전별 성능에 대한 추적을 자동으로 실행할 수 있게 된다.
3. 배포 자동화
테스트를 통과한 모델을 자동으로 운영 환경에 배포한다. 도커 컨테이너를 자동으로 빌드하고 서버를 설정하며 모니터링 도구(Prometheus, Grafana 등)를 설정하기도 한다.
롤링 업데이트 vs. 블루/그린 업데이트
롤링 업데이트
- 기존 인스턴스를 차례대로 새로운 버전으로 업데이트하는 방식
- 서버 집단의 일부만을 업그레이드하면서도 서비스를 지속할 수 있게 해 주어 점진적으로 변화를 적용할 수 있다는 장점을 가짐 (무중단 배포)
- 또한 한 번에 하나의 서버 혹은 서버 그룹을 업데이트하여 문제 발생 시 즉각 대응이 가능하며 전체 인프라를 복제할 필요가 없어 자원 사용이 효율적
- 그러나 업데이트 도중에는 구 버전과 신 버전의 모델이 동시에 운영될 수 있어 일관성이 떨어지는 경우가 발생하며 문제 발생 시 롤백이 복잡할 수 있다는 단점 또한 가짐
블루/그린 업데이트
- 배포를 위해 두 개의 동일한 환경을 준비하고 하나의 환경(블루)에서 운영 중인 동안 다른 환경(그린)에서 새 버전을 배포 및 테스트하는 방식
- 실제 트래픽을 사용하여 신 버전의 전체 테스트를 수행할 수 있고 문제가 발생 시 롤백이 간편하다는 장점을 가짐
- 그러나 두 개의 동일한 환경을 유지하기 위해 비용과 자원이 두 배로 소모되며 두 환경을 동시에 관리해야 하므로 운영의 복잡도가 증가할 수 있음
머신러닝 배포 시 유의점
- 데이터 및 예측 일관성: 모델이 업데이트되는 동안에도 예측 결과의 일관성을 유지해야 한다.
- 성능 모니터링: 새로운 모델의 성능을 지속적으로 모니터링하고 필요시 조정할 수 있어야 한다.
- 가용성 보장: 모든 사용자가 업데이트 도중에도 일관적인 서비스를 받을 수 있어야 한다.
이를 고려했을 때, 리소스 사용에 대한 제한이 존재하지 않는다면 블루/그린 방식이 더 유리하지 않을까 하는 생각..
댓글