안녕하세요. 왓챠 ML팀에서 머신러닝 엔지니어로 일하고 있는 찰스입니다.이전 글에서는 기존 왓챠 ML 파이프라인 및 실험 환경이 가진 문제점에 대해서 살펴보고, 문제를 해결하기 위해 컨테이너 환경의 도입, On-premise GPU 서버와 클라우드 서비스와의 연동, ML 파이프라인과 실험 환경을 제공하기 위해 여러 서비스를 활용한 사례에 대해 살펴보았습니다.이렇게 여러 해결책을 점진적으로 도입한 후 왓챠 ML 파이프라인 및 실험 환경은 기존에 비해 사용성과 안정성에서 많은 개선을 이루었습니다. 다만, 학습된 모델을 서빙하고 모니터링하는 과정은 여전히 개선해야 할 영역으로 남아있었습니다.이 글에서는 왓챠 추천 시스템에서 학습된 추천 모델을 서비스에 반영하기 위해 독립적인 추론 서버가 왜 필요했고 어떻게 개발했는지, 그리고 추론 서버와 추천 모델의 성능을 모니터링하기 위해 어떠한 노력을 기울였는지에 대해서 알아보도록 하겠습니다.기존 왓챠 추천 시스템의 문제점기존 왓챠 추천 시스템은 추천 모델을 학습하고 추천에 필요한 여러 데이터를 정제하는 워커(Worker)와 워커에서 생성한 모델과 정제된 데이터를 이용하여 API 형태로 추천 결과를 제공하는 서비스(Service)로 이루어져 있었습니다.기존 왓챠 추천 시스템이 중 워커는 이전 글에서 설명 드린대로 On-premise GPU 클러스터 내 Argo workflow를 기반으로 작성된 ML 파이프라인으로 이전되었고, ML 파이프라인에서 생성된 여러 모델 및 정제 데이터는 AWS S3와 Redis Pubsub을 통해 서비스로 동기화되어 실시간 반영되고 있었습니다.서비스에서는 업데이트된 학습 모델과 정제 데이터를 활용하되, 하나의 애플리케이션에서 추천 후보 필터링, 전처리, 모델 추론, 후보정과 같은 과정을 거쳐 API 형태로 제공되었으며, 왓챠/왓챠피디아 내 추천 및 랭킹을 필요로 하는 클라이언트로부터 전달받은 여러 요청을 처리하고 있었습니다.이러한 구조의 추천 서비스는 추천 모델과 추천에 필요한 데이터를 애플리케이션 내 메모리에 올려두어 사용하기 때문에 처리 속도가 매우 빠르다는 장점을 가지고 있었지만, Monolithic 서비스 특성상 특정 로직의 수정만으로도 서비스 전체에 배포되어야 하고, 모델의 문제가 추천 서비스 전체 장애로 퍼질 수 있다는 문제점을 가지고 있었습니다.그리고 서비스는 동시성(Concurrency)과 비동기(Asynchronous)를 최대한으로 활용하기에 적합한 Scala로 구현되어 있어 PyTorch로 학습된 추천 모델을 추론하기 위해서는 PyTorch JNI와 같은 Java library가 필요했습니다. 아쉽게도 Pytorch JNI는 Pytorch에서 직접 관리하지 않아 버전 업데이트가 느렸으며 학습과 추론에 효율적인 기능이 PyTorch에 업그레이드되어도 JNI 버전이 업데이트되지 않아 실 서비스에서 빠르게 적용하기가 어려웠습니다. 또한, JNI를 이용하여 모델을 추론했을 때 기본적인 Forward 이외에 지원되는 기능이 제한되어 있어 추론에 필요한 여러 정보를 별도의

