top of page

kubeflow만 있으면 충분? cnvrg.io를 통해 살펴본 End-To-End MLOps 플랫폼의 필요 충분 조건

kubeflow를 이용해 머신 러닝 파이프라인을 구축하는 것이 요즘 입니다. kubeflow는 머신 러닝 워크플로우를 쿠버네티스(kubernetes) 환경에 배포하는 작업을 간소화합니다. 간단히 말해 컨테이너 환경에서 머신 러닝 모델 배포 자동화를 지원하는 도구가 바로 kubeflow입니다. 이 툴은 손쉽고, 반복할 수 있고, 호환성 걱정 없이 모델을 다양한 인프라 상에 배포하는 것을 목표로 개발되었습니다. 온프레미스, 공용 클라우드, 멀티 클라우드 등 자원 위치에 관계없이 모델 개발, 빌드, 트레이닝, 배포할 수 있는 환경을 지향한다고 보면 됩니다.

그렇다면 kubeflow만 있으면 충분할까요? 머신 러닝 워크플로우 구간을 어디까지 보느냐에 따라 반은 맞고 반은 틀립니다. 머신 러닝과 딥러닝 워크플로우는 지속적 통합, 지속적 배포, 지속적 학습으로 전체 구간을 구분할 수 있습니다. 이 모든 구간을 지원하는 것이 End-to-End 측면에서 MLOps를 실행하는 것입니다. kubeflow의 경우 지속적 통합과 지속적 배포 구간을 위한 도구입니다. 가령 Jypyter 노트북을 이용해 모델을 만들고, 파이썬 코드로 설정 내용을 만들어 YAML 파일로 컴파일하고, 쿠버네티스 API 서버를 호출해 필요한 자원을 생성하고, 오케스트레이션 컨트롤러로 컨테이너를 실행해 모델을 트레이닝하고, 파라미터를 튜닝하고, 트레이닝을 마친 모델을 배포하는 것까지를 kubeflow가 지원하는 파이프라인 구간으로 볼 수 있습니다. 이 정도만 자동화 해도 머신 러닝 모델 개발, 빌드, 배포 관련 작업 생산성과 효율성은 매우 높아집니다. 그렇다면 구간을 더 확대하여 자동화를 적용한다면 어떨까요? 네, 생산성과 효율성은 더 커집니다.


출처: kubeflow.org


MLOps 전 구간을 파이프라인으로 이으려면 지속적 트레이닝까지 고려해야 합니다. DevOps에서 지속적 통합과 지속적 배포의 출발점은 코드입니다. 반면에 지속적 트레이닝을 포괄하는 MLOps 워크플로우 자동화를 하려면 데이터 파이프라인까지 고려해야 합니다. 데이터 저장소와 단순 연결을 넘어 다양한 데이터 소스를 대상으로 추출, 변환, 트레이닝 및 미세 조정 등의 데이터 처리가 가능해야 합니다. 특히 모델 트레이닝 재현성을 높일 수 있는 데이터 파이프라인을 갖추어야 합니다. 여기에 한 가지 더하자면 모델 성능을 지속해서 평가하고 추적할 수 있는 모니터링도 중요하게 봐야 합니다. 즉, 지속적 통합, 지속적 배포, 지속적 트레이닝 전 구간을 End-to-End로 연결하는 자동화 기반 워크플로우를 만들려면 kubeflow의 파이프라인을 수용할 수 있는 더 포괄적인 MLOps 플랫폼이 필요합니다.


convrg.io의 존재 이유


convrg.io는 MLOps 플랫폼이 갖추어야 할 요소를 두루 제공합니다. 한 번의 클릭으로 모델을 배포할 수 있는 편의성은 기본입니다. 실시간 모델 모니터링, 팀 간 협업, 지속적인 학습, 데이터 관리, 버전 관리, 손쉬운 자원 관리 및 모니터링 등의 기능을 제공합니다. AI 프로젝트의 생산성에 큰 영향을 끼치는 모델 재현성을 자동화 기반 워크플로우로 구현할 수 있습니다. 앞서 언급한 코드 수준의 지속적 통합과 배포뿐 아니라 데이터 측면의 지속적 트레이닝까지 충실히 기능을 지원하기 때문에 가능한 일입니다.


