데이터 처리 워크플로용 CI/CD 파이프라인 설정

Last reviewed 2023-04-20 UTC

이 튜토리얼에서는 Google Cloud에서 관리 제품으로 CI/CD 메서드를 구현하여 데이터 처리를 위한 지속적 통합/지속적 배포(CI/CD) 파이프라인을 설정하는 방법을 설명합니다. 데이터과학자와 분석가들이 CI/CD 방식의 방법론을 채택하면 데이터 프로세스 및 워크플로의 고품질, 유지 관리성, 조정 가능성을 보장하는 데 도움이 될 수 있습니다. 다음과 같은 응용이 가능합니다.

소스 코드의 버전 관리
앱의 자동 빌드, 테스트, 배포
프로덕션에서의 환경 격리 및 분리
복제 가능한 환경 설정 절차

이 튜토리얼은 데이터 처리 워크로드를 체계적이고 자동으로 유지관리할 수 있도록 연구 개발(R&D)을 구조화하는 데 도움이 될 반복 실행되는 데이터 처리 작업을 빌드하는 데이터과학자 및 분석가를 대상으로 합니다.

배포 아키텍처

이 튜토리얼에서는 다음 Google Cloud 제품을 사용합니다.

Cloud Build: 데이터 처리 워크플로 및 데이터 처리 자체를 빌드, 배포, 테스트하는 CI/CD 파이프라인을 만듭니다. Cloud Build는 Google Cloud에서 빌드를 실행하는 관리형 서비스입니다. 빌드는 각 단계가 Docker 컨테이너에서 실행되는 일련의 빌드 단계입니다.
Cloud Composer: 데이터 처리, 테스트, 결과 확인 등의 워크플로 단계를 정의하고 실행합니다. Cloud Composer는 이 튜토리얼의 데이터 처리 워크플로와 같은 복잡한 워크플로를 생성, 예약, 모니터링, 관리할 수 있는 환경을 제공하는 관리형 Apache Airflow 서비스입니다.
Dataflow를 사용하여 Apache Beam WordCount 예시를 샘플 데이터 처리로 실행합니다.

CI/CD 파이프라인

CI/CD 파이프라인을 구성하는 단계는 대략 다음과 같습니다.

Cloud Build에서 WordCount 샘플을 Maven 빌더를 사용해 자체 실행되는 자바 아카이브(JAR) 파일로 패키지화합니다. Maven 빌더는 Maven이 설치된 컨테이너입니다. Maven 빌더를 사용하도록 빌드 단계를 구성하면 Maven에서 태스크를 실행합니다.
Cloud Build에서 JAR 파일을 Cloud Storage로 업로드합니다.
Cloud Build가 데이터 처리 워크플로 코드에 대한 단위 테스트를 실행하고 워크플로 코드를 Cloud Composer에 배포합니다.
Cloud Composer가 JAR 파일을 선택해 Dataflow에서 데이터 처리 작업을 실행합니다.

다음 다이어그램은 CI/CD 파이프라인 단계를 자세히 보여줍니다.

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에 배포됩니다.

이 튜토리얼에서는 모든 데이터 처리 워크플로에 대한 통합 뷰를 제공하기 위해 프로덕션 데이터 처리 워크플로를 테스트 워크플로와 동일한 Cloud Composer 환경에 배포합니다. 튜토리얼의 목적에 맞게 이와 같은 환경은 입력 및 출력 데이터를 보관하는 서로 다른 Cloud Storage 버킷을 사용해 구분합니다.

환경을 완전히 구분하기 위해서는 다양한 프로젝트에서 생성되어 기본적으로 서로 분리된 여러 Cloud Composer 환경이 필요합니다. 이렇게 분리하면 프로덕션 환경의 보안에 도움이 됩니다. 이 접근 방식은 이 튜토리얼에서는 다루지 않습니다. 여러 Google Cloud 프로젝트에서 리소스에 액세스하는 방법에 대한 자세한 내용은 서비스 계정 권한 설정을 참조하세요.

데이터 처리 워크플로

Cloud Composer가 데이터 처리 워크플로를 실행하는 방법에 대한 안내는 Python으로 작성된 Directed Acyclic Graph(DAG)에서 제공하고 있습니다. DAG에는 데이터 처리 워크플로의 전 단계가 종속 항목과 함께 정의되어 있습니다.

CI/CD 파이프라인에서 DAG 정의를 Cloud Source Repositories에서 각 빌드의 Cloud Composer로 자동으로 배포합니다. 이 프로세스는 수동 작업 없이 Cloud Composer가 항상 최신 워크플로 정의를 통해 최신 상태를 유지하도록 보장합니다.

테스트 환경용 DAG 정의에는 데이터 처리 워크플로 외에 엔드 투 엔드 테스트 단계가 정의되어 있습니다. 테스트 단계는 데이터 처리 워크플로가 올바르게 실행되는 데 도움을 줍니다.

