[번역] 데이터 과학자들은 쿠버네티스에 관심이 없습니다 - MLOps

이 글은 다음 포스트를 읽고 공감하여 소개하고자 번역하였습니다. 머신러닝에서 쿠버네티스를 이용하면 효율적으로 모델을 학습 시킬 수 있습니다. 문제는 데이터 과학자들이 직접 쿠버네티스를 사용하기 불편하다는 점이 있습니다. 그 문제를 어떻게 해결하면 좋을까요?

쿠버네티스는 지난 몇 십년간 나온 제품들 중 가장 중요한 소프트웨어이자 영향력있는 오픈소스입니다. 쿠버네티스는 어플리케이션이 어떻게 개발되고 운영환경에 배포가 되어야 하는지에 대해 혁신적인 변화를 이끌어 냈습니다. 쿠버네티스의 폭발적인 성장으로 더 많은 하드웨어가 쿠버네티스에 의해 관리됩니다. 이 흐름은 딥러닝의 인기에 맞물려 같이 성장하고 있습니다. 딥러닝은 엄청 나게 많은 컴퓨팅 연산이 필요로 하는 기술로 데이터 과학자 한명이 여러 GPU 머신을 오랜 기간동안 차지합니다. 이러한 특징으로 인해 다음과 같은 개발 방법론들이 나타나기 시작했습니다.

쿠버네티스에 의해 머신러닝 하드웨어들이 관리되는 도구의 출현

이로인해 데이터 과학자들이 더 많은 하드웨어를 손쉽게 접근할 수 있기에 훌륭한 방법입니다. 단지 한가지 문제가 있습니다.

이러한 툴들은 데이터 과학자로 하여금 쿠버네티스를 이해 해야지만 사용할 수 있게 만들어졌습니다.

비슷하게 들릴지 모르지만 그렇지 않습니다. 더 많은 하드웨어에 접근할 수 있게 하는 것은 좋지만 반드시 쿠버네티스를 이해 해야지만 사용할 수 있게 만드는 것은 좋지 못합니다. 쿠버네티스는 개발자들에 의해, 개발자들을 위해 만들어졌습니다.

당신이 만약 유니콘이라면 축하드립니다! 당신의 능력으로 쿠버네티스와 딥러닝 기술을 합쳐서 멋진 무언가를 만드시길 바랍니다. 그 외 다른 사람들은 (대부분의 사람들이 여기에 해당 되죠.) ML 모델을 개발하지도 전에 컴퓨터 공학 스킬을 배워야 한다는 사실에 꽤나 귀찮아할 수 있습니다. 하지만 다행인 것은 이러한 문제를 해결할 수 있다는 점입니다. 단지 분석 도구들을 개발자들을 위해서 만드는 것이 아니라 데이터 과학자들을 위해 만들면 됩니다.

ML 도구들의 문제

Kubeflow를 한번 살펴 보면서 현재의 데이터 분석 툴들이 개발자를 위해 만들어졌다는 저의 주장에 대해서 어떤 의미인지 확인해 봅시다. Kubeflow는 구글 내부적으로 텐서플로우 모델을 어떻게 쿠버네티스 위에 적용시킬지 고민하면서 시작하게 된 프로젝트입니다. 이 기술은 쿠버네티스를 통해 딥러닝 모델을 관리하기에 굉장히 강력하고 간단한 방법을 제공하였습니다.

Kubeflow의 초기 모습은 현재 Kubeflow의 컴포넌트인 TFJob으로부터 시작하였습니다. TFJob 없이 텐서플로우 모델을 쿠버네티스 위에 운영하는 것은 매우 고통스러웠습니다. ML 코드를 실행하기도 전에 컨테이너 간의 종속성, 네트워킹, 스토리지 등을 정의하느라 시간을 낭비했어야 합니다. 반면에 TFJob을 사용하면 이러한 일들이 단순화 되었습니다. 그럼에도 불구하고 사실 TFJob을 사용하는 것은 모두에게 충분히 간단한 작업은 아닙니다.(not nearly simple enough) TFJob을 사용하려면:

• ML 코드를 컨테이너에 넣어야 합니다. 분석가가 매번 직접 자신의 코드를 패키징하여 원격 저장소에 이미지를 업로드해야 합니다. 도커는 굉장하지만 분석 업무를 하는 과정을 느리게 만듭니다.
• 직접 쿠버네티스 TFJob 정의서를 작성해야 합니다. 이것은 개발자에게는 그리 어려운 작업이 아닐 수도 있지만 쿠버네티스를 잘 알지 못하는 데이터 과학자 입장에서는 굉장히 부담스러운 작업일 수 있습니다. TFJob을 잘 작성하려면 쿠버네티스에 대해 굉장히 많이 알아야 합니다. Kubeflow 문서에서 제공하는 가장 간단한 TFJob을 한번 살펴 봅시다.

apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
  generateName: tfjob
  namespace: your-user-namespace
spec:
  tfReplicaSpecs:
    PS:
      replicas: 1
      restartPolicy: OnFailure
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
        spec:
          containers:
          - name: tensorflow
            image: gcr.io/your-project/your-image
            command:
              - python
              - -m
              - trainer.task
              - --batch_size=32
              - --training_steps=1000
    Worker:
      replicas: 3
      restartPolicy: OnFailure
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
        spec:
          containers:
          - name: tensorflow
            image: gcr.io/your-project/your-image
            command:
              - python
              - -m
              - trainer.task
              - --batch_size=32
              - --training_steps=1000

보시다시피 이 TFJob 파일은 데이터 과학자가 보기에는 이해하기 어려운 설정값들이 정의되어 있습니다. Pods, replicas, sidecards, restart 정책, 쿠버네티스 API - 이 모든 것이 헷갈리고 복잡하여 분석에 집중하지 못하게 만듭니다. 쿠버네티스 CLI (kubectl)를 배우면 되지만 쿠버네티스의 모든 기능들을 제대로 이해하는 것은 쉽지 않습니다. 쿠버네티스 Job을 하나 실행시키는 것은 비교적 간단할지 몰라도 실행된 로그 기록을 확인하고 모델링 결과를 얻는 것은 비직관적이고 불편합니다.

다시 한번 이런 불편한 일들이 생기는 이유에 대해서 생각해 봅시다. 이 기술은 구글이 딥러닝 모델을 학습 시키기 위해 도입한 것입니다. 현실과는 다르게 대부분이 유니콘인 사람들로 이루어져있죠. 이들에게는 쿠버네티스 위에 모델을 학습 시키는 일은 그리 어렵지 않습니다. 구글에게 최선의 선택이 나머지 사람들에게도 최선이 아닐 수 있습니다. 저는 실력 좋은 많은 데이터 분석가들일 Kubeflow를 사용하기 꺼려하는 것을 개인적으로 많이 봐왔습니다.

Kubeflow의 다른 컴포넌트들을 살펴 보면 비슷한 철학을 가진 것을 확인할 수 있습니다: MPIJob, PyTorchJob, Katib 이 모든 것들이 데이터 과학자들이 쿠버네티스 컨셉을 이해하고 있다고 가정합니다. 이 모든 것들이 동일하게 불편한 사용성 이슈가 있습니다. - 대부분의 데이터 과학자들은 쿠버네티스의 복잡한 개념에 깊이 빠져들고 싶어하지 않습니다. 단지 간단하게 모델을 학습 시키길 원하죠. 그들은 추상화된 툴을 이용하여 간편하게 자신들의 ML 모델을 개발하길 원합니다.

좋은 데이터 분석 툴의 모습

