배포 자동화

Last reviewed 2023-07-17 UTC

Google Cloud 아키텍처 프레임워크의 이 문서에서는 빌드, 테스트, 배포를 자동화하기 위한 권장사항을 제공합니다.

자동화는 코드 업데이트와 같은 반복 프로세스에서 사람이 야기하는 오류를 제거하여 빌드, 테스트, 배포를 표준화하는 데 도움이 됩니다. 이 섹션에서는 자동화 시 다양한 검사와 보호 조치를 사용하는 방법을 설명합니다. 표준화된 머신 제어 프로세스는 배포를 안전하게 적용하는 데 도움이 됩니다. 또한 사용자 환경에 큰 영향을 미치지 않으면서 필요에 따라 이전 배포를 복원하는 메커니즘도 제공합니다.

중앙 코드 저장소에 코드 저장

태그를 지정하고 코드 변경사항 롤백이 가능한 버전 제어 시스템을 포함하는 중앙 코드 저장소에 코드를 저장합니다. 버전 제어를 사용하면 파일을 구성하고 팀과 조직 전체의 액세스, 업데이트, 삭제를 제어할 수 있습니다.

개발의 여러 단계에서 필요한 경우 저장소에 버전을 지정하고 라벨을 지정합니다. 예를 들어 라벨은 test, dev, prod일 수 있습니다.

Google Cloud에서 Cloud Source Repositories에 코드를 저장하고 여기에 버전을 지정하여 다른 Google Cloud 제품과 통합할 수 있습니다. 컨테이너화된 애플리케이션을 빌드하는 경우 컨테이너의 관리형 레지스트리인 Artifact Registry를 사용합니다.

버전 제어에 대한 자세한 내용은 버전 제어를 참조하세요. 저장소를 사용한 트렁크 기반 개발 구현에 대한 자세한 내용은 트렁크 기반 개발을 참조하세요.

지속적 통합 및 지속적 배포(CI/CD) 사용

지속적 통합 및 지속적 배포(CI/CD) 방식을 사용하여 배포를 자동화합니다. CI/CD 방식은 개발자가 구성한 파이프라인과 개발팀이 따르는 프로세스를 조합한 것입니다.

CI/CD 방식은 소프트웨어 개발팀의 생산성을 높여 배포 속도를 높입니다. 이 방식을 통해 개발자는 철저하게 테스트한 변경사항을 더 자주 만들고 해당 변경사항을 배포하는 데 필요한 시간을 줄일 수 있습니다.

CI/CD 방식의 일환으로 코드 빌드, 테스트, 배포의 모든 단계를 자동화합니다. 예를 들면 다음과 같습니다.

  • 새 코드가 저장소에 커밋될 때마다 커밋이 빌드 및 테스트 파이프라인을 자동으로 호출하도록 합니다.
  • 통합 테스트를 자동화합니다.
  • 빌드가 특정 테스트 기준을 충족하면 변경사항이 배포되도록 배포를 자동화합니다.

Google Cloud에서는 CI/CD 파이프라인에 Cloud Build 및 Cloud Deploy를 사용할 수 있습니다.

Cloud Build를 사용하여 애플리케이션 패키지를 패키징하고 빌드하는 데 사용할 수 있는 종속 항목과 버전을 정의할 수 있습니다. 빌드 전체에 걸쳐 일관성을 유지하고 필요한 경우 이전 구성으로 롤백할 수 있도록 빌드 구성의 버전을 지정합니다.

Cloud Deploy를 사용하여 애플리케이션을 Google Cloud의 특정 환경에 배포하고 배포 파이프라인을 관리합니다.

CI/CD 구현에 대한 자세한 내용은 지속적 통합 및 배포 자동화를 참조하세요.

코드형 인프라를 사용하여 인프라 프로비저닝 및 관리

코드형 인프라는 설명적 모델을 사용하여 VM과 같은 인프라와 방화벽 규칙과 같은 구성을 관리합니다. 코드형 인프라를 사용하면 다음을 수행할 수 있습니다.

  • CI/CD 파이프라인의 배포 또는 테스트 환경을 포함하여 클라우드 리소스를 자동으로 만듭니다.
  • 인프라 변경사항을 애플리케이션 변경사항처럼 취급합니다. 예를 들어 구성 변경사항이 검토, 테스트, 감사를 받을 수 있도록 합니다.
  • 클라우드 인프라에 대한 단일 버전의 정보를 제공합니다.
  • 필요에 따라 클라우드 환경을 복제합니다.
  • 필요한 경우 이전 구성으로 롤백합니다.

