콘텐츠로 이동하기
데이터 분석

클라우드 데이터 웨어하우스로 속도 향상 니즈 충족

2020년 11월 24일
Bahar Uzan

Sales Engineer

Firat Tekiner

Senior Staff Product Manager

GCP 사용해 보기

$300의 무료 크레딧과 20개 이상의 항상 무료인 제품으로 Google Cloud 사용을 시작해보세요.

무료 체험

 * 본 아티클의 원문은 2020년 10월 22일 Google Cloud 블로그(영문)에 게재되었습니다. 

Google Cloud는 고객과 협업하는 과정에서 성장, 변화, 그리고 클라우드를 통한 성공에 관한 멋진 스토리를 접하게 되었습니다. 빠르게 성장하고 있는 터키 소재의 전자상거래 회사인 Trendyol Group과는 데이터 웨어하우스 마이그레이션 프로젝트를 통해 긴밀하게 협업했습니다. Trendyol의 직원은 2,000여 명이며 이 회사의 전자상거래 사이트는 매년 500억 페이지 조회수와 50억 회의 방문 수, 매월 5,000만 명의 순 사용자 수를 기록합니다. 이 디지털 기반 회사의 비즈니스에서 핵심은 바로 데이터입니다. 

Trendyol Group이 전례 없는 성장을 마주하고 있는 상황에서 Trendyol 데이터 웨어하우스(DWH)팀은 기존에 사용하던 Vertica 데이터 웨어하우스의 제한된 성능과 확장성 때문에 애를 먹고 있었습니다. 연말 쇼핑 시즌과 기타 소매업 성수기에는 어려움이 더했습니다. 지난 18개월 동안 성능 문제가 심각해졌고 비즈니스에도 영향을 미쳤습니다. DWH팀은 제시간에 데이터를 처리하고 내부 보고서와 대시보드를 제공하지 못한 것이 수익 손실을 일으키고 공급업체 관리의 정확성을 저하시킨 원인임을 파악했습니다. 예를 들어 공급업체에서 비효율적인 결정을 내리거나 실제로는 재고가 없는 제품을 판매한 경우 비즈니스 차원에서 신속하게 대응할 수 없었습니다.  

온프레미스 데이터 웨어하우스의 제한된 용량으로 인해 IT팀은 비즈니스 정보에 집중하지 못하고 끊임없이 성능과 계획을 조정하고 용량을 확장해야 했습니다. Trendyol의 보고팀은 Tableau를 통해 600명이 넘는 사용자에게 2,000여 통합문서와 7,000여 뷰를 제공합니다. 마이그레이션 이전에 Trendyol은 Vertica 환경에 30TB가 넘는 데이터를 보관하고 있었습니다. 이 외에도 ETL 파이프라인에 300개가 넘는 지연 변경 측정기준(SCD)이 있었기 때문에 팀에서는 매일 데이터의 10%를 업데이트해야 했습니다. 이로 인해 ELT 프로세스 중에 11TB의 데이터를 자르고 삽입해야 했습니다.

막대한 데이터 크기가 비즈니스를 짓눌렀습니다. 비즈니스 사용자는 월요일 오전마다 경영진에게 제출해야 하는 재무 보고서의 SLA를 충족하지 못했습니다. 비즈니스 사용자의 IT팀은 바쁜 일정에 맞춰 보고서 작성을 제때 완료하기 위해 장기간 실행 중인 쿼리를 중지하여 워크로드를 조정해야 했습니다. 예를 들어 비즈니스 사용자는 용량 문제로 인해 쿼리를 1년 동안만 집계할 수 있었기 때문에 집계에 3년이 걸리는 쿼리는 실행할 수 없었습니다. 비즈니스 사용자가 보고서에 액세스했을 때는 이미 데이터가 비활성 상태였습니다. 그러다 목요일이 되면 사용자가 실행하는 쿼리 수가 줄어 DWH팀은 용량이 남아돌았습니다.

코로나19 확산의 영향으로 Trendyol은 수요 급증에 대비할 수 있도록 대응 속도를 높이고 규정 미준수 제품이나 공급업체를 배제할 필요가 있었습니다.

DWH팀은 비용 효율적인 방식으로 워크로드를 자동 확장해야 한다고 판단했습니다. 일단 Vertica 환경을 1년 더 사용하도록 연장한 상태에서 다른 클라우드 데이터 웨어하우스를 평가하기 시작했습니다. 

클라우드 데이터 웨어하우스 결정 기준 

