추천 서비스와 아키텍처[2]-추천 서비스 제공을 위한 아키텍처

추천 서비스를 구현하기 위해 어떤 아키텍처를 구성해야 할까요? 이 글에서는 아키텍처의 중요한 요소와 어떻게 확장성 있는 아키텍처를 구성할 수 있는지 설명합니다.

이전 글 : 추천 서비스와 아키텍처[1]-추천 서비스란 무엇인가에서는 전반적인 추천 서비스에 대해 다룹니다.

추천 서비스의 중요 구성 요소

추천 서비스를 만드는 데 있어서 중요한 구성 요소는 다음과 정리해 볼 수 있습니다. 모든 구성요소가 전부 중요하며 상호 연결되어 있습니다.

• 확장성 있는 서비스를 위한 추천 아키텍쳐
• 추천 모델
• 유저 액션 데이터의 안정적인 수집
• 서비스를 잘 반영하는 Features
• 실시간 데이터 분석

위 요소들 중 추천 아키텍쳐에 대해 자세히 알아봅시다. 또한 추천 모델과 유저 데이터 수집에 대해서도 간력하게 정리해 보겠습니다.

추천 아키텍쳐 (Recommendations Architecture)

추천 서비스를 제공하기 위한 전반적인 아키텍처는 다음과 같습니다.

추천 아키텍처

크게는 실시간 프로세싱과 배치 프로세싱을 통해 데이터가 가공되고, 가공된 데이터가 추천 서비스 레이어에서 클라이언트 쪽에 서비스 됩니다.

• 배치 프로세싱 : 소스 데이터로부터 피쳐 생성, 추천 모델 작업을 수행하며 최종적으로 추천을 위한 데이터를 만드는 작업을 합니다.
• 실시간 스트리밍 프로세싱 : 소스 데이터로부터 실시간으로 데이터를 스트리밍하여 처리합니다. 실시간 분석 결과를 빠르게 처리 가능한 메모리 스토리지에 저장합니다. 데이터를 오래 보관하지 않으며 가장 최근의 유저 액션이나 실시간 분석 결과를 저장하고 추천 api 서버에서 쿼리합니다.
• 추천 데이터 서비스 : 배치, 스트리밍 데이터, 그리고 때로는 검색 데이터를 합쳐 최종적으로 클라이언트에 데이터를 제공합니다. 내부적으로 데이터를 합쳐서 스코어링을 하거나 유저 액션, 카테고리, 랜드마크의 스코어링 등 실시간 추천 모델을 제공합니다.

모든 작업을 자동화하고 퀄리티를 관리하기 위한 다음과 같은 부분이 포함됩니다.

• 추천 메타 데이터 : 추천 데이터를 서비스하기 위해 필요한 모든 정보를 저장합니다. 모델 알고리즘, 버전 등을 포함해 섹션의 정보와 페이지에 대한 정보도 포함합니다. 서비스되는 알고리즘의 변경이나 AB test, 버전 업 등을 포함해 추천 데이터를 서비스하는 과정에서 발생하는 모든 작업을 자동화하기 위해 필수입니다.
• 워크플로우 : 모델, Feature 등 배치에서 발생하는 작업의 플로우를 관리합니다.
• 추천 데모 : 추천의 모델 결과를 눈으로 직접 확인하는 것은 추천 퀄리티에 큰 영향을 미칩니다. 추천 데모는 추천 데이터를 상품 정보와 바인딩 시켜 눈으로 직접 확인해 볼 수 있도록 합니다.

데이터 아키텍처

데이터 관점의 구조로 각 모듈이 처리하는 데이터는 다음과 같습니다.

데이터 관점의 아키텍처

• 데이터 마트 : 상품 정보, 예약 정보, 회원 정보 등 메인 DB로부터 동기화된 데이터와 클라이언트로부터 수집된 로그를 잘 정리된 형태로 저장합니다.
• 추천 모델-배치 데이터 : 각 모델의 데이터를 표준 포맷으로 저장합니다. 표준 포맷을 준수한다면 어떤 방식으로 생성된 데이터라도 하나의 추천 서비스로서 제공 될 수 있습니다.
• 실시간 분석-스트리밍 데이터 : 상품 클릭, 구매 등 실시간 유저 액션과 실시간 통계를 저장합니다. 유저별 히스토리 스코어링, 카테고리 선호도, 랜드마크 선호도 등을 구하는데 사용될 수 있습니다.
• 추천 Provider : 실시간 데이터와 배치 데이터를 결합하여 섹션에 추천 데이터를 제공합니다. 실시간 스코어링, 데이터 병합, 필터링, 중복제거 등의 내부 연산 및 실시간 분석 기능을 수행합니다. MAB와 같이 실시간 AB를 통해 알고리즘을 선택하는 것도 Provider에서 수행할 수 있습니다.
• UI 섹션 : UI에서 추천을 보여주는 영역으로 Provider의 결과를 받아 상품정보를 매핑하여 보여줍니다. 홈, 도시 영역에서는 여러 섹션이 동시에 노출될 수 있습니다.

