[풀글] MLOps (부제: Airflow)

0. Intro

최근 블로그를 못 적었다.

 

최근 Computer vision AI 스타트업에서 일을 시작했다. Nvidia deepstream 이랑, tao 랑.. DX는 뭐의 약자길래 계속 쓰이는건지..

ML 의 M 도 모르는터라 일단 닥치는대로 머리속에 쑤셔넣고 있다. 그래서 야근이 잦다.

 

어쨌든,

 

현재 ml pipeline 과 ml engine(임시 네이밍) 을 개발하고 있다. 대부분의 작업을 파트장이 맡아서 한다.

옆에서 깨작 거리는 것 뿐이지만 그간 이를 통하여 느낀 MLOps 를 적어볼까 한다.

 

1. ML Activity

Vertex AI: Google cloud's end-to-end ML platform

OTJ 에서 파트장님이 설명할 때 사용한 자료다. 전체적인 ML 플랫폼의 구조를 잘 보여주는 것 같아서 가져왔다.

MLOps 라고 해봤자 특별한 것은 없다. 그저 소프트웨어 개발인데 거기에 머신러닝이 포함된 것 이다.

 

위 이미지는 구글의 ML 플랫폼, Vertax Ai 에 대한 내용이지만 다른 AI 제품들도 크게 다르진 않다.

 

1-0. 데이터 수집 (Data collect)

일반적으로 수학 문제집은 하나의 문제만 있어서는 만들 수 없다. 여러 문제들이 있어야만 하나의 문제집을 완성할 수 있다.

같은 느낌이다. 데이터를 수집한다.

 

1-1. 데이터셋 구축 (Data readiness)

빅데이터 관련 공부를 조금 했다면 바로 이해할 것 이다. "머신러닝", 즉, 모델을 훈련시키려면 구조화 된 데이터셋이 필요하다.

데이터를 수집하고 적재, 그리고 필요한 데이터의 형태를 만드는 것 이다. 마치 "중학수학 총정리" 와 같은 문제집을 만드는 것과 유사하다. (고 나는 생각한다.)

 

1-2. 훈련 (Training)

완성된 수학 문제집을 푸는 과정이다. 모델을 훈련시키는 과정이다.

이 부분은 주로 "만들어져있는 모델"에 새로운 데이터를 넣고 돌리는 과정이다. 만일 이 "만들어져있는 모델"의 성능이 떨어질 경우, 그럴때 리서처 (데이터 사이언티스트) 가 모델을 재정비 (혹은 하이퍼 파라미터로 튜닝..) 한다.

 

1-3. Test & Analyze (Model serving ~ Model monitoring)

훈련된 모델을 배포한다.

 

2. Data Science & Software Engineering

일반적으로 머신러닝, 딥러닝, 하면 떠오르는 부분은 리서처들이 하는 일들이 아닐까 생각된다.

수집된 데이터를 분석하고, 연관성 높은 파라미터를 선정하고, 머신러닝 알고리즘을 통하여 정확도를 높이는.

남들은 모르겠으나 나는 그것이 주라고 생각했다.

 

실제로 Traditional ML in Product 관련 내용들을 살펴보면, 이전에는 model centric, 즉, 모델에 집중된 머신러닝 제품들이 많았다.

리서처들의 업무에 집중되었다. 리서처들이 높은 정확도를 내는 모델을 만드는 것. 그것이 주였다.

 

그러나 연구소에서는 높은 정확도를 내는 모델들은 실제 제품에서는 그만큼의 성과를 내지 못했기 때문이다.

이유야 여러가지 있었겠지만, 도출된 결론은 소프트웨어 엔지니어가 머신러닝의 지식을 갖추어야 하게 되었다는 것... 이라고 생각한다.

 

Software engineer 와 Data scientist 에게 필요로 하는 스킬은 전혀 다르다. 

그러나 내가 지금 다니고 있는 회사만 하더라도 다들 머신러닝, 딥러닝 관련 문서를 자주 보고 있다. 뿐만 아니라 리서처들과 커뮤니케이션 하는데 큰 어려움을 느끼지 않는다. 다들 실제 유니콘이 되어가는 중이라고 생각된다. (물론, 박사는 기본인 리서처들만큼 깊은 내용은 알지 못한다)

 

3. ML flow - Airflow

나는 우리 팀장님의 큰 그림을 다 보지는 못했지만, Airflow 를 통한 머신러닝/딥러닝 자동 배포 를 그리고 있는 것 같다.

Airflow 는 이번 ml pipeline 에서 흐름을 담당해주는, 일명, 스케줄러 이다.

 

나도, 팀장님도, 팀원들도 사용해본 적 없는 Airflow 라서 Dag 하나, Flow 하나 만드는 데에만 해도 고생을 많이 하고 있다.

 

찾아본 결과, 대부분의 회사들은 Airflow 를 ETL 용도로 사용하고 있었다. (그런 용도로 만들어진게 아니라고 하는데. 이유를 아직 찾지 못했다.)

 

우리 프로젝트에서는, 앞서 말했듯, 스케줄러로 활용중이다. 이번 블로그 글의 반 이상이 MLops 에 관한 주저리였는데, 그 이유가 이걸 말하고 싶어서였다.

위에서 보았듯, 머신러닝의 워크플로우는 항상 앞에서 조건을 충족해야만 다음 태스크 실행이 가능하다. 데이터를 수집해야만 데이터 셋을 만들 수 있다. 또, 데이터셋이 있어야만 훈련을 시킬 수 있다. 물론, 코드상에서 이런 것들을 개발할 수 있다. 하지만 그건 너무 비효율적이라고 생각했다. 

 

Airflow 에는 Dag 과 Task 가 있다. Dag 은 여러개의 Task 로 이루어져 있고, 각 Task 는 Queue 형식으로, 예를들어 A >> B >> C 형식으로 순서를 정했다면, B 는 무조건 A 가 완료된 후에 실행되고, 만약 A 에서 조건 충족이 안 되었을 경우, 뒤의 태스크들은 실행되지 않는다. 순서를 보장한 브로커 느낌이다.

또한 Dag 은 스케쥴링이 가능하다. 주기, 날짜 혹은 조건 (특정 이벤트 발생 등) 으로 자동 실행이 가능하다.

 

머신러닝의 워크플로우는, 위에 그래프 상에서는 굉장히 가볍게 설명되어있지만 실제론 엄청 복잡하다. (물론 크기에 따라서 다를 수 있다.)

이것을 가볍게 하기위해 스케줄러를 사용했다. 

 

- 이렇게 마무리 해도 되는걸까...

- 끝...!