TFX, Kubeflow 파이프라인, Cloud Build를 사용하는 MLOps 아키텍처

이 문서에서는 TensorFlow Extended(TFX) 라이브러리를 사용하는 머신러닝(ML) 시스템의 전반적인 아키텍처를 설명합니다. 또한 Cloud BuildKubeflow Pipelines를 사용하여 ML 시스템에 지속적 통합(CI), 지속적 배포(CD), 지속적 학습(CT)을 설정하는 방법을 설명합니다.

이 문서에서 ML 시스템ML 파이프라인은 모델 스코어링 또는 예측 파이프라인이 아닌 ML 모델 학습 파이프라인을 나타냅니다.

이 문서는 Google Cloud에서 ML 솔루션을 프로덕션으로 이동하기 위해 CI/CD 방식을 조정하길 원하고, ML 파이프라인의 품질, 유지관리, 조정 성능을 보장하려는 데이터 과학자 및 ML 엔지니어를 위한 것입니다.

이 문서에서는 다음 주제를 다룹니다.

  • ML의 CI/CD 및 자동화 이해
  • TFX가 포함된 통합 ML 파이프라인 설계
  • Kubeflow 파이프라인을 사용한 ML 파이프라인 조정 및 자동화
  • Cloud Build를 사용한 ML 파이프라인을 위한 CI/CD 시스템 설정

MLOps

프로덕션 환경에서 ML 시스템을 통합하려면 ML 파이프라인의 단계들을 조정해야 합니다. 또한 모델의 연속적 학습을 위해 파이프라인 실행을 자동화해야 합니다. 새로운 아이디어와 기능을 실험하려면 파이프라인을 새로 구현할 때 여러 CI/CD 방식을 채택해야 합니다. 다음 섹션에서는 ML에서 CI/CD와 CT의 대략적인 개요를 보여줍니다.

ML 파이프라인 자동화

일부 사용 사례에서는 ML 모델의 학습, 검사, 배포를 수동으로 처리하는 것으로 충분할 수 있습니다. 이러한 수동 방식은 재학습 또는 잦은 변경이 없는 약간의 ML 모델만 팀에서 관리하는 경우에 적합합니다. 하지만 실제로 모델은 동적 환경의 변화 또는 그러한 동적 변화를 기술하는 데이터에 맞게 조정되지 못하기 때문에 실제 세계에 배포될 때 실패하는 경우가 많습니다.

ML 시스템이 이러한 변화에 맞게 조정되기 위해서는 다음과 같은 MLOps 기법을 적용해야 합니다.

  • 모든 새로운 패턴을 포착하기 위해 새 데이터에 맞게 새 모델을 재학습하도록 ML 파이프라인 실행을 자동화합니다. CT는 이 문서의 후반부에 있는 Kubeflow Pipelines를 사용한 ML 섹션에서 설명합니다.
  • 전체 ML 파이프라인의 새로운 구현을 자주 배포할 수 있도록 지속적 배포 시스템을 설정합니다. CI/CD는 이 문서의 후반부에 있는 Google Cloud에서 ML을 위한 CI/CD 설정 섹션에서 설명합니다.

새로운 데이터로 모델을 재학습하기 위해 ML 프로덕션 파이프라인을 자동화할 수 있습니다. 파이프라인 트리거는 주문형, 일정, 신규 데이터 제공, 모델 성능 저하, 데이터의 주요 통계적 특성 변화, 기타 조건을 기준으로 수행될 수 있습니다.

CI/CD 파이프라인과 CT 파이프라인 비교

새로운 데이터 제공은 ML 모델 재학습을 일으키는 트리거 중 하나입니다. ML 파이프라인의 새로운 구현 제공(새로운 모델 아키텍처, 특성 추출, 초매개변수 포함)도 ML 파이프라인 재실행을 일으키는 또 다른 중요 트리거입니다. 이러한 ML 파이프라인의 새로운 구현은 온라인 서비스 제공을 위해 REST API가 포함된 마이크로서비스와 같이 모델 예측 서비스의 새 버전으로 사용됩니다. 두 경우의 차이점은 다음과 같습니다.

  • 새 ML 모델을 새 데이터로 학습시키기 위해서는 이전에 배포된 CT 파이프라인이 실행됩니다. 새로운 파이프라인 또는 구성요소는 배포되지 않습니다. 새로운 예측 서비스 또는 새롭게 학습된 모델만 파이프라인 마지막에 제공됩니다.
  • 새 구현으로 새 ML 모델을 학습시키기 위해서는 CI/CD 파이프라인을 통해 새로운 파이프라인이 배포됩니다.

