핑크퐁의 통합 데이터 환경 구축기 (feat. Snowflake)

더핑크퐁컴퍼니가 흩어져 있던 데이터를 Snowflake 중심의 통합 환경으로 옮긴 과정이다. 단일 MongoDB 로그 서버에서 시작해 AWS Kinesis 기반 파이프라인, ELK, BigQuery 검토를 거쳐 Snowflake에 정착하기까지의 시행착오가 순서대로 담겼다. 각 단계에서 무엇이 안 맞아 다음으로 넘어갔는지가 핵심이다.

핵심 포인트

자동화된 파이프라인이 없어 사람이 직접 DB와 10여 종의 외부 대시보드에서 데이터를 내려받아 분석하고 있었다.
서비스마다 환율을 따로 크롤링해 시스템별 원화 매출이 다 달라지는 식의 일관성 문제가 있었다.
기존 로그 시스템은 replication 없는 단일 MongoDB라 장애가 연관 시스템으로 전파됐다.
앱 50여 종을 모두 업데이트할 수 없어 리시버 서버를 두고 기존 요청을 라우팅해 Kinesis로 넘겼다.
Elasticsearch는 cardinality 집계가 추정값이라 매출·사용자 지표에는 쓰기 어려웠다.
BigQuery는 Transfer가 필요한 리포트만 골라 담을 수 없고 테이블당 파티션 4,000개 제한이 걸려 Snowflake를 골랐다.

상세 정리

다루는 데이터: 유튜브 매출·구독 통계가 일 130만 건, 앱 170여 종의 사용자 로그가 일 1,300만 건 이상이며 광고·앱 플랫폼 10여 종의 매출 통계와 IPTV처럼 엑셀로 받는 리포트도 있다.
기존 구조의 문제: MySQL은 SQL로, MongoDB는 NoSQL 쿼리로 뽑는 등 저장소마다 특성을 알아야 했고 플랫폼별 제공 형식과 추출 방식도 전부 파악하고 있어야 했다.
리뉴얼 착수 지점: 통합 분석 요구가 늘어난 상황에서 신규 시스템까지 기존 로그 시스템에 얹으면 장애가 그대로 옮겨붙는다고 보고 로그 파이프라인부터 손봤다.
방향 설정: 한정된 인력이 인프라까지 직접 관리하기 어려워 관리 지점을 줄이면서도 스케일 조정이 가능한 managed 서비스를 우선했다.
Kinesis 선택 근거: shard 하나가 초당 1,000레코드 또는 1MB 쓰기와 2MB 읽기를 감당하는데 기존 로그가 초당 평균 150건에 1MB 미만이라 shard 1개로 충분하다고 봤다.
리시버 도입 이유: 앱에서 SDK로 직접 Kinesis에 보내려면 출시된 50여 종을 모두 업데이트해야 하는데 구버전 사용자까지 감안하면 현실적으로 불가능했다.
리시버 검증: k6로 부하 테스트해 노드 하나가 초당 약 710요청을 처리하고 clinic.js로 봐도 이벤트 루프 지연이 없음을 확인한 뒤, 여유를 두고 2대를 ECS 오토스케일링으로 운영한다.
적재 경로: Kinesis에 Data Firehose를 붙여 S3에 주기 적재하고, 준실시간 분석이 필요한 로그는 적재 시점에 Lambda로 Elasticsearch에 실어 Kibana에서 본다.
ELK의 한계 1: terms 쿼리 결과가 기본 10건이고 설정을 올려도 1만 건이며, 전체를 받으려면 scroll이나 search after가 필요한데 Kibana 기본 UI가 지원하지 않아 대시보드에서 전체 집계를 바로 못 본다.
ELK의 한계 2: cardinality 집계가 추정값이라 오차율이 낮아도 매출이나 사용자 수처럼 정확해야 하는 지표에 쓰기 위험하다고 봤다.
ELK의 한계 3: 데이터가 늘자 조회와 로드에서 메모리 제한 관련 오류가 났는데, 운영 경험자가 없고 개발 업무와 병행해야 하는 상황에서 러닝 커브가 높다고 판단했다.
BigQuery를 본 이유: fully managed인 데다 Transfer로 YouTube, Google Analytics, Admob 데이터를 ETL 없이 자동 적재할 수 있는 점이 컸다.
BigQuery의 단점 1: YouTube는 원하는 리포트만 골라 담을 수 없어 전부 적재한 뒤 비용을 줄이려 주기적으로 지우는 별도 파이프라인을 만들어야 했다.
BigQuery의 단점 2: 파티션 프루닝을 위해 세밀하게 나누면 테이블당 4,000개 제한에 걸려 더는 적재되지 않는 상황이 생겼고 테이블 변경 일 1,500회 제한 등 할당량이 많다.
BigQuery의 단점 3: 사용자별 쿼리 비용을 볼 UI가 없어 별도 대시보드를 만들어야 했고, 서비스 대부분이 AWS라 결국 GCS로 옮기는 통합 작업이 필요했다.
Snowflake의 이점 1: AWS 위에서 돌아 기존 파이프라인과 붙이기 쉽고, Snowpipe와 SQS를 연결해 S3 업로드 이벤트로 자동 적재하거나 RDS에서 S3로 내보낸 데이터를 External Stage로 바로 읽을 수 있다.
Snowflake의 이점 2: 표준 SQL과 Snowpark, Node.js 드라이버를 지원해 기존 Node.js 백엔드와 공용 라이브러리를 만들어 붙일 수 있었다.
Snowflake의 이점 3: warehouse 크기와 클러스터 수를 용도별로 나눠 가공·분석용과 대시보드 조회용을 분리해 비용을 조절한다.
Snowflake의 이점 4: Snowsight에서 쿼리별·사용자별 비용을 바로 보고 접근 제어와 워크시트 공유도 처리한다.
결과: Elasticsearch, BigQuery, Athena, Glue를 함께 쓸 필요가 없어져 운영 비용과 관리 지점이 줄었고 모든 시스템이 같은 데이터를 보게 됐다.