추천 모델 , Provider, 섹션과의 관계

모델, 데이터, api가 늘어나도 확장성 있는 아키텍처를 유지하려면 각 모듈들의 개념을 잘 정리하는 것이 좋습니다. 각 모듈의 관계를 다음과 같이 정의할 수 있습니다.

추천 구성요소의 관계

• 페이지 : 앱, 웹의 한 페이지를 의미합니다. 페이지 내에 여러 추천 섹션이 나갈 수 있습니다. 꼭 추천 섹션이 아니라도 함께 노출될 수 있습니다.
• 섹션 : UI 상에 추천이 나가는 자리, 보통은 제목과 상품 사진으로 구성된 상품 카드로 표시됩니다. 하나의 UI 페이지에 여러 추천 섹션이 노출될 수 있습니다.
• Provider : 추천 api 서버에서 최종적으로 내보내는 서비스를 말합니다. 여러 섹션에 같은 provider가 제공될 수 있습니다. 하나의 추천 Provider가 여러 추천 모델을 내부 연산에 사용할 수 있습니다.
• 모델 : 내부적으로 사용하는 VT와 같은 추천 엔진을 말합니다. 하나의 모델은 여러 버전으로 관리됩니다. 최종 데이터는 표준에 맞게 처리되어 다양한 모델을 추가, 업그레이드 할 수 있습니다.

추천 모델

추천 아키텍처에서 모델은 퀄리티를 결정하는 매우 중요한 구성 요소 중 하나입니다. 모델은 아키텍처의 다른 구성 요소와 매우 밀접하게 연관되어 있습니다. 좋은 모델을 구현하기 위해서는 서비스에 대한 깊은 이해가 필요합니다. 서비스나 다른 구성요소의 고려없이 모델만 따로 고민해서는 실환경에서 좋은 추천 퀄리티를 얻기 어렵습니다. 실환경에서 퀄리티가 안나온다고 모델만 어떤 모델로 변경해서 퀄리티가 잘 나올수는 없는 것이지요.

예를 들어 잘 알려진 CF(Collaborative filtering) 알고리즘을 구현하여 적용한다고 합시다. 이 모델을 그대로 적용하면 실환경에서 좋은 퀄리티를 내기가 어렵습니다. 서비스의 피쳐(Feature)를 얼마나 잘 뽑아내서 적용하느냐는 퀄리티에 매우 큰 부분을 차지합니다. 이런 모델을 그대로 실환경에 적용하는 것은 좋은 방법이 아닙니다. 이런 경우에는 피쳐를 다양하게 반영할 수 있도록 확장해서 구현해야 할 것입니다. 또 경우에 따라 구현한 알고리즘이 서비스하기에는 너무 오랜 시간이 걸릴 수도 있습니다. 이런 경우에는 실시간에 처리될 수 있도록 실시간 스트리밍 및 분석할 수 있게 실시간 모델을 고려해 볼 필요도 있습니다.

여기서는 추천에 적용될 수 있는 모델에 대해서 간단하게 개요를 설명합니다. 논문상의 모델과 실 서비스 상의 적용은 큰 차이가 있습니다. 성능, 로그, 비용, 리소스등 여러 부분에서 고려해야 할 이슈가 많습니다. 이러한 모델들은 실환경에 적용할 때는 각 서비스에 맞게 어떤 부분은 서로 조합하고, 어떤 부분은 피쳐를 다르게, 어떤 부분은 실시간으로 처리하는 등의 고려가 필요합니다.

CF(Collaborative filtering) — Low rank matrix factorization

• 오래전부터 추천에서 잘 알려진 모델이며, 기본 모델은 사용자의 속성을 기준으로 하는 User CF입니다. 사용자의 속성과 상품의 속성을 매치하는 방식으로 접근합니다. 인수분해한 매트릭스의 차원으로 속성을 매핑하는 방식입니다. Spark에서 ALS 라이브러리로 제공하고 있습니다.
• User CF는 상품을 노출하여 판매를 유도하는 형태의 서비스에서는 최근에는 거의 적용하지 않는 방식으로, Item CF(Item-to-Item)에 비해 퀄리티가 좋지 않습니다. 사용자의 속성을 기준으로 추천을 제공하는 이와 같은 방법은 최종적으로 상품을 추천하는 서비스에서는 퀄리티가 잘 나오지 않습니다. 무엇보다 큰 단점은 피쳐를 다양하게 넣을 수 없다는 데 있습니다. 서비스에 맞게 피쳐를 적용할 수 있도록 확장하고, 정답셋을 유저의 액션을 반영할 수 있도록 확장할 필요가 있습니다.