새 ML 파이프라인을 빠르게 배포하려면 CI/CD 파이프라인을 설정해야 합니다. 이 파이프라인은 새 구현이 제공되고 여러 환경(예: 개발, 테스트, 스테이징, 프리 프로덕션, 카나리아, 프로덕션)에 승인되었을 때 새로운 ML 파이프라인 및 구성요소를 자동으로 배포합니다.

다음 다이어그램은 CI/CD 파이프라인과 ML CT 파이프라인의 관계를 보여줍니다.

CI/CD 파이프라인의 결과가 CT 파이프라인입니다.

그림 1. CI/CD 및 ML CT 파이프라인

이러한 파이프라인의 결과는 다음과 같습니다.

  • 새 구현이 제공되면 성공한 CI/CD 파이프라인이 새 ML CT 파이프라인을 배포합니다.
  • 새 데이터가 제공되면 성공한 CT 파이프라인이 새 모델 예측 서비스를 제공합니다.

TFX 기반 ML 시스템 설계

다음 섹션에서는 TensorFlow Extend(TFX)를 사용해서 통합 ML 시스템을 설계하여 ML 시스템을 위해 CI/CD 파이프라인을 설정하는 방법을 설명합니다. ML 모델 빌드를 위한 여러 프레임워크가 있지만, TFX는 프로덕션 ML 시스템을 개발하고 배포하기 위한 통합 ML 플랫폼입니다. TFX 파이프라인은 ML 시스템을 구현하는 일련의 구성요소입니다. 이 TFX 파이프라인은 확장 가능한 고성능 ML 작업을 위해 설계되었습니다. 이러한 작업에는 모델링, 학습, 검사, 추론 제공, 배포 관리가 포함됩니다. TFX의 주요 라이브러리는 다음과 같습니다.

TFX ML 시스템 개요

다음 다이어그램은 ML 시스템을 구성하는 여러 TFX 라이브러리가 서로 통합되는 방식을 보여줍니다.

TFX 기반 ML 시스템의 단계

그림 2. 일반적인 TFX 기반 ML 시스템

