AWS에서 Google Cloud로 마이그레이션: Amazon EKS에서 GKE로 마이그레이션

Last reviewed 2024-08-02 UTC

Google Cloud는 Amazon Elastic Kubernetes Service(Amazon EKS)에서 Google Kubernetes Engine(GKE)으로 마이그레이션하기 위한 도구, 제품, 안내, 전문 서비스를 제공합니다. 이 문서는 Amazon EKS에서 GKE로의 마이그레이션 계획을 설계, 구현, 검증하는 데 도움이 됩니다. 이 문서에서는 마이그레이션 기회를 평가하고 마이그레이션 과정을 살펴보려는 경우에 필요한 안내도 제공합니다. Amazon EKS에는 Amazon Elastic Compute Cloud(Amazon EC2)에서 실행하는 것 외에도 AWS 출력 기반의 Amazon EKS, Amazon EKS Anywhere와 같은 몇 가지 다른 배포 옵션이 있습니다. 이 문서에서는 EC2 기반의 Amazon EKS에 대해 자세히 살펴봅니다.

이 문서는 AWS에서 Google Cloud로 마이그레이션하는 방법을 다루는 시리즈의 일부로서 이 시리즈에는 다음 문서가 포함됩니다.

GKE는 Google 인프라를 사용하여 컨테이너화된 애플리케이션을 대규모로 배포하고 운영하는 데 사용할 수 있는 Google 관리 Kubernetes 서비스이며 다음과 같은 Kubernetes 환경을 관리하는 데 도움이 되는 기능을 제공합니다.

  • GKE Standard 및 GKE Enterprise 버전 2개. GKE Standard를 사용하면 핵심 기능의 표준 등급에 액세스할 수 있습니다. GKE Enterprise를 사용하면 GKE의 모든 기능에 액세스할 수 있습니다. 자세한 내용은 GKE 버전을 참고하세요.
  • Standard 및 Autopilot의 2가지 작업 모드. 표준을 사용하면 GKE 클러스터의 기본 인프라와 각 노드의 구성을 관리할 수 있습니다. GKE는 Autopilot을 사용하여 노드 구성, 자동 확장, 자동 업그레이드, 기준 보안, 네트워크 구성과 같은 기본 인프라를 관리합니다. GKE 작업 모드에 관한 자세한 내용은 GKE 작업 모드 선택을 참고하세요.
  • 여러 영역에서 Autopilot을 사용할 때를 위한 포드에 대한 업계 고유 서비스수준계약.
  • 노드 자동 프로비저닝을 통해 노드 풀 만들기 및 삭제 자동화.
  • Google 관리형 멀티 클러스터 네트워킹을 통해 워크로드에 가용성이 높은 분산 아키텍처를 설계하고 구현할 수 있습니다.

GKE에 관한 자세한 내용은 GKE 개요를 참고하세요.

Google Cloud로의 마이그레이션의 경우 Google Cloud로 마이그레이션: 시작하기에 설명된 마이그레이션 프레임워크를 따르는 것이 좋습니다.

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

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

일련의 반복 작업을 통해 원본 환경에서 Google Cloud로 마이그레이션할 수 있습니다. 예를 들어 일부 워크로드를 먼저 마이그레이션하고 나중에 다른 워크로드를 마이그레이션할 수 있습니다. 개별 마이그레이션을 반복할 때마다 일반 마이그레이션 프레임워크 단계를 수행합니다.

  1. 워크로드와 데이터를 평가하고 탐색합니다.
  2. Google Cloud에 대한 기초를 계획하고 빌드합니다.
  3. 워크로드와 데이터를 Google Cloud로 마이그레이션합니다.
  4. Google Cloud 환경을 최적화합니다.

이 프레임워크 단계에 대한 자세한 내용은 Google Cloud로 마이그레이션: 시작하기를 참조하세요.

효과적인 마이그레이션 계획을 설계하려면 계획의 각 단계를 검증하고 롤백 전략이 있는지 확인하는 것이 좋습니다. 마이그레이션 계획을 검증하려면 Google Cloud로 마이그레이션: 마이그레이션 계획 검증 권장사항을 참조하세요.

원본 환경 평가

평가 단계에서는 원본 환경을 Google Cloud로 마이그레이션하기 위한 요구사항과 종속 항목을 결정합니다.

평가 단계는 마이그레이션의 성공에 매우 중요합니다. 마이그레이션하려는 워크로드, 요구사항, 종속 항목, 현재 환경에 대해 자세히 알고 있어야 합니다. Google Cloud 마이그레이션을 성공적으로 계획하고 실행하려면 시작점을 이해해야 합니다.

평가 단계는 다음 작업으로 구성됩니다.

  1. 워크로드의 포괄적인 인벤토리를 빌드합니다.
  2. 워크로드의 속성과 종속 항목에 따라 워크로드를 분류합니다.
  3. 팀에 Google Cloud 교육을 실시합니다.
  4. Google Cloud에서 실험 및 개념 증명을 빌드합니다.
  5. 대상 환경의 총 소유 비용(TCO)을 계산합니다.
  6. 워크로드에 적합한 마이그레이션 전략을 선택합니다.
  7. 마이그레이션 도구를 선택합니다.
  8. 마이그레이션 계획 및 타임라인을 정의합니다.
  9. 마이그레이션 계획을 검증합니다.

평가 단계와 이러한 태스크에 대한 자세한 내용은 Google Cloud로 마이그레이션: 워크로드 평가 및 탐색을 참조하세요. 다음 섹션은 해당 문서의 정보를 기반으로 합니다.

인벤토리 빌드

마이그레이션 범위를 지정하려면 다음과 같이 인벤토리 두 개를 만듭니다.

  1. 클러스터의 인벤토리.
  2. 이러한 클러스터에 배포된 워크로드의 인벤토리.

이러한 인벤토리를 빌드한 후에는 다음을 수행할 수 있습니다.

  1. 소스 환경의 배포 및 운영 프로세스를 평가합니다.
  2. 지원 서비스 및 외부 종속 항목을 평가합니다.

클러스터의 인벤토리 빌드

