Google Cloud로 컨테이너 마이그레이션: 시작하기

이 문서는 Google Cloud로 컨테이너 마이그레이션을 계획, 설계, 구현하는 방법을 설명합니다. 잘못 수행할 경우 워크로드를 다른 환경으로 이동하는 작업이 어려워질 수 있으므로 마이그레이션 계획과 실행에 신중을 기하세요.

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

이 문서는 컨테이너를 Google Cloud로 마이그레이션하는 방법을 설명하는 시리즈의 일부입니다.

이 문서는 온프레미스, 비공개 호스팅 환경 또는 다른 클라우드 제공업체에서 실행되는 컨테이너를 시작하든, 전체 워크로드를 Google Cloud로 마이그레이션하거나 온프레미스 또는 비공개 호스팅 환경에 워크로드 일부를 유지하든, 다양한 시나리오에 도움이 됩니다.

또한, 이 문서는 마이그레이션 기회를 평가하고 마이그레이션했을 때 어떤 모습이 되며 어떤 옵션을 이용할 수 있는지 알아보고 싶은 경우에도 유용합니다. 컨테이너가 Google Cloud에서 사용할 수 있는 워크로드를 실행하기 위한 다양한 환경이 존재합니다. 다양한 요소에 따라 선택하는 옵션이 달라질 수 있으며, 어떤 옵션도 다른 옵션보다 본질적으로 우월하지는 않습니다. 환경마다 나름의 장단점이 있습니다. 환경을 선택하려면 다음 절차를 따르세요.

  1. 워크로드를 실행할 컨테이너 환경을 평가하기 위한 기준 세트를 설정합니다.
  2. 평가 기준에 따라 각 환경을 평가합니다.
  3. 요구사항에 가장 적합한 환경을 선택합니다.

모든 워크로드에 동일한 환경을 선택할 필요는 없습니다. 워크로드의 유형 또는 클래스가 다른 경우 각 유형 또는 클래스에 서로 다른 환경을 선택할 수 있습니다.

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

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

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

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

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

  1. 평가. 이 단계에서는 원본 환경을 평가하고, Google Cloud로 마이그레이션하려는 워크로드를 평가하고, 각 워크로드를 지원할 수 있는 환경을 평가합니다.
  2. 계획. 이 단계에서는 워크로드의 기본 인프라를 만듭니다(예: 리소스 계층 구조 프로비저닝 및 네트워크 액세스 설정).
  3. 배포. 이 단계에서는 원본 환경의 컨테이너를 Google Cloud로 마이그레이션합니다.
  4. 최적화. 이 단계부터 클라우드 기술 및 기능을 활용하게 됩니다.

워크로드 실행을 위한 컨테이너 환경 평가 기준 설정

컨테이너 환경에서 워크로드를 실행하기 위한 옵션을 평가하기 위한 기준을 설정하려면 이러한 환경에서 필요한 가장 중요한 기능을 고려하는 것이 좋습니다. 가장 필요한 기능에 대한 정보를 수집하려면 워크로드를 평가하세요. 워크로드 평가에 대한 자세한 내용은 Google Cloud로의 마이그레이션: 워크로드 평가 및 검색을 참조하세요.