다음 다이어그램은 데이터 처리 워크플로를 보여줍니다.

4단계 데이터 처리 워크플로

데이터 처리 워크플로는 다음과 같은 단계로 구성됩니다.

Dataflow에서 WordCount 데이터 처리를 실행합니다.
WordCount 프로세스의 결과 파일을 다운로드합니다. WordCount 프로세스는 3개의 결과 파일을 생성합니다.
- download_result_1
- download_result_2
- download_result_3
download_ref_string이라는 참조 파일을 다운로드합니다.
참조 파일을 기준으로 결과를 확인합니다. 이 통합 테스트에서는 결과 3개를 모두 집계하여 집계된 결과를 참조 파일과 비교합니다.
통합 테스트가 통과한 후 Pub/Sub에 메시지를 게시합니다.

Cloud Composer와 같은 태스크 조정 프레임워크를 사용해 데이터 처리 워크플로를 관리하면 워크플로의 코드 복잡성을 완화하는 데 도움이 됩니다.

테스트

이 튜토리얼에는 엔드 투 엔드 데이터 처리 워크플로를 확인하는 통합 테스트 외에 2개의 단위 테스트가 나와 있습니다. 이러한 단위 테스트는 데이터 처리 코드 및 데이터 처리 워크플로 코드를 자동으로 테스트해 줍니다. 데이터 처리 코드 테스트는 자바로 작성되며 Maven 빌드 프로세스 중에 자동으로 실행됩니다. 데이터 처리 워크플로 코드 테스트는 Python으로 작성되며 독립적인 빌드 단계로 실행됩니다.

목표

Cloud Composer 환경을 구성합니다.
데이터를 저장할 Cloud Storage 버킷을 만듭니다.
빌드, 테스트, 프로덕션 파이프라인을 만듭니다.
빌드 트리거를 구성합니다.

비용

이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

프로젝트 선택기로 이동

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

API Cloud Build, Cloud Source Repositories, Cloud Composer, and Dataflow 사용 설정

API 사용 설정

Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

프로젝트 선택기로 이동

Google Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다.

API Cloud Build, Cloud Source Repositories, Cloud Composer, and Dataflow 사용 설정

API 사용 설정

샘플 코드

샘플 코드는 다음과 같은 두 폴더에 있습니다.

env-setup 폴더에는 Google Cloud 환경의 초기 설정을 위한 셸 스크립트가 있습니다.
source-code 폴더에는 시간 경과에 따라 개발되고 소스를 제어해야 하며 자동 빌드 및 테스트 프로세스를 트리거하는 코드가 있습니다. 이 폴더에는 다음과 같은 하위 폴더가 있습니다.
- data-processing-code 폴더에는 Apache Beam 프로세스 소스 코드가 있습니다.
- workflow-dag 폴더에는 Cloud Dataflow 프로세스를 설계, 구현, 테스트하는 단계가 포함된 데이터 처리 워크플로에 대한 Composer DAG 정의가 있습니다.
- build-pipeline 폴더에는 테스트 파이프라인 및 프로덕션 파이프라인용으로 2개의 Cloud Build 구성이 있습니다. 이 폴더에는 파이프라인의 지원 스크립트도 있습니다.

튜토리얼의 목적에 맞게 데이터 처리 및 DAG 워크플로의 소스 코드 파일은 동일한 소스 코드 저장소 내 다른 폴더에 위치해 있습니다. 프로덕션 환경에서는 소스 코드 파일이 보통 자체 소스 코드 저장소에 위치하며 다른 팀에서 관리합니다.

환경 설정

이 튜토리얼에서는 Cloud Shell에서 명령어를 실행합니다. Cloud Shell은 Google Cloud Console 하단에 창으로 표시됩니다.

Google Cloud Console에서 Cloud Shell을 엽니다.

Cloud Shell 열기

샘플 코드 저장소를 클론합니다.

git clone https://github.com/GoogleCloudPlatform/ci-cd-for-data-processing-workflow.git

스크립트를 실행하여 환경 변수를 설정합니다.
```
cd ~/ci-cd-for-data-processing-workflow/env-setup
source set_env.sh
```
스크립트에서 설정하는 환경 변수는 다음과 같습니다.
- Google Cloud 프로젝트 ID
- 리전 및 영역
- 빌드 파이프라인 및 데이터 처리 워크플로에서 사용하는 Cloud Storage 버킷의 이름
환경 변수는 세션 간에 유지되지 않으므로 튜토리얼을 진행하는 동안 Cloud Shell 세션이 종료되거나 연결이 끊어지면 환경 변수를 재설정해야 합니다.

Cloud Composer 환경 만들기