클러스터의 인벤토리를 빌드하려면 각 클러스터에서 다음 사항을 고려합니다.

  • 노드 수 및 유형 현재 환경에 있는 노드 수와 각 노드의 특성을 알고 있으면 GKE로 이동할 때 클러스터 크기를 조정합니다. 새 환경의 노드가 개발자 환경에서 사용하는 노드와 다른 하드웨어 아키텍처 또는 세대에서 실행될 수 있습니다. 각 아키텍처와 세대의 성능이 다르므로 새 환경에 필요한 노드 수가 환경과 다를 수 있습니다. 고성능 스토리지 기기, GPU, TPU와 같이 노드에서 사용하는 모든 유형의 하드웨어를 평가합니다. 노드에서 사용 중인 운영체제 이미지를 평가합니다.
  • 내부 또는 외부 클러스터. 각 클러스터가 노출되는 환경 내부 또는 외부의 작업 수행자를 평가합니다. 사용 사례를 지원하기 위해 이 평가에는 클러스터에서 실행되는 워크로드와 클러스터와 상호작용하는 인터페이스가 포함되어 있습니다.
  • 멀티테넌시. 환경에서 멀티 테넌트 클러스터를 관리할 경우 새 Google Cloud 환경에서 작동하는지 평가합니다. 멀티테넌시 전략이 Google Cloud에서의 기반 구축 방식에 영향을 미치므로 지금 멀티 테넌트 클러스터의 개선 방법을 평가하는 것이 좋습니다.
  • Kubernetes 버전. 클러스터의 Kubernetes 버전에 대한 정보를 수집하여 해당 버전과 GKE에서 사용 가능한 버전 간의 불일치 여부를 평가합니다. 이전 버전 또는 최근 출시된 Kubernetes 버전을 실행할 경우 GKE에서 사용할 수 없는 기능이 사용 중일 수 있습니다. 기능이 지원 중단되었거나 이 기능을 제공하는 Kubernetes 버전을 아직 GKE에서 사용하지 못할 수 있습니다.
  • Kubernetes 업그레이드 주기. 안정적인 환경을 유지하려면 Kubernetes 업그레이드를 처리하는 방법과 업그레이드 주기가 GKE 업그레이드와 어떻게 관련되는지 이해해야 합니다.
  • 노드 풀. 형태에 관계없이 노드 그룹화를 사용하는 경우 그룹화 기준이 GKE에 적합하지 않을 수 있으므로 그룹화가 GKE의 노드 풀 개념과 어떻게 연결되는지 고려해야 합니다.
  • 노드 초기화. 워크로드를 실행할 수 있는 것으로 표시하기 전에 각 노드의 초기화 방법을 평가하여 이러한 초기화 절차를 GKE로 포팅할 수 있습니다.
  • 네트워크 구성. 다음과 같이 클러스터의 네트워크 구성을 평가합니다. IP 주소 할당, 네트워킹 플러그인 구성 방법, DNS 서버 및 DNS 서비스 제공업체 구성 방법, 이러한 클러스터에 대해 NAT 또는 SNAT 형식을 구성했는지, 멀티 클러스터 환경의 일부인지 여부.
  • 규정 준수: 클러스터가 충족해야 하는 규정 준수 및 규제 요구사항과 이러한 요구사항을 충족하는지 여부를 평가합니다.
  • 할당량 및 한도 클러스터의 할당량 및 한도를 구성한 방식을 평가합니다. 예를 들어 각 노드에서 실행할 수 있는 포드 수는 얼마인가요? 클러스터에는 노드가 몇 개나 있을 수 있나요?
  • 라벨 및 태그. 클러스터, 노드 풀, 노드에 적용한 메타데이터와 이를 사용하는 방법을 평가합니다. 예를 들어 라벨 기반의 자세한 비용 기여 분석을 통해 보고서를 생성할 수 있습니다.

인벤토리에서 평가하는 다음 항목은 인프라와 Kubernetes 클러스터의 보안에 중점을 둡니다.

  • 네임스페이스. 클러스터에서 Kubernetes 네임스페이스를 사용하여 리소스를 논리적으로 구분하는 경우 각 네임스페이스에 있는 리소스를 평가하고 이렇게 구분한 이유를 파악합니다. 예를 들어 멀티테넌시 전략의 일환으로 네임스페이스를 사용할 수 있습니다. Kubernetes 시스템 구성요소용으로 예약된 네임스페이스에 워크로드를 배포할 수 있으며 GKE에 제어 권한이 많지 않을 수 있습니다.
  • 역할 기반 액세스 제어(RBAC). 클러스터에서 RBAC 승인을 사용할 경우 클러스터에서 구성한 모든 ClusterRole 및 ClusterRoleBinding에 대한 설명을 나열합니다.
  • 네트워크 정책. 클러스터에서 구성한 모든 네트워크 정책을 나열하고 GKE에서 네트워크 정책 작동 방식을 파악합니다.
  • 포드 보안 컨텍스트. 클러스터에서 구성한 포드 보안 컨텍스트에 대한 정보를 캡처하고 GKE에서 이들이 작동하는 방식을 알아봅니다.
  • 서비스 계정. 클러스터의 프로세스가 Kubernetes API 서버와 상호작용하는 경우 사용 중인 서비스 계정에 대한 정보를 캡처합니다.

Kubernetes 클러스터의 인벤토리를 빌드할 때 마이그레이션 중에 일부 클러스터를 사용 중단해야 할 수 있습니다. 마이그레이션 계획에 이러한 리소스 중단이 포함되는지 확인합니다.

Kubernetes 워크로드의 인벤토리 빌드

Kubernetes 클러스터 인벤토리를 완료하고 환경의 보안을 평가한 후에는 클러스터에 배포된 워크로드의 인벤토리를 빌드합니다. 워크로드를 평가할 때는 다음 측면에 대한 정보를 수집합니다.

  • 포드 및 컨트롤러. 새 환경에서 클러스터 크기를 조정하려면 배포한 각 워크로드의 인스턴스 수를 평가하고 리소스 할당량 및 Compute 리소스 소비 한도를 사용할지 여부를 평가합니다. 각 클러스터의 컨트롤 플레인 노드에서 실행 중인 워크로드와 각 워크로드에서 사용하는 컨트롤러에 대한 정보를 수집합니다. 예를 들어 사용 중인 배포 수와 DaemonSets 수를 살펴볼 수 있습니다.
  • 작업 및 CronJobs. 클러스터 및 워크로드는 초기화 또는 작업 절차의 일부로 작업 또는 CronJob을 실행해야 할 수 있습니다. 배포한 작업 및 CronJob의 인스턴스 수와 각 인스턴스의 책임 및 완료 기준을 평가합니다.
  • Kubernetes 자동 확장 처리 새 환경에서 자동 확장 정책을 마이그레이션하려면 GKE에서 수평형 포드 자동 확장 처리 및 수직형 포드 자동 확장 처리의 작동 방식을 알아봅니다.
  • 스테이트리스(Stateless) 워크로드와 스테이트풀(Stateful) 워크로드. 스테이트리스(Stateless) 워크로드는 클러스터 또는 영구 스토리지에 데이터 또는 상태를 저장하지 않습니다. 스테이트풀(Stateful) 애플리케이션은 나중에 사용할 수 있도록 데이터를 저장합니다. 스테이트풀(Stateful) 워크로드 마이그레이션은 일반적으로 스테이트리스(Stateless) 워크로드 마이그레이션보다 어려우므로 각 워크로드에서 구성요소가 스테이트리스(Stateless) 및 스테이트풀(Stateful)인지 평가합니다.
  • Kubernetes 특징. 클러스터 인벤토리에서 각 클러스터가 실행하는 Kubernetes 버전을 확인할 수 있습니다. 각 Kubernetes 버전의 출시 노트를 검토하여 제공되는 기능과 지원 중단되는 기능을 확인합니다. 그런 다음 필요한 Kubernetes 기능과 비교하여 워크로드를 평가합니다. 이 작업을 수행하는 이유는 지원 중단된 기능 또는 아직 GKE에서 사용할 수 없는 기능을 사용하고 있는지 확인하기 위함입니다. 사용할 수 없는 기능이 있으면 지원 중단된 기능에서 마이그레이션하고 새 기능을 GKE에서 사용할 수 있을 때 채택합니다.
  • 스토리지. 스테이트풀(Stateful) 워크로드의 경우 PersistenceVolumeClaim을 사용하는지 평가합니다. 크기 및 액세스 모드와 같은 스토리지 요구사항과 이러한 PersistenceVolumeClaim과 PersistenceVolume 간의 연결 관계를 나열합니다. 향후 성장을 고려하여 PersistenceVolumeClaim을 확장해야 하는지 평가합니다.
  • 구성 및 보안 비밀 삽입. 환경 구성이 변경될 때마다 배포 가능한 아티팩트를 다시 빌드하지 않으려면 ConfigMaps과 Secret을 사용하여 구성과 보안 비밀을 포드에 삽입합니다. 각 워크로드에서 사용하는 ConfigMap 및 Secret과 이들 객체를 채우는 방법을 평가합니다.
  • 종속 항목. 워크로드는 격리된 상태로 작동하지 않을 수 있습니다. 클러스터 내부 또는 외부 시스템의 종속 항목이 있을 수 있습니다. 각 워크로드에서 종속 항목을 캡처하고, 종속 항목을 사용할 수 없는 경우가 허용되는지 파악합니다. 예를 들어 일반적인 종속 항목에는 분산 파일 시스템, 데이터베이스, 보안 비밀 배포 플랫폼, ID 및 액세스 관리 시스템, 서비스 검색 메커니즘, 기타 외부 시스템이 있습니다.
  • Kubernetes 서비스. 내부 및 외부 클라이언트에 워크로드를 노출하려면 서비스를 사용합니다. 각 서비스의 유형을 알고 있어야 합니다. 외부에 노출된 서비스의 경우 서비스가 나머지 인프라와 상호작용하는 방식을 평가합니다. 예를 들어 인프라에서 LoadBalancer 서비스, 게이트웨이 객체, 인그레스 객체를 어떻게 지원하나요? 클러스터에 배포한 인그레스 컨트롤러가 무엇인가요?
  • 서비스 메시. 환경에서 서비스 메시를 사용할 경우 구성 방법을 평가합니다. 또한 걸쳐 있는 클러스터 수, 메시의 일부인 서비스, 메시의 토폴로지를 수정하는 방법도 알아야 합니다.
  • taint 및 톨러레이션(toleration)과 어피니티 및 안티-어피니티. 각 포드 및 노드에 대해 Kubernetes 클러스터에서 포드 예약을 맞춤설정하기 위해 노드 taint, 포드 톨러레이션(toleration) 또는 어피니티를 구성했는지 평가합니다. 이러한 속성은 가능한 비동질적 노드 또는 포드 구성에 대한 유용한 정보를 제공할 수 있으며 포드, 노드 또는 둘 다 특별한 집중 및 주의를 기울여 평가해야 할 수도 있음을 의미합니다. 예를 들어 특정 포드 집합이 Kubernetes 클러스터의 특정 노드에서만 예약되도록 구성한 경우 포드가 해당 노드에서만 사용할 수 있는 특수 리소스를 필요로 할 수 있습니다.
  • 인증: 워크로드가 클러스터의 리소스 및 외부 리소스에 대해 인증하는 방식을 평가합니다.

