Released at Deview 2021 - Spotlight Program, 2021.11.25

1. Makinarocks
MLOps 플랫폼을 만드는 과정의
고민과 해결 사례 공유 (feat. Kubeflow)
Deview 2021 - Spotlight Program

2. 세션 중 채팅으로
혹은 세션 후반부 Q&A 시간에
질문해주시는 분께는
Naver Deview 측에서 기념품을 드립니다!

3. CONTENTS
1. 마키나락스의 MLOps 플랫폼 팀 소개
2. 고민 1) Kubeflow Pipeline 와 HPO 의 연결
3. 고민 2) HPO 가 끝난 이후
4. 마치며

4. 1. 마키나락스의 MLOps 플랫폼 팀

5. 1.1 마키나락스

6. 1.2 MLOps 플랫폼 팀의 탄생 배경
MLOps Platform in Makinarocks ?

7. 1.2 MLOps 플랫폼 팀의 탄생 배경

8. 1.2 MLOps 플랫폼 팀의 탄생 배경

9. 1.3 어떤 분들에게 도움이 될 이야기인지
MLOps 의 정의가 궁금해요
MLOps 의 구성요소가 궁금해요
Kubernetes 를 잘 모르고 있어요

10. 1.3 어떤 분들에게 도움이 될 이야기인지
MLOps 의 정의가 궁금해요
MLOps 의 구성요소가 궁금해요
Kubernetes 를 잘 모르고 있어요

11. 1.3 어떤 분들에게 도움이 될 이야기인지
- MLOps 의 전반적인 내용보다는 마키나락스의 MLOps Engineer 는 어떤 일을 하
고 있는지 궁금하신 분
- 다음 키워드에 대해 기본적인 내용을 알고 계신 분
- 머신러닝 프로젝트의 Lifecycle
- Kubernetes
- Kubeflow
- 오픈소스 기반의 개발 방식에 관심있으신 분

12. 1.4 오픈소스 기여
https://github.com/kubeflow/internal-acls/pull/487
https://github.com/kubeflow/internal-acls/pull/507

13. 2. 첫 번째 고민 :
Kubeflow Pipeline 과 HPO 의 연결

14. 2.1 Kubeflow Pipeline (KFP)
- Kubeflow
- Machine Learning Toolkit for Kubernetes
- Kubeflow Pipeline (KFP)
- “데이터 준비 -> 전처리 -> 학습 -> … -> 서빙”으로 이어지는 ML Workflow
를 컨테이너 기반의 DAG 의 형태로 정의한 것
- 마키나락스에서는 주로 KFP 는 모델 저장까지만 수행하도록 구현

15. 2.2 Hyperparameter Optimization (HPO)
- HPO 란
- ML Model 의 다양한 Hyperparameter 조합에 대해, 가장 좋은 퍼포먼스를 내
는 Hyperparameter 조합을 찾는 것

16. 2.2 Hyperparameter Optimization (HPO)
- HPO 란
- ML Model 의 다양한 Hyperparameter 조합에 대해, 가장 좋은 퍼포먼스를 내
는 Hyperparameter 조합을 찾는 것
- 일반적인 HPO 과정
- Optuna, HyperOpt, Ray-Tune 등의 HPO 를 위한 Python 패키지를 활용하여
ML Model 학습 & 평가 로직을 반복하며 수행

17. 2.2 Hyperparameter Optimization (HPO)
Kubernetes 인프라를 활용한 HPO 를 위해서는
인프라를 추상화하거나
OR
ML Model 학습 & 평가 로직을 패키징하거나

18. 2.3 KFP 단위의 HPO 의 필요성
- 팀의 목표
- ML Engineer 가 Kubeflow Pipeline (KFP) 의 형태로 개발을 완료하면, 그 이
후의 모든 로직을 자동화 (HPO, CI, CD, CT)
소스 코드
모델 연구 및 개
발
담당자
모델 서비스화 담
당자

19. 2.3 KFP 단위의 HPO 의 필요성
- 팀의 목표
- ML Engineer 가 Kubeflow Pipeline (KFP) 의 형태로 개발을 완료하면, 그 이
후의 모든 로직을 자동화 (HPO, CI, CD, CT)
Kubeflow
Pipeline
모델 연구 및 개
발
담당자
모델 서비스화 담
당자

20. 2.3 KFP 단위의 HPO 의 필요성
Kubernetes 인프라를 활용한 HPO 를 위해서는
인프라를 추상화하거나
OR
ML Model 학습 & 평가 로직을 패키징하거나

21. 2.3 KFP 단위의 HPO 의 필요성
- 우리 팀의 목표
- ML Engineer 가 Kubeflow Pipeline (KFP) 의 형태로 개발을 완료하면, 그 이
후의 모든 로직을 자동화 (HPO, CI, CD, CT)
- 따라서 Kubeflow Pipeline 단위의 HPO 가 필요
- KFP 용 코드와 HPO 용 코드의 파편화 지양