이 튜토리얼에서는 Cloud Composer 환경을 설정합니다.

Cloud Shell에서 Cloud Composer v2 API 서비스 에이전트 확장(roles/composer.ServiceAgentV2Ext) 역할을 Cloud Composer 서비스 에이전트 계정에 추가합니다.

gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
    --member serviceAccount:service-$PROJECT_NUMBER@cloudcomposer-accounts.iam.gserviceaccount.com \
    --role roles/composer.ServiceAgentV2Ext

Cloud Shell에서 Cloud Composer 환경을 만듭니다.
```
gcloud composer environments create $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION \
    --image-version composer-2.0.14-airflow-2.2.5
```
참고: Cloud Composer 환경을 프로비저닝하는 데는 대개 약 15분이 걸리지만 최대 1시간이 걸리기도 합니다. 이 과정이 완료될 때까지 기다렸다가 다음 단계를 계속 진행하세요.
스크립트를 실행하여 Cloud Composer 환경의 변수를 설정합니다. 이 변수는 데이터 처리 DAG에 필요합니다.
```
cd ~/ci-cd-for-data-processing-workflow/env-setup
chmod +x set_composer_variables.sh
./set_composer_variables.sh
```
스크립트에서 설정하는 환경 변수는 다음과 같습니다.
- Google Cloud 프로젝트 ID
- 리전 및 영역
- 빌드 파이프라인 및 데이터 처리 워크플로에서 사용하는 Cloud Storage 버킷의 이름

Cloud Composer 환경 속성 추출

Cloud Composer는 Cloud Storage 버킷을 사용하여 DAG를 저장합니다. DAG 정의 파일을 버킷으로 옮기면 Cloud Composer에서 자동으로 파일을 읽습니다. Cloud Composer용 Cloud Storage 버킷은 Cloud Composer 환경을 만들 때 생성됩니다. 다음 절차에서는 버킷의 URL을 추출한 후 DAG 정의를 Cloud Storage 버킷에 자동으로 배포하도록 CI/CD 파이프라인을 구성합니다.

Cloud Shell에서 버킷의 URL을 환경 변수로 내보냅니다.

export COMPOSER_DAG_BUCKET=$(gcloud composer environments describe $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION \
    --format="get(config.dagGcsPrefix)")

Cloud Storage 버킷에 액세스하기 위해 Cloud Composer에서 사용하는 서비스 계정의 이름을 내보냅니다.

export COMPOSER_SERVICE_ACCOUNT=$(gcloud composer environments describe $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION \
    --format="get(config.nodeConfig.serviceAccount)")

Cloud Storage 버킷 만들기

이 섹션에서는 다음 항목을 저장하는 Cloud Storage 버킷 모음을 만듭니다.

빌드 프로세스 중간 단계의 아티팩트
데이터 처리 워크플로에 사용되는 입력 및 출력 파일
Dataflow 작업에서 바이너리 파일을 저장하는 스테이징 위치

Cloud Storage 버킷을 만들려면 다음 단계를 완료하세요.

Cloud Shell에서 Cloud Storage 버킷을 만들고 데이터 처리 워크플로를 실행할 수 있는 Cloud Composer 서비스 계정 권한을 부여합니다.
```
cd ~/ci-cd-for-data-processing-workflow/env-setup
chmod +x create_buckets.sh
./create_buckets.sh
```

Pub/Sub 주제 만들기

이 섹션에서는 데이터 처리 워크플로 통합 테스트에서 전송된 메시지를 수신하여 프로덕션 빌드 파이프라인을 자동으로 트리거하는 Pub/Sub 주제를 만듭니다.

Google Cloud Console에서 Pub/Sub 주제 페이지로 이동합니다.

주제 페이지로 이동
주제 만들기를 클릭합니다.
주제를 구성하려면 다음 단계를 완료하세요.
- 주제 ID에 integration-test-complete-topic을 입력합니다.
- 기본 구독 추가 옵션이 선택되어 있는지 확인합니다.
- 나머지 옵션은 선택하지 않은 상태로 둡니다.
- 암호화에서 Google 관리 암호화 키를 선택합니다.
- 주제 만들기를 클릭합니다.

Cloud Source Repositories로 소스 코드 푸시

이 튜토리얼에는 버전 관리에 입력해야 할 소스 코드베이스가 하나 있습니다. 다음 단계에서는 코드베이스 개발 방법과 시간에 따른 변경사항을 보여줍니다. 변경사항이 저장소에 푸시될 때마다 빌드, 배포, 테스트 파이프라인이 트리거됩니다.

Cloud Shell에서 source-code 폴더를 Cloud Source Repositories로 푸시합니다.