지원 서비스 및 외부 종속 항목 평가

클러스터와 워크로드의 평가가 끝났으면 인프라의 나머지 지원 서비스와 측면을 평가합니다. 예를 들면 다음과 같습니다.

  • StorageClass 및 PersistentVolume. 동적 프로비저닝에 StorageClass를, 정적 프로비저닝된 PersistentVolume을 나열하여 인프라에서 PersistentVolumeClaim을 지원하는 방식을 평가합니다. 각 PersistentVolume에서 용량, 볼륨 모드, 액세스 모드, 클래스, 회수 정책, 마운트 옵션, 노드 어피니티를 고려합니다.
  • VolumeSnapshots 및 VolumeSnapshotContents. 각 PersistentVolume에서 VolumeSnapshot을 구성했는지 그리고 기존 VolumeSnapshotContent를 마이그레이션해야 하는지 평가합니다.
  • 컨테이너 스토리지 인터페이스(CSI) 드라이버. 클러스터에 배포된 경우 이 드라이버가 GKE와 호환되는지, GKE와 호환되는 CSI 드라이버와 함께 작동하도록 볼륨 구성을 조정해야 하는지 여부를 평가합니다.
  • 데이터 스토리지. 외부 시스템을 활용하여 PersistentVolume을 프로비저닝하는 경우 GKE 환경의 워크로드에 이러한 시스템을 사용할 수 있는 방법을 제공합니다. 외부 시스템과 GKE 환경 간의 지연 시간은 이들 간의 거리에 비례하므로 데이터 지역성은 스테이트풀(Stateful) 워크로드 성능에 영향을 미칩니다. 각 외부 데이터 스토리지 시스템에서 블록 볼륨, 파일 스토리지 또는 객체 스토리지와 같은 유형과 충족해야 하는 성능과 가용성 요구사항을 고려합니다.
  • 커스텀 리소스 및 Kubernetes 부가기능 GKE에서 작동하지 않거나 수정해야 할 수 있으므로 클러스터에 배포했을 수 있는 커스텀 Kubernetes 리소스 및 Kubernetes 부가기능에 대한 정보를 수집합니다. 예를 들어 커스텀 리소스가 외부 시스템과 상호작용하는 경우 Google Cloud 환경에 적용할 수 있는지 평가합니다.
  • 백업. 소스 환경에서 클러스터 구성 및 스테이트풀 워크로드 데이터를 백업하는 방법을 평가합니다.

배포 및 운영 프로세스 평가

배포 및 운영 프로세스의 작동 방식을 명확하게 이해하는 것이 중요합니다. 이러한 프로세스는 프로덕션 환경과 그 환경에서 실행되는 워크로드를 준비하고 유지관리하는 관행의 중요한 부분입니다.

배포 및 운영 프로세스에서 워크로드가 작동하는 데 필요한 아티팩트를 빌드할 수 있습니다. 따라서 각 아티팩트 유형에 대한 정보를 수집해야 합니다. 예를 들어 아티팩트는 운영체제 패키지, 애플리케이션 배포 패키지, 운영체제 이미지, 컨테이너 이미지 등일 수 있습니다.

아티팩트 유형 외에도 다음 태스크를 완료하는 방법을 고려하세요.

  • 워크로드 개발. 개발팀이 워크로드를 빌드하기 위해 마련한 프로세스를 평가합니다. 예를 들어 개발팀이 워크로드를 어떻게 설계, 코딩, 테스트하는지 평가합니다.
  • 원본 환경에 배포하는 아티팩트 생성. 원본 환경에 워크로드를 배포하기 위해 컨테이너 이미지 또는 운영체제 이미지와 같은 배포 가능한 아티팩트를 생성하거나 소프트웨어를 설치 및 구성하여 제3자 운영체제 이미지와 같은 기존 아티팩트를 맞춤설정할 수 있습니다. 이러한 아티팩트를 생성하는 방법에 대한 정보를 수집하면 생성된 아티팩트가 Google Cloud 배포에 적합한지 확인하는 데 도움이 됩니다.

  • 아티팩트 저장. AWS의 Artifact Registry에 저장하는 아티팩트를 생성하는 경우 Google Cloud 환경에서 아티팩트를 사용할 수 있도록 해야 합니다. 다음과 같은 전략을 사용하면 수행할 수 있습니다.

    • 환경 간 통신 채널 설정: 원본 환경의 아티팩트를 대상 Google Cloud 환경에서 연결할 수 있도록 합니다.
    • 아티팩트 빌드 프로세스 리팩터링: 원본 환경과 대상 환경 모두에 아티팩트를 저장할 수 있도록 원본 환경의 마이너 리팩터링을 완료합니다. 이 방식은 대상 Google Cloud 환경에서 아티팩트 빌드 프로세스를 구현하기 전에 아티팩트 저장소와 같은 인프라를 빌드하여 마이그레이션을 지원합니다. 이 접근 방식을 직접 구현하거나 통신 채널을 먼저 설정하는 이전의 접근 방식으로 빌드할 수 있습니다.

    원본 환경과 대상 환경 모두에서 아티팩트를 사용할 수 있으면 마이그레이션의 일환으로 대상 Google Cloud 환경에서 아티팩트 빌드 프로세스를 구현하지 않고도 마이그레이션에 집중할 수 있습니다.

  • 코드 스캔 및 서명. 아티팩트 빌드 프로세스의 일부로 코드 스캔을 사용하여 일반적인 취약점과 의도하지 않은 네트워크 노출을 방지하고, 코드 서명을 사용하여 신뢰할 수 있는 코드만 환경에서 실행되도록 할 수 있습니다.

  • 원본 환경에 아티팩트 배포. 배포 가능한 아티팩트를 생성한 후 원본 환경에 배포할 수 있습니다. 각 배포 프로세스를 평가하는 것이 좋습니다. 이 평가는 배포 프로세스가 Google Cloud와 호환되는지 확인하는 데 도움이 됩니다. 또한 프로세스를 리팩터링하는 데 필요한 노력을 파악하는 데도 도움이 됩니다. 예를 들어 배포 프로세스가 원본 환경에서만 작동하는 경우 Google Cloud 환경을 타겟팅하도록 이를 리팩터링해야 할 수 있습니다.

  • 런타임 구성 삽입. 특정 클러스터, 런타임 환경 또는 워크로드 배포에 대한 런타임 구성을 삽입할 수 있습니다. 이 구성으로 환경 변수와 보안 비밀, 사용자 인증 정보, 키와 같은 기타 구성 값이 초기화될 수 있습니다. 런타임 구성 삽입 프로세스가 Google Cloud에서 작동하는지 확인하려면 원본 환경에서 실행되는 워크로드를 구성하는 방법을 평가하는 것이 좋습니다.

  • 로깅, 모니터링, 프로파일링. 원본 환경의 상태, 관심 측정항목, 이러한 프로세스에서 제공하는 데이터 사용 방식을 모니터링하기 위해 마련한 로깅, 모니터링, 프로파일링 프로세스를 평가합니다.

  • 인증 원본 환경에 대해 인증하는 방법을 평가합니다.

  • 리소스 프로비저닝 및 구성. 원본 환경을 준비하기 위해 리소스를 프로비저닝하고 구성하는 프로세스를 설계하고 구현했을 수 있습니다. 예를 들어 구성 관리 도구와 함께 Terraform을 사용하여 원본 환경에서 리소스를 프로비저닝하고 구성할 수 있습니다.