그림 2는 일반적인 TFX 기반 ML 시스템을 보여줍니다. 다음 단계는 수동으로 또는 자동화된 파이프라인을 통해 수행할 수 있습니다.

  1. 데이터 추출: 첫 번째 단계는 데이터 소스로부터 새로운 학습 데이터를 추출하는 것입니다. 이 단계의 결과는 모델 학습 및 평가에 사용되는 데이터 파일입니다.
  2. 데이터 검사: TFDV가 예상(원시) 데이터 스키마를 기준으로 데이터를 검사합니다. 데이터 스키마가 생성되고 시스템 배포 전 개발 단계 중에 수정됩니다. 데이터 검사 단계에서는 데이터 분포 및 스키마 편향과 관련된 이상치를 감지합니다. 이 단계의 결과는 이상치(있는 경우) 및 다운스트림 단계를 실행할지 여부에 대한 결정입니다.
  3. 데이터 변환: 데이터 검사가 완료된 후 TFT를 사용해서 데이터 변환 및 특성 추출 작업을 수행하여 ML 작업에 맞게 데이터를 분할하고 준비합니다. 이 단계의 결과는 일반적으로 TFRecords 형식으로 변환되는 모델 학습 및 평가를 위한 데이터 파일입니다. 또한 생성되는 변환 아티팩트는 모델 입력 생성 및 학습 후 제공되는 모델 내보내기에 도움이 됩니다.
  4. 모델 학습 및 미세 조정: ML 모델을 구현하고 학습시키기 위해서는 이전 단계에서 생성된 변환 데이터에 tf.estimator 또는 tf.Keras API를 사용합니다. 최상의 모델로 이어지는 매개변수 설정을 선택하기 위해서는 Keras용 초매개변수 미세 조정 라이브러리인 Keras 튜너를 사용하거나 Katib와 같은 다른 서비스를 사용할 수 있습니다. 이 단계의 결과는 평가에 사용되는 저장된 모델과 예측을 위한 온라인 모델 제공에 사용되는 또 다른 저장된 모델입니다.
  5. 모델 평가 및 검사: 학습 단계 후 모델을 내보낼 때는 TFMA를 사용하여 모델 품질을 평가하기 위해 테스트 데이터 세트에 따라 평가됩니다. TFMA는 전반적으로 모델 품질을 평가하고, 문제가 있는 데이터 모델 부분을 식별합니다. 이러한 평가는 품질 기준을 충족하는 경우에만 모델이 승급되도록 보장합니다. 이러한 기준에는 여러 데이터 하위 집합(예: 인구통계 및 위치)에서의 올바른 성능과 이전 모델 또는 벤치마크 모델에 대비 향상된 성능이 포함될 수 있습니다. 이 단계의 결과는 성능 측정항목 집합과 모델을 프로덕션으로 승격할지 여부에 대한 결정입니다.
  6. 예측을 위한 모델 제공: 새로 학습된 모델이 검사된 다음에는 TensorFlow Serving을 사용해서 온라인 예측을 제공하도록 마이크로서비스로 배포됩니다. 이 단계의 결과는 학습된 ML 모델의 배포된 예측 서비스입니다. 이 단계는 모델 레지스트리에 학습된 모델 저장으로 대체할 수 있습니다. 이후에 개별적인 모델 제공 CI/CD 프로세스가 실행됩니다.

TFX 라이브러리 사용 방법을 보여주는 가이드는 ML과 TensorFlow Extended(TFX)를 참조하세요.

Google Cloud의 TFX ML 시스템

프로덕션 환경에서 시스템 구성요소는 신뢰할 수 있는 플랫폼에서 대규모로 실행되어야 합니다. 다음 다이어그램은 TFX ML 파이프라인의 각 단계가 Google Cloud에서 대규모 민첩성, 신뢰성, 성능을 보장하는 관리형 서비스를 사용하여 실행되는 방법을 보여줍니다.

Google Cloud의 TFX 기반 ML 시스템 단계

그림 3. Google Cloud의 TFX기반 ML 시스템

다음 표에서는 그림 3에 표시된 주요 Google Cloud 서비스를 설명합니다.

단계 TFX 라이브러리 Google Cloud 서비스
데이터 추출 및 검사 TensorFlow 데이터 검사 Dataflow
데이터 변환 TensorFlow Transform Dataflow
모델 학습 및 미세 조정 TensorFlow AI Platform Training
모델 평가 및 검사 TensorFlow Model Analysis Dataflow
모델 예측 제공 TensorFlow Serving AI Platform 예측
모델 아티팩트 스토리지 북미 AI Hub
  • Dataflow는 Google Cloud에서 대규모로 Apache Beam 파이프라인을 실행하기 위한 안정적인 완전 관리형, 서버리스 서비스입니다. Dataflow는 다음 프로세스의 확장을 위해 사용됩니다.

    • 새로 추가되는 데이터 검사를 위한 통계 컴퓨팅
    • 데이터 준비 및 변환 수행
    • 대규모 데이터 세트로 모델 평가
    • 평가 데이터 세트의 여러 측면에서의 측정항목 컴퓨팅
  • Cloud Storage는 높은 가용성과 내구성을 자랑하는 대용량 바이너리 객체 스토리지입니다. Cloud Storage는 다음을 비롯해서 ML 파이프라인의 실행 전반에 걸쳐 생성되는 아티팩트를 호스팅합니다.

    • 데이터 이상치(있는 경우)
    • 변환된 데이터 및 아티팩트
    • 내보낸(학습된) 모델
    • 모델 평가 측정항목
  • AI Hub는 인공지능(AI) 및 ML 자산의 검색, 공유, 재사용을 위한 엔터프라이즈급 호스팅 저장소입니다. 학습 및 검사된 모델과 해당 관련 메타데이터를 저장하기 위해서는 AI Hub를 모델 레지스트리로 사용할 수 있습니다.

  • AI Platform은 ML 모델을 대규모로 학습하고 제공하기 위한 관리형 서비스입니다. AI Platform Training은 TensorFlow, Scikit-learn, XGboost 모델 외에도 사용자 제공 커스텀 컨테이너를 사용해서 모든 프레임워크에서 구현된 모델을 지원합니다. 또한 초매개변수 미세 조정을 위한 확장 가능한 Bayesian 최적화 기반 서비스도 사용할 수 있습니다. 학습된 모델은 REST API를 포함하는 마이크로서비스로 AI Platform Prediction에 배포될 수 있습니다.

