한 회사에서 온프레미스 Kubernetes 클러스터에서 ML 워크플로우를 실행합니다. 각 ML 서비스는 독립형 Docker 이미지로 패키징되어 있습니다. 이 회사는 운영 오버헤드를 최소화하면서 Amazon EKS 클러스터로 리프트 앤 시프트해야 합니다. 이 요구 사항을 충족하는 솔루션은 무엇입니까?

정답은 "Docker 이미지를 Amazon Elastic Container Registry(Amazon ECR) 리포지토리로 푸시하고 배포 파이프라인을 구성하여 해당 이미지를 EKS 클러스터에 배포합니다"입니다. 기존 온프레미스 Kubernetes 클러스터에서 독립형 Docker 이미지로 패키징된 ML 워크플로우를 Amazon EKS로 "리프트 앤 시프트"하는 가장 직접적이고 운영 오버헤드가 적은 방법입니다. ECR은 Docker 이미지를 저장하고 관리하는 완전 관리형 서비스이며, EKS는 Kubernetes 워크로드를 실행하기 위한 관리형 서비스입니다. 기존 Docker 이미지를 ECR에 푸시하고 배포 파이프라인을 구성하면 최소한의 변경으로 EKS에서 동일한 워크로드를 실행할 수 있습니다. Kubeflow로 재설계하는 것은 상당한 재설계 노력과 운영 오버헤드를 수반하므로 "리프트 앤 시프트" 요구 사항에 부합하지 않습니다. Amazon Redshift ML 또는 Amazon SageMaker 노트북을 사용하여 모델을 재훈련하는 것은 기존 ML 서비스의 아키텍처를 변경하는 것이므로 "리프트 앤 시프트"가 아닙니다.