소스 환경의 인벤토리를 빌드하는 도구

Amazon EKS 클러스터의 인벤토리를 빌드하려면 현재 환경에서 Google Cloud까지의 엔드 투 엔드 클라우드 여정을 가속화하는 데 도움이 되는 Google Cloud의 통합 플랫폼인 Migration Center를 사용하는 것이 좋습니다. Migration Center를 사용하면 Amazon EKS 및 기타 AWS 리소스에서 데이터를 가져올 수 있습니다. 그러면 Migration Center에서 마이그레이션할 수 있는 관련 Google Cloud 서비스를 권장합니다.

Amazon EKS 클러스터 및 워크로드의 인벤토리 미세 조정

Migration Center에서 제공하는 데이터가 원하는 측정기준을 완전히 캡처하지 못할 수 있습니다. 이 경우 이 데이터를 AWS API, AWS 개발자 도구, AWS 명령줄 인터페이스를 기반으로 하는 사용자가 만든 다른 데이터 수집 메커니즘의 결과와 통합하면 됩니다.

Migration Center에서 가져오는 데이터 외에도 마이그레이션하려는 각 Amazon EKS 클러스터에서 다음 데이터 포인트를 고려합니다.

  • 다음을 포함하여 각 Amazon EKS 클러스터의 Amazon EKS 관련 관점과 기능을 고려하세요.
    • 비공개 클러스터
    • 클러스터 엔드포인트 액세스 제어
    • 보안 비밀 암호화
    • 관리형 노드 그룹과 자체 관리형 노드
    • Amazon EKS 리소스의 태그
    • EKS의 Amazon 사용자 지정 AMI
    • Amazon EKS Fargate 사용
    • Amazon EKS Managed Prometheus 사용
    • OpenID Connect 인증 구성
  • Amazon EKS 클러스터에 대해 인증하는 방법과 Amazon EKS에 대해 AWS Identity and Access Management(IAM)를 구성한 방법을 평가합니다.
  • Amazon EKS 클러스터의 네트워킹 구성을 평가합니다.

기반 계획 및 빌드

계획 및 빌드 단계에서는 다음을 수행하도록 인프라를 프로비저닝하고 구성합니다.

  • Google Cloud 환경에서 워크로드를 지원합니다.
  • 원본 환경과 Google Cloud 환경을 연결하여 마이그레이션을 완료합니다.

계획 및 빌드 단계는 다음과 같은 태스크로 구성됩니다.

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

각 태스크에 대한 자세한 내용은 Google Cloud로 마이그레이션: 기반 계획 및 빌드를 참조하세요.

다음 섹션에서는 'Google Cloud로 마이그레이션: 기반 계획 및 빌드'의 고려사항을 통합합니다.

멀티테넌시 계획

효율적인 리소스 계층 구조를 설계하려면 비즈니스 및 조직 구조가 Google Cloud에 매핑되는 방식을 고려하세요. 예를 들어 GKE에 멀티 테넌트 환경이 필요한 경우 다음 옵션 중 하나를 선택할 수 있습니다.

  • 테넌트마다 Google Cloud 프로젝트 한 개를 만듭니다.
  • 여러 테넌트간에 프로젝트 하나를 공유하고 여러 GKE 클러스터를 프로비저닝합니다.
  • Kubernetes 네임스페이스를 사용합니다.

격리, 복잡성, 확장성 요구사항에 따라 선택합니다. 예를 들어 테넌트당 프로젝트 하나를 만들면 테넌트가 서로 격리되지만 프로젝트 수가 많아져 리소스 계층 구조 관리가 더 복잡해집니다. 그러나 Kubernetes 네임스페이스 관리는 복잡한 리소스 계층 구조보다 상대적으로 수월하지만 이 옵션은 높은 수준의 격리를 보장하지 않습니다. 예를 들어 테넌트간에 컨트롤 플레인이 공유될 수 있습니다. 자세한 내용은 클러스터 멀티테넌시를 참조하세요.

ID 및 액세스 관리 구성

GKE는 RBAC를 사용하여 Google Cloud 프로젝트 및 클러스터 내의 리소스에 대한 액세스를 관리하는 여러 가지 옵션을 지원합니다. 자세한 내용은 액세스 제어를 참조하세요.

GKE 네트워킹 구성

네트워크 구성은 환경의 기본 요소입니다. 클러스터를 프로비저닝하고 구성하기 전에 GKE 네트워크 모델, GKE 네트워킹 권장사항, GKE로 마이그레이션할 때 IP 주소를 계획하는 방법을 평가하는 것이 좋습니다.

모니터링 및 알림 설정

인프라와 워크로드의 성능을 명확하게 파악해야만 개선점도 찾을 수 있습니다. GKE는 Google Cloud Observability와 긴밀히 통합되므로 이러한 클러스터 내에서 GKE 클러스터와 워크로드에 대한 로깅, 모니터링, 프로파일링 정보를 얻을 수 있습니다.

데이터 마이그레이션 및 워크로드 배포

배포 단계에서는 다음을 수행합니다.

  1. GKE 환경을 프로비저닝하고 구성합니다.
  2. GKE 클러스터를 구성합니다.
  3. 워크로드를 리팩터링합니다.
  4. 배포 및 운영 프로세스를 리팩터링합니다.
  5. 원본 환경에서 Google Cloud로 데이터를 마이그레이션합니다.
  6. 워크로드를 GKE 환경에 배포합니다.
  7. 워크로드 및 GKE 환경을 검증합니다.
  8. GKE에서 실행되는 워크로드를 노출합니다.
  9. 트래픽을 원본 환경에서 GKE 환경으로 이동합니다.
  10. 원본 환경을 사용 중단합니다.

