brunch

You can make anything
by writing

C.S.Lewis

by 티맵모빌리티 Mar 11. 2022

주행 데이터로 실시간 핫플 랭킹 서비스 개발하기

7편 – 실시간 데이터 수집·처리를 위한 T지금 시스템 구축기

Chapter 1. 데이터

1-1. 과거의 혼잡도 관련 서비스

1-2. 데이터 처리

Chapter 2. 시스템 구축

2-1. Near Realtime Crawling

2-2. Merge & Convert

2-3. Index & Search

마치며

코로나19로 인해 외출이 꺼려지고 사람이 많은 곳에 가고 싶지 않은 요즘, 추천하고 싶은 TMAP 서비스가 있는데요. 바로 T지금입니다.


T지금은 내비게이션 주행 데이터를 이용한 실시간 데이터 처리 기술 기반 서비스로, 접속 시점에서 사용자 주변의 ‘실시간 인기 장소’를 랭킹으로 보여줍니다. T지금 탭뿐만 아니라 TMAP 검색창에서도 실시간 T지금 정보를 확인할 수 있어요. ‘이마트’ 검색하시면 가장 붐비는 지점이 어딘지 확인할 수 있는 식이죠! 

그럼 이렇게 혁신적인(!) T지금 서비스는 어떻게 만들어졌는지 구축하면서 고민했던 부분이나 적용 과정 등을 공유드리고자 합니다.


Chapter 1. 데이터
1-1. 과거의 혼잡도 관련 서비스

과거의 내비게이션 혼잡도 서비스는 크게 2가지로 나눠볼 수 있습니다.


첫째는 ‘도로 혼잡도’ 서비스입니다. 내비게이션 주행 차량 중 도로를 주행하는 차량의 주행 속도 정보를 기반으로 실시간으로 분류하는 시스템입니다. 각 도로별 혼잡 여부를 원활, 서행, 혼잡 등으로 직관적으로 보여주며 해당 지역의 도로 흐름을 한눈에 파악할 수 있습니다. 다만 교통 신호 행사나 공사 등의 외부 변수에 영향을 크게 받고 직관적으로 혼잡 여부를 판단하기에 어려움이 있습니다. 

두 번째는 ‘시간대별 혼잡도’ 서비스입니다. 과거 이력을 바탕으로 시간대별/요일별로 ‘해당 장소에 도착하는 유저의 비율’에 대한 정보를 제공하는 서비스인데요. 이 또한 다른 시점과의 상대적인 차이를 보여주는 방식이기 때문에 해당 장소에 대한 직관적인 정보로 활용하기에는 부족합니다. 

저희는 이보다 더 업그레이드된 혼잡도 서비스를 만들고자 했습니다. 그래서 실제 주행 데이터를 활용해 어뷰징에 강한 스코어를 개발하고 이를 실시간으로 집계하면서, 보다 의미 있는 혼잡도 정보를 제공하고자 했습니다. 바로 T지금입니다. 


1-2. 데이터 처리

T지금 스코어는 아래와 같은 방식으로 실제 주행 데이터를 사용해 집계됩니다.


티맵 서비스를 이용 중인 단말을 통해 차량의 속도, 향해 가고 있는 목적지, 현재 위치 등 차량 주행에 관련된 다양한 데이터를 수집합니다. 하지만 해당 데이터는 로그 수집기를 통해 주기적으로 수집되기 때문에 같은 내비게이션 사용자가 중복으로 여러 번 길안내를 요청할 수 있다는 문제가 있는데요. 그래서 유저별 ‘가장 최근 길안내 요청’을 ‘최종적으로 해당 장소에 가는 유저’로 집계하는 로직을 거칩니다. 이를 통해 티맵 유저의 실시간 주행 정보를 파악할 수 있는 것이죠.


집계의 기준이 되는 장소 데이터도 한차례 가공이 필요합니다.