gcloud source repos create $SOURCE_CODE_REPO
cp -r ~/ci-cd-for-data-processing-workflow/source-code ~/$SOURCE_CODE_REPO
cd ~/$SOURCE_CODE_REPO
git init
git remote add google \
    https://source.developers.google.com/p/$GCP_PROJECT_ID/r/$SOURCE_CODE_REPO
git add .
git commit -m 'initial commit'
git push google master

이는 Git을 새 디렉터리에서 초기화하고 콘텐츠를 원격 저장소로 푸시하는 표준 명령어입니다.

Cloud Build 파이프라인 만들기

이 섹션에서는 데이터 처리 워크플로를 빌드, 배포, 테스트하는 빌드 파이프라인을 만듭니다.

Cloud Build 서비스 계정에 액세스 권한 부여

Cloud Build는 Cloud Composer DAG를 배포하고 Cloud Build 서비스 계정에 액세스 권한을 추가할 때 사용 설정되는 워크플로를 트리거합니다. Cloud Composer 작업 시 사용할 수 있는 다양한 역할에 대한 자세한 내용은 액세스 제어 문서를 참조하세요.

Cloud Shell에서 Cloud Build 서비스 계정에 composer.admin 역할을 추가하여 Cloud Composer에서 Cloud Build 작업이 Airflow 변수를 설정할 수 있도록 합니다.
```
gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
    --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
    --role=roles/composer.admin
```

Cloud Build 작업이 Cloud Composer에서 데이터 워크플로를 트리거할 수 있도록 Cloud Build 서비스 계정에 composer.worker 역할을 추가합니다.

gcloud projects add-iam-policy-binding $GCP_PROJECT_ID \
    --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
    --role=roles/composer.worker

빌드 및 테스트 파이프라인 만들기

빌드 및 테스트 파이프라인 단계는 YAML 구성 파일에 구성됩니다. 이 튜토리얼에서는 git, maven, gsutil, gcloud에 사전 빌드된 빌더 이미지를 사용하여 각 빌드 단계에서 작업을 실행합니다. 구성 변수 대체 항목을 사용하면 빌드 시 환경 설정을 정의할 수 있습니다. 소스 코드 저장소 위치는 변수 대체 항목과 Cloud Storage 버킷의 위치를 사용해 정의됩니다. JAR 파일, 테스트 파일, DAG 정의를 배포하려면 빌드에 이 정보가 필요합니다.

Cloud Shell에서 빌드 파이프라인 구성 파일을 제출하여 Cloud Build에 파이프라인을 만듭니다.
```
cd ~/ci-cd-for-data-processing-workflow/source-code/build-pipeline
gcloud builds submit --config=build_deploy_test.yaml --substitutions=\
REPO_NAME=$SOURCE_CODE_REPO,\
_DATAFLOW_JAR_BUCKET=$DATAFLOW_JAR_BUCKET_TEST,\
_COMPOSER_INPUT_BUCKET=$INPUT_BUCKET_TEST,\
_COMPOSER_REF_BUCKET=$REF_BUCKET_TEST,\
_COMPOSER_DAG_BUCKET=$COMPOSER_DAG_BUCKET,\
_COMPOSER_ENV_NAME=$COMPOSER_ENV_NAME,\
_COMPOSER_REGION=$COMPOSER_REGION,\
_COMPOSER_DAG_NAME_TEST=$COMPOSER_DAG_NAME_TEST
```
이 명령어는 Cloud Build가 다음 단계를 통해 빌드를 실행하도록 지시합니다.
1. WordCount 자체 실행 JAR 파일을 빌드하고 배포합니다.
  1. 소스 코드를 확인합니다.
  2. WordCount Beam 소스 코드를 자체 실행 JAR 파일로 컴파일합니다.
  3. Cloud Composer에서 선택해 WordCount 처리 작업을 실행할 수 있도록 JAR 파일을 Cloud Storage에 저장합니다.
2. Cloud Composer에 데이터 처리 워크플로를 배포하고 설정합니다.
  1. 워크플로 DAG가 사용하는 커스텀 연산자 코드에 대한 단위 테스트를 실행합니다.
  2. 테스트 입력 파일 및 테스트 참조 파일을 Cloud Storage에 배포합니다. 테스트 입력 파일은 WordCount 처리 작업에 대한 입력입니다. 테스트 참조 파일은 WordCount 처리 작업의 결과를 확인할 때 참조로 사용됩니다.
  3. 새로 빌드된 JAR 파일을 가리키도록 Cloud Composer 변수를 설정합니다.
  4. 워크플로 DAG 정의를 Cloud Composer 환경에 배포합니다.
3. 테스트 환경에서 데이터 처리 워크플로를 실행하여 테스트 처리 워크플로를 트리거합니다.

빌드 및 테스트 파이프라인 확인

빌드 파일을 제출한 후에 빌드 단계를 확인합니다.

