서론
블로그 포스트의 목표 및 주제 소개
요즘 cicd 업무가 많아지고 있다.. cicd 는 절대적으로 팀내 문화적 지정과 ci와 cd 간의 그 간격, 그리고 ct에 대한 정리도 필요하기때문에 이번에 우아한기술블로그에 AI 서비스와 MLOps 도입기도 재밌게 읽은 기념으로 구글 클라우드 도큐먼트에서 데이터, mlops와 data 관련된 CICD 찾아보기 글을 진행해보려한다.
CI/CD?
일단 들어가기 전에 CICD 가 뭔지부턴 알아야하는데,
redhat 문서에 따르면, CI/CD (Continuous Integration/Continuous Delivery)는 애플리케이션 개발단계를 자동화하여 애플리케이션을 더욱 짧은 주기로 고객에게 제공하는 방법이다.
- CI/CD의 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미하는데,
- 지속적인 통합이 제대로 구현되면 애플리케이션 코드의 새로운 변경 사항이 정기적으로 빌드 및 테스트를 거쳐 공유 리포지토리에 병합된다.
- 따라서 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌하는 문제를 이 방법으로 해결할 수 있다.
- 즉, 빌드 , 테스트가 주이다.
- CI/CD의 "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환하여 사용된다. 두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.
여러 같은 축약어 다른 의미(CD, CT)
- CD(Continuous Delivery , Continous Deployment)
- 이번 찾아보기를 진행하면서 흥미로웠던 점은 CD 가, Continuous Delivery , Continous Deployment 두가지 의미가 다르게 쓰이는 것이 존재한다는 것이었다.
- https://www.redhat.com/ko/topics/devops/what-is-ci-cd
- "CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하고, 상호교환해 사용이 가능하고,
- Continuous Delivery
- 개발자들이 애플리케이션에 적용한 변경 사항이 버그 테스트를 거쳐 리포지토리(예: GitHub 또는 컨테이너 레지스트리)에 자동으로 업로드되는 것
- Continuous Deployment
- 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는
행위가 다른 2가지가 같은 축약어로 이용이 됐다.
- 개발자의 변경 사항을 리포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는
- CT
- 또한, CT 라는 CICD 이후 대두되는 CI (Continuous Integration), CD (Continuous Delivery/Deployment), /CT 라는 단어에서 CT가 mlops 와 devops 에서 각기 다른 의미로 이용되고 있었는데, Devops 에서는 Continuous Testing, 그리고 ML 진영에서는 continuous training (CT) 이라 불리고 있었다. 각각의 개발에 있어서 CD 과정 이전에 validation 이상인 중요한 과정을 CT 라 부르는 것 같아 흥미로웠다.
데이터 처리 워크플로용 CI/CD 파이프라인
https://cloud.google.com/architecture/cicd-pipeline-for-data-processing?hl=ko
튜토리얼과정으로는 Google Cloud에서 관리 제품으로 CI/CD 메서드를 구현하여 데이터 처리를 위한 지속적 통합/지속적 배포(CI/CD) 파이프라인을 설정하는 방법을 설명하고 있는데, 중요한 것은 CI, CD 과정에서 각각 무슨 처리를 했고 , 그와 관련된 툴은 어떤 기능을 하는 무엇과 유사한지 보면 될것같다.
데이터과학자와 분석가들이 CI/CD 방식의 방법론을 채택하면 데이터 프로세스 및 워크플로의 고품질, 유지 관리성, 조정 가능성을 보장하는 데 도움이 될 수 있다고한다.. 다음과 같은 응용이 가능하다..
- 소스 코드의 버전 관리
- 앱의 자동 빌드, 테스트, 배포
- 프로덕션에서의 환경 격리 및 분리
- 복제 가능한 환경 설정 절차
배포 아키텍처
다음 Google Cloud 제품을 사용이 가능하다.
- Cloud Build: 데이터 처리 워크플로 및 데이터 처리 자체를 빌드, 배포, 테스트하는 CI/CD 파이프라인을 만듭니다. Cloud Build는 Google Cloud에서 빌드를 실행하는 관리형 서비스입니다. 빌드는 각 단계가 Docker 컨테이너에서 실행되는 일련의 빌드 단계이다.
- cicd 툴로 보임. 깃허브 액션이나 젠킨스 같은 느낌
- https://zzsza.github.io/gcp/2020/05/09/google-cloud-build/
- Cloud Composer: 데이터 처리, 테스트, 결과 확인 등의 워크플로 단계를 정의하고 실행합니다. Cloud Composer는 이 튜토리얼의 데이터 처리 워크플로와 같은 복잡한 워크플로를 생성, 예약, 모니터링, 관리할 수 있는 환경을 제공하는 관리형 Apache Airflow 서비스이다.
- 에어플로라는 이야기
- Dataflow를 사용하여 Apache Beam WordCount 예시를 샘플 데이터 처리로 실행한다.
- 에어플로라는 이야기
CI/CD 파이프라인
문서
CI/CD 파이프라인을 구성하는 단계는 대략 다음과 같습니다
- Cloud Build에서 WordCount 샘플을 Maven 빌더를 사용해 자체 실행되는 자바 아카이브(JAR) 파일로 패키지화합니다. Maven 빌더는 Maven이 설치된 컨테이너입니다. Maven 빌더를 사용하도록 빌드 단계를 구성하면 Maven에서 태스크를 실행니다.
- => 깃허브 액션 러너같은 역할자에서 maven 빌드로 Jar 를 패키지한다.
- Cloud Build에서 JAR 파일을 Cloud Storage로 업로드.
- => 깃허브 액션 러너같은 역할자에서 Jar 을 스토리지에 올린다.
- Cloud Build가 데이터 처리 워크플로 코드에 대한 단위 테스트를 실행하고 워크플로 코드를 Cloud Composer에 배포한다.
- Cloud Composer가 JAR 파일을 선택해 Dataflow에서 데이터 처리 작업을 실행한다.
다음 다이어그램은 CI/CD 파이프라인 단계를 자세히 보여준다.
테스트 및 프로덕션 환경에 대한 배포를 2개의 Cloud Build 파이프라인, 즉 테스트 파이프라인과 프로덕션 파이프라인으로 구분한다.
앞의 다이어그램에서 테스트 파이프라인은 다음과 같은 단계로 구성되는데,
- 개발자가 Cloud Source Repositories에 코드 변경사항을 커밋.
- 코드 변경사항으로 인해 Cloud Build에 테스트 빌드가 트리거.
- Cloud Build가 자체 실행되는 JAR 파일을 빌드하여 Cloud Storage의 테스트 JAR 버킷에 배포.
- Cloud Build가 테스트 파일을 Cloud Storage의 테스트-파일 버킷에 배포.
- Cloud Build가 새로 배포된 JAR 파일을 참조하도록 Cloud Composer에 변수를 설정다.
- Cloud Build가 데이터 처리 워크플로 Directed Acyclic Graph(DAG)를 테스트하여 Cloud Storage의 Cloud Composer 버킷에 배포.
- 워크플로 DAG 파일이 Cloud Composer에 배포.
- Cloud Build가 새로 배포된 데이터 처리 워크플로가 실행되도록 트리거합니다.
- 데이터 처리 워크플로 통합 테스트에 통과하면 메시지 데이터 필드의 최신 자체 실행 JAR(Airflow 변수에서 가져온)에 대한 참조가 포함된 메시지가 Pub/Sub에 게시됩니다.
앞의 다이어그램에서 프로덕션 파이프라인은 다음과 같은 단계로 구성된다.
- 메시지가 Pub/Sub 주제에 게시되면 프로덕션 배포 파이프라인이 트리거됩니다.
- 개발자가 프로덕션 배포 파이프라인을 수동으로 승인하고 빌드가 실행됩니다.
- Cloud Build가 자체 실행되는 최신 JAR 파일을 Cloud Storage의 테스트 JAR 버킷에서 프로덕션 JAR 버킷으로 복사합니다.
- Cloud Build가 프로덕션 데이터 처리 워크플로 DAG를 테스트하여 Cloud Storage의 Cloud Composer 버킷에 배포합니다.
- 프로덕션 워크플로 DAG 파일이 Cloud Composer에 배포됩니다.
이해한 점
- 우선적으로 보이는 점은 ci 와 cd 를 나누지 않고, cicd 라고 같이 부르고 있다.
- 그리고 그림을 보아하니, test pipeline step 과 prod pipeline step 에 분기가 존재한다.
- test 에서만 깃 커밋 이벤트를 받고 -> test 경로에 jar 를 빌드한뒤, -> 테스트가 유닛테스트+dag 단위 런타임테스트가 성공하면 pub,sub 이라는 경로에 올리고 -> 승인이 나면 -> 테스트를 카피해와서 유닛테스트+dag 단위 런타임테스트가 성공하면 배포한다.
- 테스트를 카피해온다라는 과정이 있는 것과 테스트 파이프라인에 대한 개발과 테스트 과정에 대한 생각이 있었는데, test 는 아마 (dev, stage, real )에서 stage 인것같아 어느정도 이해를 해보려한다.
- 그 이상은 해당 도큐먼트를 보자.
MLOps 용 CICD 파이프라인
mlops 쪽에서 아싸리 devops와 mlops 비교가 있는 편이다.
DevOps와 MLOps 비교
DevOps는 대규모 소프트웨어 시스템을 개발하고 운영하는 데 널리 사용됩니다. 이 방식은 개발 주기 단축, 배포 속도 증가, 안정적인 출시 등의 이점을 제공합니다. 이러한 이점을 누리려면 소프트웨어 시스템 개발에 다음의 두 가지 개념을 도입한다.
ML 및 기타 소프트웨어 시스템은 소스 제어의 지속적 통합, 단위 테스트, 통합 테스트, 소프트웨어 모듈 또는 패키지의 지속적 배포가 유사합니다. 그러나 ML에서는 몇 가지 주목할 만한 차이점이 있는데,
- CI는 더 이상 코드 및 구성요소만 테스트하고 검증하는 것이 아니라 데이터, 데이터 스키마, 모델도 테스트하고 검증하는 것이다.
- CT 내용 이었던 데이터에 대한 "테스트"도 들어온 모습.
- CD는 더 이상 단일 소프트웨어 패키지 또는 서비스만이 아니라 다른 서비스(모델 예측 서비스)를 자동으로 배포해야 하는 시스템(ML 학습 파이프라인)이다.
- CT는 ML 시스템에 고유한 새 속성으로, 모델을 자동으로 재학습시키고 서빙하는 데 사용됩니다.
- CT 는 일종의 자동으로 재학습용 파이프라인이라고 생각하면 된다.
MLOps 수준 1: ML 파이프라인 자동화
수준 1의 목표는 ML 파이프라인을 자동화하여 모델을 지속적으로 학습시키는 것입니다. 이를 통해 모델 예측 서비스를 지속적으로 제공할 수 있습니다. 새 데이터를 사용하여 프로덕션 단계에서 모델을 재학습시키는 프로세스를 자동화하려면 파이프라인 트리거 및 메타데이터 관리뿐만 아니라 자동화된 데이터 및 모델 검증 단계를 파이프라인에 도입해야 합니다.
...
모델의 지속적 배포: 프로덕션 단계의 ML 파이프라인은 새 데이터로 학습된 새 모델에 예측 서비스를 지속적으로 배포합니다. 학습 및 검증된 모델을 온라인 예측용 예측 서비스로 제공하는 모델 배포 단계가 자동화됩니다.
아래 두개의 그림은 각각 mlops 수준 0와 수준1 그림의 도식화인데, mlops 수준1 부터 CD 에 대한 언급이 있다. 하지만, 자세히 보면
model serving 부분에있어서 CD 의 경우는
CT(Continous Training) 파이프라인에 끝부분에서 모델 서빙을 CD , 자동 배포해주는 용도로 쓰이는 부분을 확인할 수 있다.
데이터 및 모델 유효성 검사
ML 파이프라인을 프로덕션에 배포할 때는 ML 파이프라인 트리거 섹션에서 설명한 트리거 중 하나 이상이 자동으로 파이프라인을 실행하다. 파이프라인은 새 실시간 데이터가 새 데이터로 학습된 새 모델 버전을 생성할 것으로 예상합니다(그림 3 참조). 따라서 다음 예상되는 동작을 보장하기 위해 프로덕션 파이프라인은 자동화된 데이터 검증 및 모델 검증 단계가 필요하다.
- 데이터 검증: 이 단계는 모델 학습 전에 모델을 재학습할지 또는 파이프라인 실행을 중지할지 결정하는 데 필요합니다. 이 결정은 파이프라인에서 다음을 식별하면 자동으로 수행된다.
- 데이터 스키마 편향: 이러한 편향은 입력 데이터의 이상으로 간주됩니다. 즉, 데이터 처리 및 모델 학습을 포함한 다운스트림 파이프라인 단계가 예상 스키마를 준수하지 않는 데이터를 수신한다. 이 경우 데이터 과학팀이 조사할 수 있도록 파이프라인을 중지해야 한다. 팀은 이러한 변경사항을 스키마에서 처리하기 위해 파이프라인에 대한 수정 또는 업데이트를 출시할 수 있다. 스키마 편향에는 예기치 않은 특성을 수신하거나, 예상되는 모든 특성을 수신하지 않거나, 예기치 않은 값을 포함하는 특성을 수신하는 경우가 포함된다.
- 데이터 값 편향: 이러한 편향은 데이터의 통계적 속성에 큰 변화를 주어 데이터 패턴이 변경되고 있음을 의미합니다. 모델의 재학습을 트리거하여 이러한 변경사항을 포착해야 합니다.
- 모델 검증: 이 단계는 새 데이터가 제공된 모델을 학습시킨 후에 발생합니다. 모델을 프로덕션으로 승격하기 전에 사용자가 모델을 평가하고 검증합니다. 이 오프라인 모델 검증 단계는 다음으로 구성됩니다.
- 모델의 예측 품질을 평가하기 위해 테스트 데이터 세트에서 학습된 모델을 사용하여 평가 측정항목 값을 생성합니다.
- 새로 학습된 모델에서 생성된 평가 측정항목 값을 현재 모델과 비교합니다(예: 프로덕션 모델, 기준 모델 또는 기타 비즈니스 요구사항 모델). 새 모델이 프로덕션으로 승격되기 전에 현재 모델보다 우수한 성능을 제공하는지 확인합니다.
- 모델의 성능이 데이터의 다양한 세그먼트에서 일관성이 있는지 확인합니다. 예를 들어 새로 학습된 고객 이탈 모델은 이전 모델보다 전반적인 예측 정확도가 더 높을 수 있지만 고객 리전당 정확도 값은 큰 차이가 날 수 있습니다.
- 예측 서비스 API와의 인프라 호환성 및 일관성을 포함하여 모델의 배포를 테스트해야 합니다.
이해한 점
- 사실상 배포에 있어서 자동 배포를 위해서는 데이터 검증과 모델 검증이 필요하다.
MLOps 수준 2: CI/CD 파이프라인 자동화
사실상 2단계부터가 흔히 생각하는 gitops 혹은 깃에 이벤트로 인해 발생하는 cicd 파이프라인으로 보면 될 것같다.
프로덕션 단계에서 파이프라인을 빠르고 안정적이게 업데이트 하려면 강력히 자동화된 CICD 시스템이 필요합니다. 이 자동화된 CICD 시스템을 이용하면 데이터 과학자가 특성을 추출, 모델 아키텍처, 초 매개변수에 대한 새로운 아이디어를 빠르게 살펴볼 수 있습니다.
데이터 과학자는 이러한 아이디어를 구현하고 새 파이프라인 구성요소를 대상 환경에 자동으로 빌드, 테스트 , 배포할 수 있습니다.
다음 다이어그램은 자동화된 ml 파이프라인 설정과 자동화된 CICD 루틴의 특성을 가진 CICD 를 이용해 ML 파이프라인을 구현하는 방법을 보여줍니다.
이 mlops 설정에는 다음 구성요소가 포함됩니다.
- 소스 제어
- 서비스 테스트 및 빌드
- 배포 서비스
- 모델 레지스트리
- feature store
- ml 메타데이터 저장소
- ml 파이프라인 조정자
특성
다음 다이어그램은 ml ci/cd 파이프라인 단계를 보여준다.
ci(지속적 통합)
이 설정에서 파이프라인과 구성요소는 새 코드가 커밋되거나 소스 코드 저장소로 푸시될때, 빌드, 테스트 , 패키징됩니다. ci 프로세스에는 패키지, 컨테이너 이미지, 실행파일을 빌드하는 것 외에 다음과 같은 테스트가 포함될 수 있습니다.
- 특성 추출 로직을 단위 테스트 합니다.
- 모델에 구현된 다양한 메서드를 단위 테스트 합니다. 예를들어 범주형 데이터 열을 허용하는 함수가 있다면, 이 함수를 원핫 특성으로 인코딩합니다.
- 모델 학습이 수렴하는지 테스트합니다. (즉, 모델의 손실이 반복으로인해 중단되고, 몇가지 샘플 레코드를 과적합함)
- 모델 학습에서 0으로 나누거나 작은값 또는 큰 값을 조작해 NaN 값을 생성하지 않는지 테스트합니다.
- 파이프라인 구성요소 간의 통합을 테스트합니다.
cd(지속적 배포)
이 수준에서 시스템은 새 파이프라인 구현을 지속적으로 배포해 새로 학습된 모델의 예측 서비스를 전달합니다.
파이프라인 및 모델의 빠르고 안정적인 지속적인 배포를 위해 다음 사항을 고려해야합니다.
- 모델 배포하기전에 모델과 대상 인프라의 호환성을 확인합니다.
- 예를 들어 모델에 필요한 패키지가 제공하는 환경에 설치돼있는지, 그리고 메모리, 컴퓨팅, 가속기 리소스가 사용가능한지 확인해야합니다.
- 예상되는 입력으로는 서비스 api 를 호출하고 응답이 예상하는 응답을 가져오도록해 예측 서비스를 테스트합니다.
- 이 테스트는 일반적으로 모델 버전을 업데이트하고 해당 버전이 다른 입력을 예상할때 발생할 수 있는 문제를 포착합니다.
- 초당 쿼리수(QPS) 및 모델 지연 시간과 같은 측정 항목을 포착하기 위한 서비스 부하테스트가 포함된 예측 서비스 성능 테스트
- 재학습 또는 일괄 예측을 위한 데이터 유효성 검사
- 모델이 배포되기 전, 예측 성능 목표를 충족하는지 확인
- 테스트 환경에 대한 자동 배포(예. 개발 분기에 코드를 푸시해 트리거된 배포)
- 사전 프로덕션 환경에 대한 반자동 배포(예. 검토자가 변경사항을 승인한 후, 기본 분기에 코드를 병합해 트리거된 배포)
- 사전 프로덕션 환경에서 여러 번의 성공적인 파이프라인 실행 후, 프로덕션 환경에 대한 수동 배포
요약하자면 프로덕션 환경에서 ML 을 구현한다고 해서 모델이 예측용 api로 배포되는 것은 아닙니다. 대신, 새 모델의 재학습 및 배포를 자동화할 수 있는 ML 파이프라인(내생각엔 이게 CT) 배포를 의미합니다. CICD 시스템을 설정해 새로운 파이프라인 구현을 자동으로 테스트하고 배포할 수 있고, 이 시스템을 사용해 데이터 및 비즈니스 환경의 빠른 변화에 대처할 수 있습니다.
모든 프로세스를 한 수준에서 다른 수준으로 즉시 이동할 필요는 없고, 이러한 방식으로 점진적으로 구현해 ML 시스템 개발 및 프로덕션의 자동화를 개선할 수 있습니다.
이해한 점
- CT 를 위한 cicd 파이프라인이 결국 mlops 레벨2 를 위한 길
- 각각 구성요소에 대해서 하는 구성 컨텐츠가 이런 것들이 있구나.. 하고 이해했다. 특히 테스트 단계에서 예상 qps 단계에서 부하테스트를 cd 과정에서 한다는 점이 흥미로웠다.