이 문서에서는 TensorFlow Extended (TFX) 라이브러리를 사용하는 머신러닝 (ML) 시스템의 전반적인 아키텍처를 설명합니다. 또한 Cloud Build 및 Vertex AI Pipelines를 사용하여 ML 시스템에 지속적 통합(CI), 지속적 배포 (CD), 지속적 학습 (CT)을 설정하는 방법을 설명합니다.
이 문서에서 ML 시스템과 ML 파이프라인은 모델 스코어링 또는 예측 파이프라인이 아닌 ML 모델 학습 파이프라인을 나타냅니다.
이 문서는 Google Cloud에서 ML 솔루션을 프로덕션으로 이전하기 위해 CI/CD 방식을 조정하고, ML 파이프라인의 품질, 유지보수성, 적응성을 보장하려는 데이터 과학자 및 ML 엔지니어를 대상으로 합니다.
이 문서에서는 다음 주제를 다룹니다.
- ML의 CI/CD 및 자동화 이해
- TFX가 포함된 통합 ML 파이프라인 설계
- Vertex AI Pipelines를 사용한 ML 파이프라인 조정 및 자동화
- Cloud Build를 사용한 ML 파이프라인을 위한 CI/CD 시스템 설정
MLOps
프로덕션 환경에서 ML 시스템을 통합하려면 ML 파이프라인의 단계들을 조정해야 합니다. 또한 모델의 연속적 학습을 위해 파이프라인 실행을 자동화해야 합니다. 새로운 아이디어와 기능을 실험하려면 파이프라인을 새로 구현할 때 여러 CI/CD 방식을 채택해야 합니다. 다음 섹션에서는 ML에서 CI/CD와 CT의 대략적인 개요를 보여줍니다.
ML 파이프라인 자동화
일부 사용 사례에서는 ML 모델의 학습, 검사, 배포를 수동으로 처리하는 것으로 충분할 수 있습니다. 이러한 수동 방식은 재학습 또는 잦은 변경이 없는 약간의 ML 모델만 팀에서 관리하는 경우에 적합합니다. 하지만 실제로 모델은 동적 환경의 변화 또는 그러한 동적 변화를 기술하는 데이터에 맞게 조정되지 못하기 때문에 실제 세계에 배포될 때 실패하는 경우가 많습니다.
ML 시스템이 이러한 변화에 맞게 조정되기 위해서는 다음과 같은 MLOps 기법을 적용해야 합니다.
- 모든 새로운 패턴을 포착하기 위해 새 데이터에 맞게 새 모델을 재학습하도록 ML 파이프라인 실행을 자동화합니다. CT는 이 문서의 후반부에 있는 Vertex AI 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 파이프라인의 관계를 보여줍니다.
그림 1. CI/CD 및 ML CT 파이프라인
이러한 파이프라인의 결과는 다음과 같습니다.
- 새 구현이 제공되면 성공한 CI/CD 파이프라인이 새 ML CT 파이프라인을 배포합니다.
- 새 데이터가 제공되면 성공한 CT 파이프라인이 새 모델을 학습시켜 이를 예측 서비스로 배포합니다.
TFX 기반 ML 시스템 설계
다음 섹션에서는 TensorFlow Extended(TFX)를 사용해서 통합 ML 시스템을 설계하여 ML 시스템을 위해 CI/CD 파이프라인을 설정하는 방법을 설명합니다. ML 모델 빌드를 위한 여러 프레임워크가 있지만, TFX는 프로덕션 ML 시스템을 개발하고 배포하기 위한 통합 ML 플랫폼입니다. TFX 파이프라인은 ML 시스템을 구현하는 일련의 구성요소입니다. 이 TFX 파이프라인은 확장 가능한 고성능 ML 태스크를 위해 설계되었습니다. 이러한 태스크에는 모델링, 학습, 검증, 추론 서빙, 배포 관리가 포함됩니다. TFX의 주요 라이브러리는 다음과 같습니다.
- TensorFlow Data Validation(TFDV): 데이터에서 이상치를 감지하기 위해 사용됩니다.
- TensorFlow Transform(TFT): 데이터 전처리 및 특성 추출을 위해 사용됩니다.
- TensorFlow Estimators and Keras: ML 모델 빌드 및 학습을 위해 사용됩니다.
- TensorFlow Model Analysis(TFMA): ML 모델 평가 및 분석을 위해 사용됩니다.
- TensorFlow Serving(TFServing): ML 모델을 REST 및 gRPC API로 제공하기 위해 사용됩니다.
TFX ML 시스템 개요
다음 다이어그램은 ML 시스템을 구성하는 여러 TFX 라이브러리가 서로 통합되는 방식을 보여줍니다.
그림 2. 일반적인 TFX 기반 ML 시스템
그림 2는 일반적인 TFX 기반 ML 시스템을 보여줍니다. 다음 단계는 수동으로 또는 자동화된 파이프라인을 통해 수행할 수 있습니다.
- 데이터 추출: 첫 번째 단계는 데이터 소스로부터 새로운 학습 데이터를 추출하는 것입니다. 이 단계의 결과는 모델 학습 및 평가에 사용되는 데이터 파일입니다.
- 데이터 검사: TFDV가 예상(원시) 데이터 스키마를 기준으로 데이터를 검사합니다. 데이터 스키마가 생성되고 시스템 배포 전 개발 단계 중에 수정됩니다. 데이터 검증 단계에서는 데이터 분포 및 스키마 편향과 관련된 이상치를 감지합니다. 이 단계의 결과는 이상치(있는 경우) 및 다운스트림 단계를 실행할지 여부에 대한 결정입니다.
- 데이터 변환: 데이터를 검증한 후 TFT를 사용해서 데이터 변환 및 특성 추출 작업을 수행하여 ML 태스크에 맞게 데이터를 분할하고 준비합니다. 이 단계의 결과는 일반적으로
TFRecords형식으로 변환되는 모델 학습 및 평가를 위한 데이터 파일입니다. 또한 생성되는 변환 아티팩트는 모델 입력 생성에 도움이 되며 학습 후 내보내는 저장된 모델에 변환 프로세스를 삽입합니다. - 모델 학습 및 미세 조정: ML 모델을 구현하고 학습시키기 위해서는 이전 단계에서 생성된 변환 데이터에
tf.KerasAPI를 사용합니다. 최상의 모델로 이어지는 매개변수 설정을 선택하기 위해서는 Keras용 초매개변수 조정 라이브러리인 Keras 튜너를 사용할 수 있습니다. 또는 Katib, Vertex AI Vizier, Vertex AI의 초매개변수 튜너와 같은 다른 서비스를 사용할 수 있습니다. 이 단계의 결과는 평가에 사용되는 저장된 모델과 예측을 위한 온라인 모델 제공에 사용되는 또 다른 저장된 모델입니다. - 모델 평가 및 검증: 학습 단계 후 모델을 내보낼 때 TFMA를 사용해서 테스트 데이터 세트로 모델을 평가하여 모델 품질을 평가합니다. TFMA는 전반적으로 모델 품질을 평가하고, 문제가 있는 데이터 모델 부분을 식별합니다. 이러한 평가는 품질 기준을 충족하는 경우에만 모델이 승급되도록 보장합니다. 이러한 기준에는 여러 데이터 하위 집합(예: 인구통계 및 위치)에서의 양호한 성능과 이전 모델 또는 벤치마크 모델과 비교해 개선된 성능이 포함될 수 있습니다. 이 단계의 결과는 성능 측정항목 집합과 모델을 프로덕션으로 승격할지 여부에 대한 결정입니다.
- 예측을 위한 모델 서빙: 새로 학습된 모델을 검증한 다음에는 TensorFlow Serving을 사용해서 온라인 예측을 제공하도록 마이크로서비스로 배포됩니다. 이 단계의 결과는 학습된 ML 모델의 배포된 예측 서비스입니다. 모델 레지스트리에 학습된 모델을 저장하여 이 단계를 대체할 수 있습니다. 이후에 개별적인 모델 서빙 CI/CD 프로세스가 실행됩니다.
TFX 라이브러리 사용 방법의 예는 공식 TFX Keras 구성요소 튜토리얼을 참고하세요.
Google Cloud의 TFX ML 시스템
프로덕션 환경에서 시스템 구성요소는 신뢰할 수 있는 플랫폼에서 대규모로 실행되어야 합니다. 다음 다이어그램은 Google Cloud에서 규모에 맞는 민첩성, 신뢰성, 성능을 보장하는 관리형 서비스를 사용하여 TFX ML 파이프라인의 각 단계를 실행하는 방법을 보여줍니다.
그림 3. Google Cloud의 TFX기반 ML 시스템
다음 표에서는 그림 3에 표시된 주요 Google Cloud 서비스를 설명합니다.
| 단계 | TFX 라이브러리 | Google Cloud 서비스 |
|---|---|---|
| 데이터 추출 및 검사 | TensorFlow 데이터 검사 | Dataflow |
| 데이터 변환 | TensorFlow Transform | Dataflow |
| 모델 학습 및 미세 조정 | TensorFlow | Vertex AI Training |
| 모델 평가 및 검사 | TensorFlow Model Analysis | Dataflow |
| 예측을 위한 모델 서빙 | TensorFlow Serving | Vertex AI Prediction |
| 모델 저장소 | 해당 사항 없음 | Vertex AI Model Registry |
- Dataflow는 Google Cloud에서 Apache Beam 파이프라인을 대규모로 실행하기 위한 안정적인 완전 관리형, 서버리스 서비스입니다. 다음 프로세스의 확장을 위해 Dataflow가 사용됩니다.
- 새로 추가되는 데이터 검사를 위한 통계 컴퓨팅
- 데이터 준비 및 변환 수행
- 대규모 데이터 세트로 모델 평가
- 평가 데이터세트의 여러 측면에서의 측정항목 컴퓨팅
- Cloud Storage는 높은 가용성과 내구성을 자랑하는 대용량 바이너리 객체 스토리지입니다.
Cloud Storage는 다음을 비롯해서 ML 파이프라인의 실행 전반에 걸쳐 생성되는 아티팩트를 호스팅합니다.
- 데이터 이상치(있는 경우)
- 변환된 데이터 및 아티팩트
- 내보낸(학습된) 모델
- 모델 평가 측정항목
- Vertex AI Training은 ML 모델을 대규모로 학습할 수 있는 관리형 서비스입니다. TensorFlow, scikit-learn, XGBoost, PyTorch용 사전 빌드 컨테이너를 사용해 모델 학습 작업을 실행할 수 있습니다. 자체 커스텀 컨테이너를 사용하여 모든 프레임워크를 실행할 수도 있습니다. 학습 인프라에서 분산 학습을 위해 가속기와 여러 노드를 사용할 수 있습니다. 또한 초매개변수 조정을 위한 확장 가능한 Bayesian 최적화 기반 서비스도 사용할 수 있습니다.
- Vertex AI Prediction은 REST API를 통해 모델을 마이크로서비스로 배포하여 학습된 모델과 온라인 예측을 사용해 일괄 예측을 실행하는 관리형 서비스입니다. 또한 이 서비스는 Vertex Explainable AI 및 Vertex AI Model Monitoring과 통합되어 모델을 이해하고 특성 또는 특성 기여 분석 편향 및 드리프트가 있을 경우 알림을 받을 수 있습니다.
- Vertex AI Model Registry를 사용하면 ML 모델의 수명 주기를 관리할 수 있습니다. 가져온 모델의 버전을 관리하고 성능 측정항목을 볼 수 있습니다. 그런 다음 모델을 일괄 예측에 사용하거나 Vertex AI Prediction을 사용해서 모델을 온라인 서빙을 위해 배포할 수 있습니다.
Vertex AI Pipelines를 사용한 ML 시스템 조정
이 문서에서는 TFX 기반 ML 시스템을 설계하고 Google Cloud에서 시스템의 각 구성요소를 대규모로 실행하는 방법을 설명합니다. 하지만 시스템의 이러한 각 구성요소를 하나로 연결하기 위해서는 조정자가 필요합니다. 조정자는 한 시퀀스에서 파이프라인을 실행하고 정의된 조건에 따라 한 단계에서 다른 단계로 자동으로 이동합니다. 예를 들어 평가 측정항목이 미리 정의된 기준을 충족할 경우 정의된 조건에 따라 모델 평가 단계 이후 모델 서빙 단계가 실행될 수 있습니다. 예를 들어 배포 인프라를 검증하고 모델을 평가하는 시간을 절약하기 위해 여러 단계를 동시에 실행할 수 있습니다. ML 파이프라인 조정은 개발 및 프로덕션 단계 모두에 유용합니다.
- 데이터 과학자는 개발 단계 중 조정을 통해 각 단계를 수동으로 실행하는 대신 ML 실험을 실행할 수 있습니다.
- 프로덕션 단계 중에는 조정을 통해 일정 또는 특정 트리거 조건을 기준으로 ML 파이프라인 실행을 자동화할 수 있습니다.
Vertex AI Pipelines를 사용한 ML
Vertex AI Pipelines는 Google Cloud 또는 기타 클라우드 플랫폼에서 파이프라인의 각 구성요소를 컨테이너화하여 실행할 수 있는 ML 파이프라인을 조정 및 자동화할 수 있는 Google Cloud 관리형 서비스입니다. 생성된 파이프라인 매개변수와 아티팩트는 계보 및 실행 추적을 지원하는 Vertex ML Metadata에 자동으로 저장됩니다. Vertex AI Pipelines 서비스는 다음과 같이 구성됩니다.
- 실험, 작업 및 실행을 관리하고 추적하기 위한 사용자 인터페이스
- 다단계 ML 워크플로 일정 조정 엔진.
- 파이프라인 및 구성요소 정의 및 조작을 위한 Python SDK.
- 실행, 모델, 데이터 세트, 기타 아티팩트에 대한 정보를 저장하는 Vertex ML Metadata 통합
Vertex AI Pipelines에서 실행되는 파이프라인은 다음으로 구성됩니다.
- 컨테이너화된 ML 작업 집합 또는 구성요소. 파이프라인 구성요소는 Docker 이미지로 패키지화되는 독립 실행형 코드입니다. 하나의 구성요소가 파이프라인에서 한 단계를 수행합니다. 입력 인수를 사용하고 아티팩트를 생성합니다.
- Python 도메인별 언어(DSL)를 통해 정의된 ML 태스크 시퀀스 지정. 업스트림 단계의 출력을 다운스트림 단계의 입력과 연결하여 워크플로의 토폴로지를 암시적으로 정의합니다. 파이프라인 정의의 한 단계가 파이프라인에서 하나의 구성요소를 호출합니다. 복잡한 파이프라인에서는 여러 구성요소가 여러 번 순서대로 실행되거나 조건부로 실행될 수 있습니다.
- 데이터 필터링 기준 및 파이프라인이 생성하는 아티팩트 저장 위치를 포함하여 파이프라인의 구성요소에 값이 전달되는 파이프라인 입력 매개변수 집합.
다음 다이어그램은 Vertex AI Pipelines의 샘플 그래프를 보여줍니다.
그림 4. Vertex AI Pipelines 샘플 그래프
Kubeflow Pipelines SDK
Kubeflow Pipelines SDK를 사용하면 구성요소를 만들고, 조정을 정의하고, 파이프라인으로 실행할 수 있습니다. Kubeflow Pipelines 구성요소에 관한 자세한 내용은 Kubeflow 문서의 구성요소 만들기를 참고하세요.
또한 TFX Pipeline DSL 및 TFX 구성요소를 사용할 수 있습니다. TFX 구성요소는 메타데이터 기능을 캡슐화합니다. 드라이버는 메타데이터 저장소를 쿼리하여 실행자에게 메타데이터를 제공합니다. 게시자는 실행자의 결과를 수락하고 이를 메타데이터에 저장합니다. 또한 메타데이터와 동일한 통합을 갖는 커스텀 구성요소를 구현할 수 있습니다. tfx.orchestration.experimental.KubeflowV2DagRunner를 사용하여 TFX 파이프라인을 Vertex AI Pipelines 호환 YAML로 컴파일할 수 있습니다. 그런 다음 실행을 위해 파일을 Vertex AI Pipelines에 제출할 수 있습니다.
다음 다이어그램은 Vertex AI Pipelines에서 컨테이너화된 태스크가 BigQuery 작업, Vertex AI(분산) 학습 작업, Dataflow 작업과 같은 다른 서비스를 호출할 수 있는 방법을 보여줍니다.
그림 5. Google Cloud 관리형 서비스를 호출하는 Vertex AI Pipelines
Vertex AI Pipelines를 사용하면 필요한 Google Cloud 서비스를 실행하여 프로덕션 ML 파이프라인을 조정하고 자동화할 수 있습니다. 그림 5에서 Vertex ML 메타데이터는 Vertex AI Pipelines의 ML 메타데이터 저장소로 작동합니다.
파이프라인 구성요소는 Google Cloud에서 TFX 관련 서비스 실행으로 제한되지 않습니다. 이러한 구성요소는 SparkML 작업을 위한 Dataproc, AutoML, 기타 컴퓨팅 워크로드를 포함하여 모든 데이터 관련 및 컴퓨팅 관련 서비스를 실행할 수 있습니다.
Vertex AI Pipelines에서 태스크를 컨테이너화하면 다음과 같은 이점이 있습니다.
- 코드 런타임에서 실행 환경을 분리합니다.
- 테스트 항목이 프로덕션에서도 동일하기 때문에 개발 환경과 프로덕션 환경 간 코드 재현성을 제공합니다.
- 파이프라인에서 각 구성요소를 격리시킵니다. 구성요소마다 고유한 런타임 버전, 다른 언어, 다른 라이브러리를 포함할 수 있습니다.
- 복잡한 파이프라인 구성을 도와줍니다.
- 파이프라인 실행 및 아티팩트의 추적성 및 재현성을 위해 Vertex ML 메타데이터와 통합됩니다.
Vertex AI Pipelines에 대한 포괄적인 소개는 제공되는 노트북 예시 목록을 참조하세요.
Vertex AI Pipelines 트리거 및 일정 조정
파이프라인을 프로덕션에 배포할 때는 ML 파이프라인 자동화 섹션에 설명된 시나리오에 따라 해당 실행을 자동화해야 합니다.
Vertex AI SDK를 사용하면 파이프라인을 프로그래매틱 방식으로 작동할 수 있습니다. google.cloud.aiplatform.PipelineJob 클래스에는 실험을 만들고 파이프라인을 배포 및 실행하기 위한 API가 포함되어 있습니다. 따라서 SDK를 사용하면 다른 서비스에서 Vertex AI Pipelines를 호출하여 스케줄러 또는 이벤트 기반 트리거를 만들 수 있습니다.
그림 6. Pub/Sub 및 Cloud Run 함수를 사용한 Vertex AI Pipelines의 여러 트리거를 보여주는 흐름도
그림 6에서는 Vertex AI Pipelines 서비스를 트리거하여 파이프라인을 실행하는 방법에 대한 예시를 볼 수 있습니다. 이 파이프라인은 Cloud Run 함수에서 Vertex AI SDK를 사용하여 트리거됩니다. Cloud Run 함수 자체가 Pub/Sub의 구독자이며 새 메시지를 기반으로 트리거됩니다. 파이프라인 실행을 트리거하려는 모든 서비스가 해당 Pub/Sub 주제에 게시할 수 있습니다. 위의 예시에는 세 가지 게시 서비스가 있습니다.
- Cloud Scheduler가 일정에 따라 메시지를 게시하여 파이프라인을 트리거합니다.
- Cloud Composer 는 BigQuery에서 새 데이터를 처리한 후 학습 파이프라인을 트리거하는 데이터 처리 워크플로와 같은 더 큰 워크플로의 일부로 메시지를 게시합니다.
- Cloud Logging은 일부 필터링 기준을 충족하는 로그를 기반으로 메시지를 게시합니다. 필터를 설정하여 새 데이터 도착 또는 Vertex AI Model Monitoring 서비스에서 생성된 편향 및 드리프트 알림을 감지할 수 있습니다.
Google Cloud에서 ML용 CI/CD 설정
Vertex AI Pipelines를 사용하면 데이터 전처리, 모델 학습 및 평가, 모델 배포를 포함하여 여러 단계가 포함된 ML 시스템을 조정할 수 있습니다. 데이터 과학 탐색 단계에서 Vertex AI Pipelines는 전체 시스템의 빠른 실험을 도와줍니다. 프로덕션 단계에서 Vertex AI Pipelines를 사용하면 새 데이터를 기준으로 파이프라인 실행을 자동화하여 ML 모델을 학습하거나 재학습할 수 있습니다.
CI/CD 아키텍처
다음 다이어그램은 Vertex AI Pipelines를 사용한 ML을 위한 CI/CD의 개요를 대략적으로 보여줍니다.
그림 7: Vertex AI Pipelines를 사용한 CI/CD의 대략적인 개요
이 아키텍처에서 핵심은 Cloud Build입니다. Cloud Build는 Artifact Registry, GitHub, Bitbucket에서 소스를 가져오고, 사양에 맞게 빌드를 실행하고, Docker 컨테이너 또는 Python tar 파일과 같은 아티팩트를 생성할 수 있습니다.
Cloud Build는 빌드 구성 파일(cloudbuild.yaml)에 정의된 일련의 빌드 단계에 따라 빌드를 실행합니다. 각 빌드 단계는 Docker 컨테이너에서 실행됩니다. Cloud Build에서 제공하는 지원되는 빌드 단계를 사용하거나 고유 빌드 단계를 작성할 수 있습니다.
ML 시스템에 필요한 CI/CD를 실행하는 Cloud Build 프로세스는 수동으로 또는 자동화된 빌드 트리거를 통해 실행될 수 있습니다. 트리거는 변경사항이 빌드 소스에 푸시될 때마다 구성된 빌드 단계를 실행합니다. 소스 저장소 변경사항에 따라 빌드 루틴을 실행하거나 변경사항이 특정 기준과 일치할 때만 빌드 루틴을 실행하도록 빌드 트리거를 설정할 수 있습니다.
또한 여러 트리거에 따라 실행되는 빌드 루틴(Cloud Build 구성 파일)을 지정할 수 있습니다. 예를 들어 개발 브랜치 또는 기본 브랜치에 커밋이 수행될 때 트리거되는 빌드 루틴을 사용할 수 있습니다.
구성 변수 대체 항목을 사용하여 빌드 시 환경 변수를 정의할 수 있습니다. 이러한 대체 항목은 트리거된 빌드에서 캡처됩니다. 이러한 변수에는 $COMMIT_SHA, $REPO_NAME, $BRANCH_NAME, $TAG_NAME, $REVISION_ID가 포함됩니다. 트리거를 기준으로 하지 않는 다른 변수는 $PROJECT_ID 및 $BUILD_ID입니다. 대체 항목은 빌드할 때까지 값을 알 수 없는 변수에 유용하며 다른 변수 값을 사용하여 기존 빌드 요청을 다시 사용하는 데 유용합니다.
CI/CD 워크플로 사용 사례
소스 코드 저장소에는 일반적으로 다음 항목이 포함됩니다.
- 파이프라인 워크플로가 정의된 Python 파이프라인 워크플로 소스 코드
- Python 파이프라인 구성요소 소스 코드와 데이터 검증, 데이터 변환, 모델 학습, 모델 평가, 모델 서빙 등 다양한 파이프라인 구성요소에 해당하는 구성요소 사양 파일
- 각 파이프라인 구성요소별로 Docker 컨테이너 이미지를 만드는 데 필요한 Dockerfile
- 구성요소 및 전체 파이프라인에 구현된 메서드를 테스트하기 위한 Python 단위 테스트 및 통합 테스트
cloudbuild.yaml파일, 테스트 트리거, 파이프라인 배포를 포함한 기타 스크립트- 파이프라인 입력 매개변수에 대한 구성을 포함하는 구성 파일(예:
settings.yaml파일) - 모델에 대한 실험적 데이터 분석, 모델 분석, 대화형 환경에 사용되는 Notebooks
다음 예시에서 빌드 루틴은 개발자가 데이터 과학 환경에서 개발 브랜치로 소스 코드를 푸시할 때 트리거됩니다.
그림 8. Cloud Build에서 수행되는 빌드 단계 예시
Cloud Build는 일반적으로 그림 7에 표시된 다음 빌드 단계를 실행합니다.
- 소스 코드 저장소가 Cloud Build 런타임 환경의
/workspace디렉터리 아래에 복사됩니다. - 단위 테스트 및 통합 테스트를 실행합니다.
- 선택사항: Pylint와 같은 분석 도구를 사용하여 정적 코드 분석을 실행합니다.
- 테스트에 통과하면 각 파이프라인 구성요소마다 Docker 컨테이너 이미지가 하나씩 빌드됩니다. 이미지에
$COMMIT_SHA매개변수로 태그 지정됩니다. - Docker 컨테이너 이미지가 Artifact Registry에 업로드됩니다 (그림 7 참고).
- 생성되고 태그 지정된 Docker 컨테이너 이미지가 포함된 각
component.yaml파일에서 이미지 URL이 업데이트됩니다. - 파이프라인 워크플로가 컴파일되어
pipeline.json파일을 생성합니다. pipeline.json파일이 Artifact Registry에 업로드됩니다.- 선택사항: 통합 테스트 또는 프로덕션 실행 중 매개변수 값으로 파이프라인을 실행합니다. 실행된 파이프라인은 새 모델을 생성하며 Vertex AI Prediction에서 모델을 API로 배포할 수도 있습니다.
Cloud Build를 사용한 CI/CD를 포함하는 프로덕션에 즉시 사용 가능한 엔드 투 엔드 MLOps의 예시는 GitHub의 Vertex Pipelines 엔드 투 엔드 샘플을 참고하세요.
추가 고려사항
Google Cloud에서 ML CI/CD 아키텍처를 설정할 때는 다음을 고려하세요.
- 데이터 과학 환경의 경우 로컬 머신 또는 Vertex AI Workbench를 사용할 수 있습니다.
- 문서 파일이 수정되었거나 실험 메모장이 수정된 것과 같은 경우에만 트리거를 건너뛰도록 자동화된 Cloud Build 파이프라인을 구성할 수 있습니다.
- 빌드 테스트로 통합 및 회귀 테스트를 수행하기 위해 파이프라인을 실행할 수 있습니다. 파이프라인이 대상 환경에 배포되기 전
wait()메서드를 사용하여 제출된 파이프라인의 실행이 완료될 때까지 기다릴 수 있습니다. - Cloud Build를 사용하는 대신 Jenkins와 같은 다른 빌드 시스템을 사용할 수 있습니다. 즉시 배포 가능한 Jenkins는 Google Cloud Marketplace에서 제공됩니다.
- 여러 트리거를 기준으로 개발, 테스트, 스테이징을 포함하여 서로 다른 환경에 자동으로 배포되도록 파이프라인을 구성할 수 있습니다. 또한 일반적으로 출시 승인을 얻은 후 프리 프로덕션 또는 프로덕션과 같은 특정 환경에 수동으로 배포할 수 있습니다. 서로 다른 트리거 또는 서로 다른 대상 환경에 대해 여러 빌드 루틴을 사용할 수 있습니다.
- 완전 관리형 Cloud Composer 서비스를 사용하여 실행할 수 있는 범용 워크플로를 위한 인기 있는 조정 및 일정 프레임워크인 Apache Airflow를 사용할 수 있습니다. Cloud Composer 및 Cloud Build로 데이터 파이프라인을 조정하는 방법에 대한 자세한 내용은 데이터 처리 워크플로를 위한 CI/CD 파이프라인 설정을 참조하세요.
- 모델의 새 버전을 프로덕션에 배포할 때는 수행 상태 (CPU, 메모리, 디스크 사용량)를 확인하기 위해 카나리아 릴리스로 배포합니다. 모든 라이브 트래픽을 제공하도록 새 모델을 구성하기 전에 A/B 테스트를 수행할 수도 있습니다. 라이프 트래픽의 10%~20%를 제공하도록 새 모델을 구성합니다. 새 모델이 현재 모델보다 수행 성능이 뛰어나면 새 모델이 모든 트래픽을 제공하도록 구성할 수 있습니다. 그렇지 않으면 제공 시스템이 현재 모델로 롤백됩니다.
다음 단계
- Cloud Build를 사용한 GitOps 스타일의 지속적 배포 자세히 알아보기
- 데이터 처리 워크플로를 위한 CI/CD 파이프라인 설정 자세히 알아보기
- Google Cloud의 AI 및 ML 워크로드와 관련된 원칙 및 권장사항에 관한 개요는 아키텍처 프레임워크의 AI 및 ML 관점을 참고하세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.
참여자
저자:
기타 참여자: 와이트 고만 | HPC 솔루션 관리자