Google Cloud로 마이그레이션: 워크로드 배포

Last reviewed 2023-12-08 UTC

이 문서는 Google Cloud로 마이그레이션 배포 단계를 계획 및 설계하는 데 유용합니다. 현재 환경을 평가하고, Google Cloud로의 마이그레이션을 계획하고, Google Cloud 기반을 구축한 후에 워크로드를 배포할 수 있습니다.

이 문서는 Google Cloud로 마이그레이션에 대해 여러 편으로 구성된 다음 시리즈 중 일부입니다.

다음 다이어그램은 마이그레이션 과정을 보여줍니다.

4가지 단계로 구성된 마이그레이션 경로

Google Cloud로 마이그레이션의 세 번째 단계인 배포 단계에서는 워크로드 배포 프로세스를 설계합니다.

이 문서는 온프레미스 환경, 비공개 호스팅 환경, 다른 클라우드 제공업체에서 Google Cloud로 마이그레이션을 계획 중이거나, 마이그레이션 기회를 평가하고 그 결과를 살펴보고 싶은 경우에 유용합니다.

이 문서에서는 유연성, 자동화, 복잡성 순서에 따라 다양한 배포 프로세스 유형과 함께 자신에게 맞는 방법을 선택할 때의 기준을 알아봅니다.

  1. 수동으로 배포
  2. 구성 관리(CM) 도구로 배포
  3. 컨테이너 조정 도구를 사용하여 배포
  4. 자동으로 배포

워크로드를 배포하기 전에 배포 단계를 계획 및 설계해야 합니다. 먼저 워크로드에 구현할 여러 가지 배포 프로세스 유형을 평가해야 합니다. 배포 프로세스 유형을 평가할 때 간단한 프로세스로 시작한 후 나중에 더 복잡한 프로세스로 이동할 수 있습니다. 이런 방식으로 진행하면 결과를 보다 빨리 얻을 수 있지만, 간단한 프로세스를 사용하면서 누적된 기술적 채무를 흡수해야 하므로 고급 프로세스로 이동할 때 문제가 발생할 수도 있습니다. 예를 들어 완전 수동 배포에서 자동화 솔루션으로 이전할 경우 배포 파이프라인 및 앱에 대한 업그레이드를 관리해야 할 수도 있습니다.

이 방법을 사용하면 워크로드의 요구사항에 따라 여러 가지 유형의 배포 프로세스를 구현할 수 있지만 배포 단계의 복잡성이 심해질 수 있습니다. 여러 가지 유형의 배포 프로세스를 구현하면 유연성이 늘어나는 이점이 있지만 각 프로세스에 맞는 전문 기술, 도구, 리소스가 필요할 수도 있어 작업량이 증가하게 됩니다.

수동 배포

완전 수동 배포는 완전 자동화되지 않은 프로비저닝, 구성, 배포 프로세스에 의해 지원됩니다. 프로세스 단계마다 사양 및 체크리스트가 있을 수 있지만 이러한 사양이 자동으로 확인되거나 적용되지는 않습니다. 수동 프로세스는 사람의 실수에 취약하고, 반복할 수 없으며, 성능이 인적 요소에 의해 제한됩니다.

완전 수동 배포 프로세스는 샌드박스 환경에서 신속하게 실험을 진행해야 하는 경우에 유용할 수 있습니다. 몇 분간 지속되는 실험에 구조화된 자동 프로세스를 설정하면 속도가 불필요하게 느려질 수 있습니다. 특히 마이그레이션 초기 단계와 같이 자동화된 프로세스를 빌드할 수 있는 도구에 대한 전문 기술과 경험이 부족하면 속도가 느려질 수 있습니다.

Google Cloud에는 이러한 제한이 없지만 필요한 관리 API가 없는 기본 환경에서는 완전 수동 배포가 유일한 옵션일 수 있습니다. 이러한 경우에는 필요한 인터페이스 부족으로 인해 자동화된 프로세스를 구현할 수 없습니다. 자동화를 지원하지 않는 기존 가상화 인프라가 있는 경우 완전 수동 프로세스를 강제로 구현해야 할 수도 있습니다.

다른 옵션이 없는 경우가 아니라면 완전 수동 배포를 수행하지 않는 것이 좋습니다.

Google Cloud Console, Cloud Shell, Cloud API, Google Cloud CLI와 같은 도구를 사용하면 완전 수동 프로비저닝, 구성, 배포 프로세스를 구현할 수 있습니다.

