다나와 웹 트래픽 로그 데이터 분석 시스템 도입기

다나와 데이터 파트가 웹 트래픽 로그를 분석하는 내부 서비스를 새로 구축한 기록이다. 도메인 전문가와의 문답으로 요건을 뽑고 용어 사전부터 만든 뒤, AWS Athena 와 OpenSearch 를 저울질해 OpenSearch 를 골랐다. 색인 후 GA4 등 기존 솔루션과 대조하며 예외 케이스를 잡아낸 검증 기간이 가장 길었다고 적는다.

핵심 포인트

요건은 사용자가 들어와 마지막으로 이동할 때까지의 여정 분석이고, 페이지 간 30분 이상 간격이 생기면 다른 세션으로 본다.
개발자와 도메인 전문가의 배경이 달라 말이 어긋나므로 페이지 뷰, 유입 페이지, 유출 페이지, 전환 같은 용어 사전을 먼저 만들었다.
분석 결과가 늦어도 1분 안에 나와야 한다는 성능 요건이 기술 선택을 갈랐다.
최종 후보는 AWS Athena 와 OpenSearch 였고, 색인과 검색, 집계가 모두 필요한데 그 둘이 빠르고 클라우드로 쓰면 관리 포인트도 줄어드는 OpenSearch 를 택했다.
검증은 하루, 일주일, 한 달, 3개월 단위로 사내 인사이트와 GA4 같은 기존 웹로그 솔루션과 증감 추세를 대조하는 방식으로 했다.

상세 정리

요건 도출은 기획 겸 데이터 분석 담당자와 나눈 문답을 재구성해 싣는다. 세션 단위로 이동 페이지의 카테고리별 페이지 뷰, 광고를 몇 세션이나 클릭했는지 같은 분석이 필요했다.
봇과 크롤러 로그는 내부에서 쓰는 필터링 기준에 맞춰 걸러야 한다는 요건도 있었다.
Hadoop 을 쓰면 Parquet 형식까지 고려해야 해 아키텍처 고민이 커진다고 봤고, AWS 파트너사인 메가존 클라우드와 회의까지 잡아 검토했다.
OpenSearch 는 Elasticsearch 7.10 에서 갈라져 나온 프로젝트라 유사점이 많고, 데이터 파트가 이미 Elasticsearch 를 스택으로 삼고 있어 데이터 포맷 설계에 큰 어려움이 없었다.
어뷰저 판별 기준은 구체적이다. IP 는 하나인데 유저를 판별하는 ID 가 전부 다르면서 특정 페이지만 조회하면 어뷰저로 본다.
이 필터링 조건을 먼저 확인해 데이터 필터 라이브러리로 만들고, 정리한 요건을 하나씩 배치 작업으로 OpenSearch 에 색인했다.
타사 솔루션을 완전히 신뢰할 수 없고 클라이언트 사이드 로깅이라 네트워크 패킷 유실도 감안해야 하므로, 정확한 일치가 아니라 증감 추세와 대략적인 개수로 비교했다.
검증 기간이 가장 길었는데 색인 시간이 오래 걸린 데다 비교 대상이 많았기 때문이다. 대신 그 기간에 예외 케이스를 많이 발견해 데이터가 정교해졌다.
분석 내용은 쿼리로 만들어 API 로 제공했다. 결과를 보고 싶어 하는 내부 팀이 많아 API 형태가 양쪽 모두를 만족한다고 판단했다.
지금은 관리자 대시보드를 맡은 팀과 연계해 UI 를 붙여 접근성과 가독성을 높이는 작업을 진행 중이다.
엣지 케이스는 PC 와 모바일 영역을 나눠 페이지별로 점검하며 찾는다. 최근에는 모바일에서 구글을 통해 유입될 때의 로깅 이슈를 발견해 색인 시점에 로깅 데이터를 변경하는 방식으로 처리했다.
대응 주체를 정할 때는 자기 팀과 타 팀 중 어느 쪽이 더 빠르고 근본적으로 처리 가능한지를 저울질한다. 이번 건은 색인 단계에서 바꾸는 편이 더 적은 작업으로 끝났다.
남은 고민도 적는다. OpenSearch 를 떠나야 한다면 차선책은 Hadoop 과 Hive 이고 요건을 맞추려면 캐시를 미리 만들어둬야 한다고 본다. 엣지 케이스가 추가로 나오면 검증 후 재색인이 필요한데 그 범위 정책은 아직 정해지지 않았다.