Google Cloud Console에서 빌드 기록 페이지로 이동하여 이전 및 현재 실행 중인 빌드 목록을 확인합니다.

빌드 기록 페이지로 이동
현재 실행 중인 빌드를 클릭합니다.
빌드 세부정보 페이지에서 빌드 단계가 앞에서 설명한 단계와 일치하는지 확인합니다.

빌드가 완료되면 빌드 세부정보 페이지에서 빌드의 상태 필드에 Build successful이라고 표시됩니다.

Cloud Shell에서 WordCount 샘플 JAR 파일이 올바른 버킷에 복사되었는지 확인합니다.

gsutil ls gs://$DATAFLOW_JAR_BUCKET_TEST/dataflow_deployment*.jar

출력은 다음과 비슷합니다.

gs://…-composer-dataflow-source-test/dataflow_deployment_e88be61e-50a6-4aa0-beac-38d75871757e.jar

Cloud Composer 웹 인터페이스 URL을 가져옵니다. 이 URL은 다음 단계에서 사용되므로 기록해 둡니다.

gcloud composer environments describe $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION \
    --format="get(config.airflowUri)"

이전 단계의 URL을 사용해 Cloud Composer UI로 이동하여 DAG가 성공적으로 실행되었는지 확인합니다. 실행 열에 어떤 정보도 표시되지 않으면 몇 분 후에 페이지를 새로고침합니다.
1. 데이터 처리 워크플로 DAG test_word_count가 배포되었고 실행 모드인지 확인하려면 실행 아래에 있는 밝은 녹색 원 모양 위로 마우스 포인터를 가져가 실행 중으로 표시되는지 확인합니다.
2. 실행 중인 데이터 처리 워크플로를 그래프로 확인하려면 밝은 녹색 원 모양을 클릭한 후 Dag 실행 페이지에서 Dag Id: test_word_count를 클릭합니다.
3. 그래프 보기 페이지를 새로고침하여 현재의 DAG 실행 상태를 업데이트합니다. 워크플로를 완료하는 데 일반적으로 3~5분이 소요됩니다. DAG 실행이 성공적으로 완료되었는지 확인하려면 각 태스크 위로 마우스 포인터를 가져가 도움말에 상태: 성공이라고 표시되는지 확인합니다. do_comparison이라는 마지막에서 두 번째 작업은 참조 파일에 대한 프로세스 출력을 확인하는 통합 테스트입니다.
통합 테스트가 완료되면 publish_test_complete이라는 마지막 작업이 프로덕션 빌드 파이프라인을 트리거하는 데 사용될 integration-test-complete-topic Pub/Sub 주제에 메시지를 게시합니다.
1. 게시된 메시지가 최신 JAR 파일에 대해 올바른 참조를 포함하는지 확인하려면 기본 integration-test-complete-topic-sub Pub/Sub 구독에서 메시지를 가져오면 됩니다.
2. Google Cloud Console에서 구독 페이지로 이동합니다.
  
  구독 페이지로 이동
3. integration-test-complete-topic-sub를 클릭하고, 메시지 탭을 선택하고, 가져오기를 클릭합니다.
4. 출력은 다음과 비슷하게 표시됩니다.

프로덕션 파이프라인 만들기

테스트 처리 워크플로가 성공적으로 실행되면 현재 버전의 워크플로를 프로덕션 환경으로 승격할 수 있습니다. 프로덕션 환경에 워크플로를 배포하는 방법에는 몇 가지가 있습니다.

수동
테스트 또는 스테이징 환경에서 모든 테스트를 통과하면 자동으로 트리거
예약된 작업으로 자동으로 트리거

이 튜토리얼에서는 테스트 환경에서 모든 테스트가 통과할 때 자동으로 프로덕션 빌드를 트리거합니다. 자동화된 접근 방식에 대한 자세한 내용은 출시 엔지니어링을 참조하세요.

자동화된 방식을 구현하기 전에 프로덕션에 대한 수동 배포를 수행하여 프로덕션 배포 빌드를 확인합니다. 프로덕션 배포 빌드 과정은 다음 단계를 따릅니다.

WordCount JAR 파일을 테스트 버킷에서 프로덕션 버킷으로 복사합니다.
새로 승격된 JAR 파일을 가리키도록 프로덕션 워크플로용 Cloud Composer 변수를 설정합니다.
Cloud Composer 환경에서 프로덕션 워크플로 DAG 정의를 배포하고 워크플로를 실행합니다.

변수 대체 항목으로 프로덕션 처리 워크플로에서 사용되는 Cloud Storage 버킷과 프로덕션에 배포되는 최신 JAR 파일의 이름을 정의합니다. 프로덕션 Airflow 워크플로를 배포하는 Cloud Build 파이프라인을 만들려면 다음 단계를 완료하세요.

