GS리테일 Tech 블로그

고객 생활의 가치를 향상시키는 사람들의 이야기

Data&AI

실시간 추천을 위한 kubeflow 환경 구축

Harry_P 2022. 1. 4. 17:59

 안녕하세요. 검색추천팀에서 ML 엔지니어로 일하고 있는 해리입니다.

 저는 추천엔지니어로 일한지 약 6개월 정도 되었고, 그 기간동안 실시간 추천을 어떻게 준비했는지 또 준비과정 중 어떤 이슈가 있었는지 공유드리고자 합니다.

 

기존의 추천

 저희는 앞서 수년간 이른바 '배치성 추천'을 서비스 해왔습니다.

 배치성 추천이라 함은, 고객마다 고객이 가진 고유의 PCID를 기반으로 미리 어떤 제품을 추천할지 Airflow batch job을 통해 RDB 테이블에 저장해둔 데이터를 조회한 결과를 추천하는 방식입니다.

 한마디로, "이 고객은 이 상품을 좋아할거야" 라는 결과를 미리 DB에 저장해두면, 정적으로 그 정해진 결과를 추천 합니다.

이러한 추천의 경우 실시간 고객의 반응을 추천에 담기 어렵다는 단점이 있었습니다.

 

지향하는 추천

 위와 같은 이유로 저희는 다음과 같이 생각했습니다.

기존에 저장된 결과를 정적으로 추천하지 말고, 새로운 Input에 동적으로 변화하는 실시간 추천을 만들자

  • 우선 저희는 General Programming 방식이 아닌, 실시간 Serving Model 의 inference 결과를 추천하는 방식을 선택하고자 했습니다. 이로써 고객이 실시간으로 검색하고 클릭하는 데이터들이 Serving Model에 반영되어 실시간 추천 결과를 서비스 하도록 했습니다.
  • 추가적으로 배포 속도를 높이기 위해 Microservice의 Service mesh Architecture를 구성하고자 했습니다. ML workflow가 빠르게 반복되면 반복 될 수록 다양한 관점에서, 다양한 feature, 다양한 hyper-parameter를 활용해 Model 의 성능 향상 효율을 극대화 할 수 있기 때문입니다.
  • 마지막으로 누구나 쉽게 사용할 수 있도록 실시간 추천 관련 진입장벽을 최소화 하고자 했습니다.

 

 

추천 환경 구축

 위에서 언급드린 3가지 관점에서 말씀드리자면

  • 우선 실시간 Model Serving을 위해선 Tensorflow에서 제공하는 TF serving과 Pytorch Model Serving tool인 Torchserve를 활용하는 것으로 진행중이며 TF serving의 경우 현재 Deepfm을 활용한 Model이 실시간 Service 운영중에 있습니다.
  • 추가적으로 빠르게 배포, 실험, 테스팅을 위해 istio, kourier gateway를 활용 및 knative serving을 활용해 하루에도 수십번씩 테스팅이 가능한 구조로 운영하도록 했습니다
  • 마지막으로 누구나 쉽게 사용할 수 있도록 Elyra를 도입하여 분석가들이 ML pipeline을 쉽게 만들 수 있도록 했습니다. 기존의 Kubeflow Pipeline의 경우, kubernetes를 어느정도 이해해야만 pipeline 제작이 가능하였습니다. 따라서 모델러들이 커버해야하는 내용이 지나치게 방대해질 것을 고려하여 Elyra를 도입했습니다.

 관련 아키텍쳐를 클라우드상에 구축할 때, 클라우드팀의 조인혁 매니저와 보안센터에서 많은 도움을 주셨습니다. 이 기회를 빌어서 감사를 표합니다. :)

 

 Elyra의 경우 부문 내 가장 많이 사용하는 분석환경인 jupyter notebook을 이어붙이는 방식으로 pipeline을 만들 수 있었기에 차용하였고, 사용법만 간단하게 익히면 kubernetes 이해 없이도 사용이 가능했습니다.

 실제로 현재 TF serving으로 Service하고있는 Deepfm model의 경우 모델러인 Brian이 ML pipeline을 E2E 작성 및 배포하며 Model 및 Model에 사용될 data를 update하고 있습니다.

 아래는 data를 load하는 code, training하는 code, 마지막으로 model serving하는 코드를 각각의 notebook으로 총 3개의 notebook을 만들고, 이를 pipeline화 하는 Elyra UI 입니다.

 

 