안녕하세요. 왓챠 ML팀에서 머신러닝 엔지니어로 일하고 있는 찰스입니다.지난 글에서는 왓챠 추천 시스템을 컨테이너 환경으로 이전하면서 발생했던 여러 고민들을 어떻게 해결했는지 살펴보았습니다. 그 이후 왓챠 ML 팀에서는 왓챠와 왓챠피디아에 사용하는 추천 모델을 다양한 요구 조건에 맞춰 고도화했고, 다뤄야 하는 모델과 데이터가 지속적으로 늘어나게 되었습니다. 이러한 환경 변화에 발맞추어 분산되어 있는 데이터를 통합하여 관리하고 다양한 모델 학습 과정을 최적화하며 학습된 모델을 서비스에 효율적으로 반영하고 모니터링할 수 있는 MLOps에 대한 필요성을 느끼게 되었습니다. 이 글에서는 왓챠 추천 시스템에 MLOps를 어떻게 적용했는지 살펴보고 그 과정에서 발생한 여러 고민들을 어떻게 해결했는지 적어보고자 합니다.들어가기 앞서이 글에서는 MLOps를 적용하면서 있었던 고민과 개선점을 주로 다룰 예정이기 때문에 각 서비스의 설정 과정이나 상세한 기술 이야기를 다루지 않습니다.왓챠 추천 서비스의 MLOps 도입이라는 큰 주제를 하나의 글로 작성하기에는 적합하지 않아 두 개의 글로 나누어 작성할 예정입니다. 이번 글에서는 추천 모델 학습을 위한 ML 파이프라인 및 실험 환경 구축이라는 주제를 다루고, 다음 글에서는 학습된 추천 모델을 서비스에 반영하기 위한 추론 서버 개발이라는 주제로 이야기할 예정입니다.왓챠 추천 서비스는 쿠버네티스(Kubernetes) 내 여러 오브젝트와 Public Cloud 서비스인 AWS(Amazon Web Service)의 다양한 서비스를 활용합니다. 이 글에서는 여러 AWS 서비스와 쿠버네티스 오브젝트가 언급될 예정이고, 독자도 이에 대한 기본 지식이 어느 정도 있다고 가정합니다.MLOps란?최근 ML 분야에 모델 아키텍처나 학습 패러다임의 발전이 거듭되면서 각기 다른 학습 파이프라인을 갖는 다양한 모델을 쉽고 빠르게 서비스하기 위한 방법과 도구가 필요해졌습니다. MLOps는 이러한 필요성을 기반으로 데이터 수집부터 데이터 전처리, 모델 학습 및 평가, 모델 서빙 및 모니터링에 이르는 일련의 과정을 엔드 투 엔드 파이프라인으로 자동화하여 효율적인 모델 개발 및 운영을 도와줍니다.또한, ML팀과 DevOps팀 간의 불필요한 커뮤니케이션 비용을 최소화하고 나아가서는 ML팀이 직접 그들의 모델을 직접 관리하고 운영 및 모니터링할 수 있도록 합니다. 이러한 MLOps 도입을 위해 필요한 여러 컴포넌트를 간단히 살펴보도록 하겠습니다.a. 머신러닝 파이프라인머신러닝 파이프라인(ML Pipeline)은 실 서비스 환경에서 학습한 모델을 서비스에 적용하기까지 일련의 과정을 파이프라인으로 구성하는 것을 말합니다. 머신러닝 파이프라인은 다음과 같은 작업에 대해 자동화가 필요합니다.데이터 수집다양한 원천 데이터로부터 필요한 데이터를 수집할 수 있어야 합니다.2. 데이터 처리수집한 데이터를 모델이 요구하는 형태로 가공할 수 있어야 합니다.불필요한 데이터나 이상치를 제거할 수 있어야 합니다.필요하다면, Feature store를 활용하여 학습

WATCHA server-platform팀에서 서버를 개발하고 있는 rogi, carl이라고 합니다. 개발한 로그 플랫폼에 대해 공유하고자 합니다.개요WATCHA에는 이미 잘 설계된 로그 플랫폼이 개발되어 사용 중인 바 있습니다. 그러나 시간이 지나면서 개발/비개발 양쪽 모두의 상황이 달라짐에 따라 기존 로그 플랫폼이 설계되었던 당시와는 다른 요구사항들이 생겼고, 그에 따른 개선이 필요하게 되었습니다. 요구사항이라 함은 크게 아래와 같은 것들이 있습니다.서비스별 로그 플랫폼과의 통합에 소모되는 비용 해소WATCHA는 지난 몇 년간 Kubernetes를 기반으로 한 MSA 환경을 적극 도입함에 따라, 현재는 Kubernetes 클러스터 내 수십 개의 서비스들이 동작하고 있습니다. 기존 로그 플랫폼은 Kubernetes 환경을 고려하지 않은 상태로 설계되었고, Kubernetes 도입 이후 로그 플랫폼 agent를 sidecar 패턴을 적용하여 사용하고 있었습니다. 이 경우 로그 플랫폼 agent의 설정 및 구성은 각 서비스 개발자의 책임이 되므로 로그 플랫폼이 동작하는 환경을 자세히 알고 있지 않은 서비스 개발자의 입장에서는 로그 플랫폼과의 통합에 불필요한 비용을 사용하게 되는 결과를 낳게 되었습니다. 개선된 로그 플랫폼에서는 로그 플랫폼 agent를 daemonset 형태로 배포하고 각 서비스들은 pod annotation을 통해 쉽게 로그 플랫폼과 통합 가능한 형태로 구성함으로써 이러한 문제점을 해소하고자 하였습니다.2. 확장에 좀 더 열려있는 로그 구조로의 이전기존 로그 플랫폼은 로그 구조를 protobuf로 정의하여 사용하고 있었습니다. 이에 따라 자체적인 IDL, 유연한 schema 발전, 효율적인 serialization 등의 장점을 누릴 수 있었지만, 반대로 JSON 등을 로그 구조로 사용하는 서드파티 플랫폼과의 통합 불가, 개발자가 직접 읽을 수 없는 형태의 raw 로그, 이에 따라 발생한 로그 사용처에 따른 로그 파편화 등의 단점도 직면하게 되었습니다. 개선된 로그 플랫폼에서는 protobuf를 내부적인 로그 구조로 사용하긴 하지만, 이를 기반으로 한 다양한 형태의 serialization을 지원함으로써 이러한 문제점을 해소하고자 하였습니다.3. 지나친 BigQuery 의존성 제거 및 로그 성격에 따른 로그 처리 파이프라인 분리기존 로그 플랫폼은 서버 요청 로그 뿐만 아니라 서버 이벤트 로그, 클라이언트 이벤트 로그, 데이터베이스 스냅샷 등의 데이터들을 전부 BigQuery로 통합하여 다양한 조합의 분석이 가능케 하는 것을 목표로 설계되었었습니다. 이러한 구조는 두 가지의 의도치 않은 문제점을 낳았는데, 하나는 데이터 분석과는 직접적인 연관이 없는 플랫폼 성격의 서버 로그들도 전부 BigQuery로 직접 전송되어 비용 및 유연성의 측면에서 비효율이 발생하는 점, 다른 하나는 서버 개발자가 매 건 명시적인 의도를 갖고 저장하는 것이 아니므로 따라서 semantic이 고정되어 있지 않은 서버 요청 로그를 데이터 분석에 직접 사