Trendyol팀은 Snowflake와 Google Cloud를 비롯한 여러 공급업체를 살펴보기로 했습니다. 새로운 클라우드 데이터 웨어하우스를 결정한 기준은 다음과 같았습니다.

  • 즉각적인 확장성. 회사의 분석 워크로드가 지닌 변동성을 고려할 때 월요일 오전 보고서를 실행하기 위한 용량을 확보하려면 즉각적인 확장성이 반드시 필요했습니다. 

  • 운영 비용 절감. Trendyol은 계절별 요인의 영향을 받는 소매업종에 속하기 때문에 수요가 없을 때는 비용도 낮게 유지해야 했습니다. 

  • 업타임 SLA. 특히 요즘과 같은 중요한 시기에 비즈니스 니즈를 충족하려면 분석 플랫폼의 가용성이 높아야 했습니다. 현재 BigQuery에서는 99.99% SLA를 제공합니다.

  • 백업 및 복구. 프로세스 처리 중에 오류가 발생할 경우 팀에서 이전 데이터를 검토하는 데 백업 및 복구가 중요합니다. 

  • 보안. 보안은 Trendyol에서 직무에 따라 개인 식별 정보(PII)와 민감한 데이터에 대한 액세스 권한을 제한하기 위한 주요 요구사항입니다. 

  • 사용 편의성. 비즈니스 사용자가 새로운 클라우드 데이터 웨어하우스 플랫폼으로 전환하는 과정에서 사용법을 빨리 익히고 즉시 생산성을 발휘할 수 있는지가 매우 중요했습니다.

클라우드 데이터 웨어하우스 평가

BigQuery의 포괄적인 문서와 간단한 관리 인터페이스 덕분에 Trendyol은 PoC 체험 기간 동안 BigQuery를 설정하고 쿼리를 미세 조정할 수 있었습니다. 다른 데이터 웨어하우스 공급업체의 체험판을 사용하기 위해서는 환경을 최적화하고 조정하기 위한 컨설턴트가 필요했습니다. Trendyol은 BigQuery로 데이터를 직접 이전할 수 있었고 작동에도 문제가 없었습니다. 또한 백업 및 복구 요구사항을 즉시 충족하는 시간 여행 기능을 비롯한 BigQuery의 여러 기능을 사용했으며 보안 요구사항을 손쉽게 충족한 Cloud Identity and Access Management(Cloud IAM) 역할을 통합했습니다.

Trendyol에게 가장 중요한 BigQuery 기능은 스토리지와 컴퓨팅의 분리였습니다. 이 기능 덕분에 컴퓨팅을 사용한 만큼만 비용을 지불할 수 있게 되었습니다. 게다가 다른 도구들과 달리 시작과 종료에 시간이 소요되지 않아 워크로드를 간편하게 확장하고 축소할 수 있었습니다. DWH팀에서는 ELT, 엔드 투 엔드 BI, BI 통합, 다수의 OLAP 쿼리를 비롯하여 회사의 기본 워크로드를 나타내는 여러 벤치마크를 기준으로 기존 데이터 웨어하우스 도구를 대체할 새로운 서비스를 종합적으로 평가했습니다. 각각의 워크로드를 처리하는 데 필요한 가격과 성능을 고려했을 때 BigQuery가 적합한 옵션이었습니다. 

다음은 십억 개의 행(정규식, 20개 이상의 분석 함수)을 포함하는 조인을 사용한 OLAP 유형의 쿼리 예시입니다. 

  1. 고급 사용자를 나타내는 임시 쿼리: 4개 테이블 조인, 높은 카티전 조인: 632m, 162m, 13m, 23k 정규식 함수, 2x dist. count

  2. 분석 함수가 있는 ELT 게시 레이어: 5개 테이블 조인, 행: 800m, 13m, 11m, 10m, 360k 20+ 분석 함수, first/last_value group by

  3. 게시 레이어 예시: 13개 테이블 조인(하위 쿼리 포함), 행: 274m, 262m, 135m, 13m,10x group by

Trendyol의 테스트 결과

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_gwZV4fT.max-900x900.jpg

  • 동시 쿼리: BigQuery가 다른 솔루션에 비해 가장 비용 효율적이고 속도가 빨랐습니다. 다른 솔루션과 달리 BigQuery에서는 더 많은 슬롯을 테스트하고 예약 간 리소스를 원활하게 공유할 수 있었습니다.

  • DML 문 성능: CTAS/업데이트/삽입에서는 플랫폼 간 성능이 유사했지만 BigQuery가 가장 경제적이었습니다. 

  • 엔드 투 엔드 런타임: BigQuery의 BI 실행이 더 빨랐습니다.

  • 수집 시간: BigQuery가 훨씬 더 빨랐습니다. 

  • 데이터 수집 벤치마크: 63GB 크기의 Parquet 파일 492개(행 4억 개, 열 50개, snappy 압축)

  • ELT의 SCD 단계: 가장 큰 측정기준을 통해 210만 건이 넘는 업데이트와 약 100만 건의 삽입이 가능합니다.

