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

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

이 문서는 Google Cloud로 마이그레이션하는 방법을 다루는 시리즈의 일부입니다. 시리즈의 개요에 대해 자세히 알아보려면 Google Cloud로 마이그레이션: 마이그레이션 경로 선택을 참조하세요.

이 문서는 시리즈의 일부입니다.

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

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

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

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

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

  1. 수동으로 배포
  2. 구성 관리(CM) 도구로 배포
  3. 컨테이너 조정 도구를 사용하여 배포
  4. 자동으로 배포
  5. 인프라를 코드 패턴으로 적용하여 배포

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

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

수동 배포

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

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

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

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

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

구성 관리 도구로 배포

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

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

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

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

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

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

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

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

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

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

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

Google Cloud에서 Kubernetes와 같은 도구와 Google Kubernetes Engine(GKE)과 같은 관리형 서비스를 사용하면 이 배포 프로세스를 구현할 수 있습니다. 서버리스 환경에 관심이 있는 경우에는 App Engine 가변형 환경, Cloud Functions, Cloud Run과 같은 도구를 사용할 수 있습니다.

자동 배포

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

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

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

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

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

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

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

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

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

SonarQube, Jenkins, Cloud Build, Container Registry, Spinnaker와 같은 도구를 사용하면 완전 자동화된 프로세스를 구현할 수 있습니다.

인프라를 코드 패턴으로 적용하여 배포

코드형 인프라는 워크로드의 소스 코드를 처리하는 방식과 동일한 방식으로 런타임 환경에서 리소스 프로비저닝을 처리하는 프로세스입니다. 예를 들어 Cloud APIs를 사용하여 Google Cloud 리소스의 전체 수명 주기를 전체적으로 관리하고 소스 코드에서 최종 상태를 코드화할 수 있습니다. 그런 다음 워크로드에 구현하는 것과 비슷하게 인프라에 사용할 완전 자동화된 프로비저닝 프로세스를 구현하고, 포괄적인 테스트 모음을 완료합니다.

프로비저닝 도구는 인프라를 부트스트랩하고 구성을 준비할 수 있도록 설계되었지만 구성 태스크를 완료하는 데에는 적합하지 않습니다. 이러한 이유로 인해 인프라의 모든 리소스를 프로비저닝한 후에는 CM 도구를 사용하여 요구사항에 맞게 리소스를 구성해야 합니다. 프로비저닝 도구를 사용하여 구성 태스크를, CM 도구를 사용하여 프로비저닝 태스크를 구현할 수 있지만 이들 도구는 특정 용도에 맞도록 설계되어 있어 서로 보완합니다. 작업에 적합한 도구를 사용해야 하므로 프로비저닝 도구를 사용하여 인프라를 프로비저닝하고 CM 도구를 사용하여 구성합니다.

Google Cloud에서와 같이 API를 사용하여 대상 환경의 리소스를 완전히 관리할 수 있으면 코드 프로세스로 인프라를 구현해야 합니다. 전체 클라우드 인프라에 감사 기능과 버전 관리를 즉시 사용할 수 있습니다. 또한 지속적 통합 및 지속적 배포(CI/CD) 프로세스를 구현하여 인프라에 변경사항을 자동으로 적용할 수도 있습니다.

반면, 대상 환경에서 리소스 관리 및 구성에 필요한 프로그래매틱 방식의 액세스를 제공하지 않으면 코드형 인프라 배포를 구현할 수 없습니다. 또한 클라우드 환경에서 리소스를 프로비저닝 및 프로비저닝 해제하면 청구 및 지출 간에 차이가 발생할 수 있으므로 조달 부서에 문의해야 합니다.

Terraform과 같은 도구와 Deployment Manager와 같은 관리형 서비스로 코드형 인프라 프로세스를 구현할 수 있습니다. 또한 RSpec, Serverspec, InSpec과 같은 도구를 사용하여 인프라에 사용할 테스트 모음을 구현할 수도 있습니다.

요약

이제까지 다양한 옵션, 사용해야 하는 경우, 사용하지 않아야 하는 경우와 몇 가지 도구 예시를 알아보았습니다. 다음 차트에서 워크로드 및 사용 사례에 따라 각 옵션을 쉽게 비교 확인할 수 있습니다.

배포 프로세스 유형 사용해야 하는 경우 사용하지 않아야 하는 경우 도구와 서비스
완전 수동 배포 샌드박스 환경에서 실험을 신속하게 진행해야 하는 경우 또는 필요한 관리 API가 없는 기본 환경 또는 기존 가상화 인프라인 경우 보다 관리하기 쉬운 대안이 있는 경우 없음
CM 도구로 배포 수동 배포를 자동화할 방법이 필요하고 환경 구성에 필요한 CM 도구에 이미 많은 투자를 한 경우 배포 측면에서 CM 도구의 한계를 극복하기 위한 작업량이 너무 많은 경우 Ansible, Chef, Puppet, SaltStack
컨테이너 조정 워크로드가 이미 컨테이너화되었거나 향후에 컨테이너화될 수 있고 이에 투자할 계획인 경우 잠재적 문제가 컨테이너화 이점보다 큰 경우 Kubernetes, GKE, App Engine 가변형 환경, Cloud Functions, Cloud Run
배포 자동화 감사 가능한 자동화, 구조화, 간소화된 프로세스가 필요한 경우 팀에 필요한 기술이 부족하고 교육을 받을 기회가 없는 경우 또는 완전 자동 프로세스를 구현할 수 없는 경우 SonarQube, Jenkins, Cloud Build, Container Registry, Spinnaker
코드형 인프라 API를 사용하여 프로그래매틱 방식으로 대상 환경의 리소스를 완전 관리할 수 있는 경우 대상 환경에서 리소스 관리 및 구성에 필요한 프로그래매틱 방식의 액세스를 제공하지 않는 경우 Terraform, Cloud Deployment Manager

현재 상황, 전문 기술 수준, 프로세스에 대한 기대치에 따라 배포 프로세스가 완전히 달라지므로 최고의 배포 프로세스는 없습니다.

도움 받기

Google Cloud는 Google Cloud 서비스를 최적으로 활용하는 데 필요한 도움과 지원을 받을 수 있는 다양한 옵션과 리소스를 제공합니다.

  • 셀프서비스 리소스. 전담 지원이 필요하지 않은 경우 자신의 속도에 맞게 다양한 옵션을 사용할 수 있습니다.
  • 기술 파트너. Google Cloud는 여러 회사와 협력 관계를 맺어 Google 제품 및 서비스를 사용할 수 있도록 지원합니다.
  • Google Cloud 전문 서비스. Google 전문 서비스를 통해 Google Cloud 투자 효과를 극대화할 수 있습니다.

Google Cloud 마이그레이션 센터에는 워크로드를 Google Cloud로 마이그레이션하는 데 유용한 추가 리소스가 있습니다.

이러한 리소스에 대한 자세한 내용은 Google Cloud로 마이그레이션: 시작하기도움말 찾기 섹션을 참조하세요.

다음 단계