Google BigQuery와 Data Studio를 활용한 앱 광고 매출 대시보드 개발기

더핑크퐁컴퍼니 웹개발팀이 AWS RDS 와 PHP 로 돌던 앱 광고 매출 분석 시스템을 BigQuery 와 Data Studio 로 옮긴 기록이다. 트래킹 플랫폼을 1곳에서 8곳으로 늘려달라는 요구가 계기였고, 플랫폼이 늘 때마다 테이블과 프론트를 함께 손봐야 하는 기존 구조를 갈아엎기로 했다.

핵심 포인트

기존 시스템은 광고 플랫폼 하나를 추가할 때마다 테이블을 새로 만들고 프론트도 손봐야 했으며, 앱 정보와 광고단위 정보를 수동으로 관리하고 있었다.
첫 후보였던 elasticsearch 와 Kibana 는 RDB 의 relation 개념이 없어 매출 정보와 앱 정보를 별도 인덱스로 두고 조인할 수 없었다.
로그와 달리 앱 정보나 광고단위 정보는 운영 중 수시로 바뀌는 데이터라 그 조합이 맞지 않았고, 스토리지 확장 이슈도 단점으로 봤다.
BigQuery 는 완전관리형이라 확장 대응이 쉽고 SQL 과 테이블 간 relation 을 지원하며, 쿼리 결과를 구글 시트나 Data Studio 로 바로 보낼 수 있다.
단점은 키나 인덱스 개념이 없어 무조건 풀스캔이라는 것이다. 다만 이 시스템은 분석 작업 때만 쿼리가 도는 OLAP 성격이라 감수할 만하다고 판단했다.

상세 정리

BigQuery 구조는 GCP 프로젝트 아래 데이터세트를 두고 그 안에 테이블을 만드는 형태다. 필드 데이터 유형도 STRING 과 INTEGER 외에 다양하게 지정할 수 있다.
풀스캔이라 스캔량이 늘수록 비용이 오르므로, 큰 테이블을 파티션으로 나누면 성능과 비용을 함께 잡을 수 있다.
테이블 생성 시 데이터를 쿼리하려면 WHERE 절이 필요하다는 항목에 체크하면, 매 쿼리마다 파티션 기준 필드를 WHERE 로 걸어야 하고 그렇지 않으면 에러가 난다.
실측 비교도 실었다. 같은 테이블에서 전체 기간과 올해 기간으로 범위를 좁히자 처리 및 청구 바이트와 소요 시간이 함께 줄었다.
결론은 데이터가 계속 늘어날 테이블에는 파티션을 필수로 설정하는 것이 좋다는 것이다.
적재는 공식 node.js 클라이언트로 한다. 키 파일과 프로젝트 정보를 넘겨 BigQuery 인스턴스를 만들고 기능을 호출한다.
데이터를 넣는 방법은 두 가지다. 스트리밍 삽입은 거의 실시간으로 들어가지만 비용이 청구되고, 넣은 데이터는 30분간 DML 로 삭제나 변경을 할 수 없으며 프로젝트별 초당 1GB 같은 제한도 있다.
DML 방식은 실시간성은 없지만 하루 실행 수 제한이 없고 삽입 직후부터 자유롭게 수정과 삭제가 가능하다.
광고 매출 데이터는 배치로 매일 가져오므로 실시간이 필요 없어 DML 방식을 골랐다.
시각화는 필요한 쿼리 결과를 뷰 테이블로 만들고, 그 뷰들을 Data Studio 대시보드에 리소스로 연결해 구성했다.
Data Studio 는 표와 시계열, 막대 등 다양한 그래프를 제공하고 Kibana 와 달리 색상 테마와 레이아웃을 자유롭게 지정할 수 있었다.
저자는 기존이 RDB 환경이고 빠른 쿼리 속도가 꼭 필요하지 않으며 사용 빈도도 낮다면, elasticsearch 보다 BigQuery 가 작업하기 쉬울 것이라고 정리한다.