예시는 이러한 평가 기준과 나열된 순서입니다. 개발자와 워크로드에 중요한 기준 목록을 컴파일하려면 워크로드를 평가하고 중요도에 따라 정렬해야 합니다. 예를 들어 워크로드를 평가한 후 다음과 같은 평가 기준을 중요도 순으로 나열하는 것이 좋습니다.

  1. 성능 환경에 워크로드의 성능이 저하될 수 있는 오버헤드가 추가되는가?
  2. 확장성. 환경에 어떤 확장성 기능이 제공되는가? 반응 시간과 확장성 로직 측면에서 워크로드의 확장성 요구 사항을 충족하기에 충분한가?
  3. 제어 및 유연성 정도. 환경을 어느 정도로 제어하기를 원하는가? 필요에 맞게 환경을 맞춤설정할 수 있는가?
  4. 안정성 환경에서 어떤 보장이 제공되는가? 개발자의 워크로드에 충분한가? 효과적인 고가용성 및 재해 복구 전략을 구현할 수 있을 만큼 안정적인가?
  5. 관리 부담. 환경을 관리하는 데 얼마나 많은 노력이 필요한가? 필요한 능력을 갖추기 위해 팀을 교육해야 하는가 아니면 기존 지식을 사용할 수 있는가?
  6. 서비스 이용에 필요한 요구사항 워크로드가 준수해야 하는 요구사항, 기술 계약, 인터페이스가 있는가? 워크로드가 환경과 호환되도록 만드는 데 많은 노력이 필요한가?
  7. 데이터 지속성. 워크로드를 실행하는 컨테이너 환경에서 데이터 지속성을 지원하는가? 이러한 지속성이 성능, 안정성, 법적 규정을 포함한 워크로드 요구사항과 호환되는가?
  8. 가격 책정 모델 및 비용. 비용 효율적인 방식으로 환경을 사용할 수 있는가? 워크로드를 실행하기 위해 컨테이너 환경으로 전환하여 적절한 투자 수익을 얻을 수 있는가?
  9. 미래 대비. 환경은 워크로드를 발전시키는 데 사용할 수 있는 업그레이드 경로를 제공하는가?
  10. 다른 서비스와 통합. 환경이 다른 Google Cloud 서비스 및 다른 클라우드 제공업체의 서비스와 통합할 수 있는가?
  11. 록인(lock-in) 환경에서 특정 기술, 패러다임 또는 인터페이스를 사용할 수 있는가? 환경이 워크로드의 이동성을 방해하는가?
  12. 보안. 환경이 보안 및 개인정보 보호 요구사항을 충족하는가?

워크로드 실행을 위한 컨테이너 환경 평가

Google Cloud에는 컨테이너를 실행할 수 있는 다양한 옵션이 있습니다. 워크로드에 가장 적합한 옵션을 선택하려면 먼저 이전에 설정한 평가 기준과 비교하여 평가해야 합니다. 각 환경별로 임의의 정렬된 척도로 각 평가 기준에 점수를 할당합니다. 예를 들어 각 평가 기준에 대해 1~10 사이의 점수를 각 환경에 할당할 수 있습니다.

Google Cloud에서 컨테이너를 실행할 때 다음 옵션이 권장되며, 옵션은 기본 인프라에 대한 제어 수준에 따라 오름차 순으로 제시됩니다.

  1. Cloud RunCloud Run for Anthos
  2. Google Kubernetes Engine(GKE)Anthos 클러스터
  3. Compute Engine

제품 문서를 읽어 특정 기준에 대한 점수를 할당할 수 있습니다. 예를 들어 성능, 확장성, 제어 및 유연성 정도, 다른 서비스와의 통합에 대해 Cloud Run을 이미 평가할 수 있습니다. 그러나 다른 기준에 점수를 할당하려면 보다 깊이 있는 벤치마크와 시뮬레이션을 설계하고 실행해야 할 수 있습니다. 예를 들어 여러 컨테이너 런타임의 성능을 벤치마킹하여 워크로드가 상당한 오버헤드를 추가하는지 평가해야 할 수 있습니다.

Cloud Run 및 Cloud Run for Anthos

Cloud Run은 Knative를 기반으로 하는 컨테이너화된 스테이트리스(Stateless) 워크로드를 실행하는 관리형 플랫폼입니다. Cloud Run에서 관리하는 컨테이너화된 워크로드는 다음에서 실행될 수 있습니다.

  • Cloud Run을 선택하면 워크로드는 Google 관리 인프라에서 실행됩니다.
  • Cloud Run for Anthos를 선택하면 워크로드는 Google Cloud, 온프레미스 또는 다른 클라우드 제공업체에 있을 수 있는 GKE에서 실행됩니다.