Item(Item-to-Item) Cf

• 아마존에서 구현하여 실환경에서 크게 효과를 본 모델입니다. 아마존 사이트에 이런 방식으로 “책 추천”이 제공되면서 전세계적으로 크게 조명받기도 했습니다.
• 기존 CF 방식이 사용자의 속성을 기반으로 하는 것에 비해 아이템과 가까운 다른 아이템을 찾는 방식입니다. 어떤 사이트에서 파악할 수 있는 사용자의 속성은 극히 일부이며 사용자는 매우 다양합니다. 몇개의 피쳐로 사용자를 반영한다고 말하기 어렵습니다. 대신 아이템과 아이템의 관련도를 사용자의 액션을 기반으로 계산함으로써 좋은 퀄리티를 낼 수 있습니다. 많은 상품간 피쳐, 아이템에 대한 사용자 액션, 유사도 알고리즘을 함께 적용하여 실환경에서도 좋은 퀄리티를 낼 수 있습니다. 개인화가 필요한 부분은 사용자 액션 히스토리 혹은 사용자 임베딩을 함께 적용할 필요가 있습니다.
• 최근의 개인화 추천은 사용자의 속성을 기반으로 하는 것이 아닌 사용자의 액션(user feedback)을 기반으로 합니다. 사용자의 액션을 기반으로 스코어링 한 후 이를 결합하고, 사용자 클릭 시점의 문맥을 피쳐로 반영하여 사용자를 특정 차원으로 매핑하는 사용자 임베딩을 통해 개인화 추천을 구현할 수 있습니다.

FM (Factorization Machines)

• 이 방식은 CF와 비슷하지만 많은 피쳐를 반영할 수 있도록 확장한 모델입니다. 매트릭스를 각 아이템의 피쳐 벡터와 정답셋으로 구성하고, 회소(sparse)한 벡터는 원-핫 인코딩하여 처리하는 방식을 제안했습니다.
• 추천을 딥러닝으로 구현하는 모델은 이 모델을 기반으로 확장하는 방식으로 생각할 수 있습니다.

FFM (Field-aware Factorization Machines)

• FM과 비슷하지만 field의 조합을 반영하는 식으로 발전된 형태입니다.

Wide and Deep Learning

• 구글에서 추천에 딥러닝을 적용한 모델로 와이드 모델과 딥 모델(회소 벡터)을 나누어 처리합니다. 그리고 일부 관련된 피쳐를 서로 교차시킨 피쳐를 모델에 반영합니다. 주의할 점은 이 모델을 적용해도 좋은 퀄리티를 바로 얻지 못할 수도 있습니다. 왜냐하면 추천에 딥러닝을 적용하기 위해서는 impression 로그가 있어야 유저의 선택을 정확하게 정답셋으로 만들수 있습니다. 또한 많은 피쳐로부터 학습하려면 많은 트래픽, 즉 로그가 필요합니다. 이러한 준비가 되지 않으면 좋은 퀄리티가 나오기 어려울 수도 있어, 다른 방법을 함께 사용하는 것도 고려해 볼 필요가 있습니다.
• 사용자의 액션이 피쳐에 반영되려면, 실시간으로 사용자가 랜딩한 페이지에 대한 문맥정보를 쿼리할 수 있어야 합니다. 즉, 주체인 사용자가 다르므로 모든 데이터를 미리 준비할 수 없기 때문에, 런타임의 성능이 중요한 변수가 될 수 있습니다. 이 아키텍쳐 상에서는 서빙을 위한 고려도 포함되어 있는데, 랭킹의 실시간 서비스를 위해 미리 준비해 놓은 랭킹 서버를 사용하는 것을 볼 수 있습니다.

DNN For Youtube

• 이 모델은 유튜브 검색에 적용된 딥러닝 검색 랭킹 모델인데, 실환경에 적용할 수 있는 아주 실전적인 모델입니다. 개인화를 위한 좋은 출발점이 될 수 있습니다. 먼저 비디오를 후보군(Candidate)으로 추리고, 이를 영상 피쳐를 적용해서 랭킹을 구합니다. 영상 감상 히스토리(watch history), 검색 히스토리(search history), 본 시간 등의 피쳐와 사용자, 비디오, 언어 등을 임베딩한 피쳐를 결합하여 학습합니다.
• 개인화 추천을 위해 사용자의 액션 히스토리와 문맥을 사용합니다. 사용자의 속성, 성향은 유튜브에서 파악할 수 없는 외부의 요소가 너무나 많기 때문에, 사용자의 액션(implicit feedback)을 개인화 추천을 위해사용합니다.

