Google Cloud로 마이그레이션: 수동 배포에서 자동 컨테이너화된 배포로 마이그레이션

Last reviewed 2023-12-08 UTC

이 문서에서는 클라우드 기반 도구와 Google Cloud 관리형 서비스를 사용하여 수동 배포에서 컨테이너화된 자동 배포로의 마이그레이션 경로를 계획하고 설계하는 방법을 설명합니다.

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

이 문서는 배포 프로세스의 현대화를 계획 중이거나, 수동 및 기존 배포 프로세스에서 컨테이너화된 자동 배포로 마이그레이션하거나, 마이그레이션 기회를 평가하고 그 결과를 살펴보고 싶은 경우에 유용합니다.

이 마이그레이션을 시작하기 전에 마이그레이션 범위와 현재 배포 프로세스의 상태를 평가하고 기대치와 목표를 설정해야 합니다. 현재 워크로드를 배포하는 방법에 따라 시작점을 선택하세요.

  • 워크로드를 수동으로 배포합니다.
  • 구성 관리(CM) 도구로 워크로드를 배포합니다.

수동 배포에서 완전히 컨테이너화된 자동 배포로 직접 이동하기는 어렵습니다. 대신 다음과 같은 마이그레이션 단계를 따르는 것이 좋습니다.

  1. 컨테이너 조정 도구를 사용하여 배포
  2. 자동으로 배포

마이그레이션 단계별로 Google Cloud로 마이그레이션: 시작하기에서 정의된 단계를 수행합니다.

  1. 워크로드 평가 및 검색
  2. 기반 계획 및 구축
  3. 워크로드 배포
  4. 환경 및 워크로드 최적화

다음 다이어그램은 단계별 마이그레이션 단계를 보여줍니다.

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

이 마이그레이션 경로는 이상적이지만, 다음 단계로 이동할 때 얻게 될 이점이 특정 사례의 비용보다 클 경우 마이그레이션 프로세스를 일찍 중지할 수 있습니다. 예를 들어 워크로드를 자동으로 배포할 계획이 없다면 배포 후 컨테이너 조정 도구를 사용하여 중지할 수 있습니다. 여정을 계속할 준비가 되면 나중에 이 문서를 다시 참조할 수 있습니다.

마이그레이션의 한 단계에서 다른 단계로 이동할 때 다른 배포 프로세스를 동시에 사용할 수 있는 전환 단계가 있습니다. 실제로 모든 워크로드에 하나의 배포 옵션만 선택할 필요는 없습니다. 예를 들어 IaC 패턴을 적용하여 인프라를 관리하는 동시에 컨테이너 조정 도구로 워크로드를 배포하는 하이브리드 환경이 있을 수 있습니다.

Migrate to Containers 조정 도구

수동 배포에서 이동하는 첫 번째 단계 중 하나는 컨테이너 조정 도구로 워크로드를 배포하는 것입니다. 이 단계에서는 Kubernetes와 같은 컨테이너 조정 도구를 사용하여 컨테이너화된 워크로드를 처리하는 배포 프로세스를 설계하고 구현합니다.

워크로드가 아직 컨테이너화되지 않았다면 컨테이너화하는데 많은 노력이 필요합니다. 컨테이너화에 적합하지 않은 워크로드도 있습니다. 클라우드 기반이 아니거나 컨테이너화할 준비가 되지 않은 워크로드를 배포하는 경우에는 워크로드를 컨테이너화할 필요가 없습니다. 일부 워크로드는 기술 또는 라이선스를 이유로 컨테이너화를 지원하지 않을 수 있습니다.

워크로드 평가 및 검색

마이그레이션 범위를 지정하려면 먼저 생성 및 배포 중인 아티팩트의 인벤토리와 함께 다른 시스템 및 아티팩트의 종속 항목이 필요합니다. 이 인벤토리를 빌드하려면 현재 아티팩트 프로덕션 및 배포 프로세스를 설계하고 구현한 팀의 전문 지식을 사용해야 합니다. Google Cloud로 마이그레이션: 워크로드 평가 및 탐색 문서에서는 마이그레이션 중 환경 평가 방법과 앱 인벤토리 빌드 방법을 설명합니다.

