패스트캠퍼스 챌린지 26일차

모델 서빙 이후에 리터런스 서버가 잘 돌아가고 있는 지 모델의 인프런스 성능은 의도한대로 나오고 있는 지. 테스트게이트와 가정했던 분포와
비슷하게 들어오고 있는 지.
이러한 점을 모니터링 하는 방법에 대해서 알아보자
쿠버네티스 클라스터 서버에 잘 배포한 뒤의 또 다른 벽. 내가 배포한 모델이, 모델이 떠있는 인프런스 서버가. 쿠버네티스 클러스터가 24시간 , 1년 동안 의도한 대로 정상 작동을 할 까?
극단 적인 예를 들면 비트코인 자동 매매 서비스 전재산을 투자한다면 편하게 잠 잘 수 있을까? 

댜양한 예측 불가능한 상황이 벌어 질 수 있다.

모니터링 결과로 잡아낸 자동화 된 해결 시스템을 구축 해 놓지 않았기 때문이다. 모델은 서비스화해서 배포한다고 끝나는 게 아니다.
1. 가장 안정적인 서비스 제공
더 나아가서는 현재 서비스를 성능을 지속적으로 개선해서 더 좋은 모델과 서비스를 또 다시 지속적으로 배포를 해야한다.
 때문에 지속적인 모니터링 서비스와 모니터링한 데이터를 바탕으로 한
 자동화 된 재학습 재 배포 파이프라인을 구축해야 고도화된 MLOPS 시스템이라고 말할 수 있다
 
 ML모델이 기반으로 된 제품이 서비스가 잘 돌아가고 있는 지 확인하기 위해서는 어떤 것들을 모니터링 해야 할까요?
 
 구글에서 2017년에 발표한 논문에 의하면 7가지를 모니터링 해야한다고 말한다. 
 ML관련 매트릭 카이예스 테스트, KS 테스트를 사용해서 input 데이터나 특정 피쳐 , output데이터의 분포가 의도한 바와 동일한지 비슷한 지 혹은 트레이닝, 서빙 데이터가 너무 발생한지 않은 지 이런 것들을 확인하기도 하고 out라이어 데이터가 너무 많이 들어오고 있지 않은 지.퍼포먼스를 확인하기 위해서 테스트 데이터 혹은 구축된 평가용 데이터로 인퍼런스를 계속 함으로써 퍼포먼스가 계속 떨어지고 있지 않은 지 그런 매트릭을 모니터링 할 수 있다. 
 Ops관련 매트릭은 기존의 소프트웨어 모니터 링과 동일하게 서비스가 정상적으로 동작하고 있는 지 리소스는 잘 부족하지 않은 지 이런 것들을 확인하는 데 이 부분에서는 리퀘스트 레이턴시 , 리퀘스트 에러 rate. 리소스 현황과 같은 cpu, 메모리 등 결과로 스펙 업을 해야 되는 거 아닌지, 네트워크를 확인해봐야 되는 거 아닌 지 이러한 것들을 모니터 링 할 수 있다.
 모니터링 이라는 자체는 보고만 있는 거에 그치는 게 아니라 모니터링 하면서 무언가 비정상적인 이슈 상황이 발생한다면 이걸 당장 해결하든 장기적으로 해결하든 그 이슈를 해결하는 데 의미가 있다. 당연히 빨리 해결할 수록 좋다.
 이슈를 해결하지 않을 거라면 시간과 리소스를 들여서 모니터링 할 이유가 없다. 
 그래서 이러한 모니터링 된 결과를 바탕으로 이슈를 해결하기 위해서는 장애가 일어나는 것을 알애채는 알람 로직 .
 추후에 모니터링 된 결과를 바탕으로 분석, 포스터 모템 분석 하기 위해서는 log나 트레이터스 같은 것을 항상 기록하고 있어야 한다.
 무언가 이슈를 해결한 커밋을 추가하고 나서 새로운 버전을 배포하고싶다면 베포 이후에도 동일하게 정상 동작하는 것을 확인할 수 있는 AND to AND 테스트 자동화와 FAST 체크 API정도는 어느 정도 구축을 해놔야 한다.
 ML관점에서는 잘 구축된 밸리데이션 데이터set과 atic 바탕으로 밴치마크가 어느 정도 정의 되어 있어야한다,
 
 전통적인 소프트웨어 서비스 모니터링 과 ML 서비스과 결합된 모니터링은 똑같이 하면 안 된다.
 전통적인 소프트웨어 시스템과 달리 ML모델의 기반의 서비스는 성능 평가를 위한 정량적인 매트릭을 정의하는 것 자체가 어렵다
 이게 무슨 말이냐면
 예를 들면) 제가 어떤 쇼핑몰 사이트를 개발 했는 데 갑자기 페이지 로딩 속도가 느려진다고 가정해보겠습니다. 그러면 리퀘스트 sloop라든지 레이턴시부터 확인하고 서버의 cpu나 RAM용량,사용량 디스크 사용량 I/O 속도 혹은 현재 사이트의 접속량이 너무 많지 않은 지 이러한 점들을 확인하기 위해서 네트워크 트래픽 같은 정량적인 요소를 바로 파악할 수 있습니다. 쇼핑몰에서 사용자 별 맞춤 제품에 따른 추천해주는 페이지가 있는 데 그 추천한 맞춤 제품보다는 다른 제품을 구매하는 비율이 일주일 전부터 갑자기 늘어난다고 가정해보겠습니다. 그러면 소비지가 왜 갑자기 맞춤 제품을 소비하지 않는 지 어떤 지표를 파악해서 어떤 형태로 해결해야 될까요? 
  흔히 추천 시스템에서는 CTR이라는 페이지 노출 대비 클릭되는 횟수의 매트릭을 주로 활용하기 하지만 사실 추천시스템을 평가하는 단 하나의 매트릭 같은 것은 아직 존재하지 않는다고 말할 수 있다. 왜냐면 쇼핑몰 ,스트리밍 서비스, 뉴스 페이지 등 추천해주는 같은 계열을 가진다고 하더라도 도메인별로 원하는 성과 방식이 다 다르기 때문에 그거를 수치적으로 정량화를 하고 그 정량화된 매트릭을 평가할 수 있는 밸리데이션 데이터set을 구축하고 테스트 데이터set에 대해 즉 온라인 서비스를 진행하면서도 지속적인 성능 평가를 할 수 있어야 되는 데. 이런 부문이 아직까지 많이 미지의 세계라고 할 수 있다.
  
  이 처럼 매트릭 정의하기 어려운 거 뿐만 아니라 사실 해결하는 데 걸리는 시간 또한 굉장히 차이가 나기 마련이다. 방금 말씀 드린 쇼핑몰 옷 추천 서비스와 같은 경우에는 예를 들어서 맞춤 추천 옷 클릭하는 빈도가 줄어들고 새로고침을 하는 횟수가 늘어나는 걸 감지가 되면 그 이후를 우선 분석을 해야되고, 분석 결과를 바탕으로 피쳐 엔지니어링부터 다시 하거나 혹은 아예 새로운 모델 사용하거나 해야 하고 이렇게 모델 연구를 통해서 모델을 결정한 후에는 다시 또 모델을 재 학습한 후에 배포하는 형태로 나아가야 한다.
  문제 해결 사이클에 걸리는 시간이 정말 오래 걸리겠다는 걸 짐작할 수 있다. 그 과정에서 소프트웨어 개발만 하면 되는 게 아니라 개발을 본격적으로 착수하기 앞서서 통계 분석,도메인 지식,비즈니스 적 요소까지 다양한 지식이 바탕이 되어서 결정해야 되는 요소가 정말 많다. 
  모니터링 하는 데는 단순히 어떤 툴을 사용하는 게 중요한 게 아니고 어떤 문제를 해결할 것이고 ,요구사항,이해 관계자가 어떤 상황을 중요하게 여길 것이냐의 따라서 모니터링 할 요소들도 정말 많이 달라지고 시스템의 형태도 아키텍쳐도 많이 달라질 수 밖에 없다.

#직장인인강 #직장인자기계발 #패스트캠퍼스후기#온라인패키지:머신러닝서비스구축을위한실전MLOps#머신러닝서비스구축을위한실전MLOps온라인패키지Online.

https://bit.ly/37BpXiC

패스트캠퍼스 [직장인 실무교육]

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성되었습니다.