See the engineering behind real-time personalization at Tripadvisor’s massive (and rapidly growing) scale 트립어드바이저는 귀하가 사이트와 상호 작용할 때 이 점을 평가하려고 시도하고, 매 번 클릭하면 점점 더 관련 정보를 제공합니다.이 개인화는 AWS에서 실행되는 ScyllaDB에 저장된 데이터에 작용하는 고급 ML 모델에 의해 구동됩니다. 이 기사에서 Dean Poulin (Tripadvisor 데이터 엔지니어링 리드 인 AI 서비스 및 제품 팀)은이 개인화에 어떻게 영향을 미치는지 살펴 봅니다.Dean은 Tripadvisor의 대규모 (그리고 빠르게 성장하는) 규모에서 실시간으로 개인화를 제공하는 데 관련된 기술적 도전의 맛을 공유합니다. 다음과 같은 AWS re:Invent talk를 기반으로합니다. Pre-Trip 지향성 딘의 말에 의하면 트립어드바이저는 2000년에 설립된 트립어드바이저가 여행 및 환대 분야의 세계적인 리더가 되었으며 수억 명의 여행객이 완벽한 여행을 계획하는 데 도움을 줍니다.트립어드바이저는 18억 달러 이상의 수익을 창출하고 NASDAQ 증권 거래소에 공개적으로 거래된 회사입니다.오늘날 우리는 2,800명 이상의 재능있는 직원들이 혁신을 추진하고 있으며 플랫폼은 매월 400만 명의 독특한 방문자를 제공합니다. 매일, 우리의 시스템은 25~50백만 명의 사용자로부터 2억 건이 넘는 요청을 처리합니다. Tripadvisor에서 클릭하는 모든 클릭은 실시간으로 처리됩니다. 그 뒤에, 우리는 기계 학습 모델을 활용하여 개인화된 권고를 제공합니다.이 개인화 엔진의 핵심은 AWS에서 실행되는 ScyllaDB입니다.이로 인해 몇몇 조직이 도달할 수 있는 수준의 밀리초 지연을 제공할 수 있습니다. . 425K operations per second on ScyllaDB with P99 latencies for reads and writes around 1-3 milliseconds 우리는 여행자가 완벽한 여행을 계획하기 위해 필요한 모든 것을 발견하는 방법을 탐구 할 것입니다 : 숨겨진 보석, 꼭 봐야 할 명소, 잊을 수없는 경험, 또는 머물고 저녁 식사 할 수있는 최고의 장소를 발견하든 간에.이 기사는 그 뒤에있는 엔지니어링에 관한 것입니다. 개인화된 Trip Planning Tripadvisor 홈 페이지에 도착하자마자 Tripadvisor는 이미 당신이 요리사, 모험가 또는 해변 애호가인지 알고 있으며 자신의 관심사에 맞게 개인화 된 것처럼 보이는 스팟온 추천을보고 있습니다. 귀하가 Tripadvisor를 검색할 때, 당사는 귀하의 현재 및 이전 브라우징 활동에 따라 점수를 계산하는 기계 학습 모델을 사용하여 귀하가 보는 것을 개인화하기 시작합니다. 당사는 귀하가 관심을 가질 것이라고 생각하는 호텔과 경험을 권장합니다. 당사는 귀하의 개인적인 선호도에 따라 호텔을 정렬합니다. 당사는 귀하가보고 있는 호텔 근처의 인기 있는 관심사점을 권장합니다. 이들은 귀하의 개인적인 선호도와 이전 브라우징 활동에 따라 조정됩니다. Tripadvisor의 모델 서비스 아키텍처 Tripadvisor는 Kubernetes on-prem 및 Amazon EKS에서 수백 개의 독립적으로 확장 가능한 마이크로 서비스에서 실행됩니다.Our ML Model Serving Platform is exposed through one of these microservices. 이 게이트웨이 서비스는 고객 서비스에서 100개가 넘는 ML 모델을 추출하여 실험 플랫폼을 사용하여 최상의 모델을 찾기 위해 A/B 테스트를 실행할 수 있습니다. ML 모델은 주로 데이터 과학자와 기계 학습 엔지니어들이 Kubeflow의 Jupyter 노트북을 사용하여 개발합니다. ML Flow를 사용하여 관리 및 훈련을 받고 Kubernetes의 Seldon Core에 배포합니다. Custom Feature 스토어 기능 스토어는 주로 사용자 기능과 정적 기능을 제공합니다. 정적 기능은 매우 자주 변경되지 않기 때문에 Redis에 저장됩니다.우리는 데이터 파이프라인을 매일 실행하여 오프라인 데이터 스토어에서 데이터를 정적 기능으로 기능 스토어에 로드합니다. 사용자 기능은 Visitor Platform이라는 플랫폼을 통해 실시간으로 제공됩니다.We execute dynamic CQL queries against ScyllaDB, and . we do not need a caching layer because ScyllaDB is so fast 우리의 기능 스토어는 초당 최대 5 백만 개의 정적 기능과 초당 반 백만 개의 사용자 기능을 제공합니다. ML 기능이란 무엇인가요? Features are input variables to the ML Models that are used to make a prediction.There are Static Features and User Features. 정적 기능의 일부 예는 레스토랑이 수상한 상이나 호텔이 제공하는 시설 (무료 Wi-Fi, 애완 동물 친화적 인 또는 피트니스 센터와 같은)입니다. 사용자 기능은 사용자가 사이트를 탐색하는 동안 실시간으로 수집됩니다. ScyllaDB에 저장하여 빠른 쿼리를 얻을 수 있습니다. 일부 사용자 기능의 예는 지난 30분 동안 탐색된 호텔, 지난 24시간 동안 탐색된 레스토랑 또는 지난 30일 동안 제출된 리뷰입니다. The Technologies Powering 방문자 플랫폼 ScyllaDB는 방문자 플랫폼의 핵심입니다. Java 기반의 Spring Boot 마이크로 서비스를 사용하여 플랫폼을 고객에게 노출합니다. 이것은 AWS ECS Fargate에 배포됩니다. 우리는 매일 데이터 보관 작업을 위해 Kubernetes에서 Apache Spark를 실행하고 오프라인에서 온라인으로 작업을 수행합니다. 그런 다음 그 작업을 사용하여 오프라인 데이터 창고에서 데이터를 ScyllaDB로 로드하여 라이브 사이트에서 사용할 수 있습니다. 우리는 또한 Amazon Kinesis를 사용하여 스트리밍 사용자 추적 이벤트를 처리합니다. 방문자 플랫폼 데이터 흐름 다음 그래픽은 네 단계로 데이터가 우리의 플랫폼을 통해 어떻게 흐르는지 보여줍니다 : 생산, 섭취, 조직 및 활성화. 이 데이터 중 일부는 크로스 디바이스 사용자 정체성 차트, 행동 추적 이벤트 (페이지 뷰 및 클릭과 같은) 및 Kinesis를 통해 진행되는 스트리밍 이벤트를 포함합니다. Visitor Platform의 마이크로 서비스는 이 데이터를 흡수하고 조직하는 데 사용됩니다.The data in ScyllaDB is stored in two keyspaces: Visitor Identity Graph을 포함하는 Visitor Core keyspace Visitor Metric keyspace, Facts and Metrics(사람들이 사이트를 탐색하면서 했던 것들) 우리는 플랫폼의 데이터를 유지하고 정리하기 위해 매일 ETL 프로세스를 사용합니다.We produce Data Products, stamped daily, in our offline data warehouse – where they are available for other integrations and other data pipelines to use in their processing. 숫자에 따라 방문자 플랫폼을 살펴보십시오 : 왜 두 개의 데이터베이스? 우리의 온라인 데이터베이스는 실시간, 라이브 웹 사이트 트래픽에 초점을 맞추고 있습니다. ScyllaDB는 매우 낮은 지연 시간과 높은 전송량을 제공함으로써이 역할을 수행합니다. 우리는 온라인 데이터베이스의 데이터가 무한히 성장하지 않도록 단기 TTL을 사용하며 데이터 보존 작업은 실제 방문자에 대한 사용자 활동 데이터 만 보관하는 것을 보장합니다. Tripadvisor.com은 봇 트래픽을 많이 받으며 데이터를 저장하고 봇을 개인화하려고하지 않으므로 모든 데이터를 삭제하고 청소합니다. 우리의 오프라인 데이터 저장소는 보고서, 다른 데이터 제품 만들기 및 ML 모델 교육에 사용되는 역사 데이터를 저장합니다.우리는 라이브 사이트의 성능에 영향을 미치는 대규모 오프라인 데이터 프로세스를 원하지 않으므로 두 가지 다른 목적으로 사용되는 두 개의 별도의 데이터베이스가 있습니다. 방문자 플랫폼 마이크로 서비스 우리는 방문자 플랫폼을 위해 5 개의 마이크로 서비스를 사용합니다.We use 5 microservices for Visitor Platform: Visitor Core는 쿠키 및 장치 ID를 기반으로 장치 간 사용자 정체성 차트를 관리합니다. Visitor Metric은 우리의 쿼리 엔진이며, 이는 특정 방문자에 대한 사실과 측정을 노출 할 수있는 기능을 제공합니다.우리는 방문자 쿼리 언어 또는 VQL라는 도메인 특정 언어를 사용합니다.이 예제 VQL은 지난 3 시간 동안 최신 상업 클릭 사실을 볼 수 있습니다. Visitor Publisher와 Visitor Saver는 글쓰기 경로를 처리하여 데이터를 플랫폼에 기록합니다.ScyllaDB에서 데이터를 저장하는 것 외에도 데이터를 오프라인 데이터 저장소로 스트리밍합니다. Visitor Composite는 배치 처리 작업에서 데이터를 게시하는 것을 단순화합니다.It abstracts Visitor Saver and Visitor Core to identify visitors and publish facts and metrics in a single API call. Roundtrip Microservice Latency 근처 오락거리 이 그래프는 우리의 마이크로 서비스 지연이 시간이 지남에 따라 안정적으로 유지되는 방법을 보여줍니다. 평균 지연 시간은 2.5 밀리 초에 불과하며 P999은 12.5 밀리 초 이하입니다.이것은 인상적인 성능입니다, 특히 우리가 하루에 10 억 개 이상의 요청을 처리한다면. 우리의 마이크로 서비스 고객은 엄격한 지연 요구 사항을 가지고 있습니다. 95%의 통화는 12 밀리 초 이내에 완료해야합니다. ScyllaDB Latency 부근의 호텔 다음은 3 일 동안 ScyllaDB의 성능의 스냅샷입니다. 피크에서 ScyllaDB는 초당 340,000 작업을 처리하고 있습니다 (예를 들어 작성 및 읽기 및 삭제) CPU는 단지 21 %로 움직이고 있습니다. ScyllaDB는 우리를 위해 마이크로초 쓰기와 밀리초 읽기를 제공합니다.이 수준의 빠른 성능은 바로 우리가 ScyllaDB를 선택한 이유입니다. ScyllaDB에 데이터 파티션 이 이미지는 ScyllaDB에 데이터를 파티션하는 방법을 보여줍니다. Visitor Metric Keyspace에는 두 개의 테이블이 있습니다: Fact 및 Raw Metrics. Fact 테이블의 주요 키는 Visitor GUID, Fact Type, and Created At Date입니다. 복합 파티션 키는 Visitor GUID 및 Fact Type입니다. 클러스터링 키는 Created At Date로 데이터를 날짜로 파티션으로 정렬할 수 있습니다. 속성 열에는 거기서 발생한 이벤트를 나타내는 JSON 개체가 포함되어 있습니다. 일부 예제 사실은 Search Terms, Page Views, and Bookings입니다. ScyllaDB의 Leveled Compaction 전략을 사용합니다.We use ScyllaDB's Leveled Compaction Strategy because: 범위 쿼리에 대한 최적화 그것은 높은 cardinality 매우 잘 처리합니다. 그것은 읽기 힘든 워크로드에 더 좋으며, 우리는 쓰기보다 2-3 배 더 많은 읽기를 가지고 있습니다. 왜 ScyllaDB? 우리의 솔루션은 원래 Cassandra on-prem을 사용하여 구축되었습니다. 그러나 규모가 증가함에 따라 운영 부담도 증가했습니다. 데이터베이스 업그레이드, 백업 등을 관리하기 위해 전용 운영 지원이 필요했습니다. 또한, 우리의 솔루션은 핵심 구성 요소에 대한 매우 낮은 지연률을 요구합니다. 우리의 사용자 정체성 관리 시스템은 30 밀리 초 이내에 사용자를 식별해야합니다. - 그리고 최상의 개인화를 위해, 우리는 이벤트 추적 플랫폼이 40 밀리 초 이내에 응답해야합니다. 우리의 솔루션이 페이지를 표시하는 것을 차단하지 않으므로 SLA는 매우 낮습니다. Cassandra와 함께, 우리는 쓰레기 수집의 성능에 영향을 미쳤습니다. ScyllaDB를 사용하여 Proof of Concept를 실행했으며 Cassandra보다 훨씬 더 나은 전달량을 발견했으며 운영 부담이 제거되었습니다. ScyllaDB는 가능한 가장 낮은 지연 시간을 가진 괴상하게 빠른 라이브 서빙 데이터베이스를 제공했습니다. 우리는 완전히 관리되는 옵션을 원했기 때문에 Cassandra에서 ScyllaDB Cloud로 마이그레이션하여 이중 쓰기 전략을 따랐습니다.이로 인해 초당 40,000개의 작업이나 요청을 처리하는 동안 실시간 마이그레이션을 허용했습니다.이 후, ScyllaDB Cloud에서 ScyllaDB 팀이 자신의 AWS 계정에 ScyllaDB 데이터베이스를 배포할 수 있는 ScyllaDB의 "당신의 계정을 가져오기"모델로 마이그레이션했습니다. 이 차트에서는 ScyllaDB의 BYOA 배포가 어떻게 생겼는지 보여줍니다. 차트의 중앙에서 EC2에서 실행되는 6 노드 ScyllaDB 클러스터를 볼 수 있습니다.And then there are two additional EC2 instances. ScyllaDB 모니터는 Grafana 대시보드와 Prometheus 메트릭스를 제공합니다. ScyllaDB Manager는 백업 및 수리 등 인프라 자동화를 처리합니다. 이 배포를 통해 ScyllaDB는 우리의 마이크로 서비스에 매우 가깝게 배치되어 더 낮은 지연 시간과 훨씬 더 높은 전송량과 성능을 제공 할 수 있습니다. 결론적으로, 나는 당신이 이제 우리의 아키텍처, 플랫폼을 지원하는 기술, 그리고 ScyllaDB가 Tripadvisor의 매우 높은 규모를 처리 할 수 있도록하는 데 중요한 역할을하는 방법을 더 잘 이해할 수 있기를 바랍니다. Cynthia Dunlop에 대한 리뷰 보기 Cynthia는 ScyllaDB의 컨텐츠 전략 고위 이사이며 20 년 이상 소프트웨어 개발 및 품질 엔지니어링에 대해 글을 쓰고 있습니다.