Google Cloud 환경 프로비저닝 및 구성

워크로드를 새 Google Cloud 환경으로 이동하기 전에 GKE 클러스터를 프로비저닝합니다.

GKE는 기존 클러스터에서 특정 기능을 사용 설정하는 것을 지원하지만 클러스터 생성 시점에만 사용 설정할 수 있는 기능이 있을 수 있습니다. 서비스 중단을 방지하고 마이그레이션을 간소화하려면 클러스터 생성 시 필요한 클러스터 기능을 사용 설정하는 것이 좋습니다. 그렇지 않으면 클러스터를 만든 후 필요한 클러스터 기능을 사용 설정할 수 없는 경우 클러스터를 삭제하고 다시 만들어야 할 수 있습니다.

평가 단계가 끝나면 이제 새 Google Cloud 환경에서 필요에 맞게 GKE 클러스터를 프로비저닝하는 방법을 알게 됩니다. 클러스터를 프로비저닝하려면 다음 사항을 고려하세요.

GKE 클러스터 프로비저닝에 관한 자세한 내용은 다음을 참고하세요.

Fleet 관리

GKE 클러스터를 프로비저닝할 때는 환경의 모든 사용 사례를 지원하기 위해 클러스터가 다량 필요할 수 있습니다. 예를 들어 프로덕션 환경을 비프로덕션 환경과 구분하거나 여러 팀 또는 지역 간에 서비스를 분리해야 할 수 있습니다. 자세한 내용은 멀티 클러스터 사용 사례를 참조하세요.

클러스터 수가 증가하면 GKE 환경을 운영하기가 더 어려워질 수 있습니다. 다수의 클러스터를 관리하는 것은 상당한 확장성과 운영상의 문제를 야기하기 때문입니다. GKE는 Kubernetes 클러스터의 논리적 그룹인 Fleet를 관리하는 데 도움이 되는 도구와 기능을 제공합니다. 자세한 내용은 Fleet 관리를 참고하세요.

멀티 클러스터 네트워킹

GKE 환경의 안정성을 개선하고 여러 GKE 클러스터에 워크로드를 분산하려면 다음을 사용하면 됩니다.

  • 멀티 클러스터 서비스 검색: 클러스터 간 서비스 검색 및 호출 메커니즘 서비스는 GKE 클러스터 간에 검색 및 액세스할 수 있습니다. 자세한 내용은 멀티 클러스터 서비스 검색을 참고하세요.
  • 멀티 클러스터 게이트웨이는 클러스터 간 인그레스 트래픽 부하 분산 메커니즘입니다. 자세한 내용은 멀티 클러스터 게이트웨이 배포를 참조하세요.
  • 관리형 Cloud Service Mesh의 멀티 클러스터 메시. 자세한 내용은 멀티 클러스터 메시 설정을 참고하세요.

단일 클러스터 GKE 환경에서 멀티 클러스터 GKE 환경으로 마이그레이션하는 방법에 관한 자세한 내용은 멀티 클러스터 네트워킹으로 마이그레이션을 참고하세요.

GKE 클러스터 구성

GKE 클러스터를 프로비저닝한 후 워크로드를 배포하거나 데이터를 마이그레이션하기 전에 GKE 클러스터마다 네임스페이스, RBAC, 네트워크 정책, 서비스 계정, 기타 Kubernetes 및 GKE 객체를 구성합니다.

GKE 클러스터에서 Kubernetes 및 GKE 객체를 구성하려면 다음을 수행하는 것이 좋습니다.

  1. 원본 환경과 GKE 환경의 클러스터 모두에 액세스하는 데 필요한 사용자 인증 정보와 권한이 있는지 확인합니다.
  2. 원본 환경의 Kubernetes 클러스터에 있는 객체가 GKE와 호환되는지, 이러한 객체를 지원하는 구현이 원본 환경 및 GKE와 어떻게 다른지 평가합니다.
  3. 호환되지 않는 객체를 리팩터링하여 GKE와 호환되도록 하거나 사용 중지합니다.
  4. GKE 클러스터에 이러한 객체를 만듭니다.
  5. GKE 클러스터에 필요한 추가 객체를 구성합니다.

구성 동기화

GKE 확장 시 GKE 클러스터의 구성을 관리하기 위한 GitOps 권장사항을 채택하려면 GitOps 서비스인 구성 동기화를 사용하여 정보 소스에서 구성을 배포하는 것이 좋습니다. 예를 들어 GKE 클러스터의 구성을 Git 저장소에 저장하고 구성 동기화를 사용하여 해당 구성을 적용할 수 있습니다.

자세한 내용은 구성 동기화 아키텍처를 참고하세요.

정책 컨트롤러

정책 컨트롤러를 사용하면 프로그래밍 가능한 정책을 적용하고 시행하여 GKE 클러스터와 워크로드를 안전하고 규정을 준수하는 방식으로 실행할 수 있습니다. GKE 환경을 확장할 때 정책 컨트롤러를 사용하여 정책, 정책 번들, 제약 조건을 모든 GKE 클러스터에 자동으로 적용할 수 있습니다. 예를 들어 컨테이너 이미지를 가져올 수 있는 저장소를 제한하거나 각 네임스페이스에 라벨이 하나 이상 있어야 하도록 하여 정확한 리소스 소비 추적을 보장할 수 있습니다.

자세한 내용은 정책 컨트롤러를 참고하세요.

워크로드 리팩터링

컨테이너화된 워크로드를 설계할 때는 컨테이너 오케스트레이션 플랫폼에 대한 종속 항목을 피하는 것이 좋습니다. 워크로드의 요구사항과 설계 때문에 이것이 항상 가능하지는 않습니다. 예를 들어 워크로드는 부가기능, 확장 프로그램, 통합과 같이 소스 환경에서만 사용할 수 있는 환경별 기능에 종속될 수 있습니다.

대부분의 워크로드를 있는 그대로 GKE로 마이그레이션할 수 있더라도 이러한 종속성을 최소화하고 결국 GKE에서 사용 가능한 대안으로 전환하려면 환경별 기능에 의존하는 워크로드를 리팩터링하기 위한 추가 노력이 필요할 수 있습니다.

워크로드를 GKE로 이전하기 전에 리팩터링하려면 다음 단계를 따르세요.

  1. 부가기능, 확장 프로그램, 통합과 같은 원본 환경별 기능을 검토합니다.
  2. 적절한 대체 GKE 솔루션을 채택합니다.
  3. 워크로드를 리팩터링합니다.

소스 환경별 기능 검토

소스 환경별 기능을 사용 중이고 워크로드가 이러한 기능에 종속되는 경우 다음을 실행해야 합니다.

  1. 적절한 대체 GKE 솔루션을 찾습니다.
  2. 대체 GKE 솔루션을 활용할 수 있도록 워크로드를 리팩터링합니다.

이 검토의 일환으로 다음을 수행하는 것이 좋습니다.

  • 이러한 소스 환경별 기능을 지원 중단할 수 있는지 고려합니다.
  • 원본 환경별 기능이 마이그레이션의 성공에 얼마나 중요한지 평가합니다.

적절한 대체 GKE 솔루션 채택

원본 환경별 기능을 검토하고 적합한 GKE 대체 솔루션에 매핑한 후 GKE 환경에 이 솔루션을 채택합니다. 마이그레이션 복잡성을 줄이려면 다음을 수행하는 것이 좋습니다.

  • 지원 중단하려는 원본 환경별 기능에 대한 대체 GKE 솔루션의 채택을 피합니다.
  • 가장 중요한 소스 환경별 기능에 대한 대체 GKE 솔루션을 채택하는 데 집중하고 나머지 기능에 대해서는 전용 이전 프로젝트를 계획합니다.