툴 체인만 봐도 구간의 차이 느껴져


MLOps 구간의 차이는 툴 체인을 봐도 알 수 있습니다. kubeflow에 통합된 툴은 Kunernetes, TensorFlow, Jupyter, Pipelines 등입니다. 반면에 cnvrg.io에는 Python, MySQL, PostgreSQL, Kafka, Kunernetes 등 통합된 솔루션이 더 광범위합니다. 물론 cnvrg.io는 kubeflow, Github, SageMaker 등 다양한 도구와 연계성도 뛰어납니다. 전체 End-to-End 구간을 커버하는 MLOps에 다양한 도구를 연계하는 시나리오 몇 가지를 살펴보겠습니다.


예제 1: NVIDIA 딥러닝 컨테이너 배포를 통한 트레이닝

데이터 과학자 또는 개발자는 AWS S3 오브젝트 스토리지에 저장한 데이터를 로드합니다. 그리고 TensorFlow, PyTorch 딥러닝 컨테이너를 배포한 다음 로드한 데이터 세트로 트레이닝을 합니다. 컨테이너 이미지는 NGC를 이용하면 간단히 가져올 수 있습니다. 트레이닝을 거친 후 챔피언 모델을 선정해 프로덕션 환경에 배포합니다.


예제 2: Github pull request를 이용하는 방법

이번 예제는 깃허브 pull request를 이용한 것입니다. 워크플로우를 다음과 같이 생성합니다. 먼저 PostgreSQL에서 데이터를 가져옵니다. 쿠버네티스 환경에 올린 아파치 스파크를 이용해 데이터 처리 파이프라인을 돌립니다. 파라미터 최적화를 거듭하며 여러 모델을 트레이닝합니다. 결과를 비교한 다음 가장 높은 성능을 보인 모델을 골라 깃허브 pull request로 엽니다.



예제 3: 수백 개의 모델을 대시보드 상에서 비교하기

수백 개의 모델을 추적하는 것은 말만 들어도 숨이 가쁩니다. cnvrg.io를 이용하면 자동으로 모든 머신 러닝 모델을 실시간으로 추적할 수 있습니다. 개발 단계부터 프로덕션 환경까지 포괄하여 모델을 한눈에 비교하는 것이 가능합니다.



예제 4: A/B 테스팅하기

지속적인 배포 흐름 속에서 새로운 데이터 스냅숏을 반영하는 머신 러닝 모델을 트레이닝할 경우 cnvrg.io의 롤아웃 기능(Canary rollout)을 이용해 일종의 A/B 테스트를 할 수 있습니다. 이 방식은 챔피언과 챌린저를 가려내는 메커니즘을 이용하는 것으로 자동으로 라우팅, 유효성 검사 등이 수행됩니다. 안전한 배포를 위한 롤백 옵션도 제공합니다.



예제 5: SageMaker를 이용한 배포

아래 워크플로우는 PostgreSQL에서 데이터를 읽어 오는 데이터 파이프라인을 따릅니다. 날씨나 휴일 같은 외부 데이터까지 활용하여 두 개의 모델을 트레이닝하는 시나리오인데요, 최고의 성능을 보인 모델을 선택해 이를 SageMaker를 이용해 프로덕션 환경에 배포하는 워크플로우입니다.



예제 6: 쿠버네티스 기반의 추천 시스템 구축하기

다음 예는 멀티 클라우드를 이용하는 것입니다. 데이터는 AWS S3에 저장되어 있습니다. 이를 가져와 분석을 위한 처리 작업을 하는 것은 구글 클라우드의 BigGuery와 사설 또는 공용 클라우드에 구축한 쿠버네티스 상의 아파치 스파크 환경입니다. TensorFlow Ranking/XGBoost를 사용해 추천 모델과 시스템을 구축하고 이를 REST API를 이용해 쿠버네티스 환경에 배포하는 워크플로우입니다.



예제 7: 단일 대시보드에서 자원 활용 현황 파악하기

