빅쿼리로 데이터 인프라 이전하기 (2) 사용성 최적화

이전 글에서는 빅쿼리 ETL 비용 최적화에 대해 소개했었는데요,

이번 글에서는 빅쿼리를 활용한 데이터 접근성 관리와 일반 사용자들의 사용량 관리에 대해 작성해 보겠습니다.

 

Phase 4. 데이터 접근성 높이기

Trino 환경에서 가장 제한적이었던 부분은 일 배치였습니다.

서비스 DB를 긁는 부하를 줄이기 위해 사용량이 가장 낮은 시간에 한정해 ETL 파이프라인을 하루에 한 번 가동했기 때문이죠.

빅쿼리로 이전하면서 세웠던 계획 중 하나가 바로 가능하면 스트리밍, 최소 1시간 단위까지 배치 빈도를 늘리자- 였습니다.

그래서 아래와 같은 기능들을 사용하게 되었습니다.

1. DataStream
   • Google Cloud SQL, AWS RDS 등의 DB를 스트리밍할 수 있는 매니지드 서비스입니다. 
   • DB의 update log를 이용해 새로운 데이터만 추가하기 때문에 서비스 DB에 영향이 거의 없습니다.
2. Dataflow
   • MongoDB, Kafka, Google Pub/Sub 등을 Apache Beam 파이프라인을 통해 스트리밍할 수 있는 매니지드 서비스입니다.

저희가 DW 구성을 위해 입수해야 하는 주요 데이터는 아래와 같았습니다.

1. AWS RDS(MySQL Aurora)
2. MongoDB
3. Client Log(Segment)

이 중에서 RDS는 상기한 DataSteam을 통해 손쉽게 스트리밍을 구현할 수 있었는데요,

단 아직까지 BigQuery로 직접 전송할 때 Partitioning을 지원하지 않아 다음과 같은 방법을 이용했습니다.

DataStream -> Cloud Storage로 스트리밍 적재 -> Cloud Function에서 실시간으로 Storage path를 hive Partition 방식으로 변경 -> Bigquery에서 External Table 생성

이렇게 함으로써 실시간성을 유지하면서, 파티션 기능을 이용할 수 있었습니다.

 

다음 MongoDB의 경우, 기존 데이터 마이그레이션과 스트리밍 파이프라인을 분리해서 이전 작업을 진행했는데요

마이그레이션은 Apache Beam 코드를 통해 MongoDB를 직접 읽어오는 방식으로 일괄 처리가 가능했고,

스트리밍의 경우 MongoDB의 Change Stream을 활용했는데요, 이 부분은 Apache Beam에서 아직 Change Stream에 대한 메서드가 지원되지 않아 중간에 Kafka를 끼워 넣었습니다. 

하여 Kafka에서 MongoDB Change Stream을 구독하고, Dataflow에서 Kafka를 스트리밍해서 BigQuery로 전송하게 되었습니다.

 

다음 Client Log의 경우, Segment라는 플랫폼을 이용해 다양한 destination으로 보내고 있었는데요,

여기에 Google Pub/Sub destination을 추가하고, dataflow를 이용해 Pub/Sub으로 메시지가 들어올 때마다 BigQuery로 전송하도록 했습니다. 

 

이렇게 해서 주요 데이터 원천에 대한 스트리밍 파이프라인을 완성했고,

DW 수준에서는 이전 포스트에서 소개한 Dataform을 활용해 15분 ~ 한 시간 단위의 배치를 구현할 수 있었습니다.

 

이후 실시간 KPI 리포팅과 시계열 데이터 쿼리의 일원화로 정합성을 개선하고 데이터에 기반한 당일 액션이 가능하게 되었습니다.

Phase 5. 데이터 사용량 관리하기

다시 비용 이야기로 돌아와,

기초 파이프라인 비용을 크게 절감했지만 실 사용 환경에서 내부 사용자들의 사용량이 최종 비용에는 더 큰 영향을 미칠 것이기 때문에

이 부분에 대한 정책이 필요했습니다.

1. 프로젝트 단위에서의 할당량 설정
   • Google Cloud 자체에서 빅쿼리 사용량에 대한 한도를 설정할 수 있습니다.
2.  BigQuery 콘솔에서의 할당량 설정
   • 콘솔을 이용할 때, 개별 쿼리에 대한 한도를 설정할 수 있습니다.

다만 저희는 내부 사용자 전체에 빅쿼리 콘솔을 개방하지는 않았습니다.

이유 중 하나는 빅쿼리 콘솔에서 바로 시각화할 수 있는 기능이 약하기 때문에 보다 시각화에 초점을 맞춘 다른 BI툴로 통합된 쿼리 환경을 제공하고자 했기 때문입니다.

 

저희가 선택한 BI툴은 Metabase인데요,

이 툴의 강점은 SQL을 사용하지 않고 대화형 GUI를 통해 쿼리를 조회할 수 있다는 점입니다.

하여 SQL을 다루지 못하는 사용자가 대부분인 환경에서 DA들의 단순 SQL 작성 리퀘스트를 줄일 수 있고,

요청을 어려워하는 사용자들 역시 스스로 간단한 데이터를 조회할 수 있기 때문에 데이터 접근성 역시 개선될 것이라는 판단이었습니다.

 

하지만 이런 방식으로 데이터를 제공하기 위해서는 DW 구조화가 잘 되어 있어야만 합니다.

Raw Data를 그대로 옮겨놓는 방식으로는 DB 이해도가 낮은 사용자들이 활용하기 어렵기 때문입니다.

그래서 이번 데이터 인프라 이전 과정에서 비용 다음으로 중점을 둔 것이 DW Architecture였고 

대부분의 데이터를 단순한 Select, 최대 한두 번의 Join 만으로 리포팅할 수 있도록 설계했습니다.

 

그런데, 3rd party BI 툴을 사용하면 개별 쿼리에 대한 사용량을 어떻게 관리할까요?

실제로 Metabase에는 아직 빅쿼리 사용량을 통제할 수 있는 기능은 없습니다.

 

이에 대한 대안으로, 사용량에 대한 Alert을 도입했습니다.

Metabase에서 제공하는 query hashing 기능과 BigQuery api를 연계해서

유저가 조회한 쿼리의 사용량을 측정하고, 특정 사이즈 이상일 때 슬랙으로 Alert을 보내는 것입니다.

이를 통해 사후적이지만 규모가 큰 쿼리 또는 리포트를 관리할 수 있습니다.

 

추가로 최종 테이블 사이즈를 고려해서 metabase에는 특정 데이터셋만 연결하고

이러한 테이블들은 실수로 풀 스캔을 하더라도 비용에 크게 지장이 가지 않도록 설계했습니다.

 

덕분에 아직까지 일반 사용자들의 쿼리 작업으로 인해 할당량 한도가 발동한 적은 없습니다.

Epilogue. 빅쿼리 이전의 효과?

아직 이전이 완전히 마무리된 것은 아니어서 잡음도 분명히 있고, 작업으로 인한 리소스 부하도 존재하지만

결과적으로 기존 환경 대비 빅쿼리 환경에서 데이터 파이프라인 운영에 대한 전체 비용이 50% 가까이 감소했고

DW 설계 개선의 영향으로 데이터 정합성과 리포트를 작성하는 DA들의 만족도 역시 높아질 것으로 기대하고 있습니다.

다음 번에는 실제로 안정화가 되고 나서의 후기도 작성해 보겠습니다.