워크로드 리팩터링

대부분의 워크로드가 GKE에서 그대로 작동할 수 있지만 특히 대체 GKE 솔루션을 채택한 원본 환경별 기능에 의존하는 경우 일부 워크로드가 리팩터링되어야 할 수 있습니다.

이 리팩터링에는 다음이 포함될 수 있습니다.

  • 배포, 서비스와 같은 Kubernetes 객체 설명자(YAML 형식으로 표현됨)
  • Dockerfile 및 Containerfile과 같은 컨테이너 이미지 설명자
  • 워크로드 소스 코드.

리팩터링 작업을 간소화하려면 워크로드를 GKE에 적합하게 만드는 데 필요한 최소한의 변경사항을 적용하고 중요한 버그를 수정하는 데 집중하는 것이 좋습니다. 향후 프로젝트의 일환으로 다른 개선사항과 변경사항을 계획할 수 있습니다.

배포 및 운영 프로세스 리팩터링

워크로드를 리팩터링한 후에는 배포 및 운영 프로세스를 리팩터링하여 다음을 실행합니다.

  • 소스 환경에서 리소스를 프로비저닝하는 대신 Google Cloud 환경에서 리소스를 프로비저닝하고 구성합니다.
  • 워크로드를 빌드 및 구성하고 원본 환경에 배포하는 대신 Google Cloud에 배포합니다.

이 프로세스 앞부분의 평가 단계에서는 이러한 프로세스에 대한 정보를 수집한 바 있습니다.

이러한 프로세스에 대해 고려해야 하는 리팩터링 유형은 이를 설계하고 구현한 방법에 따라 달라집니다. 리팩터링은 또한 각 프로세스에서 원하는 최종 상태에 따라 달라집니다. 예를 들어, 다음 사항을 고려해 보세요.

  • 이러한 프로세스를 소스 환경에서 구현했으며 Google Cloud에서 유사한 프로세스를 설계하고 구현하려고 할 수 있습니다. 예를 들어 이러한 프로세스를 리팩터링하여 Cloud Build ,Cloud Deploy 및Infrastructure Manager 를 사용할 수 있습니다.
  • 이러한 프로세스를 원본 환경 외부의 다른 제3자 환경에서 구현했을 수 있습니다. 이 경우 원본 환경 대신 Google Cloud 환경을 타겟팅하도록 이러한 프로세스를 리팩터링해야 합니다.
  • 앞선 접근 방식을 조합합니다.

배포 및 운영 프로세스를 리팩터링하는 작업은 복잡할 수 있으며 상당한 노력이 필요할 수 있습니다. 워크로드 이전의 일부로 이러한 작업을 수행하려고 하면 워크로드 이전이 더 복잡해지고 위험에 노출될 수 있습니다. 배포 및 운영 프로세스를 평가하면 프로세스의 설계와 복잡성을 파악할 수 있습니다. 배포 및 운영 프로세스를 리팩터링하는 데 상당한 노력이 필요하다고 판단되면 별도의 전용 프로젝트의 일부로 이러한 프로세스를 리팩터링하는 것이 좋습니다.

Google Cloud에서 배포 프로세스를 설계하고 구현하는 방법에 관한 자세한 내용은 다음을 참고하세요.

이 문서에서는 배포할 아티팩트를 생성하고 대상 런타임 환경에 배포하는 배포 프로세스에 중점을 둡니다. 리팩터링 전략은 이러한 프로세스의 복잡성에 따라 크게 달라집니다. 다음 목록은 가능한 일반적인 리팩터링 전략을 간략히 보여줍니다.

  1. Google Cloud에서 아티팩트 저장소를 프로비저닝합니다. 예를 들어 Artifact Registry를 사용하여 아티팩트와 빌드 종속 항목을 저장할 수 있습니다.
  2. 원본 환경과 Artifact Registry 모두에 아티팩트를 저장하도록 빌드 프로세스를 리팩터링합니다.
  3. 대상 Google Cloud 환경에 워크로드를 배포하도록 배포 프로세스를 리팩터링합니다. 예를 들어 먼저 Artifact Registry에 저장된 아티팩트를 사용하여 Google Cloud에 워크로드의 일부를 배포합니다. 그런 다음 마이그레이션할 모든 워크로드가 Google Cloud에서 실행될 때까지 Google Cloud에 배포된 워크로드 수를 점차 늘립니다.
  4. Artifact Registry에만 아티팩트를 저장하도록 빌드 프로세스를 리팩터링합니다.
  5. 필요한 경우 배포할 이전 버전의 아티팩트를 원본 환경의 저장소에서 Artifact Registry로 마이그레이션합니다. 예를 들어 컨테이너 이미지를 Artifact Registry에 복사할 수 있습니다.
  6. 더 이상 필요하지 않으면 원본 환경에서 저장소를 사용 중단합니다.

마이그레이션 중 예기치 않은 문제로 인한 최종 롤백을 용이하게 하기 위해 Google Cloud로 마이그레이션이 진행되는 동안 Google Cloud의 현재 아티팩트 저장소에 컨테이너 이미지를 저장할 수 있습니다. 마지막으로 원본 환경을 지원 중단하는 과정에서 컨테이너 이미지 빌드 프로세스를 리팩터링하여 Google Cloud에만 아티팩트를 저장할 수 있습니다.

마이그레이션의 성공에 중요하지 않을 수도 있지만 이전 버전의 아티팩트를 원본 환경에서 Google Cloud의 아티팩트 저장소로 마이그레이션해야 할 수 있습니다. 예를 들어 워크로드를 임의의 시점으로 롤백하는 기능을 지원하려면 이전 버전의 아티팩트를 Artifact Registry로 마이그레이션해야 할 수 있습니다. 자세한 내용은 서드 파티 레지스트리에서 이미지 마이그레이션을 참조하세요.

Artifact Registry를 사용하여 아티팩트를 저장하는 경우 액세스 제어, 데이터 무단 반출 방지, 취약점 스캔, Binary Authorization과 같은 아티팩트 저장소를 보호하는 데 도움이 되는 제어 기능을 구성하는 것이 좋습니다. 자세한 내용은 액세스 제어 및 아티팩트 보호를 참조하세요.

데이터 이전

GKE는 블록 스토리지, 원시 블록 스토리지, 파일 스토리지, 객체 스토리지와 같은 여러 데이터 스토리지 서비스를 지원합니다. 자세한 내용은 GKE 클러스터용 스토리지 개요를 참고하세요.

데이터를 GKE 환경으로 마이그레이션하려면 다음 단계를 따르세요.

  1. 필요한 모든 스토리지 인프라를 프로비저닝하고 구성합니다.
  2. GKE 클러스터에서 StorageClass 프로비저너를 구성합니다. 참고: 환경에 따라 일부 StorageClass 프로비저닝 도구가 호환되지 않을 수 있습니다. StorageClass 프로비저닝 도구를 배포하기 전에 GKE와의 호환성 및 종속 항목을 평가하는 것이 좋습니다.
  3. StorageClass를 구성합니다.
  4. 이전할 데이터를 저장하도록 PersistentVolume 및 PersistentVolumeClaim을 구성합니다.
  5. 원본 환경에서 이러한 PersistentVolume로 데이터를 마이그레이션합니다. 이 데이터 이전의 세부사항은 소스 환경의 특성에 따라 달라집니다.

원본 환경에서 Google Cloud 환경으로 데이터를 마이그레이션하려면 Google Cloud로 마이그레이션: 대규모 데이터 세트 전송의 지침에 따라 데이터 마이그레이션 계획을 설계하는 것이 좋습니다.