Cloud Shell에서 최신 JAR 파일 이름에 대한 Cloud Composer 변수를 인쇄하여 최신 JAR 파일의 파일 이름을 읽습니다.

export DATAFLOW_JAR_FILE_LATEST=$(gcloud composer environments run $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION variables get -- \
    dataflow_jar_file_test 2>&1 | grep -i '.jar')

빌드 파이프라인 구성 파일 deploy_prod.yaml,을 사용하여 Cloud Build에서 파이프라인을 만듭니다.

cd ~/ci-cd-for-data-processing-workflow/source-code/build-pipeline
gcloud builds submit --config=deploy_prod.yaml --substitutions=\
REPO_NAME=$SOURCE_CODE_REPO,\
_DATAFLOW_JAR_BUCKET_TEST=$DATAFLOW_JAR_BUCKET_TEST,\
_DATAFLOW_JAR_FILE_LATEST=$DATAFLOW_JAR_FILE_LATEST,\
_DATAFLOW_JAR_BUCKET_PROD=$DATAFLOW_JAR_BUCKET_PROD,\
_COMPOSER_INPUT_BUCKET=$INPUT_BUCKET_PROD,\
_COMPOSER_ENV_NAME=$COMPOSER_ENV_NAME,\
_COMPOSER_REGION=$COMPOSER_REGION,\
_COMPOSER_DAG_BUCKET=$COMPOSER_DAG_BUCKET,\
_COMPOSER_DAG_NAME_PROD=$COMPOSER_DAG_NAME_PROD

프로덕션 파이프라인에서 만든 데이터 처리 워크플로 확인

Cloud Composer UI의 URL을 가져옵니다.

gcloud composer environments describe $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION \
    --format="get(config.airflowUri)"

프로덕션 데이터 처리 워크플로 DAG가 배포되었는지 확인하려면 이전 단계에서 가져온 URL로 이동하여 prod_word_count DAG가 DAG 목록에 있는지 확인합니다.
1. DAG 페이지의 prod_word_count 행에서 DAG 트리거를 클릭합니다.
Airflow 로고를 클릭하거나 페이지를 새로고침하여 DAG 실행 상태를 업데이트합니다. 실행 열의 밝은 녹색 원은 DAG가 현재 실행 중임을 나타냅니다. 원 위에 마우스 포인터를 올려놓으면 실행 중이라는 도움말이 표시됩니다.
실행에 성공한 후 DAG 실행 열 아래에 있는 진한 녹색 원 모양 위로 마우스 포인터를 가져가 성공이라고 표시되는지 확인합니다.

Cloud Shell에서 Cloud Storage 버킷에 결과 파일을 나열합니다.

gsutil ls gs://$RESULT_BUCKET_PROD

출력은 다음과 비슷합니다.

gs://…-composer-result-prod/output-00000-of-00003
gs://…-composer-result-prod/output-00001-of-00003
gs://…-composer-result-prod/output-00002-of-00003

Cloud Build 트리거 만들기

이 섹션에서는 소스 코드 변경사항을 테스트 빌드 프로세스에 연결하고 테스트 파이프라인과 프로덕션 빌드 파이프라인 사이에 연결하는 Cloud Build 트리거를 만듭니다.

테스트 빌드 파이프라인 트리거 구성

변경사항이 소스 저장소의 마스터 분기에 푸시될 때 새 빌드를 트리거하는 Cloud Build 트리거를 설정합니다.

Google Cloud Console에서 빌드 트리거 페이지로 이동합니다.

빌드 트리거 페이지로 이동
트리거 만들기를 클릭합니다.
트리거 설정을 구성하려면 다음 단계를 완료하세요.
- 이름 필드에 trigger-build-in-test-environment를 입력합니다.
- 리전 드롭다운에서 전역(비 리전)을 선택합니다.
- 이벤트에서 분기로 푸시를 클릭합니다.
- 소스에서 data-pipeline-source를 선택합니다.
- 분기 이름 필드에 master를 입력합니다.
- 구성에서 Cloud Build 구성 파일(yaml 또는 json)을 클릭합니다.
- 위치에 대해 저장소를 클릭합니다.
- Cloud Build 구성 파일 위치 필드에 build-pipeline/build_deploy_test.yaml을 입력합니다.

Cloud Shell에서 다음 명령어를 실행하여 빌드에 필요한 모든 대체 변수를 가져옵니다. 이후 단계에서 필요하므로 이 값을 기록해 둡니다.

echo "_COMPOSER_DAG_BUCKET : ${COMPOSER_DAG_BUCKET}
_COMPOSER_DAG_NAME_TEST : ${COMPOSER_DAG_NAME_TEST}
_COMPOSER_ENV_NAME : ${COMPOSER_ENV_NAME}
_COMPOSER_INPUT_BUCKET : ${INPUT_BUCKET_TEST}
_COMPOSER_REF_BUCKET : ${REF_BUCKET_TEST}
_COMPOSER_REGION : ${COMPOSER_REGION}
_DATAFLOW_JAR_BUCKET : ${DATAFLOW_JAR_BUCKET_TEST}"

