📌 요약

• (수행 전) 병렬처리가 필요한 DL 모델과 비교적 그렇지 않은 ML 모델 Serving 방식 차이 알아보기

• (수행 후) 실서버 목적으로 한다면 GPU 서버보다는 최대한 경량화하여 CPU 서버를 사용하는 서빙이 맞다고 합니다.

📔 상세

Before

• DL 모델은 연산도 많이 들어가고 시간/리소스도 많이 들어 클라우드로 무료 인스턴스를 사용하기는 어려울 것 같음
• 그에 비해 ML 모델은 CPU로도 돌릴 수 있을만큼 light해서, 그냥 AWS, GCP 등 무료 인스턴스로도 올릴 수 있지 않을까 생각중
• 혹시 ML모델 배포와 DL 모델 배포를 다르게 가져가는 사례가 있는지 찾아보고, 가능하다면 LGBM 등의 트리계열 모델로 serving 파이프라인을 먼저 구축해보는건 어떨지 가능성 체크

After

• DL 모델 계열 LSTM도 정상적으로 동작합니다.
• 다만, Docker Swarm을 사용하여 다수의 Replica를 두는 경우 리소스 부족으로 컨테이너가 생성되지 않는 문제가 있습니다.
• NCP로 서버만 이전해보려 합니다.

📌 요약

• (수행 전) 기존 데일리미션 템플릿에서 벗어나서 의미있는 수준의 템플릿으로 바꿔볼까 합니다.

• (수행 후) 결과는 어땠는지

📔 상세

Before

• 레퍼런스로 산타토익은 어떨까요..?

• Flask에서 기존의 q_content, tag, test_id, assess_id, answer 정보만 받아오는 형태

After

• FE에 필요한 중요한 정보인 문제를 풀었을 당시의 timestamp를 추가로 받아옴

• date format을 사용자가 편하게 수정하기 위해 moment 라이브러리 사용.

✔️ 추가하고싶은 기능

• 프로젝트에 덧붙이고 싶은 기능들을 제안합니다. 아래의 종류에 맞게 체크해주세요.

• Data

• Preprocessing

• Model

• Feature

• Paper

• Serving

• ETC (ex - library, reference)

==========

Baseline BERT 모델 MLProject로 포팅하여 MLFlow에 로컬로 올려보기.
잘되면, cloud infra에 올려봅시다.

==========

---

📚 레퍼런스 첨부

• https://zzsza.github.io/mlops/2019/01/16/mlflow-basic/

---

📸 스크린샷

airflow를 이용하여 dataload, train, reload(serve) 까지 진행이 되는것을 확인할 수 있었다.

client side page의 모습

ngrok를 이용하여 간단하게 외부에서도 접근할 수 있는 것을 확인할 수 있었다.

깃헙에 소스공유해주셔서 감사합니다.
데이터 엔지니어링 공부하다가 실례를 무릅쓰고 이렇게 질문드립니다.

https://github.com/cheat-tos/serving/blob/main/service.py

해당 소스에서
bentoml endpoint를 하나로 설정해두신 이유가 있을까요??

📌 요약

• (수행 전) Airflow가 수행하는 ETL - Train - Inference 과정을 DAG로 어떻게 짤 것인지 mockup을 논의합니다.

• (수행 후) 결과는 어땠는지

📔 상세

Before

After

📌 요약

• (수행 전) 학습 후 model 파일 object storage로 저장하도록 train.py를 수정하려고 합니다.

• (수행 후) 결과는 어땠는지

📔 상세

Before

After

📌 요약

• (수행 전) inference용 bentoml server는 도커라이징 되었고, train.py가 있는 이미지와 flask_server를 도커라이징 해보려합니다.

• (수행 후) inference 서버, flask 서버 image화 완료했습니다.

📔 상세

Before

플라스크 서버 컨테이너
─── inference 컨테이너
└── (re)train 용 컨테이너
총 세개를 둘 생각입니다. 플라스크는 상시 떠있고, airflow에서 cron으로 train을 수행해 inference 컨테이너를 죽이고 기존의 포트를 train이 물도록 하면 컨테이너 교체가 가능합니다.

After

Docker compose로 inference 컨테이너와 flask 컨테이너가 컨테이너간 통신 가능하도록 네트워크로 묶었습니다.

📌 요약

• (수행 전) 지금은 default argument로 container의 inference가 수행되고 있는데, 컨테이너 학습시 인자로 config setting을 조작할 수 있도록 만듭니다.

• (수행 후) container로 학습하지 않고 P40 서버 상에서 학습하기로 했으며, 이때 train에 config 인자를 주어 모델을 바꿔서 학습할 수 있게 했습니다.

📔 상세

Before

• argparsing을 어떻게 해야할까요? main.py를 만들어야할까요? 🧐

After

• 위와 동일

---

Reference