코드형 인프라 개념은 Google Cloud의 프로젝트에도 적용됩니다. 이 방식을 사용하면 프로젝트에서 공유 VPC 연결 또는 Identity and Access Management(IAM) 액세스와 같은 리소스를 정의할 수 있습니다. 이 방식의 예시는 Google Cloud 프로젝트 팩토리 Terraform 모듈을 참조하세요.

Terraform과 같은 타사 도구를 사용하면 Google Cloud에서 인프라를 자동으로 만들 수 있습니다. 자세한 내용은 Terraform, Cloud Build, GitOps를 사용하여 코드형 인프라 관리를 참조하세요.

실수로 또는 악의적으로 중요한 리소스를 삭제하지 못하도록 프로젝트 선취권, Cloud Storage 보관 정책, Cloud Storage 버킷 잠금과 같은 Google Cloud 기능을 사용하는 것이 좋습니다.

소프트웨어 배포 수명 주기 전반에서 테스트 통합

테스트는 소프트웨어를 성공적으로 출시하는 데 필수적입니다. 지속적 테스트는 팀이 고품질 소프트웨어를 더 빠르게 만들고 소프트웨어 안정성을 향상시키는 데 도움이 됩니다.

테스트 유형:

  • 단위 테스트: 단위 테스트는 속도가 빠르며 신속한 배포를 수행하는 데 도움이 됩니다. 단위 테스트를 코드베이스의 일부로 취급하고 빌드 프로세스의 일부로 포함합니다.
  • 통합 테스트: 통합 테스트는 특히 확장되고 두 개 이상의 서비스에 종속되도록 설계된 워크로드에서 중요합니다. 이 테스트는 상호 연결된 서비스와의 통합을 테스트할 때 복잡해질 수 있습니다.
  • 시스템 테스트: 시스템 테스트는 시간이 많이 소요되고 복잡하지만 배포 전에 특이 사례를 식별하고 문제를 해결하는 데 도움이 됩니다.
  • 기타 테스트: 정적 테스트, 부하 테스트, 보안 테스트, 정책 유효성 검사 등을 포함하여 실행할 기타 테스트가 있습니다. 프로덕션에 애플리케이션을 배포하기 전에 이러한 테스트를 실행합니다.

테스트를 통합하려면 다음 안내를 따르세요.

  • 소프트웨어 배포 수명주기 전반에서 모든 유형의 테스트를 지속적으로 수행합니다.
  • 이러한 테스트를 자동화하고 CI/CD 파이프라인에 포함합니다. 테스트가 실패하면 파이프라인이 실패하도록 만듭니다.
  • 새로운 테스트를 지속적으로 업데이트하고 추가하여 배포의 운영 상태를 개선하고 유지합니다.

테스트 환경:

  • 테스트 환경마다 별도의 Google Cloud 프로젝트를 사용합니다. 애플리케이션마다 별도의 프로젝트 환경을 사용합니다. 이렇게 분리하면 프로덕션 환경 리소스와 하위 환경의 리소스가 명확하게 구분됩니다. 이렇게 분리하면 실수로 한 환경의 변경사항이 다른 환경에 영향을 주지 않도록 할 수 있습니다.
  • 테스트 환경 생성을 자동화합니다. 이 자동화를 수행하는 한 가지 방법은 코드형 인프라를 사용하는 것입니다.
  • 합성 프로덕션 환경을 사용하여 변경사항을 테스트합니다. 이 환경은 애플리케이션을 테스트하고 엔드 투 엔드 테스트 및 성능 테스트를 포함한 다양한 유형의 워크로드 테스트를 수행할 수 있는, 프로덕션과 유사한 환경을 제공합니다.

지속적 테스트 구현에 대한 자세한 내용은 자동화 테스트를 참조하세요.

점진적 배포 실행

최종 사용자의 최소 중단, 순차적 업데이트, 롤백 전략, A/B 테스트 전략과 같은 중요한 매개변수를 기반으로 배포 전략을 선택합니다. 각 워크로드에서 이러한 요구사항을 평가하고 지속적 업데이트, 블루/그린 배포, 카나리아 배포와 같은 검증된 기술에서 배포 전략을 선택합니다.

CI/CD 프로세스만 프로덕션 환경에서 변경하고 푸시할 수 있도록 합니다.