참고: 출력 이름/값 쌍은 다음 단계에 사용됩니다.

트리거 설정 페이지의 고급, 대체 변수에서 변수를 이전 단계에서 가져온 환경 값으로 바꿉니다. 다음 항목을 한 번에 하나씩 추가하고 이름-값 쌍마다 + 항목 추가를 클릭합니다.
- _COMPOSER_DAG_BUCKET
- _COMPOSER_DAG_NAME_TEST
- _COMPOSER_ENV_NAME
- _COMPOSER_INPUT_BUCKET
- _COMPOSER_REF_BUCKET
- _COMPOSER_REGION
- _DATAFLOW_JAR_BUCKET
만들기를 클릭합니다.

프로덕션 빌드 파이프라인 트리거 구성

테스트 환경에서 테스트가 통과하고 메시지가 tests-complete Pub/Sub 주제에 게시될 때 프로덕션 빌드를 트리거하는 Cloud Build 트리거를 설정합니다. 이 트리거는 프로덕션 파이프라인이 실행되기 전 빌드를 수동으로 승인해야 하는 승인 단계를 포함합니다.

Google Cloud Console에서 빌드 트리거 페이지로 이동합니다.

빌드 트리거 페이지로 이동
트리거 만들기를 클릭합니다.
트리거 설정을 구성하려면 다음 단계를 완료하세요.
- 이름 필드에 trigger-build-in-prod-environment를 입력합니다.
- 리전 드롭다운에서 전역(비 리전)을 선택합니다.
- 이벤트에 대해 Pub/Sub 메시지를 클릭합니다.
- 구독에 대해 integration-test-complete-topic을 선택합니다.
- 소스에서 data-pipeline-source를 선택합니다.
- 버전에 대해 분기를 선택합니다.
- 분기 이름 필드에 master를 입력합니다.
- 구성에서 Cloud Build 구성 파일(yaml 또는 json)을 클릭합니다.
- 위치에 대해 저장소를 클릭합니다.
- Cloud Build 구성 파일 위치 필드에 build-pipeline/deploy_prod.yaml을 입력합니다.

Cloud Shell에서 다음 명령어를 실행하여 빌드에 필요한 모든 대체 변수를 가져옵니다. 이후 단계에서 필요하므로 이 값을 기록해 둡니다.

echo "_COMPOSER_DAG_BUCKET : ${COMPOSER_DAG_BUCKET}
_COMPOSER_DAG_NAME_PROD : ${COMPOSER_DAG_NAME_PROD}
_COMPOSER_ENV_NAME : ${COMPOSER_ENV_NAME}
_COMPOSER_INPUT_BUCKET : ${INPUT_BUCKET_PROD}
_COMPOSER_REGION : ${COMPOSER_REGION}
_DATAFLOW_JAR_BUCKET_PROD : ${DATAFLOW_JAR_BUCKET_PROD}
_DATAFLOW_JAR_BUCKET_TEST : ${DATAFLOW_JAR_BUCKET_TEST}"

참고: 출력 이름/값 쌍은 다음 단계에 사용됩니다.

트리거 설정 페이지의 고급, 대체 변수에서 변수를 이전 단계에서 가져온 환경 값으로 바꿉니다. 다음 항목을 한 번에 하나씩 추가하고 이름-값 쌍마다 + 항목 추가를 클릭합니다.
- _COMPOSER_DAG_BUCKET
- _COMPOSER_DAG_NAME_PROD
- _COMPOSER_ENV_NAME
- _COMPOSER_INPUT_BUCKET
- _COMPOSER_REGION
- _DATAFLOW_JAR_BUCKET_PROD
- _DATAFLOW_JAR_BUCKET_TEST
- _DATAFLOW_JAR_FILE_LATEST = $(body.message.data)
승인에 대해 빌드 실행 전에 승인 필요를 선택합니다.
만들기를 클릭합니다.

트리거 테스트

트리거를 테스트하려면 테스트 입력 파일에 새 단어를 추가하고 그에 맞춰 테스트 참조 파일을 조정합니다. Cloud Source Repositories로 푸시된 커밋에 의해 빌드 파이프라인이 트리거되고 데이터 처리 워크플로가 업데이트된 테스트 파일로 올바르게 실행되는지 확인합니다.

Cloud Shell에서 테스트 파일 끝 부분에 테스트 단어를 추가합니다.
```
echo "testword" >>  ~/$SOURCE_CODE_REPO/workflow-dag/support-files/input.txt
```
테스트 결과 참조 파일인 ref.txt를 테스트 입력 파일의 변경사항과 일치하도록 업데이트합니다.
```
echo "testword: 1" >>  ~/$SOURCE_CODE_REPO/workflow-dag/support-files/ref.txt
```