Kubeflow Pipelines를 사용하여 ML 시스템 조정

이 문서에서는 TFX 기반 ML 시스템을 설계하고 Google Cloud에서 시스템의 각 구성요소를 대규모로 실행하는 방법을 설명합니다. 하지만 시스템의 이러한 각 구성요소를 하나로 연결하기 위해서는 조정자가 필요합니다. 조정자는 한 시퀀스에서 파이프라인을 실행하고 정의된 조건에 따라 한 단계에서 다른 단계로 자동으로 이동합니다. 예를 들어 평가 측정항목이 미리 정의된 기준을 충족할 경우 정의된 조건에 따라 모델 평가 단계 이후 모델 제공 단계가 실행될 수 있습니다. ML 파이프라인 조정은 개발 및 프로덕션 단계 모두 유용합니다.

  • 데이터 과학자는 개발 단계 중 조정을 통해 각 단계를 수동으로 실행하는 대신 ML 실험을 실행할 수 있습니다.
  • 프로덕션 단계 중에는 조정을 통해 일정 또는 특정 트리거 조건을 기준으로 ML 파이프라인 실행을 자동화할 수 있습니다.

Kubeflow Pipelines를 사용한 ML

Kubeflow는 이식 가능한 ML 워크로드를 개발 및 실행하기 위한 오픈소스 Kubernetes 프레임워크입니다. Kubeflow Pipelines는 시스템의 각 구성요소가 Kubeflow, Google Cloud, 기타 클라우드 플랫폼에서 실행되는 ML 시스템을 구성, 조정, 자동화할 수 있게 해주는 Kubeflow 서비스입니다. Kubeflow Pipelines 플랫폼은 다음으로 구성됩니다.

  • 실험, 작업 및 실행을 관리하고 추적하기 위한 사용자 인터페이스
  • 다단계 ML 워크플로 일정 조정 엔진. Kubeflow Pipelines는 Argo를 사용하여 Kubernetes 리소스를 조정합니다.
  • 파이프라인 및 구성요소 정의 및 조작을 위한 Python SDK.
  • Python SDK를 사용하여 시스템과 상호작용하기 위한 메모장.
  • 실행, 모델, 데이터 세트, 기타 아티팩트에 대한 정보를 저장하는 ML 메타데이터 저장소.

일반적으로 Kubeflow 파이프라인은 다음으로 구성됩니다.

  • 컨테이너화된 ML 작업 집합 또는 구성요소. 파이프라인 구성요소는 Docker 이미지로 패키지화되는 독립 실행형 코드입니다. 구성요소는 입력 인수를 사용해서 결과 파일을 생성하고 파이프라인에서 한 단계를 수행합니다.

  • Python 도메인 특정 언어(DSL)를 통해 정의된 ML 작업 시퀀스 지정. 워크플로의 토폴로지는 업스트림 단계의 결과를 다운스트림 단계의 입력에 연결하여 암시적으로 정의됩니다. 파이프라인 정의에서 하나의 단계는 파이프라인에서 하나의 구성요소를 호출합니다. 복잡한 파이프라인에서는 여러 구성요소가 여러 번 순서대로 실행되거나 조건부로 실행될 수 있습니다.

  • 데이터 필터링 조건 및 파이프라인이 생성하는 아티팩트 저장 위치를 포함하여 파이프라인의 구성요소에 값이 전달되는 파이프라인 입력 매개변수 집합

