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

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

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

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

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

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

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

  1. 컨테이너 조정 도구를 사용하여 배포
  2. 자동으로 배포
  3. IaC 패턴을 적용하여 배포

다음 다이어그램은 이 마이그레이션의 경로를 보여줍니다.

수동 배포에서 자동 배포로 이동하는 마이그레이션 경로

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

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

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

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

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

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

컨테이너 조정 도구로 마이그레이션

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

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

워크로드 평가 및 검색

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

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

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

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

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

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

기반 계획 및 구축

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

Google Cloud 조직, 폴더, 프로젝트를 만들 때 여러 환경에서 공유되는 배포 프로세스를 고려해야 합니다. 기능 중심의 계층 구조 또는 세부 액세스 중심 계층 구조를 사용하는 것이 좋습니다. 이러한 계층 구조를 사용하면 유연하게 리소스를 관리하고 여러 환경에서 개발과 테스트를 수행할 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

환경 최적화

배포 프로세스를 구현한 후에는 컨테이너 조정 도구를 사용하여 배포 프로세스를 최적화할 수 있습니다. Google Cloud로 마이그레이션: 시작하기 문서에는 환경을 최적화하는 방법이 설명되어 있습니다.

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

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

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

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

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

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

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

워크로드 평가 및 검색

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

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

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

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

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

기반 계획 및 구축

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

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

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

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

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

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

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

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

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

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

환경 최적화

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

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

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

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

완전히 자동화된 배포 프로세스의 특성을 고려할 때 일반 배포 절차를 사용하지 않고 런타임 환경과 상호작용할 수 있는 긴급 상황 처리 절차를 설계하고 구현하는 것이 좋습니다. 이 절차는 예외적인 상황에서 팀 내 상급 관리자가 사전 승인한 경우에만 사용합니다. 예를 들어 배포 절차 문제로 인해 환경에 액세스할 수 없는 경우에는 긴급 상황 처리 절차를 통해 문제를 유발한 변경사항을 롤백해야 합니다.

코드형 인프라 도입

이제 팀이 Google Cloud를 효과적으로 사용하는 방법을 숙지했으므로 IaC 패턴을 적용할 수 있습니다. IaC는 워크로드의 소스 코드를 처리할 때와 동일한 방식으로 런타임 환경에서 리소스 프로비저닝을 처리하는 프로세스입니다.

인프라 평가 및 탐색

이 평가 단계에서는 다음을 포함하여 이전의 마이그레이션 단계에서 프로비저닝한 인프라를 상세하게 파악합니다.

  • 인프라의 일부로 구성한 Google Cloud 리소스
  • 현재 사용 중인 변경 관리 프로세스
  • 인프라를 수정할 권한이 있는 조직 구성원

이 마이그레이션 단계에서는 코드를 사용해 리소스를 설명해야 하므로 IaC를 도입할 때 현재 인프라에 있는 리소스의 인벤토리를 사용할 수 있는지 확인해야 합니다.

변경 관리 프로세스는 인프라의 발전을 관리하는 데 있어 기초적인 역할을 합니다. 프로세스가 있다면 이를 조정하여 IaC를 처리할 수 있습니다. 인프라의 변경 관리 프로세스가 없으면 이 단계에서 설계하고 구현할 수 있습니다. 변경 관리 프로세스에는 제안된 변경사항을 분석하는 검토 단계가 포함되어야 합니다. 인프라 변경으로 인한 다운타임이나 예기치 않은 비용을 방지하려면 이 분석과 함께 인프라를 수정할 수 있는 팀 구성원에 대한 평가가 필요합니다.

기반 계획 및 구축

이전 단계에서 구축한 기반을 확장하려면 IaC 도입을 지원하도록 인프라를 프로비저닝하고 구성해야 합니다.

먼저 도입할 도구를 선택해야 합니다. Google Cloud에서 일반적으로 사용되는 도구는 다음과 같습니다.

  • Deployment Manager: 모든 Google Cloud 리소스를 완벽하게 지원하는 관리형 서비스
  • Terraform: Google Cloud 및 기타 클라우드 제공업체를 지원하는 오픈소스 프로비저닝 도구
  • Chef, Puppet, Ansible: Google Cloud를 지원하는 오픈소스 구성 도구

IaC 도구를 선택한 후에는 이러한 도구를 지원하는 데 필요한 모든 인프라를 프로비저닝하고 구성해야 합니다. 최소한 다음이 필요합니다.

  • 리소스의 설명자를 관리하고 버전을 지정하는 소스 코드 저장소
  • 변경사항을 적용하기 전에 각 변경사항을 분석하고 승인하는 코드 검토 도구
  • 검토 중에 팀에서 변경사항을 승인한 후 IaC 도구를 실행하기 위한 런타임 환경