구성 관리 도구로 배포

CM 도구를 사용하면 반복 가능하고 통제된 방식으로 환경을 구성할 수 있습니다. 이 도구에는 이미 일반적인 구성 작업을 구현한 플러그인 및 모듈 세트가 포함되어 있습니다. 이 도구를 사용하면 최종 상태에 도달하기 위한 로직을 구현하는 것이 아닌 환경에서 달성하려는 최종 상태에 집중할 수 있습니다. 포함된 작업 세트가 부족한 경우를 위해 CM 도구에는 개발자가 자체 모듈 개발에 사용할 수 있는 확장 시스템이 있습니다. 이러한 확장은 가능하지만 추가적인 개발 및 유지보수 부담을 방지하기 위해 가능하면 사전 정의된 모듈과 플러그인을 사용하는 것이 좋습니다.

CM 도구는 환경을 구성해야 할 때 사용됩니다. 또한 인프라를 프로비저닝하고 워크로드 배포 프로세스를 구현하는 데에도 사용될 수 있습니다. CM 도구는 반복 및 감사 가능한 통제된 방식이므로 완전 수동 프로비저닝, 구성, 배포 프로세스보다 더욱 우수한 프로세스입니다. 하지만 CM 도구는 프로비저닝 또는 배포 태스크용으로 설계되지 않았으므로 몇 가지 단점이 있습니다. 일반적으로 이 도구에는 인프라의 실제 상태와 목표 상태 간의 차이를 감지 및 관리하는 등 정교한 프로비저닝 로직을 구현하는 기능이 기본 제공되지 않으며 다운타임이 없는 배포 또는 블루-그린 배포와 같은 리치 배포 프로세스도 없습니다. 이전에 언급한 확장 지점을 사용하여 이러한 누락된 기능을 구현할 수 있습니다. 맞춤설정된 배포 솔루션을 설계, 개발, 유지보수하는 데 전문 기술이 필요하므로 이러한 확장으로 인해 작업량이 추가되고 전반적인 배포 프로세스 복잡성이 증가할 수 있습니다.

Ansible, Chef, Puppet, SaltStack과 같은 도구를 사용하면 이 유형의 프로비저닝, 구성, 배포 프로세스를 구현할 수 있습니다.

컨테이너 조정 도구를 사용하여 배포

이미 워크로드의 컨테이너화에 투자했거나 투자할 계획이면 컨테이너 조정 도구를 사용하여 워크로드를 배포할 수 있습니다.

컨테이너 조정 도구는 환경을 뒷받침하는 인프라를 관리하며 기본 제공 배포로 충분하지 않을 때 사용할 수 있는 배포 로직의 구현에 필요한 다양한 배포 작업 및 구성요소를 지원합니다. 이러한 도구를 사용하면 메커니즘을 별도로 구현하지 않고 제공된 메커니즘을 통해 실제 배포 로직 구성에 집중할 수 있습니다.

또한 컨테이너 조정 도구는 배포 프로세스를 다양한 기본 환경으로 일반화하는 데 사용할 수 있는 추상화를 제공하므로 각 환경마다 여러 가지 프로세스를 설계하고 구현하지 않아도 됩니다. 예를 들어 이 도구에는 일반적으로 배포를 확장 및 업그레이드하는 로직이 포함되어 있으므로 이를 직접 구현할 필요가 없습니다. 구현이 설계상 거의 동일하므로 현재 환경에서 이 도구를 활용하여 배포 프로세스를 구현한 후 대상 환경으로 포팅할 수도 있습니다. 이 도구를 초반에 채택하면 컨테이너화된 환경 관리에 대한 전문 경험을 얻을 수 있으며, 이 경험은 Google Cloud로 마이그레이션하는 데 유용하게 활용됩니다.

워크로드가 이미 컨테이너화되어 있거나 나중에 컨테이너화될 수 있고 이에 투자할 계획이 있다면 컨테이너 조정 도구를 사용합니다. 후자의 경우 각 워크로드를 철저히 분석하여 다음 사항을 확인해야 합니다.

  • 워크로드의 컨테이너화가 가능한지 확인합니다.
  • 워크로드를 컨테이너화하여 얻을 수 있는 잠재적 이점을 평가합니다.

잠재적 문제가 컨테이너화의 이점을 능가하면 팀에서 이미 이 도구를 사용하기로 결정했고 이기종 환경을 관리하지 않으려는 경우에만 컨테이너 조정 도구를 사용해야 합니다.