각 아티팩트에 대해 현재 테스트 범위를 평가해야 합니다. 다음 단계로 이동하기 전에 모든 아티팩트에 대해 적절한 테스트 범위를 설정해야 합니다. 각 아티팩트를 수동으로 테스트하고 검증해야 한다면 자동화의 이점을 누릴 수 없습니다. 테스트 기반 개발과 같이 테스트의 중요성을 강조하는 방법을 채택합니다.

절차를 평가할 때 프로덕션에 적용할 수 있는 여러 다양한 버전의 아티팩트를 고려하세요. 예를 들어 최신 버전의 아티팩트가 지원해야 하는 인스턴스보다 여러 버전 앞서 있는 경우 두 버전을 모두 지원하는 모델을 설계해야 합니다.

또한 코드베이스를 관리하는 데 사용하는 분기 전략도 고려하세요. 분기 전략은 평가해야 하는 공동작업 모델의 일부일 뿐이므로 팀 내부 및 외부의 광범위한 공동작업 프로세스를 평가해야 합니다. 예를 들어 유연한 분기 전략을 채택했지만 커뮤니케이션 프로세스에 맞게 조정하지 않으면 팀의 효율성이 저하될 수 있습니다.

이 평가 단계에서는 현재 배포 프로세스보다 더 효율적이고 컨테이너에 적합한 아티팩트를 만드는 방법도 결정합니다. 효율성을 개선하는 한 가지 방법으로 다음을 평가해 보세요.

  • 공통 요소: 아티팩트의 공통점을 평가합니다. 예를 들어 공통 라이브러리 및 기타 런타임 종속 항목이 있으면 하나의 런타임 환경에서 통합하는 것이 좋습니다.
  • 런타임 환경 요구사항: 런타임 환경을 간소화하여 분산을 줄일 수 있는지 평가합니다. 예를 들어 모든 워크로드를 실행하기 위해 다양한 런타임 환경을 사용하는 경우 유지보수 부담을 줄이기 위해 공통된 기반에서 시작하는 것이 좋습니다.
  • 불필요한 구성요소: 아티팩트에 불필요한 요소가 포함되어 있는지 평가합니다. 예를 들어 디버깅 및 문제해결 도구와 같이 꼭 필요하지 않은 유틸리티 도구가 있을 수 있습니다.
  • 구성 및 보안 비밀 삽입: 런타임 환경의 요구사항에 따라 아티팩트를 구성하는 방법을 평가합니다. 예를 들어 현재의 구성 삽입 시스템이 컨테이너화된 환경을 지원하지 않을 수 있습니다.
  • 보안 요구사항: 컨테이너 보안 모델이 요구사항에 부합하는지 평가합니다. 예를 들어 컨테이너화된 환경의 보안 모델은 수퍼유저 권한, 시스템 리소스에 대한 직접 액세스 또는 단독 테넌시를 갖춰야 하는 워크로드의 요구사항과 충돌할 수 있습니다.
  • 배포 로직 요구사항: 고급 배포 프로세스를 구현해야 하는지 평가합니다. 예를 들어 카나리아 배포 프로세스를 구현해야 하는 경우 컨테이너 조정 도구를 통해 이 프로세스를 지원할지 여부를 결정할 수 있습니다.

기반 계획 및 구축

다음으로 Google Cloud에서 배포 프로세스를 지원하기 위해 Google Cloud 인프라와 서비스를 프로비저닝하고 구성합니다. Google Cloud로 마이그레이션: 기반 계획 및 빌드 문서에는 기반을 빌드하는 방법에 대한 안내가 포함되어 있습니다.

Google Cloud 리소스를 관리하는 데 필요한 유연성을 얻기 위해서는 개발, 테스트, 프로덕션 워크로드와 같은 여러 환경을 지원하는 Google Cloud 리소스 계층 구조를 설계하는 것이 좋습니다.

사용자 및 서비스 ID를 설정하는 경우 최상의 격리를 위해서는 배포 프로세스의 각 단계별로 최소 1개의 서비스 계정이 필요합니다. 예를 들어 아티팩트를 생성한 후 저장소에서 이 아티팩트의 스토리지를 관리하는 단계를 실행하는 프로세스의 경우 2개 이상의 서비스 계정이 필요합니다. 배포 프로세스의 개발 및 테스트 환경을 프로비저닝하고 구성하려면 더 많은 서비스 계정을 만들어야 할 수 있습니다. 환경마다 고유한 서비스 계정 집합이 있는 경우 환경이 서로 독립적으로 실행될 수 있게 만듭니다. 이 구성은 인프라의 복잡성과 운영팀의 부담을 가중시키지만 배포 프로세스에 영향을 주는 각 변경사항을 독립적으로 테스트하고 검증할 수 있는 유연성을 제공합니다.

