Migrate to Containers로 VM을 컨테이너로 마이그레이션

Last reviewed 2021-10-21 UTC

이 문서는 컨테이너에 대한 가상 머신 기반 워크로드의 마이그레이션 계획을 설계하고 구현하는 클라우드 설계자를 대상으로 합니다. 이 문서에서는 Migrate to Containers를 사용해서 소스 환경의 가상 머신(VM)을 Google Kubernetes Engine(GKE) 또는 GKE Enterprise에서 실행되는 컨테이너로 마이그레이션하는 방법을 설명합니다. 원본 환경은 온프레미스 환경, 비공개 호스팅 환경 또는 다른 클라우드에서 실행 중일 수 있습니다.

이 문서는 Migrate to Containers의 개요를 제공합니다. 또한 컨테이너로 VM 마이그레이션을 계획할 때 고려해야 할 다른 항목에 대해서도 설명합니다. 이 문서는 Google Cloud로 마이그레이션하는 방법을 다루는 시리즈의 일부입니다. 시리즈의 개요에 대해 자세히 알아보려면 Google Cloud로 마이그레이션: 마이그레이션 경로 선택을 참조하세요.

지원되는 원본 환경에서 Linux 또는 Windows와 같은 호환되는 운영체제(OS)를 실행하는 VM을 Migrate to Containers를 사용하여 GKE 또는 GKE Enterprise 환경으로 마이그레이션하는 경우 이 문서를 읽어보세요. 이러한 원본 환경에는 다음이 포함될 수 있습니다.

Migrate to Containers를 사용하면 다음 조건에 관계없이 GKE 및 GKE Enterprise 컨테이너에 기존 VM 기반 워크로드를 배치할 수 있습니다.

  • 소스 코드 액세스 요구
  • 워크로드 재작성
  • 워크로드 수동 컨테이너화

Migrate to Containers를 사용하여 VM 기반 워크로드를 마이그레이션할 때의 이점은 다음과 같습니다.

  • 다음을 갖춘 컨테이너화된 환경:
  • 높은 워크로드 밀도
  • 다양한 조정 메커니즘 및 정책 관리
  • 유연한 서비스 간 통신 채널
  • 지속적 통합 및 지속적 배포 파이프라인을 사용할 수 있습니다.
  • 지원되지 않는 OS 버전에서 이동 가능
  • VM 기반 환경 해제 시작 가능

Migrate to Containers를 사용하여 VM 기반 워크로드를 컨테이너로 마이그레이션하는 작업은 워크로드 현대화 여정에서 수행할 수 있는 여러 단계 중 하나입니다. Migrate to Containers를 사용하여 VM 기반 워크로드를 마이그레이션하면 워크로드를 현대화하는 데 필요한 고비용 재작성 작업을 방지할 수 있습니다. 하지만 클라우드 환경에서 실행하도록 설계된 워크로드로 변환하지 않습니다.

이상적인 마이그레이션 후보는 다음과 같습니다.

  • 완전한 재작성을 통한 현대화가 불가능하거나 비용이 너무 많이 드는 워크로드
  • 변화가 있는 경우 문제를 일으킬 수 있는 종속 항목이 포함된 워크로드
  • 유지보수되지만 현재 개발 중이 아닌 워크로드
  • 더 이상 유지보수되지 않는 워크로드
  • 소스 코드 액세스가 없는 워크로드

여러 방법으로 Migrate to Containers와 상호작용할 수 있습니다. 예를 들어 Google Cloud 콘솔을 통해 액세스할 수 있습니다. 마이그레이션 프로세스를 자동화하고 이를 기존 도구 모음과 통합해야 할 경우에는 명령줄 인터페이스 및 Migrate to Containers Kubernetes 커스텀 리소스 정의(CRD)를 사용할 수 있습니다.

Migrate to Containers 인터페이스에 대한 자세한 내용은 API 및 참조 | Migrate to Containers를 확인하세요.

이 문서에서는 사용자가 다음 문서를 읽고 숙지했다고 가정합니다.

Google Cloud로의 마이그레이션 설계

VM을 원본 환경에서 Google Cloud에서 실행 중인 컨테이너로 마이그레이션하려면 Google Cloud로의 마이그레이션 시리즈에 설명된 프레임워크를 따르는 것이 좋습니다.

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

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