스마트TV APP 디자인할 때 고려해야하는 요소OTT 서비스의 가장 큰 특징은 여러 플랫폼에서 콘텐츠 감상을 즐길 수 있는데요, 그중에서도 스마트 티비는 OTT 서비스를 최대로 경험할 수 있는 플랫폼이라고 생각해요.이번 글은 프로덕트 디자이너가 어떻게 스마트TV의 앱을 디자인하는지 알려드리려고 해요.여러분이 만약 프로덕트 디자이너로 스마트TV 앱을 디자인해야 한다면 어떻게 해야 할지 떠오르는 그림이 있나요?사실 우리는 모바일 및 웹의 경험을 설계하는 게 익숙해서 스마트TV의 앱을 디자인하기엔 쉽지 않은 일이라고 생각해요. 생각보다 자료도 많이 없고요. 조금은 특수한 스마트TV 앱을 디자인하는 방법을 이번 글에서 알려드리겠습니다.먼저 TV의 특징을 알아야해요. 일반적으로 가족이 함께 생활하는 집에 TV는 보통 어디에 있나요?Photo: Andres Jasso (Unsplash)대게는 거실에, 보통 소파 앞에 위치해 있어요. 최근에는 LG의 스탠바이미 같은 퍼스널 장비도 나왔지만, 일반적으로는 큰 화면으로 몰입감 있게 콘텐츠를 감상한다는 특징이 있어요. 화면이 크기 때문에 가족들과 함께 시청하기도 하는데요, 다른 거 보고 싶어도 아빠의 채널 주도권 때문에 계속 뉴스를 보던 경험이 생각나네요. 여기서 바로 리모컨으로 조작한다는 특징을 볼 수 있어요.이런 특징을 가진 디바이스를 디자인할 때 고려해야 할 사항은 무엇일까요? 크게는 세 가지 정도로 정리해 볼 수 있어요.1. 포커스가장 큰 특징이자 중요한 부분인데 터치 디바이스에는 없는 ‘포커스’가 있어요.스마트TV는 사용자와 리모컨으로 인터랙션해서 늘 포커스가 어딘가에는 있어야해요. 포커스가 없다면 사용자는 어라, 지금 내가 어디에 있는거지, 어디를 눌러야 하지? (마치 폰에서 터치했는데도 창이 안 닫히는 것과 같은 느낌과 비슷할 것 같아요)Photo: Erik Mclean (Unsplash)그렇기 때문에 버튼을 디자인한다면 꼭 2가지 상태(default / focused)를 같이 만들어야 해요.default (left) focused (right)시안에도 기본으로 포커스가 어디에 있어야 하는지 표시해주는 것도 개발자와 커뮤니케이션하는데 중요합니다.페이지 진입했을 때, 포커스가 어디에 기본적으로 위치해 있는지 시안에서 알려줘야 해요버튼을 설계할 때 주의해야 하는 상황은 명확하게 상하좌우로 갈 수 있는 위치에 있어야 해요. 개발적인 부분에서도 휴리스틱으로 사람이 인지하는 것과 달리 컴퓨터는 가까운 거리로 계산해서 이동하기 때문에 명확하지 않으면 개발 단계에서도 어려움을 겪어요.개발자에게도 화면에서 포커스를 처음에 어디에 위치해야 하는지, 어떻게 이동하는지 등 커뮤니케이션해야 최종적인 결과물에서도 설계한 대로 잘 구현될 수 있어요.아래는 하면 안 되는 사항들만 모아서 예시로 보여주기 위해서 그려봤어요.잘못된 예시 (왓챠 서비스에는 없는 화면이에요)지금 상태에서 위로 올라가면 [간편결제]와 [카드 정보 변경] 중 어디로 가야할지 몰라요.돌아가는 버튼은 좌측 오른쪽에 있어서 사용자가 리모컨으로 이동하기에