일부 IaC 도구에는 인프라를 관리하는 서비스가 필요합니다. 예를 들어 인프라를 관리하기 위해 조직의 다른 구성원과 공동작업하려면 Terraform에 원격 데이터 스토리지가 있어야 합니다.

IaC 도구로 이 기반을 관리하려면 변경사항을 적용할 때 이 기반의 작동이 중단되지 않도록 보호 장치를 구현하는 것이 좋습니다. 이러한 중단으로 인해 다운타임 증가나 복구 불가능한 데이터 손실 등의 문제가 발생할 수 있습니다. 예를 들어 인프라 설명자를 저장하는 소스 코드 저장소를 실수로 삭제한 경우 복구할 수 없는 데이터 손실 문제가 발생할 수 있습니다. 선취권과 같은 도구를 사용하면 프로젝트의 삭제를 방지할 수 있습니다.

IaC로 Google Cloud 리소스 프로비저닝

Google Cloud 환경이 준비되면 IaC를 사용하여 환경의 리소스를 관리할 수 있습니다.

  • 기존 리소스를 코드로 설명합니다.
  • IaC로 새로운 리소스를 프로비저닝합니다.

이전 단계에서는 Cloud Console, Cloud SDK 또는 Cloud APIs를 사용하여 Google Cloud 리소스를 프로비저닝했습니다. 이 단계에서는 선택한 IaC 도구의 구문과 규칙에 따라 코드를 사용하여 이러한 리소스를 설명합니다.

IaC 도구가 현재 리소스 및 인스턴스를 인식하도록 설정하려면 도구의 인벤토리에 이러한 리소스 및 인스턴스를 가져와야 합니다. 선택한 IaC 도구에는 현재 리소스 및 인스턴스에 대한 상태 정보가 없습니다. 리소스를 다시 가져오거나 해당 인스턴스를 수동으로 폐기하고 IaC 도구를 사용해 리소스 및 인스턴스를 다시 만들어야 합니다. 예를 들어 Terraform은 기존 인프라를 가져올 수 있습니다.

인프라에서 새 구성요소를 정의해야 하는 경우 이제 다른 프로비저닝 절차를 거치지 않고 코드를 사용해 직접 설명할 수 있습니다.

환경 최적화

IaC를 도입한 후에는 다른 최적화 반복을 실행합니다. 이 반복의 요구사항은 다음과 같습니다.

  • 필요에 따라 모니터링 시스템을 확장합니다.
  • 인프라를 포괄하도록 테스트 도구 모음을 확장합니다.
  • 인프라의 프로비저닝 및 구성을 자동화합니다.
  • 긴급 상황 처리 절차를 확장하여 인프라를 포괄합니다.

이전 배포 단계이전 마이그레이션 단계의 최적화 단계에서 수행한 작업을 바탕으로 IaC 도입을 지원하는 인프라로 모니터링을 확장합니다. 예를 들어 IaC 도구가 실행되는 모든 런타임 환경을 모니터링하고 각 실행에 대한 정보를 정확하게 로깅하여 나중에 검사할 수 있는 감사 추적을 빌드할 수 있습니다.

워크로드 및 컨테이너 이미지는 물론 인프라를 포괄하도록 테스트 도구 모음을 확장할 수 있습니다. InSpec, ServerSpec, RSpec과 같은 도구를 사용하여 런타임 환경의 규정 준수 테스트 도구 모음을 실행할 수 있습니다. 수동 변경이나 IaC 파이프라인 외부의 요인에서 비롯되는 변경으로부터 인프라를 보호할 수 있습니다. 인프라에 대해 테스트 도구 모음을 지속적으로 실행하면 승인되지 않은 변경사항을 감지하고 상황을 해결할 수 있습니다.

IaC 도입이 필요하다고 확신하면 새로운 절차를 설계하고 구현하여 인프라 프로비저닝을 자동화하세요. 이러한 새로운 프로비저닝 절차는 아티팩트를 생성하고 배포하는 데 사용되는 절차와 크게 다릅니다. 인프라 프로비저닝 절차는 애플리케이션이 아닌 인프라 변경사항을 처리하도록 설계되었습니다. 따라서 이러한 절차는 아티팩트 생성 및 배포 절차와는 다른 유형의 문제를 해결하고 오류의 영향 범위도 서로 다릅니다. 인프라 요소가 실패하면 오류의 영향 범위로 손상 정도를 설명합니다. 예를 들어 오류가 있는 아티팩트를 배포하면 하나 이상의 사용 사례에 영향을 미치는 서비스 중단이 발생할 수 있습니다. 오류가 있는 인프라 구성요소를 프로비저닝하면 환경의 여러 서비스에 영향을 미치는 서비스 중단이 발생할 수 있습니다.

도움 받기

Google Cloud는 다음과 같은 지원 리소스를 제공합니다.

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

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

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

다음 단계