2. Docker 빌드 자동화 (CI 파트)

이번 글에서는 CI 도구를 통해 소스 관리 하고 Pull Request 하게되면 어플리케이션을 도커로 빌드하고 자동화하는 과정을 다뤄볼 것이다.

CI 란 무엇인가, 목적/ 장점

CI(Continuous Integration)란?

CI는 개발자들의 변경 사항이 버그 테스트를 거쳐 Repository에 자동으로 업로드 되는 것을 뜻한다.

목적

버전 관리와 자동화된 build, test, reporting을 통해 최대한 빨리 오류를 발견하고 발생한 문제를 조기에 처리할 수 있다. 이로써 중간에 실수로 인해서 지체 되는 시간을 줄이고 문제를 최소화할 수 있다.

장점

빌드와 테스트 프로세스가 자동화 되어 코드 작성에 유리하다.
빌드와 테스트 환경을 독립적으로 구성할 수 잇다.
다른 개발자가 수정한 내용을 자동으로 빌드하고 통합 테스트를 진행할 수 있다.
자동화를 통해 수시로 통합하고, 문제를 조기에 발견하여 조치가 가능하다.

대표적인 도구

Jenkins
Travis CI
CircleCI
Github Action
Buddy works
Google Cloud Build

GitHub Action란?

GitHub Actions는 GitHub에서 제공하는 Workflow 자동화 도구이다. 이 도구는 Test, Build 뿐 만 아니라 다양한 작업을 만들어서 자동으로 실행할 수 있다. GitHub Actions는 Runner 위에서 실행이 되고, Runner는 가상 머신 위에서 실행이 된다. 아래는 GitHub Actions의 동작을 간략하게 보여주는 그림이다.

MLops에서 CI의 역할

DevOps와 MLOps 비교

DevOps와 MLOps는 비슷해 보이지만 크게 다른 부분이 있다. 바로 데이터이다. DevOps와 다르게 MLOps에는 Model 학습 과정이이 더해져 ML infrastructure test, model tests, Data tests, skew tests, data monitoring, system monitoring이 추가된다. 또한 머신러닝은 서비스 배포에서 끝나는 것이 아니라 실제 프로덕션 환경에서 유입되는 새로운 데이터에 대한 지속적인 학습이 필요하다. DevOps에는 없는 모델을 다루는 역할이 MLOps에서 추가 된 것이다.

MLOps에서의 CI의 역할

CI는 더 이상 코드와 구성 요소를 테스트하고 검증하는 데 그치지 않고 데이터, 데이터 스키마 및 모델 테스트와 검증 역할도 한다.

다음 다이어그램은 ML CI/CD 자동화 파이프라인의 단계를 보여준다.

이 과정 중에서 CI의 단계의 역할은 새 코드가 커밋되거나 소스 코드 저장소로 푸시될 때 빌드, 테스트, 패키징을 한다. 그리고 이 외에 다음과 같은 테스트가 포함 될 수 있다.

feature 추출 로직을 Unit Test 한다.
모델에 구현된 다양한 메서드를 Unit Test 한다. 예를 들어 범주형 데이터 열을 허용하는 함수가 있다면 이 함수를 One-hot feature로 인코딩한다.
모델 학습이 수렴하는지 테스트한다. (즉, 모델의 loss가 iterations을 돌며 과적합 인해 중단되는 지 테스트한다)
모델 학습에서 0으로 나누거나 작은 값 또는 큰 값을 조작하여 NaN 값을 생성하지 않는지 테스트한다.
파이프라인 구성요소 간의 통합을 테스트한다.

위에서 보면 알 수 있듯이 DevOps에서의 CI와 가장 큰 차이점은 모델 학습과 데이터를 다룬다는 점이다. 이런한 특성을 가지는 이유는 머신러닝의 특성상 학습의 파이프라인이 전체 프로젝트에서 차지하는 비중이 매우 높기 때문이다. 모델의 학습 과정과 데이터 전처리 과정이 통합된 환경에서 이루어 진다면 작업의 효율성을 극대화 시킬 수 있다.