이번 예제는 MLOps를 자원 관리 측면에서 활용하는 것입니다. MLOps 환경이 잘 구축되면 GPU, CPU 같은 자원을 단일 대시보드 상에서 모니터링할 수 있습니다. 이를 통해 머신 러닝 워크로드 단위의 자원 활용률을 정밀하게 추적하고 조정할 수 있습니다.



예제 8: 얼럿과 재트레이닝 관련 알림을 관리자에게 제공

이번에 살펴볼 MLOps 워크플로우는 관리자 측면에서의 자동화 예입니다. cnvrg.io를 이용해 쿠버네티스 환경을 모니터링하면 모델 트레이닝 관련 이상 상황을 탐지하고, 데이터 상관관계를 편리하게 파악할 수 있습니다. 이상 징후가 탐지되면 관련해 재교육 등의 얼럿이 관리자에게 전달됩니다.



예제 9: 한 번의 클릭으로 OpenMPI 잡 런칭하기

온프레미스와 공용 클라우드가 혼재된 멀티 노드 쿠버네티스 클러스터 환경에서 클릭 한 번으로 OpenMPI 잡을 런칭할 수 있습니다. cnvrg.io에 포함된 kubeflow MPI 오퍼레이터를 이용하면 분산 클러스터 환경에 배포된 Horvord/TensorFlow 트레이닝이 작업 관련 성능이 실시간으로 추적됩니다.



MIG 지원으로 더 진보된 하드웨어 자원 최적화를 지원하는 MLOps 플랫폼 탄생


MLOps 플랫폼과 kubeflow의 또 다다른 차이점으로 하드웨어 자원에 대한 통제력이 있습니다. kubeflow는 인프라를 코드로 바라보고 다룹니다. 물리적 자원을 직접 제어하는 방식이 아닙니다. cnvrg.io 역시 추상화된 하드웨어 자원을 활용할 뿐 아니라 NVIDIA DGX A100이 지원하는 멀티 인스턴스(MIG) 기능을 통해 하드웨어 수준의 자원 최적화까지 지원합니다. DGX A100은 NVIDIA A100 Tensor Core GPU를 장착한 최신 시스템입니다. DGX A100에서 많은 이들이 주목하는 기능 중 하나로 MIG를 꼽습니다. MIG는 모델 개발, 트레이닝, 인퍼런싱 등 다양한 단계에 있는 프로젝트를 각각 독립적인 하드웨어 자원을 제공하는 인스턴스 상에서 운영할 수 있도록 돕습니다. 이 기능을 이용하면 고가의 GPU 자원 활용률(Utilization)을 극대화할 수 있습니다. 또한, 데이터 과학자, 개발자 등 GPU 자원을 이용해 인공 지능 관련 프로젝트를 추진 중인 담당자들은 자신만을 위한 독립 시스템 운영의 편의성을 누릴 수 있습니다. cnvrg.io는 MLOps 플랫폼 중 처음으로 MIG를 지원합니다.



활용 시나리오를 볼까요. A100 GPU 한 개는 다양한 자원 조합으로 쪼개어 쓸 수 있습니다. 가령 20GB 메모리를 할당한 MIG 인스턴스 2개로 구분하거나, 10GB 메모리의 인스턴스 3개로 나누거나, 5GB 메모리 용량의 인스턴스 7개로 만들 수 있습니다. 자원이 많이 필요한 트레이닝 워크로드 위주로 돌린다면 메모리 할당을 늘려 인스턴스 수를 조금만 잡으면 되고, 자원이 그다지 많지 않아도 되는 인퍼런스 작업이 많다면 최대치인 7개로 나누는 것처럼 워크로드의 자원 요구에 맞춰 인스턴스에 자원을 할당하면 됩니다. MIG를 이용하면 200가지에 달하는 자원 조합으로 인스턴스를 구성할 수 있습니다. 이렇게 사용하면 한 대의 DGX A100은 작은 데이터센터가 됩니다. MLOps 측면에서 보면 MIG 사용은 양날의 칼과 같습니다. 리소스 할당, 예약, 공유, 모니터링이 전제되지 않으면 너무 높은 복잡성이 문제가 될 수 있기 때문입니다. 이런 이유로 cnvrg.io는 MLOps 플랫폼에 MIG 기능을 통합하였습니다. 셀프서비스 환경에서 데이터 과학자, 개발자가 편리하게 리소스를 이용하고 인프라 관리자는 평소와 같이 리소스 할당, 예약, 공유, 모니터링을 할 수 있게 하기 위해서입니다.