머신러닝은 굉장한 인기를 구가하고 있으며 그에 따라 다양한 분석 툴들도 만들어지고 있습니다. 당신이 상상할 수 있는 모든 툴들이 나오고 있습니다. 데이터 버저닝 툴, 모델 실험 트래킹 툴, 모델 서빙툴 그리고 쿠버네티스 위에서 ML를 실행 시킬 수 있는 툴도 나왔죠. 하지만 이 분야는 여전히 아직 초기 단계입니다. 물론 특정 툴이 다른 툴보다 더 선호되고 있긴하지만 아직까지 절대적 강자가 나오지 않았습니다.

데이터 분석 툴을 평정하는 제품이 나온다면 어떤 모습일까요?

• ML 툴은 데이터 과학자로 하여금 더 적은 일을 하고도 더 많은 일을 달성할 수 있게 만들어져야 합니다. 이를 가능케하기 위해서는 데이터 과학자로부터 엔지니어링 부분을 분리하여 본연의 모델링 일을 할 수 있도록 환경을 제공해줘야 합니다.
• 시스템 전문가가 아니더라도 복잡한 현대 인프라에서 높은 퍼포먼스를 낼 수 있도록 추상화된 툴을 제공해야 합니다. 이것은 쉽지는 않겠지만 더 편리하고 비용 효율적으로 모델을 개발하기 위해서는 반드시 필요한 일입니다.
• 대부분의 데이터 과학자들은 유니콘이 아닙니다. 그렇기 때문에 데이터 과학자들이 DevOps 전문가가 되어 직접 모델을 빌드하고 운영 환경에 배포할 수 있다는 생각을 버려야 합니다. 현재도 데이터 과학자들이 직접 이런 수고를 들이지 않고도 운영 배포할 수 있게 해주는 툴들이 많이 나와 있습니다.

이러한 이야기들은 결론적으로 다음과 같은 사실을 얘기하고 싶어 길게 늘여서 설명한 것입니다. 바로 최고의 소프트웨어는 최고의 UX를 가지고 있다는 것입니다. 한가지 더 얘기하고 싶은 것은, 소프트웨어의 최종 유저가 누군지를 실제로 이해하는 것이 중요하다고 말씀 드립니다. 데이터 과학자들이 현재의 워크플로우에서 어떤 점을 좋아하고 어떤 점을 싫어하는지 명확하게 구분하여 좋아하는 점은 강화시키고 싫어하는 부분은 떼어내야 합니다.

Determined AI에서의 방법

역자 주: 마지막 부분은 해당 블로그를 포스팅한 Determined AI라는 회사의 제품을 소개하는 내용이라 간단하게 설명합니다.

Determined AI에서 제안하는 해결책은 다음과 같습니다. 아래의 설정파일을 보면 알 수 있듯이 TFJob처럼 복잡한 쿠버네티스 설정값들을 전부 제거하고 모델링에 꼭 필요한 설정값들만 남아있는 것을 확인할 수 있습니다. 이로써 데이터 과학자들은 쿠버네티스의 세부 설정들에 대해서는 신경을 쓰지 않고도 쿠버네티스의 이점인 체계적인 하드웨어 관리를 학습에서 사용할 수 있게 되었습니다. (The big difference is that this configuration is written in the language of data scientists, with complicated infrastructure concepts abstracted away)

# 기계학습에 필요한 설정값만 노출
description: cifar10_pytorch
hyperparameters:
  learning_rate: 1e-4
  learning_rate_decay: 1e-6
  layer1_dropout: 0.25
  layer2_dropout: 0.25
  layer3_dropout: 0.5
  global_batch_size: 32
records_per_epoch: 50000
searcher:
  name: single
  metric: validation_error
  max_length:
    epochs: 32
entrypoint: model_def:CIFARTrial

마치며

Determined AI에서 제시하는 해결책은 제가 생각하는 방법과 비교하여 추상화를 통해 데이터 과학자들이 직접 쿠버네티스를 조작하지 않고도 편리하게 머신러닝을 수행할 수 있는 방법이 필요하다는 점에서는 유사하나 구체적인 해결책으로 조금 다른 점이 있습니다. 다음 포스트에서는 제가 생각하는 해결 방법에 대해서 소개해 보고자 합니다.