다음 목록을 사용하여 앞에서 설정한 기준에 따라 Cloud Run 및 Cloud Run for Anthos를 평가하세요.

  1. 성능 Cloud Run 및 Cloud Run for Anthos는 컨테이너화되지 않은 워크로드와 성능이 비슷한 Docker 컨테이너를 사용하므로 컨테이너가 상당한 성능 오버헤드를 추가하지 않습니다.
  2. 확장성. Cloud Run은 워크로드의 인스턴스를 자동으로 확장하며 애플리케이션을 0개 인스턴스로 조정할 수 있습니다. 이 기능은 워크로드가 항상 인스턴스를 실행할 필요가 없는 경우에 유용합니다. 인스턴스 시작 시간을 최소화하려면 워크로드 초기화를 최적화합니다.
  3. 제어 및 유연성 정도. Cloud Run 및 Cloud Run for Anthos는 워크로드가 실행되는 컨테이너화된 환경을 완전히 제어해야 하지만 환경을 맞춤설정해야 할 필요는 없는 워크로드에 적합합니다.
  4. 안정성 Cloud Run 및 Cloud Run for Anthos는Cloud Monitoring, Cloud Logging, Cloud 감사 로그, Error Reporting과 통합하여 성능 모니터링에 대한 범위를 넓히고 컨테이너, 요청, 오류, 감사 로그에 액세스할 수 있도록 합니다.
  5. 관리 부담. Cloud Run 및 Cloud Run for Anthos는 환경을 관리하여 기본 인프라를 프로비저닝, 구성, 유지보수하는 데 시간을 뺏기지 않고 워크로드에만 집중할 수 있습니다.
  6. 서비스 이용에 필요한 요구사항 워크로드는 컨테이너 런타임 계약을 준수해야 하므로 Cloud Run과 호환되도록 추가 작업을 수행할 수 없는 경우 다른 옵션 중 하나를 선택하는 것이 좋습니다. Cloud Run 제한사항에 대한 자세한 내용은 Cloud Run 알려진 문제를 참조하세요.
  7. 데이터 지속성. Cloud Run 및 Cloud Run for Anthos는 스테이트리스(Stateless) 컨테이너를 실행하도록 설계되었습니다. 워크로드에 데이터 지속성 요구사항이 있는 경우 다른 데이터 지속성 시스템을 프로비저닝하고 구성해야 합니다. 스테이트풀(Stateful) 워크로드의 컨테이너 런타임 환경이 필요한 경우 다른 옵션을 선택하는 것이 좋습니다.
  8. 가격 책정 모델 및 비용. Cloud Run은 워크로드에서 사용되는 컴퓨팅 리소스의 비용을 청구합니다. Cloud Run for Anthos는 Anthos 구독에 포함됩니다.
  9. 미래 대비. Cloud Run을 사용하면 롤백, 점진적 출시, 트래픽 마이그레이션을 수행할 수 있습니다. 배포 파이프라인에 이러한 기능을 사용할 수 있습니다.
  10. 다른 서비스와 통합. Cloud Run은 Compute Engine VM 및 내부 IP 주소가 있는 기타 리소스에 액세스할 수 있는 Virtual Private Cloud(VPC) 네트워크에 연결할 수 있습니다.
  11. 록인(lock-in) Cloud Run은 Knative를 기반으로 빌드되었습니다. 워크로드가 Knative와 호환되도록 작업한 경우 컨테이너화된 워크로드를 추가 수정 없이 Cloud Run, GKE, VMware용 Anthos 클러스터 또는 기타 Knative 호환 런타임 환경에서 실행할 수 있습니다.
  12. 보안. Cloud Run에서 실행되는 워크로드는 gVisor를 사용하여 샌드박스 처리됩니다. Cloud Run for Anthos는 컨테이너 샌드박스를 사용하지 않지만 기본 Kubernetes 컨테이너 격리 기능을 사용합니다. Identity and Access Management(IAM)로 액세스 관리서비스 ID를 구성하여 Cloud Run 리소스를 보호할 수 있습니다.

자세한 내용은 Cloud Run 플랫폼 선택을 참조하세요.

GKE 및 Anthos 클러스터

GKE 및 Anthos 클러스터는 워크로드를 실행할 컨테이너 환경을 제공하는 Google 관리 서비스입니다. GKE 및 Anthos 클러스터 모두 Kubernetes 클러스터에서 컨테이너화된 워크로드를 실행합니다. GKE를 사용하는 경우 클러스터는 Google Cloud에서 실행되며 Anthos 클러스터를 사용하는 경우 클러스터는 Google Cloud, 온프레미스 또는 다른 퍼블릭 클라우드 환경에서 실행될 수 있습니다.

