e-commerce 추천 시스템 고도화 하기 시리즈 [1] feature store

서론

실무에서 머신러닝을 활용하는 도메인 중에서, 추천 도메인의 경우 대게 실시간성보다는 배치 파이프라인 만으로 요구사항을 충분히 만족시킬 수 있는 거 같습니다. 

현재 팀에서 운영 중인 추천 파이프라인은 배치 형태이며 큰 구조에서 아래와 같은 구성을 하고 있습니다.

1. 각 모델별로 필요한 원천 데이터 수집 및 가공

2. 모델에 입력 가능한 input으로 변환

3. model train&validation

4. Batch Inference 실행 및 필요시 결과를 유저별로 aggregation 하여 DB에 업로드

추천 파이프라인 예시

Airflow로 스케줄링한 DAG의 마지막 Tasks는 주로 Batch Inference 한 결과를 서비스 요구 수준에 맞는 DB에 업로드하여 API 서버에서 서빙할 수 있도록 하고 있습니다.

위 파이프라인에 대한 전반적이 내용은 아래 테크 블로그에서 소개하고있으니 관심 있으신 분들은 읽어보시길 추천드립니다 :).

https://ridicorp.com/story/machine-learning-pipeline/

리디의 머신러닝 파이프라인 톺아보기 - 리디주식회사 RIDI Corporation

 

그 외 저는 추천 데이터를 서빙하기 위한 각종 기능을 모듈로 구현 및 유지보수, 추천 알고리즘 AB 테스트를 더욱 잘할 수 있도록 환경을 구축 및 개선해나가고 있습니다. 

이번 시리즈에서는 추천 시스템을 유저에게 제공하기 까지의 end-to-end를 관리하면서 겪었던 고민을 다루고, 나아가 개선 사항들을 적용해 나간 과정들을 기술적인 측면에서 다루어 보려 합니다.

본론

개선 할 수 있는 부분들에 대한 고민 그리고 해결책

위 서술한 추천 파이프라인은 얼추 필요한 기능을 모두 갖추어 잘 돌아가긴 하지만, 몇 가지 아쉬운 점들이 있었고 이를 총 5 가지로 정리할 수 있었습니다

(required) 첫 번째, 모델의 input으로 사용되는 데이터에는 여러 비즈니스 요구사항이 녹아있습니다(유저의 블랙리스트 제외, 소장한 아이템 제외 등). 하지만 각 모델 파이프라인별로 필요한 데이터셋을 만들다 보니 비즈니스 로직이 중복 및 분산되어 관리하기가 어려웠습니다. 이는 모델의 수가 많아질수록 우선순위 해결과제가 될 것은 분명했습니다. 따라서 비즈니스 로직을 적용한 데이터셋을 각 모델에서 공통으로 활용하기 좋게 정제하여 Object Storage 위에 offline feature store를 구축하고자 했습니다.

(required) 두 번째, train 및 validation 과정을 거친 모델이 배포되어 inference를 수행하기까지의 과정에 가시성을 전혀 확보하지 못하고 있었습니다. 모델 신규학습은 매주 월, 수, 금 주 3회 스케줄링하고 있습니다. 하지만 validation 과정에서 측정한 target metric(e.g. loss, ndcg) 값에 무관하게 항상 배포되었기 때문에 이를 제어할 수 있는 기능, 그리고 metric을 트래킹 할 수 있는 observability가 필요했습니다.

(required) 세 번째, 운영환경에 배포되어 사용중인 모델의 종류, 모델별 버전이 관리되고 있지 않았습니다. 활용 중인 모델의 수가 시간이 지남에 따라 증가하여 이를 중앙에서 관리 및 조회할 수 있는 플랫폼이 필요해졌습니다. 특히 같은 모델이라도 새롭게 정제한 feature store dataset을 적용한 모델의 경우 보다 나은 성능을 online에서 보여주었는데요, 이러한 경우 해당 모델의 버전 및 메타데이터 형태로 남겨서 추천 모델에 대한 인사이트를 축적할 수 있는 저장소 즉, model registry의 필요성을 느꼈습니다. 

(required) 네 번째, 학습과 추론이 coupling이 되어있어 추론을 실행하려면 직전 학습 후 저장한 checkpoint를 불러와야만 하는 구조였습니다. 업로드하고 있는 추론 결과 테이블은 user 당 추천 결과 set 200개를 가지고 있습니다. 따라서 실시간으로 변하는 유저의 구매 아이템 분포, 아이템 구매 시퀀스를 추천 결과에 반영되지 못하고 있습니다. 이를 위해 실시간 추론 형태로 나아갈 수 있지만, 배치 추론만이라도 매일 실행한다면, 적은 비용으로 어느 정도 커버가 가능하다 생각했습니다. 이를 위해선 위 네 번째에서 고민한 model registry를 모델 메타데이터 중앙 저장소로 활용하면 됩니다.

(optional) 마지막 다섯 번째, Next Step으로서 실시간 추천?
실제 호출되지 않는 유저의 추천 결과까지 매번 추론 및 업로드해야 하는 배치 특성상 불필요한 리소스가 낭비되는 것은 사실입니다. 또한 사내 각 시스템에 점차 머신러닝 활용 범위가 확대되고 있는 추세이다 보니, 장차 팀에서 제공하는 추천 모델을 API 형태로 제공할 수 있으면 좋겠다고 생각했습니다. 이는 모델 서빙 서버 구축, 추론 최적화, 모니터링 시스템 구축 등 꽤나 많은 리소스와 전문성을 요구하는 일일 것입니다. 이는 비즈니스 우선순위가 아니기 때문에, 사이드 프로젝트로 진행하며 별도 게시글로 다뤄볼 예정입니다.

내가 생각하는 Next Recommendation System의 모습

1. 각 모델을 개발하는 엔지니어 or 데이터사이언티스트는 feature store 명세만 보고 개발하면 되어 더 이상 비즈니스 로직에 대해선 고민할 필요 없어짐. 모델의 inference 결과를 feature로 재활용도 가능.

2. 신규 학습되어 배포된 모델 버전의 metric을 slack 으로 report 받고, 대시보드 형태로 관리할 수 있음.

3. 배포된 모델(approved status) 의 online metric이 특정 범위 이상으로 하락할 시, alert를 받고 이를 다시 이전 버전으로 롤백할 수 있음.

4. 필요시 모델 서빙 서버를 간단하게 생성하고 운영할 수 있음.

현재 1, 2, 3, 4 을 모두 구현 및 테스트해보았고, 각각 별도 게시글로 다룰 예정입니다. 그중 이번 1편에선 제가 리드하고 있는 데이터 엔지니어링팀의 추천시스템 feature store 도입기 소개를 끝으로 마무리하겠습니다. feature store 도입 후 실제 모델 성능 향상으로 이어지는 꽤나 훌륭한 성과를 거두었기에 테크 블로그로도 소개하게 되었습니다 :). 

https://ridicorp.com/story/ridi-personalization-system-feature-store/

추천 시스템 개선을 위한 Feature Store 도입기 - RIDI Corp.