본문 바로가기

개발

gcp cloudbuild 와 cloud run job을 활용한 파이프라인 구축 (aws lambda와 비교)

반응형

GCP Cloud Build와 Cloud Run Job을 활용한 파이프라인 구축은 AWS CodeBuild와 Lambda를 사용하는 것과 유사하지만, 몇 가지 중요한 차이점을 갖는 현대적인 CI/CD(지속적 통합 및 배포) 전략입니다. 두 플랫폼의 장단점을 이해하면 워크로드에 가장 적합한 도구를 선택하는 데 도움이 됩니다.


GCP 파이프라인: Cloud Build + Cloud Run Job 🚀

이 파이프라인은 코드를 컨테이너화하여 일회성 배치(Batch) 작업을 자동 배포하는 효과적인 CI/CD 전략입니다. 이 접근 방식은 개발자가 코드를 Git 리포지토리에 커밋할 때마다 자동으로 실행되어, 최종적으로 Cloud Run Job을 업데이트합니다.

  1. Git 리포지토리 연동: 먼저 Cloud Build 트리거를 설정합니다. GitHub, Bitbucket, 또는 Cloud Source Repositories와 같은 Git 리포지토리의 특정 브랜치에 코드가 푸시되면 파이프라인이 자동으로 시작됩니다.
  2. Cloud Build 실행: Cloud Build는 .yaml 또는 .json 형식의 설정 파일(cloudbuild.yaml)에 정의된 빌드 스텝을 순차적으로 실행합니다. 이 설정 파일은 파이프라인의 청사진 역할을 합니다.
    • 컨테이너 이미지 빌드: Cloud Build는 Dockerfile을 사용해 소스 코드를 실행 가능한 컨테이너 이미지로 빌드합니다. 이 과정에서 필요한 라이브러리 설치, 유닛 테스트 실행 등이 포함될 수 있습니다.
    • 이미지 푸시: 빌드된 컨테이너 이미지를 Artifact Registry(구 Container Registry)에 푸시하여 안전하게 저장합니다. Artifact Registry는 GCP의 프라이빗 컨테이너 이미지 저장소입니다.
  3. Cloud Run Job 배포:
    • Cloud Build는 Artifact Registry에 저장된 최신 컨테이너 이미지를 사용하여 gcloud run jobs deploy 명령어를 실행합니다.
    • 이 명령어는 기존 Cloud Run Job을 새로운 이미지로 업데이트하거나, Job이 없는 경우 새로 생성합니다. Cloud Run Job은 단일 태스크 또는 병렬 태스크를 실행하고, 작업이 완료되면 자동으로 종료되는 서버리스 배치 서비스입니다.

이 워크플로우는 코드를 업데이트하고 git push만 하면, 빌드-푸시-배포의 전 과정이 자동으로 처리되는 강력한 자동화 환경을 구축합니다.


AWS Lambda와의 주요 차이점 비교 🔍

GCP의 이 파이프라인은 AWS의 CodeBuild와 Lambda를 사용하는 것과 유사한 역할을 하지만, 워크로드의 특성에 따라 중요한 차이점을 가집니다.

구분 GCP (Cloud Build + Cloud Run Job) AWS (CodeBuild + Lambda)
핵심 서비스 Cloud Build (CI/CD) + Cloud Run Job (서버리스 배치) CodeBuild (CI/CD) + Lambda (서버리스 함수)
실행 모델 컨테이너 기반: Dockerfile을 사용해 컨테이너 이미지를 빌드하고 실행. 함수 기반: ZIP 파일 또는 컨테이너 이미지를 사용. 대부분은 함수 코드를 직접 업로드하는 방식.
유연성 Docker 컨테이너를 사용하므로, 런타임, 언어, 외부 라이브러리 사용에 매우 높은 유연성을 가집니다. 런타임 환경이 AWS가 제공하는 기본 스택에 제한될 수 있습니다 (커스텀 런타임 사용 시 복잡도 증가).
실행 방식 Job: 일회성 작업(gcloud run jobs execute 등)에 최적화. 스케줄러로 정기 실행 가능. Event-driven: HTTP 요청, S3 파일 업로드, DynamoDB 변경 등 다양한 이벤트에 의해 트리거됩니다.
최대 실행 시간 **최대 168시간(7일)**까지 실행 가능하여 장기 실행 배치 작업에 적합합니다. 최대 15분까지 실행 가능하여 단기 실행 작업에 적합합니다.
배포 복잡성 Dockerfile 작성 및 컨테이너 관리 지식이 필요합니다. ZIP 배포 시 별도 빌드 단계가 필요 없고 간단하나, 컨테이너 배포 시 복잡도가 증가합니다.

결론: 워크로드에 따른 최적의 선택 🎯

GCP Cloud Build + Cloud Run Job 파이프라인은 특히 Docker 컨테이너의 유연성을 활용해 복잡하거나 장시간이 필요한 일회성 배치 작업을 자동화하는 데 매우 강력합니다. Dockerfile을 통해 원하는 환경을 자유롭게 구성할 수 있어, 복잡한 데이터 처리, 정기적인 백업 스크립트, AI/ML 모델 학습 및 추론과 같은 다양한 워크로드에 적합합니다.

이 파이프라인의 핵심은 컨테이너의 유연성Job의 긴 실행 시간에 있습니다. 개발자는 Dockerfile에 필요한 모든 종속성과 환경을 명시함으로써, 개발 환경과 동일한 환경에서 코드가 실행될 것을 보장받습니다. 이는 "내 컴퓨터에서는 잘 되는데..."와 같은 문제를 근본적으로 해결해 줍니다. 또한, 최대 7일이라는 긴 실행 시간 덕분에 대규모 데이터 ETL(추출, 변환, 적재) 작업이나 복잡한 시뮬레이션 같은 작업도 서버리스 환경에서 안정적으로 처리할 수 있습니다. 이는 전통적인 서버 환경을 관리하는 부담을 덜어주면서도 강력한 컴퓨팅 성능을 제공합니다.

반면, AWS CodeBuild + Lambda는 짧은 시간 안에 완료되는 이벤트 기반 함수를 배포하는 데 탁월합니다. HTTP API 요청이나 S3 버킷에 파일이 업로드되는 등 특정 이벤트에 반응하는 마이크로서비스를 구축할 때 더 효율적입니다. Lambda는 실행 시간이 짧고 비용 효율적인 작은 단위의 태스크에 최적화되어 있습니다.

두 플랫폼 모두 CI/CD 자동화를 위한 강력한 도구를 제공하지만, 워크로드의 특성과 실행 시간에 따라 적합한 솔루션을 선택하는 것이 중요합니다. Cloud Run Job의 긴 실행 시간은 복잡한 데이터 파이프라인이나 AI/ML 모델 학습과 같은 작업에 큰 이점을 제공하며, 이는 GCP가 배치 처리 워크로드에 얼마나 많은 노력을 기울였는지 보여주는 사례입니다.

반응형