앞의 다이어그램에 표시된 프레임워크는 다음 4가지 단계로 구성되어 있습니다.

  1. 평가. 이 단계에서는 원본 환경, Google Cloud로 마이그레이션할 워크로드, 각 워크로드를 지원하는 VM을 평가합니다.
  2. 계획. 이 단계에서는 리소스 계층 구조 프로비저닝 및 네트워크 액세스 설정과 같은 Migrate to Containers의 기본 인프라를 만듭니다.
  3. 배포. 이 단계에서는 Migrate to Containers를 사용해서 VM을 원본 환경에서 GKE 또는 GKE Enterprise로 마이그레이션합니다.
  4. 최적화. 이 단계부터 클라우드 기술 및 기능을 활용하게 됩니다.

원본 환경 및 워크로드 평가

평가 단계에서는 원본 환경 및 마이그레이션하려는 VM 기반 워크로드에 대한 정보를 수집합니다. 이를 통해 마이그레이션과 대상 환경 모두에 필요한 리소스의 크기를 적절하게 조정할 수 있습니다.

평가 단계에서 다음을 수행합니다.

  1. 워크로드의 포괄적인 인벤토리를 빌드합니다.
  2. 워크로드의 속성과 종속 항목에 따라 애플리케이션을 분류합니다.
  3. 팀에 Google Cloud 교육을 실시합니다.
  4. Google Cloud에 대한 실험 및 개념 증명을 빌드합니다.
  5. 대상 환경의 총 소유 비용(TCO)을 계산합니다.
  6. 먼저 마이그레이션할 워크로드를 선택합니다.

다음 섹션에는 Google Cloud로 마이그레이션: 워크로드 평가 및 검색의 정보가 사용됩니다. 하지만 Migrate to Containers를 사용해서 컨테이너로 마이그레이션하려는 VM 기반 워크로드를 평가하는 작업과 관련된 정보를 제공합니다.

인벤토리 빌드

마이그레이션 범위를 지정하려면 현재 VM 기반 환경을 이해해야 합니다. 환경을 이해하기 위해서는 워크로드 및 해당 종속 항목에 대한 정보를 수집합니다.

앱의 인벤토리 빌드에서는 VM 기반 환경에서 워크로드 인벤토리를 빌드하는 방법 및 해당 종속 항목에 대해 설명합니다. 이 문서를 따라하기 전에 해당 안내에 따라 인벤토리를 빌드하세요.

워크로드의 인벤토리 및 종속 항목을 빌드한 후 인벤토리를 세분화합니다. Migrate to Containers를 사용해서 VM 기반 워크로드를 마이그레이션할 때 조직에 필요한 측면 및 기능을 평가합니다.

