머신러닝용 CI/CD란 무엇일까?
대부분의 사람들은 전통적인 소프트웨어에서의 CI/CD에 익숙합니다. 그렇다면 머신러닝에서는 어떻게 작동할까요? 알아두어야 할 핵심을 정리했습니다. 이 글은 AI 번역본입니다. 오역이 의심되는 부분이 있으면 댓글로 알려주세요.
Created on September 12|Last edited on September 12
Comment
소개 및 동기
전통적인 소프트웨어 개발에서는 CI/CD 테스트, 빌드, 소프트웨어 배포를 포함한 많은 작업을 자동화합니다. 전통적인 소프트웨어 환경에서는 코드 변경이 CI/CD를 촉발하는 경우가 많습니다. 예를 들어, 코드를 변경하기 위해 풀 리퀘스트를 만들면 다음과 같은 도구가 GitHub Actions 테스트, 빌드, 코드 배포를 자동화할 수 있습니다. 이러한 패턴은 일반적으로 GitOps라고 부릅니다.
하지만 ML을 위한 CI/CD는 다릅니다. 코드 변경 외에도 새 데이터나 라벨의 유입, 모델 또는 데이터의 드리프트, 고정 주기(예: 일간/주간 모델 재학습) 등 다양한 이벤트가 ML의 테스트와 배포를 촉발할 수 있습니다.
��스트와 배포뿐 아니라, ML에서는 가시성 확보와 로깅 요구사항도 본질적으로 다릅니다. 실험 추적과 모델 모니터링 같은 도구가 이러한 고유한 관측 가능성 요구를 해결합니다.
마지막으로, 전통적인 소프트웨어에서는 코드만 버전 관리해도 충분한 경우가 많지만, ML 시스템에서는 데이터셋과 모델처럼 ML과 연관된 아티팩트까지 버전 관리하는 것이 큰 이점을 제공합니다. 따라서 ML의 CI/CD를 원활히 구현하려면 GitOps와는 성격이 다른 접근법에 의존해야 합니다.
작성 시점 기준으로, ML을 위한 엔드투엔드 CI/CD를 단독으로 지원하는 단일 도구는 없습니다. ML의 테스트, 빌드, 배포 과정은 통합된 CI/CD 시스템을 만들기 위해 여러 도구와 글루 코드가 조화를 이루어야 합니다.
게다가 시장에는 도구가 너무나도 다양하게 존재해 선택 마비에 빠지기 쉽습니다. 이들 중 상당수는 모델 개발 라이프사이클에서 매우 제한된 문제를 자동화하거나 해결하는 포인트 솔루션입니다. 아래에는 ML을 위한 CI/CD를 구현할 때 사람들이 사용할 수 있는 여러 범주와 도구를 보여 주는, 널리 알려진 인포그래픽이 있습니다. 이 인포그래픽은 인기 있는 도구들을 분류하고 정리하려는 성실한 시도였지만, 동시에 ML 인프라가 얼마나 범위가 방대하고 단편화되어 있는지, 그 부조리함을 드러내기도 합니다.
참고:
또 한 가지 알려 드릴 점은, 이 보고서에서 다룬 개념들을 새로 출시한 과정인 ‘CI/CD for ML’에서 훨씬 더 깊이 있게 다룰 예정이라는 것입니다. 완전히 무료로 등록할 수 있으니, 꼭 한번 확인해 보세요:
전통적 소프트웨어 엔지니어링과의 비교
이런 이유로 ML에서 CI/CD가 무엇을 의미하는지에 대해 혼란이 많습니다. 사실 만능 해법은 존재하지 않습니다. 나아가, CI/CD라는 용어 자체는 잠시 잊고 CI/CD의 목표에 집중할 것을 권합니다. 아래 표는 이러한 목표 일부와 그것이 전통적 소프트웨어 개발과 ML에 각각 어떤 함의를 갖는지 정리한 것입니다.
| Goal | Traditional Software | Machine Learning |
|---|---|---|
| Update and ship software incrementally and frequently, by using collaboration tools for reviewing, versioning, and integrating changes. | This is often focused on code, for example versioning, reviewing, and integrating code changes through tools like GitHub and GitLab. | In addition to code, you also need to collaborate through reports, analysis, and sharing of experimental data. In addition to code, artifacts like data and models need to be versioned and tracked. Because there are many artifacts, tracking the relationships and lineage between them is important. |
| Automated testing of software, both pre and post deployment | Pre-deployment tests are triggered by changes to code. Post-deployment may happen with canary deployments or other kinds of phased rollouts. | Tests can be triggered by events in addition to code changes, such as new data or labels, drift in model(s) or data, fixed cadence (daily/weekly model re-training). There is a blurry line between pre and post-deployment as different versions of models can be tested in production. |
| Automated and reproducible packaging of your software to your dev, test, and production environment | Container technologies are often used to create reproducible builds | Also uses container technologies, but ML can have special hardware requirements (GPUs for example) and compute can be very spiky. Furthermore, developers of ML systems may not be familiar with container technologies, and use different tools than traditional software. |
| Observability into the status of your dev, test, build, and deployment pipelines. | Dev, test, and build automation is often co-located with code collaboration and versioning tools, such as GitHub and Gitlab. This means observability into the status of those pipelines tends to be in tools like GitHub and Gitlab. | In addition to runtime observability, you want observability and tracking of your experiments. Because your dev, test, and build pipelines can be triggered by events other than code changes, you want to view the status of these pipelines outside GitHub/GitLab. |
위 표는 모든 내용을 망라하려는 것이 아니라, 전통적 소프트웨어와 ML CI/CD 사이의 핵심 차이를 보여 주기 위한 것입니다.
사례 연구: 전자상거래 추천 시스템
현실적인 프로덕션 시스템과 유사한 CI/CD 시스템의 훌륭한 엔드 투 엔드 사례로는 Jacopo Tagliabue의 레퍼런스 프로젝트 “더 큰 배는 필요하지 않다(YDNBB). YDNBB��� 온라인 리테일 추천 시스템을 운영 환경에 올리기 위한 풀스택 구성을 보여 주며, 합리적인 수준의 CI/CD를 달성합니다.
아래에는 이 시나리오에서 CI/CD를 원활히 하기 위해 이러한 도구들이 어떻게 사용되는지에 대한 설명이 있습니다:
아래에는 이 시나리오에서 CI/CD를 원활히 하기 위해 이러한 도구들이 어떻게 사용되는지에 대한 설명이 있습니다:
- Great Expectations (GE) 데이터의 유효성을 테스트하는 데 사용됩니다. GE는 통계적 테스트와 스키마 검증을 포함해 데이터에 대한 단위 테스트를 작성할 수 있도록 해줍니다.
- Metaflow 은 머신러닝 작업을 위한 워크플로와 오케스트레이션 시스템입니다. Metaflow는 재현성, 환경 격리, 확장, 테스트, 아티팩트 저장, 그리고 모델 학습을 위한 컴퓨팅 오케스트레이션을 지원합니다.
CI/CD 트리거
YDNBB에서 소개한 아키텍처는 머신러닝 모델의 지속적 통합(CI)과 지속적 배포(CD)을 프로덕션에 구현할 수 있게 합니다. 아래는 CI/CD가 어떻게 트리거될 수 있는지에 대한 상세 개요입니다.
1) 새 데이터가 데이터베이스에 도착한다
- 새 데이터가 도착하면 Prefect가 자동으로 트리거되어 dbt로 변환을 수행하고 GE로 데이터를 테스트합니다.
- 테스트를 통과하면 Metaflow가 모델을 재학습합니다. 학습 실행 중의 지표는 W&B에 기록됩니다. 관련 모델 아티팩트는 버전이 관리되어 Metaflow의 아티팩트 스토어에 저장됩니다.
- 후보 모델은 Metaflow에서 다음과 같이 테스트됩니다:
- 모델이 기준선을 특정 임계값 이상으로 능가하도록 보장하기
- 모델이 잘 알려진 또는 쉬운 예시를 특정 임계값 내에서 정확히 예측하도록 보장하기.
- 지연 시간 등 운영 요구 사항은 프로그램적으로 테스트됩니다.
- 모델이 이러한 테스트를 통과한 경우에만 해당 실행에 Metaflow에서 배포 후보 태그가 지정됩니다.
- 이후 Metaflow가 AWS SageMaker를 트리거하여 모델을 가져오고 REST API 엔드포인트를 통해 서빙합니다.
- 선택적으로, 전체 트래픽의 일부만 처리하는 카나리 모델을 사용할 수도 있습니다. 그러나 YDNBB에서는 단순화를 위해 최적의 모델을 배포합니다.
- Gantry는 운영 환경에서 모델이 어떻게 동작하는지에 대한 통찰과 진단을 제공하는 관측 레이어를 제공합니다.
2) 운영 환경에서 모델 성능이 저하되기 시작함
- Gantry가 모델 성능이 매우 저조하다고 팀에 알립니다. 자동화는 SageMaker에 Metaflow 아티팩트에서 기준선 모델로 롤백하도록 지시합니다.
- ML 엔지니어들은 회귀 문제를 조사하고 오류 분석을 수행하기 위해 다양한 애드혹 실험을 진행합니다. 많은 실험과 분석이 이루어지며, 이는 W&B를 통해 추적되고 공유됩니다.
- 이후 W&B를 통한 동료 검토 프로세스를 통해 새로운 배포 후보를 선정할 수 있습니다.
- 선정된 최종 실험은 W&B에서 Metaflow로 승격되며, 그곳에서 최종 운영 실행이 수행되고 결과는 W&B와의 일관성 여부가 자동으로 검증됩니다.
- 모델 배포 프로세스는 첫 번째 예시와 동일한 방식으로 계속 진행됩니다.
3) 누군가 모델 관련 코드를 변경함
- 누군가 모델의 하이퍼파라미터나 데이터 처리 파이프라인을 변경하는 풀 리퀘스트를 엽니다.
- GitOps(예: GitHub Actions)은 다음과 같은 방식으로 모델 성능 정보를 풀 리퀘스트에 가져오는 데 사용할 수 있습니다:
- Metaflow을 사용해 자체 인프라에서 전체 모델 학습을 트리거하고, 메트릭은 W&B에 기록합니다.
- GitOps를 사용해 W&B와 Metaflow 실행에서 요약 메트릭을 가져와 PR에 표시합니다. 이는 모델 변경 사항의 영향에 대한 투명성을 제공하여 코드 리뷰를 원활하게 합니다.
- GitOps는 모델 평가를 촉진하고 시나리오 #1에서 해당하는 모델 배포 단계를 트리거할 수 있습니다. ChatOps를 사용해 다음 배포 단계를 트리거할 수도 있습니다.
모델의 재배포를 트리거하는 다른 이벤트가 있을 수도 있습니다. 그러나 위에 언급한 이벤트들만으로도 ML을 위한 CI/CD가 어떤 종류의 자동화를 가능하게 하는지 구체적인 그림을 제시할 것입니다.
YDDNB에서 다루지 않은 MLOps 기능
YDNBB는 ML CI/CD의 매우 타당한 예시이지만, YDNBB에서 소개한 도구들과 관련된 기능들 중에는 추가적인 자동화를 촉진할 수 있는 것들이 있습니다. 아래에 몇 가지를 나열합니다:
모델 레지스트리
이를 통해 모델의 버전 관리와 계보 추적이 가능해집니다. 모델 레지스트리는 어떤 모델이 프로덕션 준비가 되었는지에 대한 가시성을 제공하고, 모델을 버전 관리하는 편리한 방법을 제공합니다.
모델 레지스트리는 모델이 연결된 실험 실행의 계보를 추적할 수 있게 해주며, 배포와 관련된 모델 아티팩트에 메타데이터를 연계할 수 있도록 합니다. 예를 들어, 모델 레지스트리의 태깅과 버저닝을 활용해 다음과 같은 용도로 모델을 추적할 수 있습니다 블루/그린 배포(참고: 블루/그린 배포는 프로덕션 소프트웨어를 점진적으로 배포하는 널리 사용되는 방식으로, 모델에도 적용할 수 있습니다). W&B Models는 그런 접근 방식 중 하나입니다.
프로그래매틱 리포트
머신러닝 프로젝트에서는 표준화된 시각화와 진단 항목 세트를 갖추는 것이 유용할 수 있습니다. CI/CD 관점에서는 가능한 한 리포트 생성을 자동화해야 합니다.
이러한 리포트에 대한 참조는 모델 검토 및 배포 워크플로에 통합할 수 있습니다. 예를 들어, 워크플로, 트래킹 시스템, 프로덕션 시스템에 리포트 링크를 자동으로 포함해 모델 검토를 더 쉽게 만들 수 있습니다. 다음과 같은 기능은 W&B를 활용한 프로그래매틱 리포트 (파이썬 SDK 탭 참조) 또는 Metaflow의 노트북 카드 이를 용이하게 할 수 있습니다.
연동
도구가 매우 많기 때문에, 도구 간 경계를 넘어 프로젝트나 워크플로의 계보를 추적하는 것이 유용합니다. 예를 들어 YDNBB에서는 모델 실행을 Metaflow가 오케스트레이션하고, W&B로 추적합니다. 이러한 도구 중 다수는 탁월한 연동예를 들어, Metaflow와 W&B 간의 이 연동 교차 플랫폼 통합과 연계를 그 어느 때보다 쉽게 만들어 줍니다.
겹치는 기능
YDNBB에서 소개된 많은 도구는 기능의 일부만 사용합니다. 예를 들어, Weights & Biases와 Metaflow는 아티팩트 저장소와 지표 보고·추적 도구를 제공합니다. 이러한 기능의 세부 사항은 각 플랫폼마다 매우 다르므로, 여러분의 환경에 가장 적합한 것을 선택해야 합니다. 이와 같은 기능 겹침은 발전 중인 ML 및 데이터 도구 생태계에서 불가피합니다. 더 나아가, 이러한 도구들의 기능 세트는 빠르게 변화하고 확장되고 있습니다.
YDNBB 모델을 따를 때, 일부 기능이 서로 겹치더라도 각 분야에서 최고 수준의 기능을 가진 도구를 선택하는 것은 타당합니다. 또한 도구를 신중하게 고르는 것은 필수적입니다. 이 발표에서, 제가 커리어 전반에 걸쳐 도구를 선택할 때 사용해 온 몇 가지 팁과 가이드라인을 공유했습니다:
결론
머신러닝을 위한 CI/CD에는 만능 해법이 없습니다. 전통적인 소프트웨어 엔지니어링과 마찬가지로, ML에서의 CI/CD 목표는 가능한 한 테스트, 빌드, 배포를 자동화하여 엔지니어링 속도를 높이는 것입니다.
ML을 위한 CI/CD에 대해 더 알아보고 싶으신가요? 새로운 ML을 위한 CI/CD 강좌에 함께하세요링크를 클릭하면 강의 계획서와 학습 목표에 대해 더 자세히 알아볼 수 있습니다.
Add a comment