다음 목록을 사용하여 앞에서 설정한 기준에 따라 GKE 및 Anthos 클러스터를 평가하세요.

  1. 성능 GKE 및 Anthos 클러스터는 컨테이너화되지 않은 워크로드와 성능이 비슷한 Docker 컨테이너를 사용하므로 컨테이너가 상당한 성능 오버헤드를 추가하지 않습니다.
  2. 확장성. GKE 및 Anthos 클러스터에는 사용자의 요구에 맞게 조정할 수 있는 세분화된 확장 로직이 포함됩니다. 워크로드를 확장할 수 있으며 GKE 및 Anthos 클러스터 클러스터를 둘 다 수직수평으로 확장할 수 있습니다. 복잡한 확장 로직이 필요 없는 경우 다른 옵션을 선택하는 것이 좋습니다. 그렇지 않으면 효과적인 확장성 메커니즘을 구성하는 데 많은 시간을 들여야 하기 때문입니다.
  3. 제어 및 유연성 정도. 필요에 따라 GKE 및 Anthos 클러스터 클러스터를 프로비저닝하고 구성할 수 있습니다. 스토리지, 네트워킹, 보안을 비롯한 클러스터 노드의 모든 측면을 맞춤설정할 수 있습니다. Google에서 제어 영역을 관리하므로 제어 영역의 구성을 맞춤설정해야 하는 경우에는 다른 옵션을 선택하는 것이 좋습니다.
  4. 안정성 GKE 및 Anthos 클러스터는 Cloud Monitoring 및 Cloud Logging과 통합되어 완전한 성능 모니터링 및 컨테이너, 요청, 오류, 감사 로그에 대한 액세스를 제공합니다. GKE 리전별 클러스터Anthos 클러스터 고가용성 옵션을 사용하여 환경의 안정성을 높일 수 있습니다.
  5. 관리 부담. GKE를 사용하면 클러스터의 제어 영역을 관리할 필요가 없으며 Anthos 클러스터를 사용하면 동일한 도구 모음 및 프로세스로 모든 Kubernetes 클러스터를 관리할 수 있습니다. 이 기능은 환경 관리에 드는 노력을 크게 줄여주지만 기본 인프라의 일부를 관리해야 합니다. 예를 들어 GKE를 사용하면 클러스터 노드를 관리할 수 있습니다. 대부분의 관리 작업은 자동화될 수 있지만 환경을 유지보수하는 데 필요한 작업을 계획할 때는 여전히 수동 작업을 고려해야 합니다. 워크로드를 실행하는 완전 관리형 컨테이너 환경이 필요한 경우 다른 옵션을 선택하는 것이 좋습니다.
  6. 서비스 이용에 필요한 요구사항 GKE 또는 Anthos 클러스터에 워크로드를 배포하려면 이를 컨테이너화해야 합니다.
  7. 데이터 지속성. GKE와 Anthos는 스테이트풀(Stateful) 애플리케이션영구 디스크 스토리지를 실행할 수 있습니다.
  8. 가격 책정 모델 및 비용. GKE는 클러스터 관리 수수료와 클러스터 노드가 사용하는 리소스에 대한 요금을 청구합니다. Anthos 클러스터는 Anthos 구독에 포함되어 있습니다.
  9. 미래 대비. GKE와 Anthos 클러스터 둘 다 복잡한 배포 프로세스를 처리할 수 있는 기능이 있습니다.
  10. 다른 서비스와 통합. 필요한 연결, 인증, 승인 시스템을 설정하면 GKE 및 Anthos 클러스터에 배포된 워크로드에 다른 Google Cloud 서비스에 대한 액세스 권한이 부여될 수 있습니다.
  11. 록인(lock-in) GKE 또는 Anthos 클러스터에서 실행할 워크로드를 컨테이너화한 후 약간의 조정을 거쳐 다른 환경으로 포팅할 수 있습니다. Kubernetes는 이식 가능한 플랫폼이며 공급업체 환경에 종속되지 않습니다.
  12. 보안. GKE는 노드, 제어 영역, 워크로드를 보호하는 여러 가지 방법을 제공합니다.

자세한 내용은 GKE 보안 개요를 참조하세요.

GKE 및 Anthos 클러스터로의 마이그레이션에 대한 자세한 내용은 Google Cloud로 컨테이너 마이그레이션: Kubernetes를 GKE로 마이그레이션Google Cloud로 컨테이너 마이그레이션: OpenShift에서 Anthos로 마이그레이션을 확인하세요.

Compute Engine

Compute Engine을 사용하면 Google 인프라에서 VM을 만들고 실행할 수 있습니다.

Compute Engine VM에서 컨테이너를 실행할 수 있지만 이 문서에서 설명하는 워크로드를 실행하려면 다른 컨테이너 환경 중 하나를 선택하는 것이 좋습니다. Compute Engine에서 실행되는 자체 관리형 환경을 운영하기 위해 기울여야 하는 수고가 이를 통해 얻을 수 있는 이익을 크게 상회합니다.