워크로드의 인벤토리를 완료하려면 다음을 고려하세요.

  • 원본 환경. Migrate to Containers는 여러 원본 환경에서의 VM 마이그레이션을 지원합니다.

    • Compute Engine
    • VMware vSphere
    • Microsoft Azure VM
    • Amazon EC2

    워크로드를 마이그레이션할 수 있도록 Migrate to Containers를 올바르게 설정하기 위해서는 원본 환경을 액세스해야 합니다.

  • VM에서 실행되는 운영체제: VM에서 실행되는 운영체제 및 해당 라이선스에 대한 정보를 수집하고 운영체제가 Migrate to Containers와 호환되는지 확인합니다. Migrate to Containers에서 지원되지 않는 OS를 실행하는 경우에는 지원되는 버전으로 업그레이드하거나 OS를 Migrate to Containers에서 지원되는 OS로 변경합니다.

  • VM의 워크로드: 각 VM에 배포된 워크로드를 평가합니다. 그런 후 워크로드 사이 및 워크로드와 외부 서비스 사이의 종속 항목을 매핑합니다. 그런 후 워크로드의 구성 소스에 대한 정보를 수집합니다. 예를 들어 워크로드를 동적으로 구성하기 위해 환경 변수, 분산 구성 시스템, 메타데이터 서버 등이 사용되는지 확인합니다. 또한 워크로드가 로깅 시스템으로 정보를 전송하는 방법을 평가합니다.

  • Migrate to Containers 적합성 점수: Migrate to Containers를 사용하여 마이그레이션을 수행하는 데 워크로드가 적합한지 여부를 평가합니다. Migrate to Containers는 적합성 점수 계산을 위해 VM에서 실행할 수 있는 Linux 및 Windows용 적합성 평가 도구를 제공합니다. 적합성 점수가 낮으면 워크로드를 마이그레이션하기 전 해결해야 할 문제가 있음을 나타냅니다. 예를 들어 VM에서 보안 향상된 Linux를 사용 설정했으면 마이그레이션하기 전 이러한 종속 항목 문제를 해결하기 위해 추가 노력이 필요할 수 있습니다.

  • 네트워크 서비스: 네트워크 서비스 구성과 VM 기반 워크로드에서 이러한 서비스가 사용되는 방법에 대한 정보를 수집합니다. 예를 들어 다른 워크로드 및 서비스 위치를 확인하기 위해 워크로드에 DNS(도메인 이름 시스템), 멀티캐스트 DNS, 호스트 파일, 기타 서비스 검색 메커니즘이 사용되는 방식을 평가합니다. 그런 후 워크로드에 필요한 맞춤설정된 항목에 대해 각 VM의 호스트 파일을 평가합니다. 호스트 파일에 대한 자세한 내용은 생성된 리소스 및 설명자 확인 및 검증을 참조하세요.

  • 하드웨어 종속 항목: .고성능 스토리지 기기, GPU, TPU, 네트워크 어플라이언스와 같은 VM 기반 환경에서 사용하는 모든 유형의 하드웨어를 평가합니다.

  • 스테이트리스(Stateless) 및 스테이트풀(Stateful) 워크로드: 스테이트리스(Stateless) 워크로드는 클러스터 또는 영구 스토리지에 상태를 저장하지 않습니다. 스테이트풀(Stateful) 워크로드는 나중에 사용할 수 있도록 데이터를 저장합니다. 스테이트풀(Stateful) 워크로드를 마이그레이션하는 것이 스테이트리스(Stateless) 워크로드를 마이그레이션하는 것보다 일반적으로 더 어렵기 때문에 어떤 워크로드가 스테이트리스(Stateless)이고 무엇이 스테이트풀(Stateful)인지 평가합니다.

  • 스토리지: 스테이트풀(Stateful) 워크로드에 대해 스토리지 요구사항 목록을 만듭니다. 목록을 만들 때 고려해야 할 사항은 다음과 같습니다.

    • 스토리지 시스템 유형(블록 볼륨, 파일 스토리지 또는 객체 스토리지)
    • 스토리지 시스템 크기
    • 스토리지 시스템에 대한 워크로드 액세스

      • 예: 워크로드가 네트워크 파일 시스템(NFS) 또는 서버 메시지 블록(SMB)을 사용하여 네트워크를 통해 파일에 액세스하나요?
      • 예: VM이 NFS 또는 SMB 서버를 실행하나요?

        VM이 커널 모드로 NFS 서버를 실행하는 경우 이러한 서버를 마이그레이션하기 위해 추가 노력이 필요합니다. 이러한 서버를 Compute Engine 또는 GKE와 같은 다른 런타임으로 마이그레이션할 수 있습니다. 또는 완전 관리형 네트워크 연결 스토리지 서비스인 Filestore로 데이터를 마이그레이션할 수 있습니다.

    • 디스크 구성:

      • VM의 모든 디스크, 데이터 파티션, 볼륨의 구성과 각각의 보안 및 비밀유지 기능을 평가합니다.
  • 데이터 위치: 데이터 위치는 스테이트풀(Stateful) 워크로드의 성능에 영향을 줍니다. 외부 시스템과 환경 간의 거리와 연결은 지연 시간에 영향을 줍니다. 각 외부 데이터 스토리지 시스템에 대해 충족해야 하는 성능 및 가용성 요구사항을 고려하세요.

평가 완료

환경 및 VM 기반 워크로드와 관련된 인벤토리를 빌드한 후 Google Cloud로 마이그레이션: 워크로드 평가 및 검색에 설명된 나머지 평가 단계 활동을 완료합니다. 작업을 마치면 이 문서를 계속 읽습니다.

기반 계획 및 구축

계획 및 구축 단계에서는 Google Cloud에서 워크로드를 지원하는 클라우드 인프라와 서비스를 프로비저닝하고 구성합니다.

  1. 리소스 계층 구조를 빌드합니다.
  2. Identity and Access Management 구성
  3. 결제를 설정합니다.
  4. 네트워크 연결을 설정합니다.
  5. 보안을 강화합니다.
  6. 모니터링 및 알림을 설정합니다.

