현직 MLOps Engineer의 쿠버네티스(Kubernetes) 간단한 고찰

현재 MLOps Engineer로 2년간 업무를 진행하고 있습니다.
업무를 위해서 무식하게 부딪혀서 Kubernetes에 꽤나 능숙해졌는데..
매일 부딪히는 이 친구를 글로써 간단히 정리해보고 싶어 글을 씁니다.

 

Kubernetes란

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 지원 그리고 도구들은 광범위하게 제공된다. (쿠버네티스 공식 페이지)

간단하게 말해서 쿠버네티스는 컨테이너를 좀 더 잘 관리하게 위해서 사용되는 프레임워크입니다.

어플리케이션 배포 관점에서 봤을 때, 자동화된 컨테이너 조정 기능을 제공하기 때문에, 시스템의 안정성을 높이고 일상적인 운영 작업에 들어가는 시간과 리소스를 절약할 수 있습니다. 
여기서 자동화란 애플리케이션이 다운된다고 하더라도 쿠버네티스에서 자동적으로 이를 감지하고, 이미지를 통해서 기존과 똑같은 컨테이너를 띄울 수 있다는 것입니다.

어플리케이션의 구조가 복잡하면 복잡할수록 이런 관리적 요소들이 늘어나기 때문에 이를 간단히 처리하기 위해서 쿠버네티스를 사용합니다.

 

그럼 MLOps 에서 Kubernetes를 사용하는 이유는?

자원 관리

모델을 훈련하는데 가장 중요한 것 중 하나는 GPU입니다.
Kubernetes에서는 이런 컴퓨터 리소스 관리를 쉽게할 수 있습니다.
GPU 자원은 비싸고 한정적이기 때문에 적재적소에 이 자원을 이용하기 위해서 쿠버네티스를 사용하게 됩니다.

이에 더해서 만약 하나의 노드의 GPU가 8인데, 훈련 시 GPU가 16이 필요하다면 노드 간에 GPU를 공유해서 훈련하도록 설정할 수도 있습니다.

모델 크기가 작은 경우에는 하나의 GPU를 점유하는 것도 아까워서 Nvidia에서는 MIG 기능을 통해서 1개의 GPU를 최대 7개로 나누어서 사용할 수 있는 기능도 제공합니다. (그만큼 GPU는 소중해요)

 

재현성

ML모델 개발 시, 훈련 코드를 일관되게 재현할 수 있어야 합니다.
이건 사실 컨테이너를 사용하는 이유이기는 한데.. 최적의 파라미터를 찾았을 때, 그때의 모델을 재현할 수 있어야 합니다.

이런 요소를 무시한다면 최적의 모델의 파라미터가 소실되거나 그 때의 설치된 패키지 버전에 문제가 생겨 모델 훈련이 원활히 이루어지지 않을 수 있습니다.

 

안정성

Kubernetes는 내장된 장애 허용 기능과 자가 복구 기능이 있어서 ML 파이프라인을 안정적으로 유지할 수 있습니다.
이는 모델 배포 시에 가장 크게 두각을 드러내는데, 요즘 모델들은 크기 때문에 다운로드 및 로딩에만 대략 1시간 정도 소요됩니다.
만약 우리가 chat-gpt같은 서비스를 제공하는데, 배포가 죽어서 1시간동안 서비스를 못한다? 끔찍합니다..

그렇기 때문에 안정성이 중요하고, Kubernetes에서는 LoadBalancer, Service, Deployment 등의 리소스를 통해서 트래픽을 분산하고, 이를 통해서 안정성을 구현할 수 있습니다.
뭐.. Pod를 10개 띄우면 그게 다.. 죽을 확률은 적을테니까요.

 

자동화와 파이프라인 관리

ML의 라이프사이클은 여러 단계로 나뉘어져 있습니다.
모델 훈련, 배포, 운영 등 복잡한 워크플로우를 쉽게 관리할 수 있습니다. 
결국 ML과 관련된 모든 프로세스를 Kubernetes 안에서 할 수 있다는 말입니다.

구글에서는 MLOps 플랫폼의 성숙도에 따라서 3단계로 구별하고 있습니다.
https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning?hl=ko

그 중 가장 성숙도가 높은 2단계를 보면 모델 훈련 및 테스트, 배포를 자동화했고, 성능 모니터링도 구성한 것을 볼 수 있습니다.
사실 이 정도까지 구현하는 것은 굉장히 까다로운데, 이를 통해서 좋은 모델을 만들 수 있는 기반이 될 수 있습니다.

 

이러한 장점들을 통해서 모델 개발자들은 모델 개발에 좀 더 신경쓸 수 있고, 인프라를 담당하는 사람들은 좀 더 안정적인 서빙 환경을 관리할 수 있도록 합니다.

하지만 단점도 있는데요. 그건 러닝레이트가 높다는 것입니다.. 비교적 최신 기술이기 때문에 이에 능숙한 사람이 별로 없고, 그래서 오픈소스뒤져보면서 열심히 부딪혀봐야합니다.
또한 구조가 복잡한 편인데, 누군가는 이를 인셉션이라고 합니다. 클러스터 내에 네트워크가 있고, Pod 내에서도 네트워크 연결이 있고, 그리고 클러스터 간에도 네트워크가 있고... 이런... 
하지만 이렇기 때문에 무언가를 구현했을 때, 정복감(?)이 드는 매력도 있는 것 같습니다. ^^

 

쿠버네티스 구조, Kserve, Istio, Cloud Native 등 쓰고싶은 말은 많은데 더 길어질까봐...
다음에 또 써보도록 하겠습니다 🏃‍♂️‍➡️