기록하고 성장하자

5 분 소요

주로 블로그에 올린 글의 거의 모든 글 유형이 기술에 대한 기술이었는데, 그 공부를 시작하게 된 이유, 어떠한 생각을 가졌는지 기록을 바로바로 해두는 것이 좋을 것 같아서 이렇게 기록을 해본다.

개요

  • 머신러닝, 딥러닝에 관심있고 관련 프로젝트 및 개발을 진행해본 입장에서 ML 프로젝트는 구현할 수 있는 경우의 수가 무수히 많다.
  • Data collection & preprocessing, Model training, testing 등 각 과정마다 선택해야 할 사항들이 많으며 기존에는 이를 단순히 local 환경의 파일에 직접 저장시키면서 디렉터리에 정리하여 진행했다.
  • 프로젝트의 규모가 작은 경우는 위의 방식이 좀 지저분한(?) 방식이더라도 사람이 관리할 수 있을 정도가 되었다.
  • 하지만 큰 규모의 프로젝트인 경우, (물론 아직 학생이라 기업 규모의 프로젝트는 아니고 연구실 대회 정도…) 정말 다양한 실험들을 진행했는데, 모델 관리, 하이퍼파라미터 관리, data관리를 위의 방식으로 진행했을 때 상당히 힘이 들었다.
    • 더 좋은 방법이 있었겠지만 당시에는 단순 무식하게 학습된 model의 파일명에 핵심 파라미터 사이즈를 기입하여 구분을 하였다..
      • ex) Roberta-16-2_1_1_1_1 …..
      • : Roberta모델인데 batch size는 16, 5-class data 학습 비율은 2:1:1:1:1… 이게 무슨 해괴망측한 방법이었는가….
      • 암튼 당시에는 급한 대로 그렇게 진행을 하였다.
  • MLOps라는 개념이 있다는 것을 안 지는 얼마 안 되었다.
    그리고 ML을 개발하는 입장에서 프로젝트의 규모가 점점 커지면서 이를 관리하려면 MLOps가 정말 필요하다는 것을 느꼈다.
  • 솔직히 당장의 혼자 진행하는 혹은 학부생 수준에서 진행하는 프로젝트 같은 경우 case by case이긴 하지만 일반적으로 MLOps를 관리할 정도로 크지는 않다.
  • 그리고 Service화를 위한 serving을 진행하는 것도 아니어서 지금 상황에서 굳이 필수적으로 요구되는 기술은 아닐 수도 있다.
  • MLOps 환경을 구축하여 진행하는 것이 오히려 computational cost가 훨씬 더 들 것이다.
    • 단순히 코드로만 구성해서 바로바로 실행했던 구조를 따로따로 요소로 나누어서 docker형태로 contained 한 후 진행하게 되기 때문이다.
    • (이 부분은 당장은 무슨 말인지 안 와닿아도 공부하다 보면 알게 될 것이다.)
  • 그럼에도 불구하고 내가 MLOps를 시작한 이유는 내 개발 인생이 학부생에서 끝나는 것이 아니기 때문이다.
  • 학부생 때 진행한 프로젝트들은 보통 일정 성능 타협점에 다다르면 결과를 시각화해서 보여주고 끝이 난다. 그야 대다수가 서비스 운영을 목적으로 하는 것이 아닌 학문을 탐구하고 구현하는 목적이기 때문이다. 물론 학부생 때 직접 서비스를 운영하는 훌륭하신 분들도 많으시다. 하지만 공대생들은 알다시피 학교 수업을 듣는 동시에 여러 프로젝트를 진행하는 것이 일반적이므로 그러기 쉽지 않다. 나 또한 그랬고(여전히… 그렇고..) 프로젝트뿐만 아니라 할게 넘쳐난다^^; 물론 이러한 생각은 나의 굉장히 주관적인 견해이며, 누군가에겐 핑계로 들릴 수도 있다. 하지만 나도 한 열심했다고 생각하……ㄴ다!! 공부하는 방향과 투자에 따라 경험의 차이가 존재하는 것 같다.
  • 구현한 모델은 이후 서비스화가 이뤄지지 않기 때문에 그리고 시간적, 컴퓨팅적 제약으로 보통 보완과 추후 관리가 이뤄지지 않는다.
  • 하지만 개발한 모델을 서비스화 해야 한다면 상황은 정말 달라진다.
    개발 당시 좋은 성능이 나왔다고 끝나지 않는다.
    당시 test 데이터로 성능이 좋게 나왔어도, 서비스로 serving 된 후 사용자들이 test로 사용하는 데이터는 성능이 좋지 않을 수도 있다.
    또한 모델을 개발하고 지속적인 성능 update, 새로운 class 추가 등 다양한 개선들이 필요할 것이다.
  • 위에서 말했듯이 내 개발 인생은 졸업하면 끝나는 것이 아니고 오히려 시작이기에 이를 공부해야겠다는 생각이 들었고, 또한 computational cost는 들더라도 여러 실험을 할 때 그리고 규모를 늘려갈 때 MLOps를 구축해보는 것이 지금 그리고 앞으로 내가 진행할 프로젝트에 사용해도 유용할 것이라고 생각을 했고 필요하다고 느꼈다.
  • 그래서 MLOps가 무엇인지 서칭하고 공부를 했다.

그래서 MLOPS가 뭔데??