워크로드 및 종속 항목을 지원하는 클라우드 인프라 및 서비스를 빌드하는 방법은 Google Cloud로 마이그레이션: 기반 구축을 참조하세요. 해당 안내에 따라 환경 기반을 구축합니다. 작업을 마치면 이 문서를 계속 읽습니다.

'Google Cloud로 마이그레이션: 기반 구축'의 안내를 따른 후 Migrate to Containers를 설정하여 기반 작업을 완료합니다.

  1. 워크로드 및 원본 환경이 Migrate to Containers 기본 요건을 충족하는지 확인합니다.
  2. Migrate to Containers Cloud API를 사용 설정합니다.
  3. Migrate to Containers가 대상 환경의 리소스에 액세스하기 위해 사용하는 서비스 계정을 프로비저닝합니다.
  4. 워크로드를 Google Cloud의 GKE 또는 GKE 클러스터로 마이그레이션하는 경우 Migrate to Virtual Machines를 설정합니다.
  5. Migrate to Containers 처리 클러스터를 구성합니다. Migrate to Containers 처리 클러스터는 마이그레이션 중 Migrate to Containers 구성요소를 실행합니다.
  6. 처리 클러스터에서 Migrate to Containers 설치 및 구성합니다.

앞에서 언급한 'Migrate to Containers 설정' 문서에서는 Migrate to Containers 및 종속 항목을 프로비저닝 및 구성하는 방법을 설명합니다. 이 안내에 따라 Migrate to Containers를 설정하세요.

이 섹션에 설명된 작업을 마치면 이 문서로 돌아갑니다.

VM 기반 워크로드를 컨테이너로 마이그레이션

배포 단계에서는 다음 주요 단계를 사용하여 원본 환경의 VM을 GKE 또는 GKE Enterprise에서 실행 중인 컨테이너로 마이그레이션하는 과정을 안내합니다.

  1. 마이그레이션 계획을 생성하고 검토합니다.
  2. 컨테이너 아티팩트 및 배포 설명자를 생성합니다.
  3. Migrate to Containers에서 생성된 리소스 설명자를 확인, 검증, 맞춤설정합니다.
  4. GKE 또는 GKE Enterprise에 컨테이너화된 워크로드를 배포하고 검증합니다.
  5. Migrate to Containers를 제거합니다.

Migrate to Containers를 사용하여 VM을 마이그레이션하는 데 필요한 단계에 대한 자세한 내용은 마이그레이션 실행을 참조하세요.

마이그레이션 계획 생성 및 검토

VM 기반 워크로드에 대해 Migrate to Containers 마이그레이션 계획을 만듭니다.

  1. 원본 환경을 Migrate to Containers 마이그레이션 소스로 구성합니다. VM 기반 워크로드를 마이그레이션하기 위해서는 Migrate to Containers에 VM이 현재 실행되는 원본 환경에 대한 정보가 필요합니다. 이 정보는 이 문서의 인벤토리 빌드 섹션에 설명된 태스크를 수행하여 수집되었습니다. 소스 환경 구성에 대한 자세한 내용은 마이그레이션 소스 추가(Linux)마이그레이션 소스 추가(Windows)를 참조하세요.
  2. 마이그레이션 계획을 만듭니다. 원본 환경에서 지원되는 대상 환경으로 마이그레이션하려는 VM 기반 워크로드를 지정하기 위해 마이그레이션 계획을 만듭니다. 예를 들어 영구 데이터를 저장할 위치를 구성할 수 있습니다. 마이그레이션 계획 만들기 및 모니터링에 대한 자세한 내용은 마이그레이션 만들기(Linux)마이그레이션 만들기(Windows)를 참조하세요.
  3. 마이그레이션 계획을 검토하고 맞춤설정합니다. 마이그레이션하려는 각 VM 기반 워크로드에 대해 마이그레이션 계획을 생성한 후에는 요구사항에 적합한지 확인하기 위해 각 마이그레이션 계획을 검토하고 맞춤설정하는 것이 좋습니다. 마이그레이션 계획 맞춤설정에 대한 자세한 내용은 마이그레이션 계획 맞춤설정(Linux)마이그레이션 계획 맞춤설정(Windows)을 참조하세요.

이 섹션에 설명된 작업을 마치면 이 문서로 돌아갑니다.

컨테이너 아티팩트 및 배포 설명자 생성

