GCP Recommendations AI(Retail) 서비스를 활용한 추천 서비스 구축
안녕하세요 . 29CM Data Growth 팀 데이터 엔지니어 윤원진입니다. 이번 포스팅에선 GCP Retail 서비스를 사용하여 추천 서비스를 구축한 전반적인 파이프라인 과정을 공유하기 위해 글을 작성했습니다.
1. 들어가며
29CM에서는 각 고객에게 원하는 상품들을 추천하여 고객들의 니즈를 충족시키고자 추천 파이프라인을 구축했습니다.
29CM 데이터 팀은 DW를 BigQuery로 사용 중입니다. 따라서 BigQuery와 빠르게 확장할 수 있도록 GCP 플랫폼에 추천 서비스 구축을 생각하였고 GCP의 Recommendations AI (Retail) 서비스를 사용하여 추천 서비스 파이프라인을 진행했습니다.
1–1. 29CM 의 추천 서비스
29CM 고객들이 서비스를 사용하며 생성된 행동 이벤트들을 통해 사용자 취향에 맞는 상품들을 GCP Retail 서비스를 활용하여 추천하고 있습니다.
GCP Retail 도입에 앞서 사용할 고객 행동 데이터를 결정하게 된 과정은 아래와 같습니다.
- 현재 Firebase 데이터는 초기 설정 문제로 인해 현재 날짜에서 2일 전 데이터 확인이 가능합니다. 사용자의 니즈는 실시간으로도 계속 바뀌기 때문에 현재 날짜에서 2일 전 데이터를 반영하기보다, 데이터를 가져오는 주기를 앞당겨 사용자의 니즈를 빠르게 반영해야 했습니다.
- 전사적으로 데이터 활용을 Firebase에서 Amplitude로 전환하고 있고, Amplitude 데이터는 2시간 전 데이터까지 확인이 가능하기에 Retail 학습 시 사용자 니즈를 조금 더 빠르게 반영하고자, Amplitude 데이터를 활용하여 진행했습니다.
- 불필요한 데이터들(특수문자 및 오탈자)이 들어가 있는 경우 모델 훈련 시 품질을 낮출 수 있기에 모델 훈련시 데이터의 전처리를 통해 모델의 품질을 고도화함에 있었습니다.
Firebase : 모바일 및 웹 애플리케이션 개발 플랫폼으로, 구글 애널리틱스와 구글 패브릭에서 제공하는 기능들을 포함한 다양한 기능들을 제공합니다. 구글 드라이브와 애널리틱스를 적용해서 어떤 기기에서나 개발할 수 있는 환경을 만들어 주고, 사용자들의 이용 횟수, 광고 효과, 문제 발생 빈도 등을 알려줘서 개발자들이 쉽게 활용할 수 있도록 지원합니다.
Amplitude : 앰플리튜드는 코호트 분석에 매우 용이한 사용자 분석 툴로 특정 기간 동안 공통된 특성이나 경험을 갖는 사용자들을 수많은 기준으로 나누고, 다양한 차트를 활용해 데이터 시각화가 가능한 서비스입니다.
2. 29CM Retail 파이프라인
위 아키텍처는 29CM Retail 파이프라인 아키텍처입니다. 각 단계는 아래의 프로세스로 진행됩니다.
1.Amplitude file이 GCS(Google Cloud Storage)에 적재되고, 매일 오전 7시마다 GCP Dataproc 에서 Spark를 통해 데이터를 가공하여 분석하기 용이한 형태로 BigQuery에 데이터 마팅을 진행합니다.
2. Amplitude 데이터의 유사한 사용자 이벤트 속성끼리 테이블 마팅을 진행합니다.
3. 마팅된 테이블로부터 Retail 서비스 학습 시 사용할 데이터 세트를 ML 프로젝트의 BigQuery로 적재합니다.
4. DE 프로젝트의 Worker 인스턴스를 통해 ML 프로젝트의 Retail 서비스로 모델 학습 시 필요한 BigQuery 테이블을 import 시킵니다.
5. Retail 서비스에서 모델 학습 후, 사용자에게 서빙을 제공하여 생성 후 모델을 평가합니다.
2–1. Amplitude 데이터 파이프라인
Amplitude의 Raw File이 GCS에 떨어지게 되면 Dataproc내 Spark를 통해 데이터를 가공하여 분석하기 용이한 형태로 변환 및 Timezone을 KST로 변환하여 BigQuery 테이블로 적재합니다.
2–2. Amplitude Event Mart 파이프라인
Amplitude Raw File로 부터 생성된 테이블에서 사용자 이벤트 성격에 맞게끔 이벤트 마팅을 진행하였습니다.
마팅의 이유는 분석 시 자주 사용되는 사용자 이벤트의 유형끼리 나누어 데이터 분석 시에도 이점을 가져갈 수 있고, 마팅된 사용자 이벤트 테이블로 Retail 데이터 세트를 생성하여 비용도 절감할 수가 있어 우선으로 작업을 진행했습니다.
내부 정책으로 결정한 비슷한 유형의 Event type을 가진 쿼리 기반으로 Airflow Dag 에서 하루마다 파티셔닝된 BigQuery 테이블에 적재됩니다.
2–3. GCP Retail 서비스 — Dataset 생성
Retail 서비스는 GCP의 완전 관리형 서비스로 머신 러닝을 깊게 알지 못해도 Google의 Retail 내부 알고리즘을 통해 간단한 파이프라인만으로도 모델 구성부터 Endpoint까지 설정할 수 있으며, 훈련을 위한 인프라 구현 없이도 추천 기능을 쉽게 이용할 수 있습니다.
모델 생성 시 가장 중요한 것은 데이터의 품질입니다. Retail 서비스에서도 추천 모델 생성 시 데이터의 품질이 가장 중요합니다. 따라서 Retail 서비스 모델 학습을 위해 GCP에서 요구하는 데이터와 스키마를 지정해서 import 할 수 있도록 진행했습니다.
Retail 서비스에서 요구하는 데이터는 크게 제품 카탈로그 데이터와 사용자 이벤트 데이터로 나누어져 있습니다.
제품 카탈로그
제품 카탈로그는 29CM의 상품의 데이터입니다.
고유 키가 될 상품 ID와 상품명, 가격, 카테고리와 태그 등 다양한 정보를 입력할 수 있습니다.
29CM에서 사용한 속성은 다음과 같습니다.
- Name : 제품의 리소스 이름으로 29CM로 설정함
- Type : 제품유형으로 상품단위 또는 옵션단위를 결정함. 29CM에선 사용의 편의성을 위해 상품단위인 Primary로 선택
- Availability : 상품 판매상태로, 재고의 유무, 재고부족등의 상태를 나타내는 값으로 아래의 현재 29CM 사용하고있는 판매 상태값과 GCP 에서 요구하는 상품 판매상태값과 매핑하여 진행함
이밖에도 판매 수량, 이미지와 같은 추가정보들을 포함하여 데이터셋으로 생성했습니다. 추가적인 파라미터는 아래에서 확인이 가능합니다.
사용자 이벤트
사용자 이벤트는 29CM 웹과 앱을 사용하는 고객들의 행동 데이터입니다. 위 마팅된 Amplitude BigQuery 테이블 내 고객들의 홈페이지 방문 기록, 상품 페이지 방문 기록, 장바구니 담기 기록, 구매 기록 등의 데이터를 추출하여 Retail 서비스에 사용할 데이터 세트를 생성합니다.
모델을 생성하기 위해선 GCP 에서 요구하는 사용자 이벤트 유형의 테이블이 필요합니다. 아래는 각 이벤트 유형 테이블에서 요구하는 필드 값입니다.
사용자 이벤트의 필수값인 VisitorID는 29CM의 UserID를 사용하여 진행했습니다. GCP VisitorID 값은 사용자를 식별할 수 있는 고유 식별자 값을 사용하여 학습했습니다.
추가적인 사용자 이벤트 파라미터값은 아래에서 확인이 가능합니다.
2–4. GCP Retail 서비스 — Dataset import
GCP Retail 서비스에서 제공하는 테이블 import 방식은 GCP Cloud Scheduler를 통해 Retail 서비스로 제공하는 프로세스였습니다.
하지만 Retail Dataset을 만드는 Dag에서 테이블 생성 오류 시 잘못된 데이터가 Retail 서비스에 import 될 수 있어 GCP Cloud Scheduler 서비스를 제거하고, Airflow Dag에 Retail Import 파이프라인을 포함시켜 진행했습니다.
테이블 생성 오류시에 모니터링 및 알림을 통해서 잘못된 Dataset으로 모델 학습 시키는 과정을 사전에 방지하였습니다.
최종적으로 Retail 서비스에서 활용될 Bigquery 데이터 생성과 데이터를 import 시키는 Airflow Retail Dag입니다.
3. 모델 및 서빙 생성
GCP Retail 모델 및 서빙 생성은 GCP 콘솔 상에서 구성이 가능하며 클릭 몇 번만으로도 생성이 되어 프로세스는 간단했습니다.
Retail 학습 시 모델에서 요구하는 데이터를 충족하게끔 90일 이상의 데이터를 import 이후에 Retail 서비스에서 아래와 같이 원하는 모델을 선택하여 생성하였습니다.
29CM에서는 GCP에서 제공해주는 모델 항목들을 활용하였고 일부 모델의 설명은 다음과 같습니다.
모델 생성 후에 project_id와 모델의 이름을 넣어 생성된 모델의 서빙 Endpoint 를 아래와 같이 정상 작동 하는지 확인할 수 있었습니다.
모델 호출 명령어와 결과값은 아래와 같습니다.
모델 호출 input 값
curl -X POST "https://retail.googleapis.com/v2/projects/{project_ID}/locations/global/catalogs/default_catalog/placements/{model_name}:predict" \
-H "Authorization: Bearer {ACCESS_TOKEN}" \
-H "Content-Type: application/json; charset=utf-8" \
--data '{
"validateOnly": true,
"userEvent": {
"eventType": "detail-page-view",
"visitorId": {visitorID},
"productDetails": [
{
"product": {
"id": "1325340"
}
},
{
"product": {
"id": "1325323"
}
}
]
}
}'모델 호출 output 값
"results": [
{
"id": "152626"
},
{
"id": "236236"
},
{
"id": "3276373"
},
{
"id": "347347"
},
{
"id": "373726"
},
],
"attributionToken": "{TOKEN}",
"validateOnly": true
}생성한 모델을 Retail 서비스 평가 탭을 사용하는 방법으로도 모델의 예측값을 확인할 수 있습니다.
추가 개선 사항
GCP Retail 서비스를 사용하여 학습 및 Endpoint의 과금이 모델 1개의 경우 최소 일 600달러가 청구되는 상황으로 비용 감소가 필요해 보였습니다.
Retail 서비스의 모델 결과를 고객에게 서빙하는 API 서버에서 VisitorID 기반으로 Redis Cache를 설정하여 새로 학습되지 않은 상태의 API 재 호출하는 현상을 방지해 하루에 약 80달러까지 줄여 비용 최적화까지 진행하였습니다.
4. 마치며
이번 글에서 GCP Retail 서비스를 사용한 추천시스템을 고도화한 과정을 소개드렸습니다. 사용자의 입맛에 맞게 모델의 튜닝을 할 순 없지만 구글에서 검증된 추천 모델을 사용하여 빠르게 도입하기 좋은 서비스라고 생각했습니다.
GCP Retail 서비스를 통해 추천시스템을 도입하실 분들께 도움이 되셨으면 좋겠습니다.
긴글 읽어주셔서 감사합니다.
[함께 성장할 동료를 찾습니다]
29CM (무신사) 는 3년 연속 거래액 2배의 성장을 이루었습니다.다양한 소스 데이터에서 안전하고 빠르게 수집, 처리, 저장, 제공하도록 파이프라인을 개발하고 운영하며, 제공된 데이터를 활용하여 데이터 기반 의사결정을 돕기 위해 다양한 대시보드를 제작 및 분석을 진행하고 있습니다. 데이터를 활용하여 가치를 창출하고 함께 성장할 동료 데이터 엔지니어 및 데이터 분석가를 찾고 있습니다.많은 지원 부탁드립니다!
🚀 29CM 채용 페이지 : https://www.29cmcareers.co.kr/
📌채용이 완료되면 공고가 닫힐 수 있으니 빠르게 지원해주세요!