또한 컨테이너화된 워크로드를 지원하기 위해 서비스와 인프라를 프로비저닝하고 구성해야 합니다.

새로운 워크로드를 배포할 때 컨테이너 조정 도구를 사용하면 인프라 프로비저닝에 대해 걱정할 필요가 없습니다. 예를 들어 Autopilot을 사용하여 GKE 클러스터 구성을 자동으로 관리할 수 있습니다.

컨테이너 조정 도구로 아티팩트 배포

평가 단계에서 수집한 요구사항과 이 단계의 기반 단계를 따라 다음을 수행하세요.

  • 워크로드를 컨테이너화합니다.
  • 컨테이너화된 워크로드를 처리하기 위한 배포 절차를 구현합니다.

워크로드를 컨테이너화하는 태스크는 쉽지 않습니다. 아래에서는 워크로드 컨테이너화를 위해 조정 및 확장해야 하는 활동의 일반 목록을 확인할 수 있습니다. 목표는 네트워킹 및 트래픽 관리, 영구 스토리지, 보안 비밀 및 구성 삽입, 내결함성 요구사항 등의 자체 요건을 처리하는 것입니다. 이 문서에서는 기반으로 사용할 컨테이너 이미지 집합을 빌드하고 워크로드에 맞춰 컨테이너 이미지 집합을 빌드하는 두 가지 활동을 다룹니다.

먼저 아티팩트 프로덕션을 자동화하므로 새 배포를 만들 때마다 새로운 이미지를 수동으로 생성할 필요가 없습니다. 소스 코드가 수정될 때마다 아티팩트 빌드 프로세스가 자동으로 트리거되므로 각 변경사항에 대한 즉각적인 피드백을 얻을 수 있습니다.

다음 단계를 실행하여 각 이미지를 생성합니다.

  1. 이미지 빌드
  2. 테스트 모음 실행
  3. 레지스트리에 이미지 저장

예를 들어 Cloud Build를 사용하여 아티팩트를 빌드한 후 이 아티팩트를 기준으로 테스트 도구 모음을 실행할 수 있으며, 테스트에 성공하면 Container Registry에 결과를 저장할 수 있습니다.

또한 아티팩트를 식별하기 위한 규칙을 설정해야 합니다. 이미지를 생성할 때 각 이미지에 라벨을 지정하여 각 프로세스가 반복 실행되도록 설정할 수 있습니다. 예를 들어 많이 사용되는 규칙은 컨테이너 이미지를 출시할 때 해당 이미지에 태그를 지정하는 경우 시맨틱스 버전 관리를 사용하여 출시를 식별하는 것입니다. 출시 전에도 작업이 필요한 이미지를 생성하는 경우 해당 이미지를 프로세스에서 생성된 코드베이스의 특정 지점에 연결하는 식별자를 사용할 수 있습니다. 예를 들어 Git 저장소를 사용하는 경우 커밋 해시를 저장소의 기본 브랜치에 커밋을 푸시할 때 생성되는 해당 컨테이너 이미지의 식별자로 사용할 수 있습니다.

이 단계의 평가 단계에서 아티팩트, 공통 요소, 런타임 요구사항에 대한 정보를 수집했습니다. 이제 이 정보를 사용하여 워크로드에 사용할 기본 컨테이너 이미지 집합과 다른 이미지 집합을 설계하고 빌드할 수 있습니다. 기본 이미지를 시작점으로 사용하여 워크로드에 맞게 이미지를 빌드합니다. 지원되지 않는 런타임 환경이 확산되지 않도록 기본 이미지 집합을 철저하게 제어하고 지원해야 합니다.

기본 이미지를 기반으로 컨테이너 이미지를 생성할 때는 각 이미지 내부의 워크로드뿐만 아니라 테스트 도구 모음을 확장하여 이미지를 처리해야 합니다. InSpec, ServerSpec, RSpec과 같은 도구를 사용하여 런타임 환경에서 규정 준수 테스트 도구 모음을 실행할 수 있습니다.