22. 2.4 Katib
- Kubeflow 의 Components 중 하나
- AutoML 을 위한 Kubernetes-native 프로젝트
- Hyperparameter Tuning, Early Stopping 및 Neural Architecture
Search 지원
https://github.com/kubeflow/katib

23. Upstream Katib
Research Model
Experiment
KF Pipeline 구현
Train.py 분리
Docker Build
& Push
YAML 작성 후
kubectl apply
HPO Result
HPO Result
MRX Katib
kubectl
Click, Click,
Click
2.5 Katib 의 개선 포인트

24. 2.5 Katib 의 개선 포인트
https://blog.kubeflow.org/katib

25. 2.5 Katib 의 개선 포인트
KFP
KFP
KFP

26. 2.6 마주한 이슈 1
- Istio-sidecar Handling 지원
- Upstream 의 Katib 에서는 Istio sidecar injection 과 함께 사용할 수 없어, Disable 하는 것을
안내하고 있음
https://www.kubeflow.org/docs/components/katib/hyperparameter/

27. 2.6 마주한 이슈 1
- Istio-sidecar Handling 지원
- Upstream 의 Katib 에서는 Istio sidecar injection 과 함께 사용할 수 없어, Disable 하는 것
을 안내하고 있음
- 하지만, HPO 과정 중 kubeflow 관련 API 를 수행하기 위해서는 istio-proxy sidecar 가
반드시 enable 되어 있어야 함

28. 2.6 마주한 이슈 1
- 원인
- Katib 에서 생성되는 Worker 에 istio sidecar injection 을 enable 하면 init-container 를
제외하고 총 3 개의 컨테이너로 구성
- metrics-logger-and-collector 컨테이너
- Hyperparameter Search 를 위한 로깅
- istio-proxy 컨테이너
- 인증/인가
- main 컨테이너
- 학습 및 평가 로직
- 이들 간의 시작 순서를 지정할 수 없는 문제
- https://github.com/kubernetes/kubernetes/issues/65502
- 이들 간의 종료 시점을 지정할 수 없는 문제
- https://github.com/istio/istio/issues/6324

29. 2.6 마주한 이슈 1
- 해결
- Istio 에서는 이러한 문제를 지원하기 위한 2 가지 Endpoint 를 제공
- Readiness Endpoint & Terminate Endpoint
- Metrics-logger-and-collector 컨테이너의 Lifecycle
- 시작 시점에서 Istio 의 Readiness Endpoint 를 활용하여 Wait
- 종료 시점에서 Istio 의 Terminate Endpoint 를 활용하여 강제 종료
- 업스트림 Kubeflow/Katib 에 Issue up
- https://github.com/kubeflow/katib/issues/1638

30. 2.7 마주한 이슈 2
Experiment 를 만들기 어렵고,
실수할 여지가 많다.
UI 의 사용성이 떨어진다.

31. 2.8 마주한 이슈 3
- 내부적으로만 빠르게 구현 후 사용
- Katib 에서도 비슷한 목적을 이루기 위한 다양한 기능들이 추가되고, 논의되는 중
- https://github.com/kubeflow/katib/pull/1605
- https://github.com/kubeflow/katib/issues/1682

32. 3. 두 번째 고민 : HPO 가 끝난 이후

33. 3.1 First Idea - Naive
Best Model 을 저장하고,
Best Model 로 서빙을 수행하고 싶다.

34. 3.1 First Idea - Naive
Best Model 을 저장하기 위해서,
HPO 과정의 모든 모델을 저장한다.

35. 3.2 Second Idea - PostHook
https://github.com/kubeflow/katib/issues/1692

36. 3.2 Second Idea - PostHook

37. 3.2 Second Idea - PostHook

38. 3.3 Third Idea - Event Driven Architecture
A 의 상태가 변하면, B 라는 action 을 수행한다.
=
HPO 가 완료되면, Best Model 을 저장한다.
=
A/B Testing 이 완료되면, 승자 Model 을 배포한다.
=
서빙 중인 Model 의 성능이 하락하면, 새로운 Config 로 재학습한다.

39. This document is strictly confidential 39
Serving
Machine
Pipeline
Monitoring
Alarming
Stream
DB (Feature Store) Re-Training
(with HP Tuning)
A/B Testing
Labeling
CT Trigger
3.4 Continuous Training

40. 4. 마치며

41. 4.1 요약
➔ 어떤 고민이었는가
➔ 왜 고민했는가
➔ 무엇을, 어떻게, 왜 수정하였는
가
➔ 그래서 더 좋아졌는가

42. 4.2 채용 정보

43. 4.2 채용 정보

44. Q & A

45. Thank You