https://stackoverflow.com/questions/53543881/docker-run-pass-arguments-to-entrypoint

📌 요약

• (수행 전) MLOps Conference, Full Stack Deep Learning 등에서 관련 내용 찾아보기

• (수행 후) 모델 학습관리는 MLFlow 사용, 배포는 SageMaker 사용하거나 Ec2 배포로 들어갈듯

📔 상세

Before

• ML 파이프라인 구성 툴 / 키워드 위주로 skim
• 정리하여 코어타임 끝나고 serving 방향 정한 뒤 주말간 더 research 할것

After

• Airflow
  • 가장 많이 사용하고, feature도 가장 많음
  • 그만큼 세세한 세팅이 많고, 설정 및 유지관리에 시간이 많이 듬
  • 오케스트레이션 툴(여러 컨테이너를 다루고, 배포를 수행하기에 좋음)
• Luigi
  • Airflow에 비해 기능이 적지만 더 시작하기 쉽다. 근데 한국어 레퍼런스가 적은듯하다(거의 본적없음)
• MLFlow
  • ML 모델 배포 및 실험 tracking용 기능이 많음
  • 근데 다른 툴들과 사용법이 조금 다르고, MLFlow식의 패턴이 있음(난이도는 어렵지 않은듯)
    • DAG 형식으로 의존성 순서를 정하기 어렵고, 정해진 패턴대로만 수행해야하는것같다. 세세한 세팅이 필요하다면 꺼리겠지만, 지금 상황에서는 차라리 편함.
  • 오케스트레이션 툴이라기보다는 실험관리 툴에 가까움. 배포를 위해서는 추가적인 세팅이 필요한듯?
• KubeFlow
  • ML 모델 배포 및 실험 tracking용 기능이 많음
  • Kubernetes를 사용하고 싶지만 YAML 대신 python으로 세팅하고싶은경우
  • 실질적 레퍼런스가 가장 많은듯(그러나 오버엔지니어링 감이 있음)
• Argo
  • Kubenetes 사용에 익숙하고 Python 대신 YAML을 사용하고 싶다면..

난이도, 레퍼런스 등을 고려해봤을때 해볼만한 것은

MLFlow > AirFlow > KubeFlow > 외 나머지

MLFlow 사용 후 AzureML 또는 SageMaker이용하여 배포 가능하다고!

📌 요약

• (수행 전) Production service에 올리기는 MLflow보다 BentoML이 낫다던데, 일단 MLflow로 먼저 올려보고 차이점 알아보기.

• (수행 후) BentoML은 실제 많은 기능을 제공하였으며, 이번 프로젝트 서빙에서 주축이 되는 프레임워크로 사용

📔 상세

Before

• API Swagger docs까지 제공해주는건 좋은데.. 굳이 두개나 툴을 배울필요가 있을까?
• https://dailyheumsi.tistory.com/256?category=980484

After

BentoML Review

@bentoml.env()

• 서버에서 사용되는 라이브러리를 입력하는 데코레이터
• 서버에서 사용되는 라이브러리들을 추론하여 requirement 파일을 만들어준다.
  • 기존의 requirement.txt를 사용하여 만들 수도 있으며, 라이브러리 이름을 직접 입력하여 만들 수도 있다.

@bentoml.artifacts()

• 서버에서 사용되는 모델 파일, json 파일, pickle 파일 등을 저장해주는 데코레이터
• baseline lstm을 사용할 때, 필요한 artifacts

  1. 학습되어 있는 모델 파일, model.pt

  2. inference 시 예측할 test data, pandas dataframe type으로 pickle로 저장

  3. 모델 학습, 데이터 전처리 등에서 사용되는 config 파일, json 파일

  4. test dataset의 categorical feature를 training dataset과 같이 label encoding해줄 np.array type, pickle로 저장

     (assessmentItemID_classes, testId_classes, KnowledgeTag_classes)

@bento.api()

• 해당 url에 접속하였을 때, 실행되는 함수에서 input 또는 batch process를 설정해주는 데코레이터

• 해당 데코레이터 다음에 나오는 함수 명이 url 명이 된다.

  ex) 함수명 : predict, url : 0.0.0.0:port/predict

packing

• @bento.artifact() 에서 설정한 artifacts들을 [bento class].pack()으로 packing 해주고 save()를 해주면 최신 버전의 디렉토리가 생성된다.

Imported py files

• bentoml에서 env, artifacts 등을 설정하는 파일이나 packing 해주는 파일에서 import하는 다른 python 파일들은 bentoml에서 추적하여 서버에 저장해준다.
• import하는 python 파일이 다른 디렉토리에 있는 경우에는 해당 디렉토리에서 여러 python 파일을 init.py로 묶어줘야 디렉토리 전체가 서버에 저장된다.

Serving

• CLI에서 bentoml serve [bento class]:latest 를 입력하여 serving