다음 다이어그램은 Kubeflow Pipelines의 샘플 그래프를 보여줍니다.

Kubeflow Pipelines를 사용한 ML 파이프라인 그래프

그림 4. Kubeflow Pipelines 샘플 그래프

Kubeflow Pipelines 구성요소

구성요소가 파이프라인에 호출되도록 하려면 구성요소 작업을 만들어야 합니다. 구성요소 작업은 다음 방법을 통해 만들 수 있습니다.

  • 경량형 Python 구성요소 구현: 이 구성요소는 코드가 변경될 때마다 컨테이너 이미지를 새로 빌드할 필요가 없으며, 메모장 환경에서 빠른 반복을 위해 사용됩니다. kfp.components.func_to_container_op 함수를 사용하여 Python 함수로부터 경량형 구성요소를 만들 수 있습니다.

  • 재사용 가능한 구성요소 만들기: 이 기능을 이용하려면 component.yaml 파일에 구성요소 사양이 포함되어 있어야 합니다. 구성요소 사양은 인수, 실행할 Docker 컨테이너 이미지 URL, 결과와 관련해서 Kubeflow Pipelines에 대한 구성요소를 기술합니다. 구성요소 작업은 파이프라인 컴파일 중 Kubeflow Pipelines SDK에서 ComponentStore.load_components 함수를 사용하여 component.yaml 파일에 자동으로 생성됩니다. 재사용 가능한 component.yaml 사양은 다른 Kubeflow Pipelines 프로젝트에서 호환성을 위해 AI Hub에 공유될 수 있습니다.

  • 사전 정의된 Google Cloud 구성요소 사용: Kubeflow Pipelines는 필요한 매개변수를 제공하여 Google Cloud에서 여러 관리형 서비스를 실행하는 사전 정의된 구성요소를 제공합니다. 이러한 구성요소는 BigQuery, Dataflow, Dataproc, AI Platform과 같은 서비스를 사용하여 작업을 실행할 수 있도록 도와줍니다. 이러한 사전 정의된 Google Cloud 구성요소는 AI Hub에서도 사용할 수 있습니다. 재사용 가능한 구성요소를 사용하는 것과 비슷하게, 이러한 구성요소 작업은 ComponentStore.load_components를 통해 사전 정의된 구성요소 사양으로부터 자동으로 생성됩니다. 다른 사전 정의된 구성요소는 Kubeflow 및 다른 플랫폼에서 작업을 실행하기 위해 제공됩니다.

또한 TFX Pipeline DSLTFX 구성요소를 사용할 수 있습니다. TFX 구성요소는 메타데이터 기능을 캡슐화합니다. 드라이버는 메타데이터 저장소를 쿼리하여 실행자에게 메타데이터를 제공합니다. 게시자는 실행자의 결과를 수락하고 이를 메타데이터에 저장합니다. 또한 메타데이터와 동일한 통합을 갖는 커스텀 구성요소를 구현할 수 있습니다. TFX는 파이프라인의 Python 코드를 YAML 파일로 컴파일하고 Argo 워크플로를 설명하는 명령줄 인터페이스(CLI)를 제공합니다. 그런 다음 사용자가 파일을 Kubeflow Pipelines에 제출할 수 있습니다.

다음 다이어그램은 Kubeflow Pipelines에서 컨테이너화된 작업이 BigQuery 작업, AI Platform(분산) 학습 작업, Dataflow 작업과 같은 다른 서비스를 호출할 수 있는 방법을 보여줍니다.

Google Cloud에서 Kubeflow Pipelines 아키텍처

그림 5. Kubeflow Pipelines 및 Google Cloud 관리형 서비스가 포함된 ML 파이프라인