워크로드에 대해 대상 컨테이너 아티팩트를 생성하기 위해 Migrate to Containers는 마이그레이션 계획의 VM에서 추출한 워크로드 및 데이터가 포함된 컨테이너 이미지를 만듭니다. 그런 후 컨테이너 이미지 사본을 구성된 컨테이너 이미지 저장소에 저장합니다. 또한 Migrate to Containers는 대상 환경에서 컨테이너 이미지의 인스턴스를 배포하는 데 사용하고 맞춤설정할 수 있는 배포 설명자를 생성합니다.

컨테이너 아티팩트 생성에 대한 자세한 내용은 마이그레이션 실행(Linux)마이그레이션 실행(Windows)을 참조하세요.

만들고 마이그레이션하는 컨테이너 아티팩트의 진행 상태를 모니터링할 수 있습니다. 마이그레이션 모니터링에 대한 자세한 내용은 마이그레이션 모니터링(Linux)마이그레이션 모니터링(Windows)을 참조하세요.

Windows 워크로드에 대해 컨테이너 아티팩트를 생성하는 경우 Migrate to Containers에서 해당 워크로드에 대해 Windows 컨테이너 이미지를 빌드하기 위해 생성된 아티팩트 및 배포 설명자를 사용합니다. 워크로드의 Windows 컨테이너 이미지 빌드에 대한 자세한 내용은 Windows 컨테이너 이미지 빌드를 참조하세요.

이 섹션에 설명된 작업을 마치면 이 문서로 돌아갑니다.

생성된 리소스 및 설명자 확인 및 검증

Migrate to Containers를 사용하여 컨테이너 아티팩트와 배포 설명자를 생성한 후 해당 아티팩트와 설명자를 검토하고 업데이트하여 요구사항을 충족하는지 확인합니다. 컨테이너 아티팩트 및 배포 설명자를 업데이트하는 데 필요한 시간은 마이그레이션하려는 VM 기반 워크로드 수 및 복잡성에 따라 달라집니다. 컨테이너 아티팩트 및 배포 설명자 검토에 대한 자세한 내용은 생성된 배포 파일 검토(Linux)Windows 컨테이너 이미지 빌드를 참조하세요. 예를 들어 다음 측면을 고려하세요.

리소스 및 설명자 이름 지정

구성 및 로그 리소스 및 설명자

정책 및 프로필 리소스 및 설명자

기타 리소스 및 설명자

이 섹션에 설명된 작업을 마치면 이 문서로 돌아갑니다.

컨테이너화된 워크로드 배포 및 검증

워크로드의 배포 설명자가 준비되었으면 다음 단계를 수행합니다.

  1. 대상 환경에 마이그레이션된 워크로드 배포. 마이그레이션된 Linux 및 Windows 워크로드 배포에 대한 안내는 다음 대상 클러스터에 Linux 워크로드 배포대상 클러스터에 Windows 워크로드 배포를 참조하세요.
  2. 마이그레이션된 워크로드를 모니터링합니다. 마이그레이션된 Linux 워크로드 및 Windows 워크로드를 배포한 후 수행 방법에 대한 정보를 수집할 수 있습니다. 자세한 내용은 마이그레이션된 워크로드 모니터링(Linux)마이그레이션된 워크로드 모니터링(Windows)을 참조하세요.

  3. 마이그레이션된 워크로드를 통합합니다. 대상 환경에 배포된 워크로드가 작동하면 이를 통합합니다. 컨테이너 아티팩트 생성과 워크로드의 배포 프로세스를 배포 프로세스 및 파이프라인과 통합합니다. 현재 자동 배포 프로세스가 마련되어 있지 않고 워크로드를 수동으로 배포하는 경우, 수동 배포에서 자동 배포로 마이그레이션하는 것이 좋습니다.

이 섹션에 설명된 작업을 마치면 이 문서로 돌아갑니다.

Migrate to Containers 제거

Migrate to Containers를 사용하여 워크로드 마이그레이션을 완료한 후에는 다음을 수행하는 것이 좋습니다.

  1. Migrate to Containers가 마이그레이션 중에 생성한 아티팩트에 대한 모든 참조가 있는지 확인합니다.
  2. Migrate to Containers를 제거합니다.

이 섹션에 설명된 작업을 마치면 이 문서로 돌아갑니다.

마이그레이션 후 환경 최적화

환경 최적화는 마이그레이션의 마지막 단계입니다. GKE 및 GKE Enterprise 환경을 최적화하려면 환경 최적화를 참조하세요.

다음 단계