실시간 추천을 준비하며 직면한 문제들

Model Inference speed issue

 대국민 서비스로 실시간 추천을 준비하며 가장 신경썼던 부분은 “속도”문제 였습니다.

 Model 의 Inference 속도, Model 의 input을 만드는 API의 속도가 매우 빨라야 매초 접속하는 수백명의 고객에게 Model 기반 추천 결과를 고객에게 서비스 할 수 있었습니다.

 이를 해결하기 위해 아래와 같은 방법을 사용했습니다.

  1. AWS EC2의 다양한 Instance type에서의 Model Serving을 부하테스트 및 최적의 instance 사용
  2. Gateway 역할을 하는 python api의 경우 gunicorn의 worker 갯수를 늘리고 전처리 로직을 최소화
  3. TF Serving Model과 Gateway API사이의 GRPC 통신

 그 결과 초당 평균 650개 정도의 request를 처리할 수 있었습니다

 

Model update issue

 Model을 지속적으로 update해주는 것 또한 큰 고민이었습니다. Kubeflow pipeline이 정상적으로 동작하면 최신화된 Model이 AWS의 특정 S3 Bucket에 upload되는데, 이를 trigger하여 Serving model을 update하는 역할의 API개발이 추가적으로 필요했습니다.

 고민 중 Sam이 AWS SQS를 활용하면 이를 해결할 수 있겠다고 얘기해주셨고 이를 바탕으로 아래와 같은 Architecture가 만들어졌습니다.

 

  1. 추천 모델러들이 kubeflow notebook에서 ML engineering 관련 코드 작성 및 ML pipeline 작성
  2. GPU Node에 Pipeline 배포
  3. 새로 생성된 model 및 inference에 필요한 데이터 S3에 저장
  4. AWS SQS 가 S3 Bucket update catch
  5. AWS SQS 가 Bucket update 사실을 Queue
  6. S3 monitoring API가 Queue를 받아서 새로 update될 모델 검증 ( prediction ), 검증 완료시 Efs volume update
  7. TF serving pod, Gateway API rollout

 

운영 이슈

 실시간으로 Model을 Kubernetes Pod으로 Serving하여 운영하다보니, 다양한 운영상의 Risk가 있을 수 있었습니다. 현재 Kubeflow 환경의 경우 DevOps의 구조로 개발자가 동시에 운영을 함께하다보니 운영 효율을 극대화할 필요가 있었습니다.

 따라서 운영관련 Kubernetes Node, Namespace를 실시간 Monitoring하고, 운영상 이슈가 발생했을 때 이를 Line Application을 통해 휴대폰으로 알림을 받는 custom API 또한 개발 완료 되었고 및 고도화 진행중입니다.

 

마치며

 이번 서비스 구축을 바탕으로 다양한 사람들과 협업하는 값진 경험을 한 것 같아 개인적으로는 무척 뿌듯하고 잊지 못할 경험이 되었습니다. 

 실시간 Model Serving을 경험하며, 앞으로 가야할 길이 정말 멀고 그 길이 재밌겠다는 생각이 들었습니다.

 아키텍쳐 고도화부터 시작해 Logging, Monitoring 관련 다양한 open source활용, 나아가 Kubeflow Feast, Katib를 활용한 Feature Store, Hypterparameter auto tunning 도입 등 일일이 열거하자면 끝도 없을 만큼 개발, 배포, 운영 및 고도화 할 것 투성이 입니다.

 앞으로 이런 분석 환경을 좀 더 정교하게 다듬어 나가야 할 필요성을 느낍니다.

 


 

임동원 Harry | 뉴테크본부 > 검색추천팀

검색추천팀에서 ML 엔지니어 업무를 담당하고 있습니다.

새로운 기술을 배우는 것에 관심이 많습니다.