Kubeflow Pipelines를 사용하면 필요한 Google Cloud 서비스를 실행하여 프로덕션 ML 파이프라인을 조정하고 자동화할 수 있습니다. 그림 5에서 Cloud SQL은 Kubeflow Pipelines를 위한 ML 메타데이터 저장소 역할을 합니다.

Kubeflow Pipelines 구성요소는 Google Cloud에서 TFX 관련 서비스 실행으로 제한되지 않습니다. 이러한 구성요소는 SparkML 작업을 위한 Dataproc, AutoML, 기타 컴퓨팅 워크로드를 포함하여 모든 데이터 관련 및 컴퓨팅 관련 서비스를 실행할 수 있습니다.

Kubeflow Pipelines에서 작업을 컨테이너화하면 다음과 같은 이점이 있습니다.

  • 코드 런타임에서 실행 환경을 분리합니다.
  • 테스트 항목이 프로덕션에서도 동일하기 때문에 개발 환경과 프로덕션 환경 간 코드 재현성을 제공합니다.
  • 파이프라인에서 각 구성요소를 격리시킵니다. 구성요소마다 고유한 런타임 버전, 다른 언어, 다른 라이브러리를 포함할 수 있습니다.
  • 복잡한 파이프라인 구성을 도와줍니다.
  • 추적성 및 재현성을 위해 ML 메타데이터 저장소와 통합됩니다.

Kubeflow Pipelines 및 TFX 라이브러리 예시에 대한 자세한 소개를 보려면 Kubeflow Pipelines 시작하기 블로그 게시물을 참조하세요.

Kubeflow Pipelines 트리거 및 일정 조정

한 Kubeflow 파이프라인을 프로덕션에 배포할 때는 ML 파이프라인 자동화 섹션에 설명된 시나리오에 따라 해당 실행을 자동화해야 합니다.

Kubeflow Pipelines는 파이프라인을 프로그래매틱 방식으로 작동하기 위해 Python SDK를 제공합니다. kfp.Client 클래스에는 실험을 만들고 파이프라인을 배포 및 실행하기 위한 API가 포함되어 있습니다. Kubeflow Pipelines SDK를 사용하면 다음 서비스를 사용하여 Kubeflow Pipelines를 호출할 수 있습니다.

  • 일정에서 Cloud Scheduler를 사용합니다.
  • Pub/SubCloud Functions를 사용하여 이벤트에 응답합니다. 예를 들어 이벤트는 Cloud Storage 버킷에서 새로운 데이터 파일의 가용성을 나타낼 수 있습니다.
  • 더 큰 데이터 및 프로세스 워크플로 중에는 Cloud Composer 또는 Cloud Data Fusion을 사용합니다.

Kubeflow Pipelines는 또한 Kubeflow Pipelines에서 반복되는 파이프라인을 위한 기본 스케줄러를 제공합니다.

Google Cloud에서 ML용 CI/CD 설정

Kubeflow Pipelines를 사용하면 데이터 전처리, 모델 학습 및 평가, 모델 배포를 포함하여 여러 단계가 포함된 ML 시스템을 조정할 수 있습니다. 데이터 과학 탐색 단계에서 Kubeflow Pipelines는 전체 시스템의 빠른 실험을 도와줍니다. 프로덕션 단계에서 Kubeflow Pipelines를 사용하면 새 데이터를 기준으로 ML 모델 학습 또는 재실행을 위한 파이프라인 실행을 자동화할 수 있습니다.

CI/CD 아키텍처

다음 그림은 Kubeflow Pipelines를 사용한 ML을 위한 CI/CD 개요를 보여줍니다.

Kubeflow Pipelines를 사용한 ML 파이프라인을 위한 CI/CD 아키텍처

그림 6: Kubeflow Pipelines를 위한 CI/CD 개요

이 아키텍처에서 핵심은 Google Cloud 인프라에서 사용자 빌드를 실행하는 관리형 서비스인 Cloud Build입니다. Cloud Build는 Cloud Source Repositories, GitHub, Bitbucket에서 소스를 가져오고, 사양에 맞게 빌드를 실행하고, Docker 컨테이너 또는 Python tar 파일과 같은 아티팩트를 생성할 수 있습니다.