전반적으로 BigQuery가 가격 대비 성능이 가장 뛰어난 것으로 확인되었으며 BigQuery의 예측 가능한 정액제 가격 책정은 의사 결정을 내리는 데 핵심적인 역할을 했습니다. 과거에는 DWH팀에서 시간보다 용량을 기준으로 구매를 결정하면서 구매한 용량을 모두 활용할 수 있을 것이라고 생각했지만 예상이 빗나간 경우가 많아 막대한 비용이 발생하고 예측 가능성도 대폭 떨어졌습니다. 이제 DWH팀은 매월 말에 사용량이 어느 정도일지 예측할 수 있게 되었습니다. 또한 가변 슬롯을 활용하여 분 단위로 확장과 축소를 수행할 수 있습니다. 이는 다른 공급업체에서는 제공하지 않는 기능입니다.  

BigQuery로 마이그레이션

Trendyol의 DWH팀은 마이그레이션을 세 가지 주요 카테고리로 나누었습니다.

  • BI/Tableau 마이그레이션: 2주 만에 완료되었습니다. 2,000개의 워크시트와 7,000개의 Weave 보고서에서 액세스하는 50개의 소스 테이블을 변경했습니다. Tableau에 BigQuery와의 기본 연결이 있었기 때문에 마이그레이션이 간편했습니다. 팀은 Tableau 보고서에서 사용하는 것과 동일한 테이블과 열 이름을 BigQuery에서 사용했고 작동에 문제가 없었습니다. 또한 Tableau에서 커스텀 SQL을 사용하지 않았기 때문에 대부분의 보고서를 다시 작성할 필요가 없었습니다. 팀에서는 BigQuery의 ANSI SQL 호환 언어가 회사의 요구사항 대부분과 호환된다는 사실을 파악했습니다. 아울러 약 10개의 UDF를 작성하여 손쉽게 처리할 수 있는 충분한 양의 정규 표현식이 포함된 커스텀 SQL도 일부 갖췄습니다.

  • ETL: 1,500건이 넘는 ETL 작업이 세 가지 도구(Attunity, 커스텀 Python 스크립트, Kafka Connect)에 분산되어 있습니다. ETL을 온프레미스로 처리하던 팀은 이제 마이그레이션의 두 번째 단계에서 ETL을 BigQuery로 마이그레이션하기 시작했습니다.

  • 데이터: 우선 Vertica에서 BigQuery로 옮겨야 할 데이터가 22TB였습니다. 팀은 SQL Server에 Attunity를, 클라우드 기반 소스에 Kafka Connect를 사용했습니다. 또한 커스텀 Python 코드는 BigQuery JDBC 드라이버와 기본적으로 통합되었습니다. 팀은 세 달 안에 600TB를 BigQuery로 수집했는데 이는 예상했던 것보다 훨씬 많은 양이었습니다.  

현재 Trendyol팀은 650TB의 데이터와 300개 이상의 SCD를 BigQuery에 보관 중이며 매일 11TB의 데이터를 처리합니다. Trendyol은 정액제, 슬롯 예약, 가변 슬롯을 조합하여 항상 최적의 비용으로 작업을 처리합니다. 예를 들어 이제 Trendyol에서는 주문형 방식으로 가변 슬롯을 구매하여 수요 변동에 대응할 수 있습니다. 또한 데이터팀에서는 데이터 웨어하우스 운영에 신경쓰는 대신 가치를 창출하는 데 더욱 집중할 수 있습니다.

IT팀과 비즈니스팀의 관계도 크게 바뀌었습니다. 현재 두 팀은 속도와 확장성 면에서 많은 이점을 누리고 있습니다. 데이터팀은 월요일 오전에 1시간 만에 보고서를 생성하여 SLA를 안정적으로 충족할 수 있습니다. 이전에는 요일에 따라 ODS 파이프라인에 2~3시간이 소요되었습니다. Trendyol은 BigQuery 마이그레이션을 통해 IT팀과 비즈니스팀 간에 신뢰를 회복하고, 데이터를 기반으로 의사 결정을 내리며, 비용을 절감하고, 고객의 니즈를 신속하게 충족할 수 있게 되었습니다. 

TrendyolBigQuery의 데이터 웨어하우스 마이그레이션 프로그램에 대해 자세히 알아보기


게시 위치