변경사항을 커밋하고 Cloud Source Repositories로 푸시합니다.

cd ~/$SOURCE_CODE_REPO
git add .
git commit -m 'change in test files'
git push google master

Google Cloud Console에서 기록 페이지로 이동합니다.

기록 페이지로 이동
마스터 브랜치에 대한 이전 푸시로 새 테스트 빌드가 트리거되는지 확인하려면 현재 실행 중인 빌드에서 참조 열에 마스터라고 표시되어 있는지 확인합니다.

Cloud Shell에서 Cloud Composer 웹 인터페이스의 URL을 가져옵니다.

gcloud composer environments describe $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION --format="get(config.airflowUri)"

빌드가 완료되면 이전 명령어의 URL로 이동하여 test_word_count DAG가 실행 중인지 확인합니다.

DAG 실행이 완료될 때까지 기다립니다. 실행이 완료되면 DAG 실행 열의 밝은 녹색 원 모양이 사라집니다. 프로세스를 완료하는 데 일반적으로 3~5분이 소요됩니다.

Cloud Shell에서 테스트 결과 파일을 다운로드합니다.

mkdir ~/result-download
cd ~/result-download
gsutil cp gs://$RESULT_BUCKET_TEST/output* .

새로 추가된 단어가 결과 파일 중 하나에 있는지 확인합니다.
```
grep testword output*
```
출력은 다음과 비슷합니다.
```
output-00000-of-00003:testword: 1
```
Google Cloud Console에서 기록 페이지로 이동합니다.

기록 페이지로 이동
통합 테스트가 완료되어 새 프로덕션 빌드가 트리거되었고 빌드가 승인을 대기 중인지 확인합니다.
빌드 옆의 상자를 선택하고 승인을 클릭하고 확인 상자에서 승인을 클릭하여 프로덕션 빌드 파이프라인을 실행합니다.
빌드가 완료되면 이전 명령어의 URL로 이동하고 prod_word_count DAG를 수동으로 트리거하여 프로덕션 파이프라인을 실행합니다.

삭제

이 튜토리얼에서 사용된 리소스 비용이 Google Cloud 계정에 청구되지 않도록 하려면 리소스가 포함된 프로젝트를 삭제하거나 프로젝트를 유지하고 개별 리소스를 삭제하세요.

프로젝트 삭제

Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
리소스 관리로 이동
프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

개별 리소스 삭제

이 튜토리얼에서 사용한 프로젝트를 유지하려는 경우 다음 단계를 실행하여 튜토리얼에서 만든 리소스를 삭제합니다.

Cloud Build 트리거를 삭제하려면 다음 단계를 완료하세요.
1. Google Cloud Console에서 트리거 페이지로 이동합니다.
  
  트리거 페이지로 이동
2. 만든 트리거 옆에 있는 더보기를 클릭한 다음 삭제를 클릭합니다.

Cloud Shell에서 Cloud Composer 환경을 삭제합니다.

gcloud -q composer environments delete $COMPOSER_ENV_NAME \
    --location $COMPOSER_REGION

Cloud Storage 버킷과 관련 파일을 삭제합니다.

gsutil -m rm -r gs://$DATAFLOW_JAR_BUCKET_TEST \
    gs://$INPUT_BUCKET_TEST \
    gs://$REF_BUCKET_TEST \
    gs://$RESULT_BUCKET_TEST \
    gs://$DATAFLOW_STAGING_BUCKET_TEST \
    gs://$DATAFLOW_JAR_BUCKET_PROD \
    gs://$INPUT_BUCKET_PROD \
    gs://$RESULT_BUCKET_PROD \
    gs://$DATAFLOW_STAGING_BUCKET_PROD

Pub/Sub 주제 및 기본 구독을 삭제하려면 Cloud Shell에서 다음 명령어를 실행합니다.

gcloud pubsub topics delete integration-test-complete-topic
gcloud pubsub subscriptions delete integration-test-complete-topic-sub

저장소를 삭제합니다.

gcloud -q source repos delete $SOURCE_CODE_REPO

내가 만든 파일과 폴더를 삭제합니다.

rm -rf ~/ci-cd-for-data-processing-workflow
rm -rf ~/$SOURCE_CODE_REPO
rm -rf ~/result-download

다음 단계

Cloud Build를 사용한 GitOps 스타일의 지속적 배포 자세히 알아보기
Cloud Composer로 인프라 자동화 자세히 알아보기
일반 Dataflow 사용 사례 패턴 자세히 알아보기
출시 엔지니어링 자세히 알아보기
Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터 살펴보기