워크로드를 컨테이너화하고 이러한 컨테이너 이미지를 자동으로 생성하는 절차 구현이 완료되면 컨테이너 조정 도구를 사용하기 위한 배포 절차를 구현합니다. 평가 단계에서는 리치 배포 절차를 설계하기 위해 수집한 배포 로직 요구사항에 대한 정보를 사용합니다. 컨테이너 조정 도구를 사용하면 메커니즘을 수동으로 구현하지 않고 제공된 메커니즘을 통해 배포 로직 구성에 집중할 수 있습니다.

배포 절차를 설계하고 구현할 때는 워크로드에 구성 파일 및 보안 비밀을 삽입하고 스테이트풀(Stateful) 워크로드에 대한 데이터를 관리하는 방법을 고려하세요. 구성 파일 및 보안 비밀 삽입은 고정 아티팩트를 생성하는 데 중요한 역할을 합니다. 고정 아티팩트를 배포한 후에는 다음을 수행할 수 있습니다.

  • 예를 들어 개발 환경에 아티팩트를 배포하면 테스트와 검증을 거쳐 품질 보증 환경으로 이동한 다음 마지막으로 프로덕션 환경으로 이동합니다.
  • 동일한 아티팩트가 여러 테스트와 검증 활동을 거쳤기 때문에 프로덕션 환경에서 문제가 발생할 가능성이 줄어듭니다.

워크로드가 스테이트풀(Stateful)인 경우 데이터에 필요한 영구 스토리지를 프로비저닝하고 구성하는 것이 좋습니다. Google Cloud에는 다음과 같은 다양한 옵션이 있습니다.

배포할 아티팩트를 자동으로 생성할 수 있으면 워크로드를 배포하는 데 사용하는 도구의 런타임 환경을 설정할 수 있습니다. 배포 도구의 런타임 환경을 제어하려면 환경을 Cloud Build의 빌드로 설정하고 해당 빌드를 환경에 아티팩트를 배포하는 유일한 수단으로 사용할 수 있습니다. Cloud Build를 사용하면 각 작업자가 머신에 런타임 환경을 설정할 필요가 없습니다. 빌드 구성의 소스 코드를 검사하여 런타임 환경과 관련 콘텐츠를 만드는 절차를 즉시 감사할 수 있습니다.

환경 최적화

배포 프로세스를 구현한 후에는 컨테이너 조정 도구를 사용하여 배포 프로세스를 최적화할 수 있습니다. 자세한 내용은 Google Cloud로 마이그레이션: 환경 최적화를 참조하세요.

이 최적화 반복의 요구사항은 다음과 같습니다.

  • 필요에 따라 모니터링 시스템을 확장합니다.
  • 테스트 범위를 확장합니다.
  • 환경의 보안을 강화합니다.

모니터링 시스템을 확장하여 새로운 아티팩트 프로덕션, 배포 절차, 새로운 모든 런타임 환경을 포괄합니다.

프로세스를 효과적으로 모니터링, 자동화, 코드화하려면 테스트 범위를 넓히는 것이 좋습니다. 평가 단계에서는 적어도 최소한의 엔드 투 엔드 테스트 범위를 확보해야 합니다. 최적화 단계에서는 테스트 도구 모음을 확장하여 더 많은 사용 사례를 처리할 수 있습니다.

마지막으로 환경의 보안을 강화하기 위해 서명된 이미지 집합만 클러스터에 배포하도록 Binary Authorization을 구성할 수 있습니다. Artifact Analysis를 사용 설정하여 Artifact Registry에 저장된 컨테이너 이미지에 취약점이 있는지 검사할 수도 있습니다.

배포 자동화로 마이그레이션

컨테이너 조정 도구로 마이그레이션한 후에는 전체 배포 자동화 단계로 이동할 수 있으며, 아티팩트 프로덕션 및 배포 절차를 확장하여 워크로드를 자동으로 배포할 수 있습니다.

워크로드 평가 및 검색

이전의 평가 결과에 따라 이제 배포 프로세스의 요구사항에 집중합니다.

  • 수동 승인 단계: 배포 절차에서 수동 단계를 지원해야 하는지 평가합니다.
  • 시간당 배포 단위: 지원해야 하는 시간당 배포 단위 수를 평가합니다.
  • 새 배포를 유발하는 요소: 배포 절차와 상호작용하는 외부 시스템을 평가합니다.

수동 배포 단계를 지원해야 한다고 해서 절차를 자동화할 수 없다는 의미는 아닙니다. 이 경우 절차의 각 단계를 자동화하고 필요에 따라 수동 승인 게이트를 배치합니다.