장소에는 여러 가지 다른 동의어가 존재하는데요. 어떤 장소에 대한 실제 이름, 지번 주소, 도로명 주소, 해당 장소에서 전용으로 운영하는 주차장, 그리고 해당 장소가 어떤 건물이나 쇼핑몰 같은 거대한 장소인 경우 내부에 속해 있는 장소(ex. 스타벅스 하남 스타필드 지점)까지도 모두 ‘장소’입니다. 따라서 위와 같은 여러 가지 동의어를 통합하는 과정을 거친 후, 실제 이동 중인 유저를 집계하는 T지금 추천 엔진에 연동하는 과정을 주기적으로 거치고 있습니다. 


Chapter 2. 시스템 구축
2-1. Near Realtime Crawling

실시간 데이터 처리를 위해 얼마나 실시간에 가깝게 데이터를 수집할지, 수집한 다양한 데이터를 어떤 방법으로 머지할지, 머지한 데이터를 서비스하기 좋게 어떻게 변환할지, 마지막으로 그 데이터를 서비스에 빠르게 노출하기 위해 어떤 방법을 선택할지에 대한 고민이 있었습니다. 


먼저 준 실시간에 가깝게 데이터 수집을 하기 위해서 사용자 앱에서 넘어오는 정보들은 카프카를 이용해서 시스템에 바로 하둡에 적재하도록 했습니다. 그리고 다른 외부 데이터들은 보안상의 이유로 바로 데이터를 가져올 수 없는 경우가 있어 파일로 전달받으면 바로 읽어 카프카로 보내 시스템에 적재하도록 하였습니다. 

2-2. Merge & Convert

하둡에 적재된 다양한 데이터들을 먼저 머지한 뒤 각 서비스에 맞게 변환하는 작업을 진행하고 있는데요. 저희는 es-Hadoop 라이브러리를 이용하여 spack과 elasticsearch 사용을 편하게 진행했습니다. 머지할 때는 dataframe으로 진행하였고 컨버팅 할 때는 rdd를 이용했습니다. Collection type 일 때 rdd가 더 성능이 좋아서 사용했습니다. 

(출처: https://posts.specterops.io/threat-hunting-with-jupyter-notebooks-part-3-querying-elasticsearch-via-apache-spark-670054cd9d47)


2-3. Index & Search

최종 결과를 실시간으로 업데이트할 때는 ‘110만 건 이상의 데이터들을 5분 이내로 업데이트’ 하고 ‘검색 성능에도 크게 영향이 없게 해야 한다’는 목표가 있었습니다.


특히나 검색 poi는 형태소 분석기도 사용하고 있어 색인 작업이 굉장히 무거운데요. 이 부분을 개선하기 위해서 2가지가 필요했습니다.


1. 같은 내용은 업데이트하지 않는다.

2. 기존 poi문서에 업데이트할 경우 성능 저하가 심하기 때문에 분리해야 한다.


1번은 es-hadoop에서 update를 할 경우 알아서 같은 내용은 업데이트하지 않기 때문에 해당 라이브러리만 사용하면 문제가 없었습니다.


2번은 api에서 여러 번 호출해서 머지할지, 아니면 색인에서 머지 가능한 방법이 없는지 고민하다가 Elasticsearch에서 prent – child + routing 기능을 사용해 색인에서 문서를 물리적으로 분리한 뒤 Elasticsearch sql에서 바로 머지 가능한 구조로 구현하였습니다. 이를 통해 곧바로 poi에 업데이트하는 것보다 시간을 30분에서 2분 정도로 줄일 수 있었습니다. 


마치며


T지금 서비스를 이용하면 낯선 장소에 방문했을 때도 근처에 가볼 만한 곳이 어디인지, 이 장소가 얼마나 혼잡한지 실시간으로 알 수 있습니다. 여행을 갔을 때나, 내 주변 핫플이 궁금할 때, 또는 붐비는 곳을 피하고 싶을 때 모두 유용한 서비스죠:)


물론 아직 출시한 지 얼마 되지 않아 서비스나 시스템 모두 개선의 여지가 많습니다. 좀 더 효율적인 방법으로 보다 다양한 혼잡/선호 점수를 제공할 수 있도록 차근차근 개선해나가고 있고요. 계속 발전해 나가는 T지금 서비스를 기대해 주세요. 감사합니다.  


매거진의 이전글 버그 없는 업데이트를 위해 - QA 테스트 자동화

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari