발표 개요와 통계의 필요성
빠른 정보 제공을 위한 통계 시스템 개선 과정을 소개하며 발표 순서를 안내한다. 많은 서비스가 데이터 기반 의사결정을 원해 통계 기능 개발을 요구받지만, 배치·쿼리로 만들다 보니 원하는 데이터가 조금만 달라져도 큰 시간과 노력이 들어가는 배경을 설명한다.
기획팀의 전체 회원수 증감 추이, OS 종류, 실시간 확인 같은 요청들을 소개하고, 한정된 리소스로 다 처리하기 힘든 현실을 짚는다. 기획팀이 요청하면 배치를 만들고 다시 수정하는 과정이 끝없이 반복되는 상황을 펜로즈의 무한 계단에 빗대며 개선을 결심한다.
요청들을 모아 시계열·문서형 데이터, 일/월/연 단위 다양화, 실시간·인사이트 필요라는 공통 조건을 도출한다. 데이터 처리 과정(수집·추출·변환·분석·시각화·공유)을 학습하고, 분석보다 시스템 구축이 우선이라 판단해 장애 대응에 유리한 람다 아키텍처를 카파와 비교해 선택한다.
데이터 흐름을 담은 목표 구성도를 제시한다. 수집 레이어→Kafka→스피드/배치 레이어→데이터웨어하우스→시각화로 이어지는 구조에서, 수집·스피드 레이어는 스프링부트로 직접 구현하고 데이터웨어하우스와 분석 도구는 Elasticsearch·키바나로 정한 이유를 설명한다.
시계열·문서형 두 타입을 모두 지원하는 Elasticsearch를 데이터웨어하우스로 선택한다. 최소 3개 마스터 노드가 필요한 클러스터 구조를 설명하며, 마스터 후보 정보를 IP에서 도메인으로 바꿨다가 노드 간 공유 정보와 형태가 달라 클러스터가 안 뜬 오류를, 변경 여지 없는 노드명으로 확정해 해결한 경험을 공유한다.
Kafka에서 받은 데이터를 실시간 처리해 Elasticsearch에 저장하는 스피드 레이어를 스프링부트로 구현한다. 메시지를 객체로 매핑하고 처리를 개발자 구현체에 위임하는 공통 프레임워크로 input/output을 추상화해, 새 실시간 처리 앱을 붙이기만 하면 기존 앱·서비스 수정 없이 새 통계를 만들 수 있게 한다.
하나의 이벤트로 여러 데이터를 만들기 위해 메시지 큐가 필요하다고 보고, 메시지 영속성 측면에서 파일 시스템에 저장하는 Kafka를 RabbitMQ 대신 택한다. 데이터 수집기는 REST API로 JSON 반정형 데이터를 받아 Kafka를 외부로부터 은닉하며, 서버·클라이언트 양쪽에서 수집 요청을 받는 게이트웨이 역할을 한다.
배치 레이어를 비용·데이터 규모 문제로 미구현으로 남긴 아쉬움을 밝히면서도, 다양한 형태 데이터 수집, 실시간 수집·분석, 서비스와 결합된 인사이트, 키바나로 자잘한 수정 요청 감소 등의 성과를 정리한다. 배치 레이어 구현과 그라파나 도입으로 Elasticsearch·MySQL을 통합 대시보드로 보는 향후 목표를 제시한다.