EKS에서 GKE로 데이터 이전

AWS는 Amazon EKS에 대한 몇 가지 데이터 저장소 옵션을 제공합니다. 이 문서에서는 다음과 같은 데이터 마이그레이션 시나리오를 자세히 설명합니다.

  • 데이터를 Amazon EBS 볼륨에서 GKE PersistentVolume 리소스로 마이그레이션합니다.
  • 데이터를 Amazon EBS 볼륨에서 Amazon S3 또는 Cloud Storage로 복사한 후 데이터를 GKE PersistentVolume 리소스로 마이그레이션합니다.
Amazon EBS 볼륨에서 GKE PersistentVolume으로 데이터 마이그레이션

다음 방식 중 하나를 사용하여 데이터를 Amazon EBS 볼륨에서 GKE PersistentVolume 리소스로 마이그레이션할 수 있습니다.

  • 데이터를 직접 Amazon EBS 볼륨에서 Compute Engine 영구 디스크로 복사합니다.
    1. Amazon EC2 인스턴스를 프로비저닝하고 마이그레이션할 데이터가 포함된 Amazon EBS 볼륨을 연결합니다.
    2. 마이그레이션할 데이터를 저장하기에 충분한 용량이 있는 빈 영구 디스크로 Compute Engine 인스턴스를 프로비저닝합니다.
    3. rsync와 같은 데이터 동기화 도구를 실행하여 데이터를 Amazon EBS 볼륨에서 Compute Engine 영구 디스크로 복사합니다.
    4. 영구 디스크를 Compute Engine 인스턴스에서 분리합니다.
    5. Compute Engine 인스턴스를 사용 중단합니다.
    6. 영구 디스크를 GKE PersistentVolume 리소스로 구성합니다.
  • Amazon EC2 인스턴스와 Amazon EBS 볼륨을 Compute Engine으로 마이그레이션합니다.
    1. Amazon EC2 인스턴스를 프로비저닝하고 마이그레이션할 데이터가 포함된 Amazon EBS 볼륨을 연결합니다.
    2. Migrate to Virtual Machines를 사용하여 Amazon EC2 인스턴스와 Amazon EBS 볼륨을 Compute Engine으로 마이그레이션합니다.
    3. 영구 디스크를 Compute Engine 인스턴스에서 분리합니다.
    4. Compute Engine 인스턴스를 사용 중단합니다.
    5. 영구 디스크를 GKE PersistentVolume 리소스로 구성합니다.

Amazon EC2 인스턴스를 Compute Engine으로 마이그레이션하는 방법에 대한 자세한 내용은 AWS에서 Google Cloud로 마이그레이션: Amazon EC2에서 Compute Engine으로 마이그레이션을 참조하세요.

Compute Engine 영구 디스크를 GKE PersistentVolume 리소스로 사용하는 방법에 대한 자세한 내용은 기존 영구 디스크를 PersistentVolume으로 사용을 참조하세요.

Amazon EBS 볼륨에서 중간 미디어로 데이터를 복사한 후 GKE PersistentVolume으로 마이그레이션

Amazon EBS 볼륨에서 GKE PersistentVolume 리소스로 직접 마이그레이션하는 대신 객체 저장소와 같은 중간 미디어를 사용할 수 있습니다.

  1. 데이터를 Amazon EBS 볼륨에서 Amazon S3 버킷 또는 Cloud Storage 버킷과 같은 중간 미디어로 업로드합니다.
  2. 데이터를 중간 미디어에서 GKE PersistentVolume 리소스로 다운로드합니다.

특정 시나리오에서는 여러 미디어를 사용하면 네트워크 및 보안 구성을 기준으로 데이터 전송을 단순화할 수 있습니다. 예를 들어 처음에 데이터를 S3 버킷에 업로드한 다음 S3 버킷에서 Cloud Storage 버킷으로 복사하고 마지막으로 영구 볼륨에 데이터를 다운로드할 수 있습니다. 선택한 접근 방식에 관계없이 중요한 고려사항을 알고 원활하게 전환할 수 있도록 AWS에서 Google Cloud로 마이그레이션: Amazon S3에서 Cloud Storage로 마이그레이션을 검토하는 것이 좋습니다.

이전 옵션 선택하기

가장 적합한 마이그레이션 옵션은 다음 고려사항과 같은 특정 필요 및 요구사항에 따라 달라집니다.

  • 마이그레이션해야 하는 데이터 양
    • 마이그레이션할 데이터 양이 적은 경우(예: 데이터 파일 몇 개) rsync와 같은 도구를 사용하여 데이터를 Compute Engine 영구 디스크에 직접 복사하는 것이 좋습니다. 이 옵션은 비교적 빠르지만 대량의 데이터에는 적합하지 않을 수 있습니다.
    • 마이그레이션할 데이터 양이 많은 경우 Migrate to Virtual Machines를 사용하여 데이터를 Compute Engine으로 마이그레이션하는 것이 좋습니다. 이 옵션은 데이터를 직접 복사하는 것보다 더 복잡하지만 더 안정적이고 확장 가능합니다.
  • 마이그레이션해야 하는 데이터 유형
  • 소스 및 대상 환경 간의 네트워크 연결
    • AWS EC2 및 Compute Engine 인스턴스 간에 직접 네트워크 연결을 설정할 수 없는 경우 Amazon S3 또는 Cloud Storage를 사용하여 Compute Engine으로 마이그레이션하는 동안 데이터를 일시적으로 저장할 수 있습니다. 이 옵션은 EC2 및 Compute Engine 인스턴스를 동시에 실행할 필요가 없으므로 비용이 적게 들 수 있습니다.
  • 마이그레이션 일정
    • 네트워크 대역폭이 제한되어 있거나 데이터 양이 많지만 일정에 여유가 있으면 Transfer Appliance를 사용하여 데이터를 AWS에서 Google Cloud로 이동하는 것이 좋습니다.

어떤 옵션을 선택하든 마이그레이션을 실행하기 전에 테스트하는 것이 중요합니다. 테스트하면 잠재적 문제를 식별하고 마이그레이션이 성공했는지 확인할 수 있습니다.

워크로드 배포

배포 프로세스가 준비되면 GKE에 워크로드를 배포합니다. 자세한 내용은 워크로드 배포 개요를 참조하세요.

GKE에 배포할 워크로드를 준비하려면 Kubernetes 설명어를 분석하는 것이 좋습니다. GKE가 자동으로 프로비저닝하는 일부 Google Cloud 리소스는 이러한 리소스를 수동으로 프로비저닝할 필요 없이 Kubernetes 라벨 및주석을 사용하여 구성할 수 있기 때문입니다. 예를 들어 LoadBalancer 서비스에 주석을 추가하여 외부 부하 분산기 대신 내부 부하 분산기를 프로비저닝할 수 있습니다.

워크로드 검증

GKE 환경에 워크로드를 배포한 후 이러한 워크로드를 사용자에게 노출하기 전에 광범위한 유효성 검사 및 테스트를 실행하는 것이 좋습니다. 이 테스트를 통해 워크로드가 예상대로 동작하는지 확인할 수 있습니다. 예를 들어 다음과 같은 작업을 할 수 있습니다.

  • 워크로드가 예상된 매개변수 내에서 그리고 사양에 따라 작동하는지 확인하는 데 도움이 되는 통합 테스트, 부하 테스트, 규정 준수 테스트, 안정성 테스트, 기타 확인 절차를 수행합니다.
  • Google Cloud Observability의 로그, 측정항목, 오류 보고서를 조사하여 잠재적인 문제를 식별하고 추세를 파악하여 문제가 발생하기 전에 문제를 예측합니다.