매일 또는 시간당 여러 배포를 지원하는 것이 매월 또는 매년 몇 가지 배포를 지원하는 것보다 더 복잡합니다. 하지만 자주 배포하지 않으면 민첩성, 문제 대응력, 워크로드에 새로운 기능을 제공하는 기능이 저하될 수 있습니다. 따라서 완전히 자동화된 배포 절차를 설계하고 구현하기 전에 기대치와 목표를 설정하는 것이 좋습니다.

또한 런타임 환경에서 새 배포를 트리거하는 요소를 평가합니다. 예를 들어 개발 환경에는 모든 새로운 출시를 배포할 수 있지만 품질 보증 환경에는 특정 품질 기준을 충족하는 출시만 배포할 수 있습니다.

기반 계획 및 구축

이전 단계에서 구축한 기반을 확장하기 위해 자동 배포 절차를 지원하도록 서비스를 프로비저닝하고 구성합니다.

각 런타임 환경에 배포 절차를 지원하는 데 필요한 인프라를 설정합니다. 예를 들어 개발, 품질 보증, 사전 프로덕션, 프로덕션 환경에 배포 절차를 프로비저닝하고 구성하면 절차 변경사항을 자유롭고 유연하게 테스트할 수 있습니다. 그러나 단일 인프라를 사용하여 런타임 환경을 배포하는 경우 환경 관리는 더 쉬워지지만 절차를 변경해야 할 때 유연성이 떨어집니다.

서비스 계정과 역할을 프로비저닝할 때는 책임을 공유하지 않는 전용 서비스 계정을 만들어 환경과 워크로드를 서로 격리하는 것이 좋습니다. 예를 들어 동일한 서비스 계정을 서로 다른 런타임 환경에 재사용하면 안 됩니다.

완전히 자동화된 절차로 아티팩트 배포

이 단계에서는 승인 단계 외에 수동 작업 없이 아티팩트를 배포하도록 배포 절차를 구성합니다.

이 마이그레이션 단계의 평가 단계 중에 수집한 요구사항에 따라 Cloud Deploy와 같은 도구를 사용해서 자동화된 배포 절차를 구현할 수 있습니다.

특정 아티팩트의 경우 각 배포 절차에서는 다음 작업을 실행해야 합니다.

  1. 대상 런타임 환경에 아티팩트를 배포합니다.
  2. 배포된 아티팩트에 구성 파일과 보안 비밀을 삽입합니다.
  3. 새로 배포된 아티팩트에 대해 규정 준수 테스트 모음을 실행합니다.
  4. 아티팩트를 프로덕션 환경으로 승격합니다.

배포 절차에서 요구사항에 따라 새 배포를 트리거하는 인터페이스를 제공하는지 확인합니다.

코드 검토는 자동 배포 절차를 구현할 때 필요한데, 이는 설계상 자동 배포 절차의 일부로 짧은 피드백 루프가 있기 때문입니다. 예를 들어 별도의 검토 없이 프로덕션 환경에 변경사항을 배포하면 프로덕션 환경의 안정성과 신뢰성이 영향을 받게 됩니다. 검토를 거치지 않았거나 잘못된 형식이거나 악의적인 변경사항으로 인해 서비스가 중단될 수 있습니다.

환경 최적화

배포 절차를 자동화한 후에는 다른 최적화 반복을 실행할 수 있습니다. 이 반복의 요구사항은 다음과 같습니다.

  • 자동 배포 절차를 지원하는 인프라를 포괄하도록 모니터링 시스템을 확장합니다.
  • 고급 배포 패턴을 구현합니다.
  • 긴급 상황 처리 절차를 구현합니다.

효과적인 모니터링 시스템을 사용하면 환경에 필요한 추가 최적화를 계획할 수 있습니다. 환경의 동작을 측정할 때 성능을 저해하는 병목 현상이나 다른 문제(예: 실수나 무단의 액세스, 악용 등)를 찾을 수 있습니다. 예를 들어 특정 리소스의 소비가 일정 기준에 도달하면 알림을 받도록 환경을 구성합니다.

컨테이너를 효율적으로 조정할 수 있으면 필요에 따라 고급 배포 패턴을 구현할 수 있습니다. 예를 들어 블루-그린 배포를 구현하여 환경의 신뢰성을 높이고 문제 발생 시 사용자에게 미치는 영향을 줄일 수 있습니다.

다음 단계