변경 불가능한 인프라를 사용하는 것이 좋습니다. 변경 불가능한 인프라는 변경 또는 업데이트되지 않는 인프라입니다. 환경에서 새 코드를 배포하거나 다른 구성을 변경해야 할 경우 전체 환경(예: VM 또는 포드 모음)을 새 환경으로 바꿉니다. 블루/그린 배포는 변경할 수 없는 인프라의 예시입니다.

카나리아 테스트를 수행하고 변경사항을 배포할 때에는 시스템에 오류가 있는지 관찰하는 것이 좋습니다. 강력한 모니터링 및 알림 시스템이 있으면 이 유형의 관찰이 더 쉬워집니다. A/B 테스트 또는 카나리아 테스트를 수행하기 위해 Google Cloud의 관리형 인스턴스 그룹을 사용할 수 있습니다. 그런 다음 느린 출시 또는 필요한 경우 복원을 수행할 수 있습니다.

Cloud Deploy를 사용하여 배포를 자동화하고 배포 파이프라인을 관리하는 것을 고려해 보세요. 또한 Google Cloud에서 Spinnaker 및 Tekton과 같은 다양한 서드 파티 도구를 사용하여 배포를 자동화하고 배포 파이프라인을 만들 수 있습니다.

이전 출시 버전을 원활하게 복원

배포 전략의 일환으로 복원 전략을 정의합니다. 배포 또는 인프라 구성을 이전 버전의 소스 코드로 롤백할 수 있어야 합니다. 이전의 안정적인 배포를 복원하는 작업은 안정성 및 보안 이슈 모두를 위한 이슈 관리에서 중요한 단계입니다.

또한 배포 프로세스가 시작되기 전의 상태로 환경을 복원할 수 있어야 합니다. 여기에는 다음이 포함될 수 있습니다.

  • 애플리케이션의 코드 변경사항을 되돌릴 수 있습니다.
  • 환경에 대한 구성 변경사항을 되돌릴 수 있습니다.
  • 변경 불가능한 인프라를 사용하고 배포로 환경이 변경되지 않도록 합니다. 이렇게 하면 구성 변경사항을 쉽게 되돌릴 수 있습니다.

CI/CD 파이프라인 모니터링

자동화된 빌드, 테스트, 배포 프로세스를 원활하게 실행하려면 CI/CD 파이프라인을 모니터링합니다. 파이프라인에서 문제가 발생한 시기를 나타내는 알림을 설정합니다. 파이프라인의 각 단계에서 파이프라인이 실패하는 경우 팀에서 근본 원인 분석을 수행할 수 있도록 적절한 로그 구문을 작성해야 합니다.

Google Cloud에서 모든 CI/CD 서비스는 Google Cloud Observability와 통합됩니다. 예를 들면 다음과 같습니다.

모니터링 및 로깅에 대한 자세한 내용은 모니터링, 알림, 로깅 설정을 참조하세요.

애플리케이션을 안전하게 배포

아키텍처 프레임워크의 보안, 규정 준수, 개인 정보 보호 카테고리에서 애플리케이션을 안전하게 배포 섹션을 검토합니다.

버전 출시에 대한 관리 가이드라인 설정

엔지니어가 실수를 방지하고 빠른 소프트웨어 배포를 가능하게 하려면 새로운 소프트웨어 버전 출시에 대한 관리 가이드라인을 명확하게 설명해야 합니다.

출시 엔지니어는 소프트웨어의 빌드 및 제공 방식을 감독합니다. 출시 엔지니어링 시스템은 다음과 같은 4가지 권장사항을 따라야 합니다.

  • 셀프서비스 모드. 소프트웨어 엔지니어의 일반적인 실수를 방지하는 데 도움이 되는 가이드라인을 수립합니다. 이 가이드라인은 일반적으로 자동화된 프로세스에 코드화되어 있습니다.

  • 빈번한 출시. 빠른 속도로 출시하면 문제를 더 쉽게 해결하는 데 도움이 됩니다. 출시 빈도를 높이려면 자동화된 단위 테스트가 수반되어야 합니다.

  • 기본 제공 빌드. 빌드 도구의 일관성을 확보합니다. 현재 버전을 빌드하는 데 사용하는 빌드 컴파일러 버전과 한 달 전 버전을 비교합니다.

  • 정책 시행. 모든 변경사항에는 코드 검토가 필요하며 원칙적으로 보안을 강화하기 위한 가이드라인과 정책 세트가 포함되어야 합니다. 정책을 시행하면 코드 검토, 문제 해결, 새 출시 버전의 테스트가 향상됩니다.

다음 단계