예를 들어 데이터 웨어하우스 솔루션은 일반적으로 컨테이너 조정 도구를 통해 배포되지 않습니다. 임시 컨테이너에서 실행되도록 설계되지 않았기 때문입니다.

Google Cloud에서 Google Kubernetes Engine(GKE)을 사용하여 이 배포 프로세스를 구현할 수 있습니다. 서버리스 환경에 관심이 있으면 Cloud Run과 같은 도구를 사용하면 됩니다.

자동 배포

환경에서 사용하는 프로비저닝, 구성, 배포, 조정 도구에 상관없이 완전 자동화된 배포 프로세스를 구현하면 사람의 실수를 최소화하고, 조직 전체의 프로세스를 통합, 간소화, 표준화할 수 있습니다. 필요 시 배포 프로세스에 수동 승인 단계를 삽입할 수도 있지만 모든 단계가 자동화됩니다.

일반적인 엔드 투 엔드 배포 파이프라인의 단계는 다음과 같습니다.

  1. 코드 검토
  2. 지속적 통합(CI)
  3. 아티팩트 프로덕션
  4. 최종 수동 승인이 포함된 연속 배포(CD)

위의 각 단계를 서로 독립적으로 자동화할 수 있으므로 현재 배포 프로세스를 자동화된 솔루션으로 점차 마이그레이션하거나 대상 환경에서 직접 새 프로세스를 구현할 수 있습니다. 이 프로세스가 효과적이려면 코드 검토 단계나 CI 단계뿐만 아니라 파이프라인의 각 단계에서 테스트 및 검증 절차를 진행해야 합니다.

코드베이스가 변경될 때마다 이를 철저하게 검토하여 변경 품질을 평가해야 합니다. 대부분의 소스 코드 관리 도구에서는 코드 검토를 최고 수준으로 지원합니다. 또한 코드베이스의 각 부분을 담당하는 팀이 구성되어 있는 경우 종종 수정된 소스 코드 부분을 확인하여 검토의 자동 생성 및 초기화를 지원하기도 합니다. 검토 시마다 린터 및 정적 분석기와 같은 자동 검사를 소스 코드에 실행하여 코드베이스 전체에 일관성 및 품질 표준을 적용할 수도 있습니다.

개발자가 코드베이스의 변경사항을 검토 및 통합하면 CI 도구가 자동으로 테스트를 실행하고 그 결과를 평가한 후 현재 빌드와 관련된 문제를 알려줍니다. 각 워크로드 기능의 전체 테스트 범위에 대한 테스트 기반 개발 프로세스에 따라 이 단계에 가치를 부가할 수 있습니다.

빌드가 성공할 때마다 배치 아티팩트 생성을 자동화할 수 있습니다. 이러한 아티팩트는 최신 변경사항이 적용된 즉시 배포 가능한 워크로드 버전입니다. 아티팩트 생성 과정에서 아티팩트 검증을 자체적으로 자동 수행할 수도 있습니다. 예를 들어 알려진 문제에 대해 취약점 스캔을 실행하고 취약점이 발견되지 않은 경우에만 아티팩트 배포를 승인합니다.

마지막으로 대상 환경에서 승인된 각 아티팩트의 배포를 자동화할 수 있습니다. 런타임 환경이 여러 개인 경우 각 환경마다 고유한 배포 로직을 구현하고 필요한 경우 수동 승인 단계를 추가할 수도 있습니다. 예를 들어 개발 환경, 품질 보증, 사전 프로덕션 환경에 새 버전의 워크로드를 자동으로 배포하면서 프로덕션 환경에 배포하기 전에 프로덕션 관리팀에게 수동 검토 및 승인을 계속 요구할 수도 있습니다.

완전 자동화된 엔드 투 엔드 프로세스는 자동화, 구조화, 간소화되고 감사 가능한 프로세스가 필요한 경우에 최고의 옵션 중 하나지만 이 프로세스 구현은 결코 쉬운 태스크가 아닙니다. 이 유형의 프로세스를 선택하기 전에 예상되는 이점, 관련 비용, 현재 팀 지식과 전문 기술의 수준이 완전 자동화된 배포 프로세스를 구현하기에 충분한지 명확하게 파악해야 합니다.

Cloud Deploy를 사용하면 완전 자동화된 배포 프로세스를 구현할 수 있습니다.

다음 단계