워크로드 유효성 검사에 관한 자세한 내용은 안정성 테스트를 참고하세요.

워크로드 노출

GKE 환경에서 실행되는 워크로드의 유효성 검사 테스트를 완료한 후에는 워크로드를 노출하여 액세스할 수 있도록 합니다.

GKE 환경에서 실행되는 워크로드를 노출하려면 Kubernetes 서비스와 서비스 메시를 사용하면 됩니다.

GKE에서 실행되는 워크로드를 노출하는 방법에 관한 자세한 내용은 다음을 참고하세요.

Google Cloud 환경으로 트래픽 전환

워크로드가 GKE 환경에서 실행 중인지 확인하고 클라이언트에 노출한 후에는 원본 환경에서 GKE 환경으로 트래픽을 전환합니다. 대규모 마이그레이션 및 모든 관련 위험을 방지하려면 원본 환경에서 GKE로 트래픽을 점진적으로 전환하는 것이 좋습니다.

GKE 환경의 설계 방식에 따라 원본 환경에서 대상 환경으로 트래픽을 점진적으로 전환하는 부하 분산 메커니즘을 구현할 수 있는 몇 가지 옵션이 있습니다. 예를 들어 GKE 환경에 속한 IP 주소에 대한 요청의 일정 비율을 확인하기 위해 특정 정책에 따라 DNS 레코드를 확인하는 DNS 확인 정책을 구현할 수 있습니다. 또는 가상 IP 주소와 네트워크 부하 분산기를 사용하여 부하 분산 메커니즘을 구현할 수 있습니다.

GKE 환경으로 트래픽을 점진적으로 전환하기 시작하면 부하가 증가함에 따라 워크로드가 어떻게 작동하는지 모니터링하는 것이 좋습니다.

마지막으로 컷오버를 수행합니다. 이 작업은 원본 환경에서 GKE 환경으로 모든 트래픽을 전환할 때 발생합니다.

부하 분산에 대한 자세한 내용은 프런트엔드에서 부하 분산을 참조하세요.

원본 환경 사용 중단

GKE 환경의 워크로드가 요청을 올바르게 처리하면 원본 환경을 사용 중단합니다.

소스 환경에서 리소스 사용 중단을 시작하기 전에 다음을 실행하는 것이 좋습니다.

  • 원본 환경의 리소스를 복원하는 데 도움이 되는 모든 데이터를 백업합니다.
  • 환경을 지원 중단하기 전에 사용자에게 알립니다.

원본 환경을 사용 중단하려면 다음을 수행합니다.

  1. 소스 환경의 클러스터에서 실행 중인 워크로드를 사용 중지합니다.
  2. 소스 환경에서 클러스터를 삭제합니다.
  3. 보안 그룹, 부하 분산기, 가상 네트워크와 같이 이러한 클러스터와 연결된 리소스를 삭제합니다.

분리된 리소스가 남지 않도록 원본 환경에서 리소스를 사용 중단하는 순서가 중요합니다. 예를 들어 일부 공급업체는 부하 분산기를 만들 수 있는 Kubernetes 서비스를 사용 중단해야 해당 부하 분산기가 포함된 가상 네트워크를 사용 중단할 수 있습니다.

Google Cloud 환경 최적화

최적화는 마이그레이션의 마지막 단계입니다. 이 단계에서는 대상 환경이 최적화 요구사항을 충족할 때까지 최적화 태스크를 반복합니다. 각 반복 단계는 다음과 같습니다.

  1. 현재 환경, 팀 및 최적화 루프를 평가합니다.
  2. 최적화 요구사항 및 목표를 설정합니다.
  3. 환경 및 팀을 최적화합니다.
  4. 최적화 루프를 조정합니다.

최적화 목표에 도달할 때까지 이 순서를 반복합니다.

Google Cloud 환경 최적화에 대한 자세한 내용은 Google Cloud로 마이그레이션: 환경 최적화 및 성능 최적화 프로세스를 참조하세요.

다음 섹션에는 'Google Cloud로 마이그레이션: 환경 최적화'의 고려사항이 통합되어 있습니다.

최적화 요구사항 설정

최적화 요구사항을 사용하면 현재 최적화 반복의 범위를 좁힐 수 있습니다. 최적화 요구사항 및 목표에 관한 자세한 내용은 최적화 요구사항 및 목표 설정을 참고하세요.

GKE 환경의 최적화 요구사항을 설정하려면 먼저 다음 관점을 고려하세요.

  • 보안, 개인 정보 보호, 규정 준수: GKE 환경의 보안 상황을 개선하는 데 도움이 됩니다.
  • 안정성: GKE 환경의 가용성, 확장성, 복원력을 개선하는 데 도움이 됩니다.
  • 비용 최적화: GKE 환경의 리소스 소비 및 결과 지출을 최적화하는 데 도움이 됩니다.
  • 운영 효율성: GKE 환경을 효율적으로 유지하고 운영하는 데 도움이 됩니다.
  • 성능 최적화: GKE 환경에 배포된 워크로드의 성능을 최적화하는 데 도움이 됩니다.

보안, 개인정보 보호, 규정 준수

  • GKE 클러스터의 보안 상황 모니터링. 보안 상황 대시보드를 사용하여 GKE 환경의 보안 상황을 개선하는 데 도움이 되는 독자적이고 실행 가능한 권장사항을 확인할 수 있습니다.
  • GKE 환경 강화. GKE 보안 모델 및 GKE 클러스터 강화 방법을 이해합니다.
  • 소프트웨어 공급망 보호. 보안이 중요한 워크로드의 경우 Google Cloud는 소프트웨어 수명 주기 전반에서 소프트웨어 공급망 보안 권장사항을 구현하는 모듈식 제품 세트를 제공합니다.

안정성

  • 클러스터의 안정성 향상. 발생 가능성이 높지 않은 영역 장애에 대해 복원력이 우수한 GKE를 설계하려면 영역 또는 멀티 영역 클러스터보다 리전별 클러스터를 사용하는 것이 좋습니다.
  • 워크로드 백업 및 복원 Backup for GKE로 워크로드 백업 및 복원 워크플로를 구성합니다.

비용 최적화

GKE 환경의 비용 최적화에 대한 자세한 내용은 다음을 참조하세요.

운영 효율성

프로덕션 환경에 영향을 미치는 문제를 방지하려면 다음을 따르는 것이 좋습니다.

  • GKE 클러스터를 대체 가능하도록 설계. 클러스터를 대체 가능한 것으로 간주하고 프로비저닝 및 구성을 자동화하면 운영 프로세스를 간소화하고 일반화하여 향후 마이그레이션 및 GKE 클러스터 업그레이드를 간소화할 수 있습니다. 예를 들어 대체 가능한 GKE 클러스터를 새 GKE 버전으로 업그레이드해야 할 경우, 업그레이드된 새 클러스터를 자동으로 프로비저닝 및 구성하고, 새 클러스터에 워크로드를 자동으로 배포하고, 이전의 오래된 GKE 클러스터를 사용 중단할 수 있습니다.
  • 관심 측정항목 모니터링. 워크로드 및 클러스터와 관련하여 관심 있는 모든 측정항목이 올바르게 수집되었는지 확인합니다. 또한 이러한 측정항목을 입력으로 사용하는 모든 관련 알림이 설정되어 있고 작동하는지 확인합니다.

GKE 환경에서 모니터링, 로깅, 프로파일링을 구성하는 방법에 대한 자세한 내용은 다음을 참조합니다.

성능 최적화

자세한 내용은 GKE 확장성 정보를 참고하세요.

다음 단계

참여자

저자: