핑크퐁의 통합 데이터 환경 구축기 (feat. Snowflake)
안녕하세요. 더핑크퐁컴퍼니에서 Software Engineering 업무를 맡고있는 메타입니다.😀
이번 포스트에서는 저희 더핑크퐁컴퍼니에서 Snowflake를 활용하여 어떻게 기존의 복잡하고 비효율적이었던 데이터 처리 업무를 단순화할 수 있었는지에 대해 소개하려 합니다.
목차
핑크퐁이 다루고자 하는 데이터
기존 데이터 아키텍처의 소개
기존 데이터 아키텍처의 문제점: Data Silo
Data Silo에서 중앙화된 데이터 플랫폼으로
변화의 시작: 기존 앱 사용자 이벤트성 로그 처리 시스템을 클라우드 기반으로 변경
▸ 기존 로그 시스템 리뉴얼의 필요성 1: 단일 장애 점(SPOF, Single Point Of Failure)
▸ 기존 로그 시스템 리뉴얼의 필요성 2: 신규 앱에 대한 사용자 활동 분석 니즈 증가
▸ 신규 로그 시스템: IDC에서 클라우드로, Self-Managed에서 Managed로
▸ 로그 수집기 (1): AWS Kinesis 도입
▸ 로그 수집기 (2): 리시버 서버 추가
▸ 로그 수집기 (3): AWS Data Firehose + Lambda 파이프라인
Elasticsearch와 Kibana를 사용한 분석 환경의 문제점
Data Warehouse의 도입
▸ Google BigQuery를 고려한 이유
▸ Google BigQuery를 사용해보니…
Snowflake를 메인으로 하는 최종 형태
▸ Snowflake 도입의 이점
적용 프로젝트 소개
정리 및 요약: Data Silo에서 중앙화된 데이터 환경으로
핑크퐁이 다루고자 하는 데이터
먼저 저희가 다루고자 하는 데이터는 어떤 것들이 있는지, 그리고 각 데이터를 어떻게 활용하고자 하는지 소개해드리겠습니다.
핑크퐁, 아기상어 IP는 국내뿐 아니라 244개국에서 25개 언어로 유튜브를 포함한 다양한 플랫폼에서 서비스하고 있습니다. 그리고 그 다양한 플랫폼에서 발생하는 데이터들을 활용해 콘텐츠를 서비스하면서 필요한 분석 업무를 수행하고 있습니다.
1. 유튜브 매출 및 구독 통계 데이터
자체 운영 중인 채널들에서는 현재 누적 조회수 800억 뷰를 돌파했고, 일 130만 건 이상의 매출 및 구독 통계 데이터가 유튜브 단일 플랫폼에서 발생 되고 있습니다. (2023년 8월 기준)
2. 앱 및 자체 개발 서비스에서 발생하는 사용자 이벤트성 로그 데이터
핑크퐁, 아기상어 IP를 활용한 모바일 앱 시리즈 170여 종에서 발생하는 일 1,300만 건 이상의 사용자 로그를 사내 앱 로그 시스템을 통해 처리하고 분석에 활용하고 있습니다.
3. 광고 및 앱 플랫폼 매출 및 통계 데이터
10여 종이 넘는 서로 다른 광고 및 앱 플랫폼에서 발생하는 매출 및 통계 데이터를 통합해 분석에 활용하고 있습니다.
4. 그 외 다른 데이터 소스
IPTV 와 같은 플랫폼들은 업체로부터 직접 리포트를 엑셀 파일 형태로 받는데요, 해당 데이터도 다른 소스의 데이터들과 함께 분석에 활용하고 있습니다.
기존 데이터 아키텍처의 소개
앞서 소개해 드린 것 처럼, 자체 개발 앱 서비스 뿐만 아니라 유튜브와 같은 여러 플랫폼에서 저희의 콘텐츠를 서비스하게 되면서 발생하는 데이터 소스가 다양해지고, 처리해야 하는 데이터의 양 또한 많아지게 되었습니다.
그리고 자연스럽게 다양한 플랫폼에서 발생하는 데이터를 기반으로 한 통합 분석 요청 또한 증가하게 되었습니다.
“어떤 콘텐츠가 어떤 플랫폼에서 가장 인기 있었는지 한번에 알고 싶어요”
“이번에 업데이트한 팝업 배너로 얼마나 구독자가 늘었는지 알고 싶어요”
“IP별로 작년 한 해 동안 어느 플랫폼에서 어떤 콘텐츠가 가장 많은 매출을 달성했는지 알고 싶어요”
“BEP를 가장 빨리 달성한 프로젝트가 궁금해요”
하지만 기존 저희의 데이터 처리 프로세스는 앱 로그 분석 시스템 이외에 별다른 자동화된 데이터 처리 파이프라인이 없어 수동으로 “사람이 직접” 운용 중인 서비스의 데이터베이스에서 데이터를 추출하거나, 10여 종이 넘는 외부 플랫폼에서 제공하는 웹 대시보드를 통해 데이터를 내려받아 분석에 활용하고 있었습니다.
그러다 보니 다음과 같은 문제 때문에 데이터 분석 작업은 늘 고되고 힘든 일이 되었습니다.
기존 데이터 아키텍처의 문제점: Data Silo
복잡성 증가 및 운영 포인트 증가
위 그림처럼 MySQL 서버에서 데이터를 추출할 때는 SQL, MongoDB에서 데이터를 추출할 때는 NoSQL Query를 사용하는 등 데이터베이스마다 서로 다른 특성을 고려해서 분석 작업을 수행해야 했습니다.
또 운영하는 플랫폼별로 데이터가 어떤 형식으로 제공되는지, 데이터를 추출은 어떤 방식으로 할 수 있는지 모든 시스템의 스키마와 각 컬럼 특성을 모두 이해하고 있어야 했습니다.
데이터 일관성 유지가 힘듦
서비스마다 데이터 관리와 운영이 분리되어 있다 보니, 각 서비스가 같은 데이터를 중복으로 가지고 있는 경우도 있었고, 서로 데이터를 동기화하는 시간이 달라서 결과적으로 같은 데이터이지만 모두 다른 시점의 데이터를 가지고 있게 되는 등(대표적으로 환율 데이터, 각 서비스마다 환율을 크롤링 해오는 곳도, 기준도 달랐다…. 결국 원화 매출액이 시스템마다 다 다른 이슈가 발생되었다.) 데이터 일관성을 유지하기 힘들어지는 문제도 발생했습니다.
대규모 데이터 통합 및 분석 힘듦
이렇게 사용하는 서비스들도 다양하고, 각 서비스에서 제공하는 BI 툴 또한 다양하기 때문에 결과적으로 대규모 데이터를 통합하는 업무나 분석업무가 힘들었습니다.
Data Silo에서 중앙화된 데이터 플랫폼으로
데이터가 분산되어 관리되다 보니 통합 분석 작업에 늘 어려움이 있었고, 중앙화 된 데이터 관리 및 분석 시스템을 구축하는 것에 대한 필요성을 느끼게 되었습니다.
그래서 핑크퐁에서 분석하고자 하는 데이터를 효과적으로 운용하기 위해 기존 앱 사용자 로그 처리 시스템부터 개선하기 시작해서, 현재 Snowflake를 데이터웨어하우스로 사용하는 다음과 같이 중앙화된 형태의 데이터 아키텍처로 개선하는 작업을 진행했습니다.
변화의 시작: 기존 앱 사용자 이벤트성 로그 처리 시스템을 클라우드 기반으로 변경
Snowflake를 도입하기 전 저희는 단일 MongoDB 서버로 구성된 기존 레거시 아키텍처로부터 ELK 환경, Google BigQuery를 사용한 환경 등을 거치며 시행착오를 겪었습니다.
그리고 그 작업은 저희의 앱에서 발생하는 사용자 이벤트성 로그를 처리하는 파이프라인을 개선하는 작업에서부터 시작했습니다.
기존 로그 시스템 리뉴얼의 필요성 1: 단일 장애 점(SPOF, Single Point Of Failure)
기존 파이프라인은 IDC에서 운용 중인 MongoDB 서버 하나에 애플리케이션 서버를 연결하여 앱으로부터 들어오는 사용자 이벤트를 적재하고 가공하는 방식으로 운용하고 있었습니다.
별도 replication 구성 없이 단일 MongoDB 서버로 운영 중인 이 시스템에 여러 내부 관리용 서비스들이 의존 되어있는 상황이었기 때문에 이 서버에 장애가 생기면 연관된 다른 시스템에도 장애가 전파되었습니다.
기존 로그 시스템 리뉴얼의 필요성 2: 신규 앱에 대한 사용자 활동 분석 니즈 증가
그리고 신규 앱인 아기상어 키즈월드 앱의 경우, 사용자들이 앱 내에서 여러 영상이나 게임 콘텐츠를 직접 플레이할 수 있는데요, 운영팀에서는 여러 콘텐츠가 서비스되는 이 앱 내에서 사용자들의 활동을 분석하고 싶어 하는 니즈가 있었습니다.
“이번 분기에 어떤 영상 또는 게임이 가장 많이 재생되었는지 알고 싶어요”
“이번에 업데이트한 팝업 배너로 얼마나 구독자가 늘었는지 알고 싶어요”
이렇게 새로운 데이터 분석에 대한 니즈가 증가하는 상황에서 신규 분석 시스템 또한 기존 로그 처리 시스템에 의존하게 된다면, 기존 로그 시스템의 문제가 생겼을 때 신규 시스템 또한 영향을 받을 거라 생각되었습니다.
그래서 신규 데이터 분석을 수행하기 전에 먼저 이 기존 로그 시스템을 개선하는 작업을 먼저 진행했습니다.
신규 로그 시스템 : IDC에서 클라우드로, Self-Managed에서 Managed로
저희가 가장 먼저 고려한 것은 관리 Point의 축소였습니다. 한정된 개발 인력이 개발 업무와 함께 인프라를 직접 구성하고 관리하기 힘든 상황이었기 때문입니다.
그러면서도 기존 시스템에서는 힘들었던 유동적으로 스케일 조정이 가능한 서비스를 우선으로 고려하였습니다.
로그 수집기 (1): AWS Kinesis 도입
로그 수집기는 기존 Redis, MongoDB 와 Django Application Server로 구성된 환경에서 AWS Kinesis의 서비스들로 대체하였습니다.
AWS Kinesis 서비스는 실시간 데이터 스트리밍 서비스로 Kinesis Data Streams , Kinesis Data Firehose, Kinesis Data Analytics, Kinesis Video Streams제품들로 구성되어있습니다.
그 중 Kinesis Data Streams의 경우 Apache Kafka처럼 실시간 데이터 스트리밍 및 처리를 가능하게 해주는 서비스로, 특히 데이터 레코드가 스트림 내의 특정 “shard”에 저장되고, 이 shard의 수에 따라 다음과 같이 처리 용량이 결정된다는 특징이 있습니다.
쓰기 처리량:
* 하나의 shard는 초당 최대 1,000개의 데이터 레코드 또는 1MB의 데이터를 쓸 수 있습니다. (둘 중에 더 큰 것이 적용)읽기 처리량:
* 하나의 shard는 초당 최대 2MB의 데이터를 읽을 수 있습니다.
(하나의 shard에서 두 개의 컨슈머를 사용하는 경우 각 컨슈머는 초당 최대 1MB의 데이터 읽기 만 가능)
로그 발생량이 많아질 경우, 얼마든지 Kinesis Data Stream에서 유동적으로 Shard 수를 늘림으로써 scale out이 가능하고, AWS Kinesis는 사용할 때 클러스터 구성, 패치 관리 등의 작업을 사용자가 직접 할 필요가 없는 Managed Service이기 때문에 저희의 두 마리 토끼를 잡고자 하는 요구사항과 맞는 서비스라고 생각되었습니다.
그뿐만 아니라 기존 로그 시스템의 경우, 초당 평균 150건의 로그가 발생하고 있었고, 그 크기 또한 초당 1MB를 넘지 않기 때문에 shard 1개의 저렴한 비용으로 기존 서비스를 충분히 대체해 운용할 수 있을 것 같다는 판단이 있었습니다.
로그 수집기 (2): 리시버 서버 추가
위에서 말한 것과 같이 Kinesis는 shard 수를 늘림으로써 수평 확장이 가능하기 때문에 앱에서 로그를 많이 보내는 상황에 대처할 수 있다는 장점이 있었습니다.
하지만, 그러기 위해서는 위와 같이 앱에서 AWS SDK를 사용해 Kinesis로 로그를 바로 보내게 되어있어야 했습니다.
하지만, 이렇게 앱에서 바로 Kinesis Stream으로 로그를 보내기 위해서는 이미 출시되어 서비스되고 있는 50여 종의 앱의 업데이트가 불가피했습니다.
앱들을 모두 업데이트한다고 해도 사용자가 스토어에서 직접 앱을 업데이트하지 않고 이전 버전을 그대로 사용하는 경우 등 고려해야 할 부분이 많았기 때문에, 결국 앱을 전부 업데이트하는 것은 현실적으로 불가능하다고 판단했습니다.
그래서 중간에 앱들로부터 로그를 받아서 AWS Kinesis로 보내는 역할을 하는 리시버 서버를 두고, 기존 앱들이 로그를 보내는 요청을 기존 로그 서버에서 신규 리시버 서버로 라우팅시켜 앱 업데이트 없이 로그를 Kinesis로 받을 수 있도록 했습니다.
각 리시버 서버는 앱들에서 발생하는 로그를 받아 Kinesis가 받을 수 있는 형태로 전처리 작업을 수행 후 Kinesis로 처리된 로그를 PutRecord 또는 PutRecords API를 통해 Kinesis Data Streams로 전달합니다.
이렇게 앱에서 바로 Kinesis로 로그를 보내는 것이 아니라, 리시버를 통해서 보냈고, 리시버에서는 로그를 전처리하는 작업도 수행했기 때문에 각 리시버 서버에 대한 부하 테스트 또한 수행하였습니다.
부하 테스트 결과 한 개의 node.js 리시버 서버는 초당 평균 약 710개의 요청처리할 수 있었습니다. 그리고 clinic.js를 통해 개발 환경에서 성능 평가를 진행했을 때, 특별히 로직 상 event loop가 delay되거나 하는 현상은 발견되지 않았는데요.
각 리시버의 경우, 부하 테스트 결과 초당 710개의 request까지 처리할 수 있었기 때문에 평균 초당 150건 발생하는 기존 로그 트래픽을 충분히 단일 서버로 감당할 수 있을 거라 판단했습니다.
하지만 예상치 못한 트래픽에 대응하기 위해 리시버 서버를 2개 운용하고, ECS Auto Scaling을 적용해 로그를 보내는 트래픽이 많아지는 상황을 자동으로 대응할 수 있도록 설정하였습니다.
로그 수집기 (3): AWS Data Firehose + Lambda 파이프라인
AWS Data Firehose 서비스를 Kinesis Stream에 연동하여 Stream으로 들어온 로그를 일정 주기마다 Data Lake로 사용할 S3에 적재할 수 있도록 구성했습니다.
그리고 사용자 접속 로그 등 준실시간 성으로 분석이 필요한(기존 시스템에서는 매 분마다 수집 및 가공) 로그의 경우 Elasticsearch와 Kibana로 구성된 환경에서 분석을 수행할 수 있도록 했는데요
AWS Firehose를 통해 S3에 로그가 적재 될 때, 로그를 Elasticsearch에 로드하는 AWS Lambda 함수가 실행될 수 있도록 설정하여 분석에 필요한 일부 로그를 Kibana에서 분석할 수 있도록 파이프라인을 구성했습니다.
Elasticsearch 와 Kibana를 사용한 분석 환경의 문제점
앱을 운영하면서 Elasticsearch에 적재한 앱 사용자 로그 데이터와 YouTube나 App Store와 같이 다른 소스들에서 발생하는 데이터들을 통합해서 분석하고 싶어 하는 니즈가 생겼습니다.
그래서 저희는 먼저, 다음과 같이 통합되어야 하는 신규 데이터들 또한 Kibana에서 함께 조회할 수 있도록 하는 방안을 적용했습니다. Elasticsearch로 신규 데이터들을 로드하는 ETL 프로세스를 추가로 개발했고, 기존 앱 사용자 로그 데이터와 신규 데이터들을 함께 통합해 분석을 시도했습니다.
하지만 Elasticsearch와 Kibana로 구성된 환경에서 여러 소스의 데이터들을 함께 통합해서 분석하기에는 여러 어려운 점이 있었는데요.
1. Elasticsearch 집계 쿼리의 한계
Elasticsearch의 terms 쿼리의 결과로 반환되는 문서의 수는 size 매개변수에 의해 제한되는데 기본값으로 10개의 결과만 표시되며, Elasticsearch의 index.max_result_window 설정값을 늘림으로써 한 번의 검색 요청에 최대 10,000개의 결과 문서를 반환받을 수 있습니다.
그래서 Elasticsearch에서 전체 결과 데이터를 받아오기 위해서는 scroll이나 search after와 같이 결과를 여러 번에 걸쳐 나누어 받아와야 하는데, Kibana의 기본 검색 UI에서는 사용자가 직접 scroll이나 search after 기능을 제공하지 않기 때문에 전체 집계 결과 데이터를 대시보드에서 바로 조회할 수 없다는 문제점이 있었습니다.
2. 정확한 distinct count를 계산하기 힘든 문제
Elasticsearch에서 고유한 값의 개수를 세려면 다음과 같이 “Cardinality” 집계를 사용합니다.
{
"size": 0,
"aggs": {
"unique_user_ids": {
"cardinality": {
"field": "user_id"
}
}
}
}이 쿼리를 실행하면, 다음과 같이 결과에서 고유한 값의 개수를 확인할 수 있습니다.
{
...
"aggregations": {
"unique_user_ids": {
"value": 12345
}
}
}하지만 이 “Cardinality” 집계가 실제 정확한 distinct count 값이 아닌 추정값을 반환한다는 특징이 있습니다.
threshold 값을 100으로 낮추더라도 수백만 개의 항목에서 error율이 1~6%로 매우 낮게 유지되긴 하지만, 어쨌든 정확한 수치가 아니기 때문에 추이 지표와 같이 빠르게 확인하고 넘기는 지표가 아닌, 매출이나 사용자 분석과 같이 정확한 값이 있어야 하는 지표 계산에까지 사용하기에는 위험도가 있었다고 생각했습니다.
3. 대용량 데이터 조회 및 로드 시 문제, 높은 러닝 커브
데이터가 많아질수록 데이터 조회나 로드 시 문제가 되는 부분들이 생겨나기 시작했습니다.
Data too large, data for [] would be …
rejected execution of coordinating operation …
이 문제를 해결하기 위해서는 직접 메모리 제한이나, 노드 수를 늘리는 작업을 해주어야 했는데요.
한 번에 많은 데이터를 처리하기 위해서 고려해야 할 부분들이 많아지는 것은 어떻게 보면 당연한 일이라고 생각될 수 있습니다.
하지만 팀 내에 Elasticsearch를 운영해 본 경험자가 없었고, 개발자 한 명이 직접 기존 개발 업무와 함께 추가적인 인프라 또한 관리해야 하는 저희의 상황에서는 Elasticsearch의 러닝 커브가 높다고 판단 되었습니다. 또 프로덕션 레벨에서 이렇게 문제가 생길 때마다 직접 클러스터를 모니터링 하고, 최적화 조치를 취하기에도 한계가 있었습니다.
그 외에도 Kibana에서는 저희의 요구사항과 맞는 고도화된 그래프를 그리기 힘들다는 점 등 여러 문제 상황에 부딪히게 되었고, 그럴 때마다 결과적으로 추가적인 시스템을 따로 개발해서 운영하게 되었는데요. 이렇게 오히려 추가 개발과 운영 point가 늘어나는 문제 때문에 최종적으로 저희의 상황에서 Elasticsearch와 Kibana로 구성된 환경에서 대용량 데이터를 통합 분석하기에는 힘들다는 결론을 내렸습니다.
Data Warehouse의 도입
이러한 과정을 겪으며, 대용량 데이터를 대상으로 통합된 쿼리를 실행할 수 있는 데이터 분석 전용 데이터 웨어하우스 서비스에 대한 필요성을 느끼게 되었습니다.
그리고 그중 클라우드 기반에서 운용이 가능하며, fully-managed 서비스인 Google BigQuery와 Snowflake 두 서비스에 대해 기술 검토를 진행했습니다.
Google BigQuery를 고려한 이유
앞서 언급한 것 처럼 클라우드 환경에서 운용이 가능하고, 저희가 직접 클러스터를 구성하거나, 관리, 튜닝할 필요가 없는 fully-managed 서비스라는 점뿐만 아니라,
BigQuery Transfer 서비스를 이용하면 YouTube나, Google Analytics, Admob과 같이 저희가 다루고자 하는 데이터 중 큰 비중을 차지하는 데이터 소스들에서 발생하는 데이터를 별도의 ETL 프로세스를 구성할 필요 없이 자동으로 적재할 수 있다는 점 또한 큰 장점으로 생각했습니다.
Google BigQuery를 사용해보니…
하지만 Snowflake와 함께 기술검토를 진행하면서 Google BigQuery를 적용하기에는 몇가지 단점도 있었습니다.
1. BigQuery Transfer에서 원하는 event만 선택해서 적재 불가
저희가 다루고자 하는 데이터 중 YouTube, Google Analytics, Admob과 같이 Google 서비스들에서 발생하는 데이터의 비중이 높았는데요. BigQuery Transfer 서비스를 이용하면 이렇게 Google에서 자체 서비스하는 플랫폼들에서 발생하는 데이터를 별도의 ETL 프로세스를 구성할 필요 없이 데이터 발생 시점에 자동으로 Google BigQuery로 로드할 수 있었습니다.
하지만 YouTube의 경우 원하는 레포트의 데이터만 선택해서 적재할 수 없었기 때문에 결국 YouTube를 통해 발생하는 모든 데이터를 일단 BigQuery에 자동으로 로드되게 한 후, 적재 비용을 줄이기 위해 원하는 테이블만 남기고 다른 데이터는 주기적으로 삭제해 주어야 했고, 이 작업을 수행하기 위한 별도 파이프라인을 만들어 운용해야 했습니다.
2. Partition Limit
Google BigQuery의 경우, 쿼리의 성능과 비용 절감을 위해서는 데이터마다 파티셔닝과 클러스터링에 대해 직접 고민해야 했는데요.
더 효과적인 파티션 프루닝을 위해 세밀하게 파티셔닝을 적용할 경우, 테이블당 파티션 개수가 4,000개로 제한 되어있기 때문에 이 파티션 개수가 초과해 버려서 더 이상 데이터를 로드할 수 없는 문제가 생기기도 하였습니다.
그래서 테이블을 구성하기 전에 어느 정도의 파티션 크기를 가져가야 할지, 그러기 위해선 어떤 키를 파티션 키로 사용해야 할지 등을 고려해야 했습니다.
Partition Limit 이외에도 (OLAP 환경에서는 큰 문제가 되지 않을 수도 있지 만) 테이블 생성이나 수정, 삭제 작업이 테이블당 일 1,500회로 제한되어 있다거나 , 동시에 처리할 수 있는 Insert DML 문의 개수 또한 제한 되어 있고, 데이터를 CSV로 GCS에 언로드 시 청크 파일 사이즈 세밀하게 지정 못 하는 부분 등 클라우드 기반 데이터 웨어하우스 서비스이다 보니, 작업마다 정해진 제한과 할당량이 존재했으며, 특정 사용 사례나 비즈니스 요구사항에 따라 이 제한은 “까다롭다”고 느껴질 수도 있겠다고 생각했습니다.
3. Query History를 직관적으로 확인하지 못함.
BigQuery에서 사용자별로 수행한 쿼리의 비용을 추정하고, 실제로 특정 기간 어떤 사용자가 얼마나 많은 데이터를 스캔했는지 모니터링하기 위한 UI가 따로 제공되지 않았습니다.
INFORMATION_SCHEMA 나 Cloud Logging에서 제공하는 사용자 활동 및 API 호출에 대한 로그를 활용하여 별도 모니터링 대시보드를 만들어 확인해야 했는데요, 이러한 모니터링 관련 작업이 복잡하고 UI가 바로 제공되지 않는 점 또한 불편하다고 생각했습니다.
4. 결국 AWS + GCP integration 이 필요
무엇보다 대부분의 서비스가 AWS에서 운영 중이었기 때문에 결국 AWS에서 구성한 데이터 아키텍처와 통합하는 작업 또한 필요했습니다.
예를 들어 S3에 데이터가 업로드될 때 자동으로 BigQuery에도 로드되도록 하거나 AWS Kinesis Stream으로 들어온 실시간성의 데이터를 BigQuery에서 분석할 수 있도록 하는 등, 여러 소스에서 발생한 데이터를 BigQuery로 로드하기 위해서는 해당 데이터를 결국 Google Cloud Storage로 전송해야 했습니다.
Snowflake를 메인으로 하는 최종 형태
이러한 상황에서 Snowflake와 PoC를 진행하면서 Snowflake에서는 저희가 ELK, BigQuery를 사용하면서 불편하게 여겼던 부분에 개선점이 있었기에 최종적으로 다음과 같은 Snowflake를 단일 데이터 웨어하우스로 사용하는 형태의 통합 데이터 환경을 구성하게 되었습니다.
Snowflake 도입의 이점
저희의 이러한 상황에서 Snowflake를 도입하면서 느낀 이점으로는
1. 클라우드 기반, Snowflake에서 모든 분석 환경 구성 가능
먼저 Snowflake는 AWS 클라우드 환경에서 운용이 가능하기 때문에, 기존 IDC에서 직접 서비스를 운용할 때 비해서 서버 자원을 직접 관리하지 않아도 되기에 운용이 쉬워졌습니다. 그리고 기존 AWS 환경에 구성되어 있던 데이터 파이프라인을 Snowflake로 integration을 할 때도 용이했는데요.
Snowpipe와 AWS SQS를 연결할 수 있기 때문에 S3에서 파일 업로드 이벤트를 감지해 자동으로 데이터가 Snowflake로 로드되도록 설정할 수 있었습니다.
또 저희 AWS RDS로 운용하는 OLTP 서비스에서 발생하는 데이터들과 통합할 때도 RDS에서 데이터를 바로 S3로 내보내는 기능을 지원해 주기 때문에, 일단 S3에 데이터를 적재하고 나면 그 이후부터는 Snowflake에서 External Stage를 설정하면 데이터 로드까지 Snowflake에서 바로 수행할 수 있었습니다.
2. SQL, Snowpark(python), Node.js Driver 등 다양한 개발 환경 지원
두 번째로 SQL(ANSI SQL:1999 및 SQL:2003 분석 확장의 하위 집합을 포함하여 표준 SQL을 지원), python 언어를 지원하기 때문에 개발자가 직접 데이터 분석작업을 하는 것에 대한 러닝 커브가 적었습니다.
또, Snowflake에서는 Node.js Driver 또한 지원되기 때문에 Node.js로 개발한 저희의 기존 백엔드 서비스와의 통합할 때에도 직접 Snowflake용 커스텀 라이브러리를 만들어 공통으로 사용할 수 있는 등 기존 서비스와의 통합이 용이했습니다.
3. 사용 패턴에 따라 scale 조정이 용이
Snowflake에서는 data warehouse의 size와 clustering 조정으로 사용 패턴에 따라 유동적으로 scale을 조정할 수 있습니다.
저희의 경우 데이터 가공 및 분석용 warehouse와 Retool 대시보드에서 단순 조회용 warehouse를 나누어 사용하고 있는데요, 이렇게 목적에 따라 각 warehouse의 size와 cluster 수를 나누어 설정하여 운용시 드는 비용을 최적 화 할수 있다는 점이 장점이라고 생각했습니다.
4. 직관적인 Snowsight UI
그 외로 Snowflake를 도입하기 전 기존 데이터 웨어하우스 환경에서는 쿼리 스캔 비용을 모니터링 하기 위해 따로 로그 이벤트를 적재하는 등 부가 작업이 필요했고, 권한 제어나 데이터 공유 또한 번거로웠습니다.
하지만, Snowflake에서는 Snowsight라는 웹 인터페이스에서 바로 쿼리별, 사용자별 실행 코스트 분석이 가능했고, Snowsight를 통해 사용자별로 접근을 제어하거나 워크시트를 바로 공유해서 함께 작업을 할 수 있는 등 편의성 높은 환경이 제공되었습니다.
적용 프로젝트 소개
위에 소개한 부분들로 인해 핑크퐁에서는 기존에는 대응하기 까다로웠던 데이터 분석 업무를 효과적으로 대응할 수 있게 되었습니다.
저희 팀에서는 언제든 구성원이 통합된 데이터를 통해 분석 업무를 수행할 수 있도록 두 가지 분석 시스템을 만들어 운영하고 있는데요.
1. 앱 & 콘텐츠 통합 예상 매출 분석 시스템
“IP별로 작년 한 해 동안 어느 플랫폼에서 어떤 콘텐츠가 가장 많은 매출을 달성했는지 알고 싶어요”
“BEP를 가장 빨리 달성한 프로젝트가 궁금해요.”
더핑크퐁컴퍼니에서 서비스하는 모든 앱 및 영상 콘텐츠와 관련하여, 다양한 소스로부터 발생하는 사용자 로그, 매출데이터를 기반으로 예상 비용과 매출을 분석하는 시스템 또한 개발해 운영중에 있습니다.
2. 아기상어 키즈월드 앱 구독 경로 분석 시스템
“아기 상어 키즈 월드 앱에서 어떤 콘텐츠가 어떤 플랫폼에서 가장 인기 있었는지 한번에 알고 싶어요”
“이번에 앱 내에 업데이트한 팝업 배너로 얼마나 구독자가 늘었는지 알고 싶어요.”
신규 출시 앱인 아기상어 키즈월드 앱에서 발생하는 데이터들에 대한 분석 요구사항이 있을 때, 앱 운영팀에서 언제든 원하는 지표를 바로바로 확인할 수 있도록 하는 시스템을 개발해 운영하고 있습니다.
정리 및 요약: Data Silo에서 중앙화된 데이터 환경으로
이렇게 사내에 중앙화된 데이터 환경이 구축됨에 따라, 기존 저희의 데이터 수집 및 분석 환경에서 겪었던 문제점들이 해결되었습니다.
데이터 처리 및 분석 아키텍처의 단순화
복잡했던 아키텍처가 통합 및 단순화됨에 따라 Elasticsearch, Google BigQuery, AWS Athena, AWS Glue 등의 다른 서비스를 사용할 필요가 없어지면서 해당 서비스에서 발생하던 운영 비용, 관리 point 또한 줄어들게 되었습니다.
각 시스템에 일관된 데이터 제공
앞서 설명해드린 환율 데이터의 예시와 같이 각 시스템마다 데이터를 개별로 가지고 있었기 때문에 데이터가 중복되고, 통합 분석 시 데이터의 일관성이 떨어지는 문제가 있었는데요, 한곳에서 데이터를 모아 관리하게 되면서 모든 시스템이 동일한 상태의 일관성 있는 데이터를 바라볼 수 있게 되었습니다.
대규모 데이터 통합 및 분석 용이
또 기존에는 사용하는 서비스들 마다 제공하는 BI 툴 또한 다양했기 때문에 한곳에서 대규모 데이터를 통합하거나 분석하기가 힘들었는데요, 이제는 언제든 단일 플랫폼에서 대규모 데이터에 대해 통합된 분석 업무를 수행할 수 있는 환경이 되었습니다.