cnvrg.io의 MLOps 플랫폼을 이용하면 한 번의 클릭으로 MIG 인스턴스를 사용할 수 있습니다. 데이터 과학자는 다른 컴퓨팅 리소스를 쓸 때와 같이 사전에 선별된 템플릿 메뉴에서 MIG 리소스를 워크로드에 할당할 수 있습니다. 이렇게 마련한 독립적인 인스턴스 환경에 NVIDIA NGC에서 필요한 소프트웨어, 프레임워크, 라이브러리 등을 담은 컨테이너를 불러와 사용하면 됩니다.

cnvrg.io의 MLOps 플랫폼은 백그라운드에서 메타 스케줄러를 이용해 MIG 인스턴스를 예약하고, 작업이 완료되면 다시 MIG 인스턴스 풀로 자원을 반환합니다. 사용자가 일일이 신경 쓸 필요가 없습니다. MIG 인스턴스 자원 풀은 지속적으로 모니터링되는 가운데 할당과 반환이 이루어집니다. 이에 따라 이상적인 MLOps, DevOps 환경을 위한 자원 관리가 가능합니다.

참고로 MIG 템플릿은 사용자 편의에 맞게 만들 수 있습니다. cnvrg.io의 MLOps 플랫폼은 사용자 친화적인 GUI, CLI, Python SDK를 제공합니다. 따라서 편한 방식으로 템플릿을 작성하면 됩니다. 이렇게 만든 템플릿은 cnvrg.io 메타 스케줄러가 관리하는 MIG 자원 풀의 일부가 됩니다. 다른 머신 러닝 리소스와 마찬가지로 MIG 자원 풀은 물리적으로 위치가 다른 DGX A100 서버나 다른 데이터센터 내에 있는 시스템의 것이 될 수 있습니다.


cnvrg.io의 MLOps 플랫폼을 이용해 머신 러닝 파이프라인 설계를 해봤다면, 아주 쉽게 파이프라인에 맞게 MIG 인스턴스를 할당할 수 있습니다. 이때 사용자는 가용성, 우선순위 같은 기준에 따라 인스턴스를 유연하게 할당할 수 있습니다. 모든 MIG 인스턴스가 사용 중일 경우 클라우드 사업자가 제공하는 NVIDIA V100 GPU 인스턴스를 이용할 수도 있습니다. 자원이 없어 프로젝트 진행에 차질이 생기는 일이 없겠죠.

MIG 인스턴스 할당은 다음과 같이 이루어집니다. 이 예는 데이터 준비 작업을 위한 Spark 워크로드를 전체 GPU로 할당하고, 18개의 TensorFlow 트레이닝 워크로드는 총 18개의 인스턴스(1g.5GB A100 MIG)로 할당하는 것을 보여 줍니다. 데이터 과학자 입장에서 보면 트레이닝, 분석, 인퍼런싱을 동시에 여러 독립적인 인스턴스를 이용해 처리할 수 있게 됩니다.


인프라 관리자에게 자원 모니터링과 사용률 추적 및 리포팅 기능은 매우 중요합니다. cnvrg.io의 MLOps 플랫폼은 MIG 통합 덕에 풍부한 대시보드 상에서 MIG 자원 풀 이용 현황에 대한 통찰력을 확보할 수 있습니다. 현재 조직에서 이용 중인 A100 GPU의 MIG 인스턴스를 혼선 없이 추적할 수 있으며, 각각에 대한 할당 내용 및 가용성 등도 대시보드를 통해 직관적으로 파악할 수 있습니다.

이상으로 A100 GPU의 MIG 기능을 MLOps 또는 DevOps 플랫폼에서 이용하는 쉽고 편리한 방법을 알아보았습니다. 더 자세한 내용은 유클릭으로 문의 바랍니다.




조회수 1,050회댓글 0개
bottom of page