트립어드바이저의 실시간 대용량 데이터 개선 방법

 

이번 포스팅에서는 해외여행 필수 앱인 트립어드바이저가 어떻게 Samza를 성공적으로 도입했는지 알아보도록 하겠다.

트립어드바이저가 생소한 사람들을 위해 잠깐 간단히 설명을 하도록 하겠다.

 

여행 정보를 제공하는 서비스 업체이고 전 세계 870만 개의 숙박시설, 항공사, 맛집, 관광명소 등에 관한 8억 6천만여 건의 여행자 리뷰와 후기를 제공하는 세계 최대의 여행 플랫폼이다. 2019년 기준 월간 방문자 수는 약 4억 6300만 명에 달한다고 한다.

 

세계 여행지 곳곳 마다 방대한 리뷰를 가지고 있어 해외여행 준비를 할 때 해외에 도착했을 때 참고하는 필수적인 앱이라고 할 수 있겠다.

 

하루에 수억명의 방문자와 수십억 데이터를 다루는 사이트인 만큼 어떻게 데이터를 다루는지 상당히 궁금한 곳이기도 하였다. Samza 사용 사례를 보면서 한번 파악해보도록 하자.

 

TripAdvisor의 Samza 도입 목표

기존 Hedwig - Hadoop 맵리듀스로 구성된 ETL (Extract Transfer Load) 시스템을 스트림 프로세싱으로 변환 하고자 Samza를 도입했다.

 

위에서 설명했다싶이 트립어드바이저는 호텔 및 레스토랑 리뷰, 숙박 예약 및 기타 여행 관련 콘텐츠를 제공하는 세계 최대 여행사이트 중 하나이기 때문에 정산 기록, 리포트, 모터링 이벤트 및 애플리케이션 알림을 포함하여 매일 수십억 개의 이벤트를 생산하고 처리한다.

 

Samza를 도입하기전 트립어드바이저는 하둡(Hadoop)을 사용하여 데이터를 ETL 시스템에 전송했다. 이 모델에서 메타데이터는 조인과 슬라이딩 윈도우가 적용된 여러 단계에서 시간별 및 하루치 스냅샷까지 롤업 되었다. 그런 다음 하루치 스냅샷에서 세션 데이터를 추출했다. 매일 약 3억 개의 세션이 생산되었고 이런 해결법은 엔지니어링 팀에게 몇 가지 과제를 안기게 되었다.

 

• 비즈니스 성공 핵심 요인 메트릭스를 생성하기 위한 긴 지연 시간
• 스크립트 및 개발환경 등으로 인한 디버깅과 트러블슈팅의 어려움

 

위의 문제를 해결하기 위해 트립어드바이저 엔지니어링 팀은 하둡 솔루션을 Samza의 멀티 스테이지(multi-staging; 다단계) 파이프라인으로 교체하기로 결정했다.

 

 

Samza를 도입한 새로운 해결방법은 메타데이터는 처음부터 Flume에 의해 수집되고 Kafka(카프카) 클러스터를 통해 처리된다. 카프카 클러스터 다음에는 LookBack 라우터에 의해 파싱 및 정제 작업을 거쳐 다시 재분할된다.

 

그리고 세션 수집기와 부정방지 수집기에 의해 슬라이딩 윈도윙, 그룹화, 조인 그리고 부정행위 탐지 등의 로직을 처리하고 파이프라인은 Samza의 RocksDB 저장소를 사용하여 상태를 집계한다. 마지막으로 업로더는 엘라스틱서치(ElasticSearch), RedShift, 및 하이브(Hive)에 결과를 저장한다.

 

새로 도입한 Samza를 활용한 해결법은 아래와 같이 상당히 의미 있는 개선을 하였다.

• 처리시간이 3시간에서 1시간으로 단축
• 파이프라인의 개별 단계가 독립적으로 확장 가능하게 됨
• 최적화를 이루어 전체 하드웨어 요구사항이 ⅓으로 감소 
• 디버깅 및 테스트가 훨씬 간단해짐.

사용된 Samza의 주요 기능 : 상태 저장 처리, Windowing(윈도윙), 카프카 연동 (kafka-integration)

 

더 자세한 내용은 Converting Hadoop M/R ETL to use Stream Processing at TripAdvisor 여기를 참고하기 바란다.

 

위 링크는 링크드인 행사에서 트립어드바이저가 발표한 유튜브 영상이다. 영어로 진행되니 위 글이 발표 내용을 이해하는데 도움이 되었으면 좋겠다.