하지만 Compute Engine VM에서 컨테이너를 실행하기로 결정한다면 다음 목록을 사용하여 앞에서 설정한 기준에 따라 Compute Engine을 평가하세요.

  1. 성능 Compute Engine VM에는 컨테이너 런타임이 미리 설치되어 있지 않으므로 요구사항에 가장 적합한 런타임을 선택하세요.
  2. 확장성. Compute Engine은 관리형 인스턴스 그룹을 사용하여 VM 인스턴스를 자동으로 확장합니다. 관리형 인스턴스 그룹의 자동 확장 메커니즘을 구성할 때는 Compute Engine이 관리형 인스턴스 그룹을 확장하거나 축소하는 데 사용하는 자동 확장 신호를 정의합니다.
  3. 제어 및 유연성 정도. Compute Engine 리소스 할당량을 준수하는 한에서는 각 Compute Engine VM의 프로비저닝 및 구성의 모든 측면을 맞춤설정할 수 있습니다.
  4. 안정성 Cloud Monitoring, Cloud Logging, Cloud 감사 로그로 Compute Engine VM을 모니터링하여 성능 모니터링 및 로그를 완전히 포괄할 수 있습니다. Compute Engine은 관리형 인스턴스 그룹, 인스턴스 상태 확인, 자동 복구도 사용합니다.
  5. 관리 부담. Compute VM은 자체 관리형이므로 환경을 효과적으로 관리하기 위한 상당한 운영 작업의 계획을 세우세요.
  6. 서비스 이용에 필요한 요구사항 워크로드가 지원되는 운영체제 중 하나에서 실행되는 한 워크로드를 Compute Engine VM에서 실행할 수 있습니다. Compute Engine 제한사항에 대한 자세한 내용은 Compute Engine 알려진 문제를 참조하세요.
  7. 데이터 지속성. Compute Engine에는 영역 영구 디스크, 리전 영구 디스크, 로컬 솔리드 스테이트 드라이브(SSD) 등 데이터 지속성을 위한 다양한 옵션이 있습니다.
  8. 가격 책정 모델 및 비용. Compute Engine은 워크로드에 필요한 리소스에 대한 요금을 청구합니다.
  9. 미래 대비. 배포 프로세스를 위해 Compute Engine VM에 통합, 배포, 프로비저닝, 또는 구성 관리 도구를 설치할 수 있습니다.
  10. 다른 서비스와 통합. 필요한 연결, 인증, 승인 시스템을 설정하면 Compute Engine에 배포된 워크로드에 다른 Google Cloud 서비스에 대한 액세스 권한이 부여될 수 있습니다.
  11. 록인(lock-in) Compute Engine을 사용해도 특정한 독점 제품이나 서비스만 사용하도록 록인되지 않습니다. 프로비저닝 및 구성 프로세스를 자동화하고 포팅할 수 있도록 자체 운영체제 이미지를 빌드할 수 있습니다.
  12. 보안. Compute Engine은 환경의 보안을 강화하는 데 도움이 됩니다.

자세한 내용은 Google Cloud 보안을 참조하세요.

대상 환경에 올바른 옵션 선택

이전 섹션에서는 각 제품의 모든 기준에 값을 할당했습니다. 워크로드를 실행할 각 컨테이너 환경의 총 점수를 계산하려면 기준에 따라 해당 환경에 대한 모든 평점을 추가합니다. 예를 들어 환경의 성능 기준에 10점을 부여하고 확장성 기준에 6점을 부여하면 해당 환경의 총 점수는 16입니다.

또한 평가에 대한 각 기준의 중요도를 나타내기 위해 각 기준에 대한 점수에 다른 가중치를 할당할 수 있습니다. 예를 들어 평가에 확장성보다 성능이 더 중요한 경우 이를 반영하는 배율(성능을 위한 1.0 배율, 확장성을 위한 0.7 배율)을 정의할 수 있습니다. 그런 다음 이러한 배율을 사용하여 옵션의 총 점수를 계산합니다.

평가한 각 환경의 총 점수를 계산한 후 총 점수 기준의 내림차순으로 해당 환경을 정리합니다. 그런 다음 점수가 가장 높은 환경을 선택합니다.

이 데이터를 나타내는 방법은 여러 가지가 있습니다. 예를 들어 방사형 차트와 같이 다변수 데이터를 나타내기 적합한 차트로 결과를 시각화할 수 있습니다.

다음 단계