Cloud Build는 빌드 구성 파일(cloulbuild.yaml)에 정의된 일련의 빌드 단계에 따라 빌드를 실행합니다. 각 빌드 단계는 Docker 컨테이너에서 실행됩니다. Cloud Build에서 제공되는 지원되는 빌드 단계를 사용하거나 고유 빌드 단계를 작성할 수 있습니다.

ML 시스템에 필요한 CI/CD를 수행하는 Cloud Build 프로세스는 수동으로 또는 자동화된 빌드 트리거를 통해 실행될 수 있습니다. 트리거는 변경사항이 빌드 소스에 푸시될 때마다 구성된 빌드 단계를 실행합니다. 소스 저장소 변경사항에 따라 빌드 루틴을 실행하거나 변경사항이 특정 기준과 일치할 때만 빌드 루틴을 실행하도록 빌드 트리거를 설정할 수 있습니다.

또한 여러 트리거에 따라 실행되는 빌드 루틴(Cloud Build 구성 파일)을 지정할 수 있습니다. 예를 들어 다음 설정을 사용할 수 있습니다.

  • 빌드 루틴은 개발 분기에 커밋이 수행될 때 시작됩니다.
  • 빌드 루틴은 마스터 분기에 커밋이 수행될 때 시작됩니다.

구성 변수 대체 항목을 사용하여 빌드 시 환경 변수를 정의할 수 있습니다. 이러한 대체 항목은 트리거된 빌드에서 캡처됩니다. 이러한 변수에는 $COMMIT_SHA, $REPO_NAME, $BRANCE_NAME, $TAG_NAME, $REVISION_ID가 포함됩니다. 트리거를 기준으로 하지 않는 다른 변수는 $PROJECT_ID$BUILD_ID입니다. 대체 항목은 빌드할 때까지 값을 알 수 없는 변수에 유용하며 다른 변수 값을 사용하여 기존 빌드 요청을 다시 사용하는 데 유용합니다.

CI/CD 워크플로 사용 사례

소스 코드 저장소에는 일반적으로 다음 항목이 포함됩니다.

  • 데이터 검사, 데이터 변환, 모델 학습, 모델 평가, 모델 제공을 포함한 Kubeflow Pipelines 구성요소 구현을 위한 Python 소스 코드
  • 구성요소에 구현된 메서드를 테스트하기 위한 Python 단위 테스트
  • 각 Kubeflow Pipelines 구성요소에 대해 하나씩 Docker 컨테이너 이미지를 만들기 위해 필요한 Docker 파일
  • 파이프라인 구성요소 사양을 정의하는 component.yaml 파일 이러한 사양은 파이프라인 정의에서 구성요소 작업을 생성하기 위해 사용됩니다.
  • Kubeflow Pipelines 워크플로가 정의된 Python 모듈(예: pipeline.py 모듈)
  • cloudbuild.yaml 파일을 포함한 기타 스크립트 및 구성 파일
  • 모델에 대한 실험적 데이터 분석, 모델 분석, 대화형 환경에 사용되는 메모장
  • 파이프라인 입력 매개변수에 대한 구성을 포함하는 설정 파일(예: settings.yaml 파일)

다음 예시에서 빌드 루틴은 개발자가 데이터 과학 환경에서 개발 분기로 소스 코드를 푸시할 때 트리거됩니다.

빌드 단계 예시

그림 7. Cloud Build에서 수행되는 빌드 단계 예시