MLOps는 다음과 같이 간단하게 정의될 수 있다.

  • ML 모델을 프로덕션으로 전환하는 프로세스를 간소화하고, 이를 유지 관리하고 모니터링을 하는데 주안점을 둔 머신러닝 엔지니어링의 핵심적 기능으로 ML과 DevOps의 어휘를 합쳐서 MLOps라고 부른다.
  • Engineer과 Reasearcher 사이의 CI/CD 그리고 CT까지 더하여 유용하게 하는 기술이다.
  • 더 자세한 설명은 구글이 정말 잘 알려준다.
  • 개인적으로 MLOps를 잘 설명하고 참조한 링크는 다음과 같다.
  • 그래 MLOps 뭔지 대략 알았어! 그래서 구현하려면 난 뭐부터 시작해야…?
  • 처음에 너무 막막했다. 왜 필요한지 알겠고 어떻게 쓰이는지 대략 알겠는데 그래서 뭐 부터 구현해야 하는 거야…?
  • 잘 모르겠어서 방향성을 잡기 위해 더 서칭 해보고 찾아보았다.
  • 일단 추가적으로 찾아보니 MLOps에도 Level 수준이라는 것이 존재했다.
    • Level 0~2까지 총 3개의 레벨로 규모와 CI/CD/CT의 여부, 서비스 배포 여부 등에 따라 나뉜다.
  • 내가 잘 못 찾은 것일 수도 있지만, 각 레벨에 대한 전체적으로 필요한 기능에 대한 구조는 나와 있지만, 뚜렷하게 자주 쓰이는 구조의 방식이 존재하는 것은 아니었다. (물론 따지고 보면 모든 분야가 그렇겠지만 다른 분야에 비해 상대적으로 정보가 적다고 개인적으로 느꼈다)
  • 또한 MLOps 관련 library와 tool들이 이렇게나 많다. 아래의 깃헙 링크에서 확인할 수 있다.
  • https://github.com/EthicalML/awesome-production-machine-learning
  • 그래서 많은 외국 블로그 글들에서 MLOps를 시작할 때 구현하고자 하는 목적과 방향성을 먼저 잡아야 한다고 이야기를 많이 한다.
  • 뭐 이 말도 어느 분야에서나 마찬가지라서 당연한 소리 하고 있다고 할 수 있지만 상대적으로 다른 분야들보다 따라 해 볼 자료가 적기에, 내게는 좀 더 와닿았다.
  • 즉 다시 말하자면, MLOps를 만드는 이유와 목적에 따라 규모가 다르게 설정되고 구현하는 범위도 달라진다.
  • 예를 들어 설명하자면, 앞서 MLOps를 공부한 이유에서 언급한 하나로 서비스를 운영하고 serving에 힘을 쓰게 된다면 service 배포까지의 flow를 구축하는 것이 구현될 수도 있고 구현되지 않을 수도 있다.
    보통 service를 하는 기업의 입장에서는 필수적이다.
    하지만 research 성향을 주로 띄고 있는 당장의 나 같은 경우는 service를 serving 하는 목적보다 모델을 관리하고 반복적인 flow를 줄이는 프로젝트 규모 관리가 주요 목적이 된다.
  • MLOps는 공부해야 하는 범위와 규모가 너무 커서 당장에 모든 것을 구현하는 것은 어렵다.
  • 그래서 나는 그중 파이프라인 구축을 중점을 두어서 여러 실험을 체계적으로 진행하고 모델 관리를 용이하는 것을 주목적을 잡고 공부하고 구현하는 것을 우선순위로 잡게 되었다.
  • 목적과 구축 이유를 잡았으니 어떠한 tool을 사용해서 구현할지 정하고, 해당 tool을 공부해야 한다.
  • “파이프라인 구축” 이것이 당장 우선 시 되어야 하는 과제이고 나는 파이프라인을 구축하는데 Kubeflow를 선택하였다.

Why kubeflow?

  • 그 많은 MLOps tool 중에서 Kubeflow를 고른 이유는 다음과 같다.
  • 다른 tools와 세부적인 비교는 직접 해보지 않아서 제일 적합한 선택이 아닐 수도 있다.
    하지만 내 상황에서는 제일 적합한 선택이라고 생각한다.
    • Kubernetes를 사용하고 싶었다.
      • DevOps에서 거의 모든 서비스가 docker 형태로 container화 되어 container들을 관리하는 식으로 구축이 된다.
        Container을 관리하는 대표적으로 인기 있고 실제로 많이 쓰는 tool은 google에서 만든 Kubernetes (K8s)이다.
        이러한 Kubernetes 기반으로 구현되는 MLOps tool이 Kubeflow이다.
        Kubernetes에 대해서 공부해보고 싶었고, 실제로 많이 사용되는 만큼 Kubernetes에서 운영되는 Kubeflow가 호환성이 좋다고 생각했다.
    • Tasks를 정의하는데 YAML대신 python으로도 정의할 수 있다.
      • MLOps를 처음 공부하는데 좀 더 익숙한 python으로 구현해보는 것이 좋다고 생각했다.
    • Google에서 만든 만큼 공식 Document가 자세히 나와 있고 다른 tool보다 상대적으로 자료가 많았다.
  • Kubeflow에 대해서 다른 MLOps tool과 비교했을 때 좋지 않다는 관점도 존재한다.
  • 하지만 제한된 시간에 공부하고 구현하는 데 위와 같은 이유에 따라 Kubeflow를 구현하는데 사용하기로 결정했다.
  • Kubeflow를 사용하는 것은 맞는데 나는 Kubeflow의 다양한 기능들을 모두 적극 활용하는 것은 아니다.
  • 오직 파이프라인 구축에만 Kubeflow을 사용하는 것이다. 파이프라인 뼈대를 구축하는데 Kubeflow components 중 Kubeflow-pipeline components만 사용할 것이다.
  • Hyperparameter관리, 모델 관리 등은 다른 tool을 사용할 것 같다.

[참조]

https://databricks.com/kr/glossary/mlops

댓글남기기

참고