DeepFM(Deep Factorization Machines)

• FM에 딥러닝을 적용한 모델이라고 할 수 있습니다. 광고서비스에서 CTR 예측의 퀄리티를 높이려는 모델이며 추천에 딥러닝 고려 시 거의 동일하게 적용해 볼 수 있습니다.

LTR(Learning to rank)

• 검색쪽에서 검색 결과의 랭킹 퀄리티를 올리기 위한 모델로 추천에서도 상품의 랭킹을 적용할 때 고려해볼 수 있습니다. 검색은 (쿼리,결과 리스트)로 구성된다면 추천은 (소스 아이템, 추천 아이템)으로 구성된다는데 있어 상당히 유사합니다. 대부분을 추천에 그대로 적용할 수 있습니다. 정답셋을 구성하는 것도 상당히 닯아 있습니다.
• 그중에서 LTR Pairwise 접근은 Item CF와 구조가 상당히 유사합니다. 하지만 결과를 뽑고 평가하는 방식은 추천에 맞게 변경이 필요합니다. 실환경에 퀄리티 개선에 효과를 볼 수 있는 접근입니다.

마이리얼트립은 이러한 모델에서 여러 아이디어를 취해 서비스에 맞는 형태로 적용하고 있습니다. 단지 추천 섹션 뿐 아니라 카테고리 페이지의 리스팅 상품에도 추천 기술이 활용되고 있습니다.

유저 액션 로그 수집 (User feedback)

앱, 웹 클라이언트로부터의 데이터의 수집은 추천 퀄리티의 근간이 되는 부분으로 매우 중요합니다. 특히 impression 로그의 수집이 중요한데 추천 모델에 딥러닝을 적용하려면 사용자의 액션(implicit feedback)으로 부터 정답셋을 구성하는 것이 굉장히 중요하기 때문입니다.

Impression 로그란 사용자가 어떤 상품을 본 순간 남는 로그를 말합니다. 사용자가 페이지에 진입하더라도 상품은 사용자에게 아직 보이지 않을 수 있습니다. “페이지 view”에 대한 로그만 가지고 있다면 사용자가 상품을 좋아하지 않아서 클릭하지 않았는지, 상품을 아예 못보았기 때문에 클릭하지 않았는지 구분할 수 없습니다. Impression 로그를 처리하려면, 많은 양의 로그를 처리할 수 있도록 견고한 수집 플랫폼이 필요합니다.

추천의 퀄리티는 다음과 같은 로그 수집 이슈에 큰 영향을 받습니다.

• Impression 로그의 수집
• 사용자의 트래픽(로그)이 많아야 함
• 앱, 웹의 모든 액션의 위치에 로그가 있어야 하고, 이를 유실없이 수집해야 함
• 주요 로그(클릭, 구매 등)는 실시간 스트리밍 처리되어야 함

마지막으로

이 글에서는 추천 서비스와 아키텍쳐에 대한 전반적인 내용을 설명하였습니다. 추천 서비스는 고정되어 있는 것이 아니라 추천 개발자의 좋은 아이디어에 의해 서비스가 시작됩니다. 이렇게 시작된 추천 서비스를 퀄리티 있게 구현하려면 아키텍쳐 상의 모든 구성 요소가 확장성 있고 구현되고 서로 잘 연결되어야 합니다. 또한 지속적으로 지표를 관찰하고 업그레이드 하여 품질을 계속 개선하는 것이 중요합니다.

마이리얼트립에서는 추천의 전반적인 개인화와 퀄리티의 개선을 목표로 꾸준히 노력 하고 있습니다. 이는 앞으로도 중요하게 고려되어야 할 추천 개발의 방향이라고 할 수 있습니다. 추천 피쳐와 랭킹 모델의 개선, 실시간 사용자 피드백 개선 더 나아가서는 실시간 AB를 통해 알고리즘을 선택하는 MAB(Multi-Armed Bandit) 고도화도 목표로 하고 있습니다.

추천 개발에 관심이 있으신가요?

마이리얼트립 검색&추천 개발팀은 추천에 관심있는 개발자를 지속적으로 채용하고 있습니다. 서비스를 제안하는 것부터 추천 기술을 사용자에게 노출하는 것까지 스스로 주도하며 도전해볼 수 있습니다. 추천 엔지니어 채용에 관심이 있으시다면 채용공고를 확인해주세요!

🧑🏻‍💻 마이리얼트립 채용 보러 가기