MLOps로 소잡는 칼을 만들어보자

MLOps 에는 흐름이란게 있다.

 

첫번째 스타트는 데이터의 원천으로부터, 데이터 마트라 칭하는 (DS의 입장에서) 접근성이 좋은 곳까지 ETL을 수행하는 것. 에어플로우가 대표적이지만, 단순한 스크립트라도 좋다. ETL 용도로, 굳이 무거운 Airflow를 쓰기보다는 그냥 스크립트로 일일이 다 하는게 더 좋을때도 (가뭄에 콩나듯) 있다.

 

데이터만 앞에 놓아주면 DS가 전부다 해주는건 아니다. DS가 열심히 짜둔 스크립트를 크론탭이 되었거, 에어플로우에 있는 스케쥴링 기능을 사용하건, 아무튼 주기적으로 학습을 해야한다.

 

데이터가 바뀌면 모델도 바뀌어야 한다. 컬럼이 바뀌면 그건 그것대로 작업이 많겠지만, 오래되서 트렌드를 반영하지 못하는 데이터는 쳐내고, 새로 들어온 데이터들은 즉각즉각 반영해서 다시 모델을 만들어야한다.

조금 정적인 서비스라면, 데이터가 새로 만들어지는 것을 트리거로 해서, 작업을 할 수도 있겠지만, 데이터 원천이 DB라면, DB에 있는 SQL TRIGGER로는 MLOps에서 원하는 부류의 작업을 수행할 수 없다. 트리거가 필요하다면, 주기적으로 DB를 관찰해야한다.

 

모델만 새로 만들면 끝인가?

모델은 다양한 형태로 제공된다. 가장 러프하게는 inferece 한 결과를 하드에 떨구는 방식이 있을 것이고,  DB에 직접 꽂아주는 방식도 있을 것이고, 모델 자체가 제공되어야 하는 경우도 있다.

모델 자체가 제공되는 것은 inference 가 빈번하게 일어나는 (ex. 유튜브 추천 알고리즘) 것들일텐데, 상당한 트래픽이 예상되는건 당연하다. Inference 를 위한 서버를 분리하는 것은 그러한 이유다.

 

드디어 서버가 나왔다. 서버가 나오면 이제는 정말 DevOps의 영역이다. Flask로 API 하나 만들어서 EC2에 달랑 하나 올리는것은 이제부터 꽃필 에로사항들을 나몰라라 하겠다는 뜻이다. 온프레미스환경이라면 서버가 다운될 것을 대비해 최소한 이중화는 해두어야 할 것이고, 트래픽이 몰린다면 고가용성을 확보해야 한다. 말이 고가용성이지, 현재는 대부분 쿠버네티스든 도커스웜이든 아무튼 "컨테이너 오케스트레이션" 을 기반으로 한다.

 

고객의 앞에 떨어지는 것이 단순한 인퍼런스 결과라면, 관리자에게 떨어져야 하는 것은 좀 더 치밀한 통계가 필요하다. 인퍼런스 결과와 실제 고객의 행동패턴을 비교한 수많가지 차트를 들이밀어야 한다. 차트를 구성하는 지표는 도메인 지식과 더 많은 도메인 지식과, 그리고 약간의 창이력이 필요하다. 통계적 베이스는 기본이다. 최소한 AI 시스템을 사용했을때와, 하지 않았을때의 A-B 테스트 후, 유의미한 차이가 있는지 검증 정도는 해야하지 않겠는가.

 

그리고 이 모든 과정은 언제든지 수정될 수 있다.

라이브 서비스에는 당연히 커밋-테스트-자동배포 라는 파이프라인이 구성되어 있어야지.

3개 전부다 일이다.

커밋할때는 commit-zen 따위의 코드 커미터를 덕지덕지 발라서 개발자를 불편하게 해줘야'만' 하고,

테스트 할때는 예외사항을 빡빡하게 구성해서 달아둔 코드로 넘겨야 한다.

자동배포....는 평소에 기도를 얼마나 잘 했는지 신앙심을 시험에 들게 하시메....

자동배포도 컨테이너 기반으로 빌드하고, 쿠베에 올리면 된다. 헬름 차트로 사용하는게 그나마 마음이 편하다.

 

이러면 끝인가? 싶겠지만, 로깅과 모니터링이 남았다.

노드 익스포터를 달고 프로메테우스에서 수집하고 그라파나에 연결하고 어딘가에서 누군가 만들어둔 대시보드를 긁어와 달아두자. 적어도, CPU, Memory 정도는 실시간으로 확인할 수 있다.

로깅은 시각화가 필수다. Logstash든 fluentd 든 아무튼 로그를 수집해서 Elastic Search에 잔뜩 쌓아두고, Kibana로 시각화하자. Kibana 로도 그라파나로 수행했던 APM 은 수행할 수 있지만 이런.... Alert이 유료네?

로깅과 모니터링을 아무리 잘하면 뭐하나. 개발자들 자고 있고, 다음날 아침에 와봤더니 사이트는 폭파되어 있다. Prometheus Alert 기능을 활용해서, Slack Webhook 을 연동해서 당직을 서는 개발자건, 집에서 자택근무 하는 개발자건 알람 폭탄으로 두들겨 깨워서 새벽에도 장애 대처하게 하자.

 

장애는 대처만 하면 되는가? 문제원인을 찾고, 열심히 해결책을 찾아서 해결하고 재배포까지 자동으로 파바박! 하고 끝내서 큰문제가 되기전에 끝났다면 정말로 끝인가?

그럴리가 있나! 보고된 장애는 당장 사내 슬랙에 공유하자. "내가 이렇게 신앙심이 부족하다" 를 뽐내고 에러로그를 회람판처럼 보게해서 헤이헤진 개발팀 신앙심에 기강을 잡아야한다.

그런데 이걸...... 자동화할 수는 없으니, 문화로 남기고 Alert까지만 범위로 잡을 것이다.

 

이래저래 주저리주저리 늘어놓았지만, 아무튼 해보고 싶은건 이 과정들을 하나부터 열까지 내 손으로 직접 구현해보는 것이다.

돈이 좀... 아까우니까 ㅎ;; AWS는 쓰지말고, 비싼돈주고 공유기 쓰고 있으니 반쯤 고정 IP라 생각하고 로컬서버에 구현해볼 것이다. EKS는.... 하루이틀 띄우면 몇만원이다. 내 박봉으로는 도저히 감당할 수 없다.

 

다시 정리해보자.

 

1. ETL 파이프라인

2. 주기적 재학습

3. inference server

4. dockerizing & container ochestration

5. CI/CD/*CT

6. APM

7. Logging

 

요렇게 7개를 진행할 예정.

 

 

 

 

*CT: Continuous Test 의 약자다. 보통은 CI/CD만을 이야기하는데, 당연히 CT도 해야한다고 내 딥러닝 선생님이 알려주셨다. 그런데 선생님... 아무리 검색해봐도 한국에서는 CT라 하면 Continuous Training 이라고 알아듣는것 같습니다....