그림 7에 표시된 것처럼 Cloud Build는 다음 빌드 단계를 수행합니다.

  1. 소스 코드 저장소가 Cloud Build 런타임 환경의 /workspace 디렉터리 아래에 복사됩니다.
  2. 단위 테스트가 실행됩니다.
  3. (선택사항) Pylint와 같은 정적 코드 분석이 실행됩니다.
  4. 테스트가 통과하면 Kubeflow Pipelines 구성요소당 하나씩 Docker 컨테이너 이미지가 빌드됩니다. 이미지에 $COMMIT_SHA 매개변수로 태그 지정됩니다.
  5. Docker 컨테이너 이미지가 Container Registry에 업로드됩니다.
  6. 생성되고 태그 지정된 Docker 컨테이너 이미지가 포함된 각 component.yaml 파일에서 이미지 URL이 업데이트됩니다.
  7. workflow.tar.gz 파일을 생성하도록 Kubeflow Pipelines 워크플로가 컴파일됩니다.
  8. workflow.tar.gz 파일이 Cloud Storage에 업로드됩니다.
  9. 컴파일된 파이프라인이 Kubeflow Pipelines에 배포됩니다. 여기에는 다음 단계가 포함됩니다.
    1. settings.yaml 파일에서 파이프라인 매개변수를 읽습니다.
    2. 실험을 만듭니다(또는 기존 실험 사용).
    3. Kubeflow Pipelines에 파이프라인을 배포합니다(그리고 이름에 버전을 태그로 지정).
  10. (선택사항) 통합 테스트 또는 프로덕션 실행 중 매개변수 값으로 파이프라인을 실행합니다. 실행된 파이프라인은 결국 AI Platform에서 모델을 API로 배포합니다.

이러한 단계가 대부분 포함된 포괄적인 Cloud Build 예시를 보려면 Kubeflow Pipelines 및 Cloud Build가 포함된 간단한 CI/CD 예시를 참조하세요.

추가 고려사항

Google Cloud에서 ML CI/CD 아키텍처를 설정할 때는 다음을 고려하세요.

  • 데이터 과학 환경의 경우 로컬 머신을 사용하거나 Deep Learning VM(DLVM) 기반의 AI Platform Notebooks 인스턴스를 사용할 수 있습니다.
  • 문서 파일이 수정되었거나 실험 메모장이 수정된 것과 같은 경우에만 트리거를 건너뛰도록 자동화된 Cloud Build 파이프라인을 구성할 수 있습니다.
  • 빌드 테스트로 통합 및 회귀 테스트를 수행하기 위해 파이프라인을 실행할 수 있습니다. 파이프라인이 대상 환경에 배포되기 전 wait_for_pipeline_completion 메서드를 사용하여 샘플 데이터 세트에서 파이프라인 테스트를 위해 파이프라인을 실행할 수 있습니다.
  • Cloud Build를 사용하는 대신 Jenkins와 같은 다른 빌드 시스템을 사용할 수 있습니다. 즉시 배포 가능한 Jenkins는 Google Cloud Marketplace에서 제공됩니다.
  • 여러 트리거를 기준으로 개발, 테스트, 스테이징을 포함하여 서로 다른 환경에 자동으로 배포되도록 파이프라인을 구성할 수 있습니다. 또한 일반적으로 출시 승인을 얻은 후 프리 프로덕션 또는 프로덕션과 같은 특정 환경에 수동으로 배포할 수 있습니다. 서로 다른 트리거 또는 서로 다른 대상 환경에 대해 여러 빌드 루틴을 사용할 수 있습니다.
  • 완전 관리형 Cloud Composer 서비스를 사용하여 실행할 수 있는 범용 워크플로를 위한 인기 있는 조정 및 일정 프레임워크인 Apache Airflow를 사용할 수 있습니다. Cloud Composer 및 Cloud Build로 데이터 파이프라인을 조정하는 방법에 대한 자세한 내용은 데이터 처리 워크플로를 위한 CI/CD 파이프라인 설정을 참조하세요.
  • 모델의 새 버전을 프로덕션에 배포할 때는 수행 상태(CPU, 메모리, 디스크 사용량)를 확인하기 위해 카나리아 릴리스로 배포합니다. 모든 라이브 트래픽을 제공하도록 새 모델을 구성하기 전에 A/B 테스트를 수행할 수도 있습니다. 라이프 트래픽의 10%~20%를 제공하도록 새 모델을 구성합니다. 새 모델이 현재 모델보다 수행 성능이 뛰어나면 새 모델이 모든 트래픽을 제공하도록 구성할 수 있습니다. 그렇지 않으면 제공 시스템이 현재 모델로 롤백됩니다.

다음 단계