• —-port를 통해 port 번호 설정 가능

• 아래 코드를 통해 파이썬에서 테스트 가능

  res = requests.post('http://0.0.0.0:5000/predict', json= data)
  print(res.text)

Docker

• 서버가 생성되면 디렉토리 안에 자동으로 docker file이 생성된다.
• 해당 docker로 이미지 생성 가능

HTML Rendering

• HTML로 Rendering 기능은 없기에 flask를 이용
• flask로 렌더링하여 데이터를 받고 requests.post로 데이터를 bentoml로 post한 뒤 결과를 받아 다시 랜더링하는 방식

📌 요약

• (수행 전) flask로 들어온 요청을 여러 포트로 로드밸런싱하는 Nginx를 추가합니다.

• (수행 후) Nginx나 Traefik 대신 Docker Swarm을 사용합니다.

📔 상세

Before

• Nginx는 로드밸런서 역할을 하여, 하나의 포트로 들어온 요청을 여러 포트로 분산시켜 보낼수 있습니다.
  • Nginx는 컨테이너에 적합하게 설계된 로드밸런서가 아니므로, traefik을 사용해봅니다.
• 이를 이용하여, 많은 사용자의 요청을 처리하도록 Inference 서버를 늘릴 수 있습니다.(docker compose --scale 옵션)
• 또, 새로운 데이터로 재학습된 컨테이너를 바꿔치기하는동안 기존의 서버가 계속 요청을 처리하도록 할 수 있습니다.

After

• Docker swarm을 사용하기로 하여 기존의 로드밸런서 건을 폐기합니다!

---

Reference

• https://stackoverflow.com/questions/39168239/update-only-one-container-via-docker-compose
• https://www.atlantic.net/vps-hosting/how-to-update-docker-container-with-zero-downtime/
• https://coderbook.com/@marcus/how-to-do-zero-downtime-deployments-of-docker-containers/

📌 요약

• (수행 전) 기존 baseline lstm으로 training, inference되던 bentoml 코드를 유지님의 saint 코드로 변경

• (수행 후) train, inference 코드에 saint 추가, s3 추가

📔 상세

Before

• 유지님의 saint 코드가 기존 baseline 형식을 따르기 때문에 부분 부분만 수정해주면 될 듯합니다.
• dkt.model.py에 saint를 추가해야 될 것 같으며 feature engineering으로 추가된 feature의 label encoder를 packing 해줘야 할 듯 합니다.

After

수정사항

• dkt.dataloader와 labeled_dataloader 합침, is_trained 변수로 구분
• dataloader.py, model.py, service.py, packer.py를 saint 모델에 맞게 수정
• train.py에서 s3에서 training data를 받도록 수정
• service.py에서 추가되는 데이터를 additional_data.csv에 저장하도록 수정
• 기존 training data와 추가되는 additional data를 합하여 s3에 저장하는 upload_s3.py 추가
• requirements.txt 추가

📌 요약

• (수행 전) 하나의 flask 서버로 들어온 요청에 대하여 Load Balancing과 fail over check, Rolling update까지 수행할 수 있는 오케스트레이션 툴을 사용합니다.

• (수행 후)

📔 세팅은 잘 되나 리소스가 부족하여 ec2 서버 사이즈를 키울 생각입니다.

Before

• 러닝커브가 낮은 Docker Swarm 사용예정이며, 사실상 데모 시연용이므로 EC2 서버에 배포하는 형태는 그대로 가져갑니다.
• 원래 올바른 부하분산을 위해서는 워커 노드를 각각 다른 EC2나 컨테이너 서비스에 할당하는것이 맞지만, 현재 아키텍쳐에서는 무리가 있으므로 차선책을 선택했습니다.

After

• 리소스 부족으로 inference 컨테이너가 생성이 안되어 플랫폼을 옮기거나, 그냥 조금 더 큰 인스턴스를 사용할 예정입니다.

---

Reference

• https://roseline124.github.io/kuberdocker/2019/08/02/docker-study10.html

✔️ 추가하고싶은 기능

• 프로젝트에 덧붙이고 싶은 기능들을 제안합니다. 아래의 종류에 맞게 체크해주세요.

• Data

• Preprocessing

• Model

• Feature

• Paper

• Serving

• ETC (ex - library, reference.

==========

이전에 언급했던 KF Serving 레퍼런스를 토대로 모델 서빙을 합니다.
클라우드는 아직 사용하지 않습니다.
성진/유지님이 만드신 SAINT 모델을 사용합니다.

• Airflow
• ETL pipeline
• Serving - KFserving
• Cloud Infra

==========

---

📚 레퍼런스 첨부

• 노션 참조

---

📸 스크린샷

• 해당 기능을 적용시켰을 때의 사례를 미리볼 수 있게 사진 등으로 첨부해주세요.