Hyesung Oh

TL;DR지난 추천 시스템 고도화 시리즈의 실시간 추론 편 마지막 단락에서 계획 중인 사이드 프로젝트에 대해 말씀드렸었는데요, 운이 좋게도 사내 추천 시스템에 실시간 추론을 도입하여 사용자에게 조금 더 다이내믹한 탐색 경험을 제공하자는 방향성이 논의되어 사내 PoC Task로 진행해 보게 되었습니다 :).https://surgach.tistory.com/139 e-commerce 추천 시스템 고도화 하기 시리즈 [3] Realtime inference서론지난 게시글에서는 end-to-end 추천 파이프라인에서 꼭 필요했던 기능들을 적용하며 개선한 과정을 소개했습니다. https://surgach.tistory.com/138 e-commerce 추천 시스템 고도화 하기 시리즈 [2] AWS Sagsurg..

TL;DR지난 포스팅에서는 Bloom Filter 소개와 Pyspark Integration에 대해서 소개했습니다.https://surgach.tistory.com/140 Bloom Filter 를 사용해봅시다 [1] python, pyspark bloom filter 구현TL;DR개발자가 작성하는 많은 비즈니스로직에는 특정 조건, 집단에 해당하는 item, user만 포함 or 제외하는 형태가 많은 부분을 차지합니다. 특히 데이터 엔지니어의 경우 통계 마트 테이블을 만들surgach.tistory.comBloom Filter는 다양한 활용처가 있겠지만, 그중에서도 추천 시스템에 활용할 수 있습니다. Redis-stack에서는 Bloom Filter를 제공하는데요, 추천 결과를 유저에게 제공할 때, 유저..

TL;DR개발자가 작성하는 많은 비즈니스로직에는 특정 조건, 집단에 해당하는 item, user만 포함 or 제외하는 형태가 많은 부분을 차지합니다. 특히 데이터 엔지니어의 경우 통계 마트 테이블을 만들일이 많기 때문에 이와 같은 패턴에 익숙할 것입니다. 그중 Spark를 예를 들어, (1) user별 구매이력, (2) user 정보 두 테이블이 있을 때, user id를 key로 하여 두 테이블을 join 후 특정 조건 (1)에 해당하는 row만 (2)에서 filter 하는 식일 것입니다.하지만 join시 여러 worker node간에 분산 배치되어 있는 동일 key들을 동일 partition에 위치시키기 위해 필연적으로 동반되는 shuffling 동작은 데이터가 커질 시 병목으로 작용하게 됩니다. S..

서론지난 게시글에서는 end-to-end 추천 파이프라인에서 꼭 필요했던 기능들을 적용하며 개선한 과정을 소개했습니다. https://surgach.tistory.com/138 e-commerce 추천 시스템 고도화 하기 시리즈 [2] AWS SageMaker model registry서론추천 시스템을 고도화하기 마음먹은 과정과 feature store 도입기에 대한 짧은 소개에 이어서, 이번 편에서는 본격적으로 파이프라인에 필요했던 개선사항들을 적용한 내용들을 정리해보려 합surgach.tistory.com이번 포스트에선 AWS SageMaker를 활용하여 실시간 추천 모델 서버를 구축해 본 경험을 정리해보려 합니다. 소위 real-time inference는 당장의 비즈니스 요구 사항은 아닙니다만,..

서론추천 시스템을 고도화하기 마음먹은 과정과 feature store 도입기에 대한 짧은 소개에 이어서, 이번 편에서는 본격적으로 파이프라인에 필요했던 개선사항들을 적용한 내용들을 정리해보려 합니다.https://surgach.tistory.com/137 e-commerce 추천 시스템 고도화 하기 시리즈 [1] feature store서론실무에서 머신러닝을 활용하는 도메인 중에서, 추천 도메인의 경우 대게 실시간성보다는 배치 파이프라인 만으로 요구사항을 충분히 만족시킬 수 있는 거 같습니다. 현재 팀에서 운영 중surgach.tistory.comManaged MLOps Platform에 올라탈 결심MLOps를 위한 Open Source Tool들이 다양했지만, 최근에는 모델 실험 및 버전 관리를 위한..

서론실무에서 머신러닝을 활용하는 도메인 중에서, 추천 도메인의 경우 대게 실시간성보다는 배치 파이프라인 만으로 요구사항을 충분히 만족시킬 수 있는 거 같습니다. 현재 팀에서 운영 중인 추천 파이프라인은 배치 형태이며 큰 구조에서 아래와 같은 구성을 하고 있습니다.1. 각 모델별로 필요한 원천 데이터 수집 및 가공2. 모델에 입력 가능한 input으로 변환3. model train&validation4. Batch Inference 실행 및 필요시 결과를 유저별로 aggregation 하여 DB에 업로드Airflow로 스케줄링한 DAG의 마지막 Tasks는 주로 Batch Inference 한 결과를 서비스 요구 수준에 맞는 DB에 업로드하여 API 서버에서 서빙할 수 있도록 하고 있습니다.위 파이프라인..

개요 현재 팀의 Machine Learning 파이프라인의 모델 학습 워크로드는 아래와 같은 컴포넌트들로 구성되어있습니다. 출처: https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/index.html model.train()를 entrypoint로 하는 pod pod node의 gpu resource allocation 및 container가 사용할 device config 정보를 kubelet에 등록하는 nvidia device plugin daemonset pod container runtime 및 runc prestart hook을 통해 container에서 사용할 수 있는 device를 설정해주는 nvidia cont..

서론 배치성 Spark Job은 Airflow에서 trigger 하였지만 Streaming application은 이와 달리 클러스터를 상시 점유하고 있어 다음과 같은 요구사항을 가진다. 애플리케이션 배포, 상태를 선언적으로 관리할 수 있어야 한다. 하나 이상의 Kakfa Topic을 구독하는 애플리케이션(subscriber) 배포 시에 필요한 resource 정의 (코드)를 재활용할 수 있어야 한다. 개발자는 master에 merge 하면 코드는 자동으로 배포되어야 한다. 참고로 필자는 1을 만족하기 위해 ack-emrcontainers-controller를, 2를 위해 helm chart를, 3을 위해 argocd를 사용하였지만, 이는 각자 처한 상황에 맞게 다르게 가져갈 수 있다. 또한 아래 기술들..