Woot.com은 어떻게 AWS 기반 서버리스 데이터 레이크를 구축 하였는가?

이 글에서는 관계형 데이터베이스를 기반으로 구축된 기존 데이터 웨어하우스를 대체할 클라우드 네이티브 데이터 웨어하우스를 설계하는 방법에 대해 Woot.com의 사례를 소개합니다. (Woot는 2004 년에 설립되어 2010년 Amazon에 의해 인수된 최초의 일일 거래 사이트입니다. 원래 Woot는 매진 할 때까지 하루에 단 하나의 제품만을 제공했으나, 최근에는 7 가지 카테고리에 걸쳐 특별 일일 거래 및 기타 기간 한정 상품을 제공하고 있습니다.)

우선 설계 초기에는 관계형 데이터베이스에서 다른 관계형 데이터베이스로 그대로 마이그레이션하는 것이 가장 단순한 솔루션으로 보였습니다. 하지만 데이터 웨어하우스에서 정말로 필요로 했던 것에 우선적으로 역점을 두기로 결정했습니다.

작업에 적합한 도구를 사용하여 레거시 Oracle 데이터베이스를 더 작은 마이크로 서비스로 분리하는 방법을 모색하기 시작했습니다. 이 프로세스의 목적은 단순히 AWS 도구를 사용하는 것에 그치지 않고 클라우드 네이티브 기술을 사용하여 최종적인 목표를 실현하는 것 입니다.

이 마이그레이션을 위해서는 ETL(추출, 변환, 로드) 파이프라인을 새로 개발하여 기존 데이터를 마이그레이션하면서 새로운 데이터의 흐름을 유도해야 했습니다. 이 마이그레이션 덕분에 여러 대의 서버를 사용하는 대신 AWS Glue를 사용하여 완전한 서버리스 데이터 웨어하우스로 전환할 수 있었습니다.

이 블로그 글에서는 다음의 전환 과정을 소개합니다.

데이터 웨어하우스용으로 서버리스 데이터 레이크를 선택한 이유
Woot 시스템의 아키텍처 다이어그램
마이그레이션 프로젝트의 개요
마이그레이션 결과

아키텍처 및 설계 고려 사항

설계 시에 저희가 고려한 몇 가지 주안점은 다음과 같습니다.

고객 경험
저희는 항상 고객이 무엇을 필요로 하는지를 기준으로 거꾸로 작업합니다. 저희의 데이터 웨어하우스는 다양한 기술 전문 지식을 가진 사람들이 비즈니스 전반에 걸쳐 사용합니다. 따라서 다양한 유형의 사용자가 운영에 대한 통찰력을 얻고 더 나은 피드백 메커니즘을 제공하여 전반적인 고객 경험을 향상시킬 수 있는 능력에 중점을 두었습니다.
최소한의 인프라 유지 보수
“Woot 데이터 웨어하우스 팀”은 사실 Chaya라는 한 사람으로 이루어진 팀입니다. 따라서 클라우드 고유 기술을 사용할 수 있게 해주는 AWS 서비스에 초점을 맞추는 것이 중요합니다. 이를 통해 수요가 변화하고 기술이 발전하는 중에도 여전히 존재하는 인프라 관리의 부담을 해소합니다.
데이터 원본 변경에 대한 대응
저희의 데이터 웨어하우스는 다양한 내부 서비스로부터 데이터를 가져옵니다. 기존 데이터 웨어하우스에서 이러한 서비스를 업데이트하려면 ETL 작업 및 테이블을 수동으로 업데이트해야 했습니다. 이러한 데이터 원본의 응답 시간은 주요 이해 관계자들에게 중요한 문제입니다. 따라서 고성능 아키텍처를 선택하는 데 있어서 데이터 중심의 접근 방식이 필요합니다.
프로덕션 시스템에서 분리
원래 데이터 웨어하우스 시스템은 프로덕션 시스템과 긴밀하게 결합되어 있었습니다. 여러 사용자가 사용할 수 있도록 프로덕션 시스템에서 분리하고 여러 VPC에서 리소스를 탐색하는 복잡성을 최소화해야 했습니다.

이러한 요구 사항에 따라 운영 및 아키텍처 측면에서 데이터 웨어하우스를 변경하기로 결정했습니다. 운영 관점에서는 데이터 수집을 위한 새로운 공동 책임 모델을 설계했습니다. 아키텍처에 있어서는 기존의 관계형 데이터베이스와 달리 서버리스 모델을 택했습니다. 이 두 가지 결정은 마이그레이션에 적용한 모든 설계 및 구현 관련 결정 사항의 바탕이 되었습니다.

공동 책임 모델로 전환하는 과정에서 몇 가지 중요한 사항에 주목하게 되었습니다. 첫째, 새로운 데이터 수집 방식은 Woot의 기술 조직에서 중대한 문화적 변화였습니다. 과거에는 데이터 수집을 데이터 웨어하우스 팀이 담당했고 서비스에서 데이터를 가져오는 데 사용자 지정 파이프라인이 필요했습니다. 저희는 “가져오는 것이 아니라 푸시”하는 방식으로 전환하기로 결정했습니다. 서비스에서 데이터 웨어하우스로 데이터를 보내는 것입니다.

여기에서 공동 책임이라는 개념이 등장합니다. 처음으로, 개발 팀이 데이터 웨어하우스의 서비스 데이터에 대한 소유권을 가지게 된 것입니다. 그러나 개발자가 데이터 엔지니어 역할도 병행해야 하는 상황은 원하지 않았습니다. 대신 개발자의 기존 기술 세트에 맞추어 데이터를 손쉽게 푸시할 수 있는 방법을 제공하고자 했습니다. 또한 당사 웹 사이트에서 사용하는 다양한 기술에서 데이터에 액세스 할 수 있어야 했습니다.

이러한 고려 사항에 따라 서버리스 데이터 웨어하우스용으로 다음과 같은 AWS 서비스를 선택할 수 있었습니다.

데이터 수집을 위한 Amazon Kinesis Data Firehose
데이터 저장을 위한 Amazon S3
데이터 처리를 위한 AWS Lambda 및 AWS Glue
데이터 마이그레이션을 위한 AWS Data Migration Service(AWS DMS) 및 AWS Glue
오케스트레이션 및 메타데이터 관리를 위한 AWS Glue
쿼리 실행 및 데이터 시각화를 위한 Amazon Athena 및 Amazon QuickSight

다음 다이어그램은 저희가 이들 서비스를 어떻게 활용했는지를 개략적으로 보여 줍니다.

절충안

이러한 구성 요소들이 통합되어 모든 요구 사항을 충족시키고 공동 책임 모델을 가능하게 했습니다. 하지만 다른 관계형 데이터베이스로 그대로 마이그레이션하는 것과 비교해 몇 가지를 절충했습니다.

가장 큰 절충은 사전 작업과 지속적인 유지 보수 간의 절충이었습니다. 모든 데이터 파이프라인을 처음부터 효과적으로 시작해야 했으며 모든 웹 사이트 서비스에 새로운 기술을 도입해야 했고, 그러기 위해서는 여러 기술 팀이 공동으로 작업해야 했습니다. 지속적인 유지 보수 작업을 최소화하는 것이 핵심 요구 사항이었습니다. 사용하는 서버리스 구성 요소의 관리형 인프라를 활용하기 위해 이러한 절충안을 기꺼이 수용했습니다.
또 다른 절충은 기술에 대한 전문 지식이 없는 사용자를 위한 사용 편의성과 빅 데이터 기술의 이점 사이에서 균형점을 찾는 것이었습니다. 이러한 상반된 이점을 고려할 때 고객 경험을 핵심 요구 사항으로 삼은 것이 의사 결정을 진행하는 데 도움이 되었습니다. 궁극적으로 다른 관계형 데이터베이스로 전환하는 것만으로도 고객은 더 나은 경험이 아니라 동일한 경험을 갖게 됩니다.

Kinesis Data Firehose 및 Lambda를 사용하여 데이터 파이프라인 구축

사이트가 이미 AWS에서 실행되고 있기 때문에 개발자의 입장에서는 AWS SDK로 Kinesis Data Firehose에 데이터를 전송하기가 쉬웠습니다. 이 단계에서는 다음과 같은 사항을 고려해야 했습니다.

Kinesis Data Firehose에 대한 직접 PUT 수집은 개발자가 구현하기에 자연스럽고, 서비스에서 사용되는 모든 언어로 작동하며, Amazon S3에 데이터를 전달합니다.
데이터 저장에 S3를 사용하면 고가용성, 확장성 및 내구성이 자동으로 실현됩니다. S3에 저장한 데이터는 여러 계정에서 공유할 수 있기 때문에 별도의 AWS 계정에서 데이터 웨어하우스를 관리하고 여러 VPC를 탐색해야 하는 복잡성을 피할 수 있습니다.

또한 Amazon DynamoDB 테이블에 저장된 데이터를 사용합니다. 여기서도 Kinesis Data Firehose는 솔루션의 핵심 요소를 제공하며, 이번에는 DynamoDB Streams 및 Lambda와 결합되었습니다. 각 DynamoDB 테이블에 대해 DynamoDB 스트림을 활성화한 다음 이 스트림을 사용하여 Lambda 함수를 트리거했습니다.

Lambda 함수는 DynamoDB 스트림 출력을 지우고 정리된 JSON을 boto3를 사용하여 Kinesis Data Firehose에 데이터를 넣습니다. 그런 다음 다른 프로세스와 융합하여 S3에 데이터를 출력합니다. 자세한 내용은 AWS 데이터베이스 블로그에서 AWS Lambda 및 Amazon Kinesis Firehose를 사용하여 Amazon DynamoDB에서 Amazon Aurora로 데이터를 스트리밍하는 방법 게시물을 참조하십시오.

Lambda는 세분화된 제어 기능을 제공하면서 계정 간에 파일을 옮길 수 있습니다.

S3 버킷에서 S3 이벤트 알림을 활성화하고 Amazon SNS 주제를 생성하여 Kinesis Data Firehose가 객체를 버킷에 넣을 때 알림을 수신합니다.
이 SNS 주제는 Kinesis 출력을 가져와 선택한 파티션 구조의 데이터 웨어하우스 계정으로 옮기는 Lambda 함수를 트리거합니다.

원래 S3 이벤트 알림은 Lambda 함수를 직접 트리거 할 수 있지만 이 경우는 S3 버킷과 Lambda 함수가 별도의 계정에 있었기 때문에 SNS를 중개자로 선택했습니다.

AWS DMS 및 AWS Glue를 사용하여 기존 데이터 마이그레이션

기존 RDS 데이터베이스의 데이터를 S3로 마이그레이션해야 했고, 이 작업은 AWS DMS를 사용하여 수행했습니다. DMS는 DMS 설명서에서 설명하는 것처럼 대상으로서 S3를 기본 지원합니다.

이를 설정하는 것은 비교적 간단했습니다. DMS의 연결 특성을 조정하여 프로덕션 VPC에서 별도의 데이터 웨어하우스 계정으로 직접 데이터를 내보냈습니다. 사용한 스트링은 다음과 같습니다.

"cannedAclForObjects=BUCKET_OWNER_FULL_CONTROL;compressionType=GZIP;addColumnName=true;”

이 코드는 버킷 소유자(대상 데이터 웨어하우스 계정)에 소유권을 부여하고, 파일을 압축하여 스토리지 비용을 절감하며, 모든 열 이름을 포함합니다. S3에 데이터를 저장한 후 AWS Glue 크롤러를 사용하여 내보낸 모든 테이블의 스키마를 추측 한 다음 원본 데이터와 비교했습니다.

AWS Glue를 활용하여 극복한 몇 가지 당면 과제는 다음과 같습니다.

포럼 및 블로그 게시물과 같은 비정형 텍스트 데이터
DMS는 이러한 데이터를 CSV로 내보냅니다. 이 방식은 텍스트 데이터에 있는 쉼표와 충돌합니다. 저희는 AWS Glue를 사용하여, 열을 직접 인코딩하기 때문에 쉼표의 영향을 받지 않는 Parquet 형식으로 RDS에서 S3로 데이터를 내보내는 방식을 선택했습니다.
계정 간 내보내기
이 문제는 각 AWS Glue 작업의 상단에

"glueContext._jsc.hadoopConfiguration().set("fs.s3.canned.acl", "BucketOwnerFullControl”)”

코드를 포함하여 버킷 소유자에게 AWS Glue엠서 생성되는 모든 S3 파일에 대한 액세스 권한을 부여하는 방법으로 해결했습니다.

전반적으로, AWS DMS는 설정 속도가 더 빠르고 규칙 기반 변환을 통해 많은 양의 데이터를 내보낼 수 있었습니다. AWS Glue에서는 사전에 작업을 설정하는 과정이 더 복잡하지만 출력에 대한 세부적인 제어 능력이 상황에서는 더 나은 결과를 제공했습니다.

CSV 또는 JSON으로 작성된 기존의 원시 데이터를 Parquet으로 변환하려는 경우 AWS Glue 작업을 설정하여 이를 수행 할 수 있습니다. 이 프로세스에 대해서는 AWS 빅 데이터 블로그 게시물 AWS Glue 및 Amazon S3를 사용하여 데이터 레이크 기반 구축에서 설명하고 있습니다.

AWS Glue, Amazon Athena 및 Amazon QuickSight를 사용한 통합

데이터가 S3에 도달하고 나면 비로소 흥미로운 작업이 시작됩니다. 실제로 데이터를 작업에 사용하게 되는 것입니다. 저는 데이터 엔지니어입니다. 제게는 AWS Glue를 살펴보는 것이 큰 즐거움 중 하나였습니다.

AWS Glue는 ETL 작업 예약을 처리합니다.
AWS Glue 크롤러는 AWS Glue 데이터 카탈로그의 메타데이터를 관리합니다.

크롤러는 스키마 변경 사항에 대응하기 위한 “비밀 병기”라고 할 수 있습니다. 파이프라인 전체에서 각 단계를 가능한 한 스키마에 독립적으로 만들어 AWS Glue에 도달할 때까지 스키마 변경 사항이 전체적으로 전달되도록 하기로 결정했습니다.

하지만 원시 데이터는 종종 중복되거나 잘못된 데이터 유형을 가지고 있기 때문에 대부분의 비즈니스 사용자에게는 적합하지 않습니다. 무엇보다 Firehose에서 데이터 출력시에 JSON 포맷 대신 Parquet 포맷을 사용하면 Athena의 쿼리 성능이 크게 향상됩니다. 이와 관련해서는 빅 데이터 블로그 게시물 Amazon Athena – 10가지 성능 향상 팁에서 소개하는 성능 향상 팁 중 하나를 활용했습니다.

공동 책임 모델을 사용하면 데이터 웨어하우스 및 BI 팀이 데이터를 큐레이트된 데이터 세트로 최종 처리하여 보고할 준비가 됩니다. Lambda와 AWS Glue를 사용하면 이 팀이 Python 및 SQL(Amazon 데이터 엔지니어링 및 BI 역할의 핵심 언어)로 작업할 수 있습니다. 또한 최소한의 인프라 설치 또는 유지 관리로 코드를 배포할 수 있습니다.

ETL 프로세스는 다음과 같습니다.

예약된 트리거.
이전 작업에 종속된 후속 작업의 흐름을 제어하는 일련의 조건부 트리거.
많은 작업에서 나타나는 원시 데이터를 읽고, 데이터를 중복 제거한 다음, Parquet을 작성하는 유사한 패턴. 함수의 Python 라이브러리를 생성하고 S3에 업로드함으로써 이 로직을 중앙 집중화했습니다. 그런 다음 이 라이브러리를 AWS Glue 작업에 추가 Python 라이브러리로 포함했습니다. 이렇게 하는 방법에 대한 자세한 내용은 AWS Glue 설명서에서 AWS Glue에 Python 라이브러리 사용을 참조하십시오.

또한 비즈니스 지표가 수록된 보고 테이블을 만드는 데 사용되는 복잡한 작업을 마이그레이션했습니다.

AWS Glue에 PySpark를 사용한 결과 SparkSQL 쿼리를 작업에 직접 포함할 수 있게 되어 이러한 쿼리의 마이그레이션이 간단해졌습니다.
SparkSQL으로 변환하는 과정에서 약간의 시행 착오를 거쳤지만 궁극적으로는 SQL 쿼리를 Spark 메서드로 변환하는 것보다 작업 부담이 적었습니다. 그러나 이전에 Pandas 와 Spark에서 근무한 BI 팀의 직원의 경우는 Spark 데이터 프레임을 사용한 작업쪽이 더 익숙했습니다. Python을 배우기 전에 SQL을 몇 년 동안 사용해 본 사람으로서 저는 PySpark를 사용하여 SQL과 객체 지향 프레임워크를 간을 신속하게 전환할 수 있었습니다.

AWS Glue 작업을 사용하는 데 따른 다른 숨은 이점으로는, Lambda와 마찬가지로 Python boto3가 AWS Glue에 이미 설치되어 있다는 점을 들 수 있습니다. 따라서 ETL 작업에서 추가 구성 없이 AWS API 작업을 직접 사용할 수 있습니다.

예를 들어 AWS Glue가 S3에 데이터를 쓰는 동안 사용자가 해당 테이블을 쿼리할 경우 오래 실행되는 일부 작업에서 읽기 불일치가 유발되었습니다. 저희는 Spark를 사용하여 임시 디렉토리에 기록한 다음 boto3을 사용하여 파일을 제자리로 옮기도록 AWS Glue 작업을 수정했습니다. 이를 통해 읽기 불일치를 최대 90%까지 줄였습니다. 이 기능은 쉽게 사용할 수 있기 때문에 매우 유용했습니다. 자체적으로 Spark 클러스터를 관리했다면 불가능한 일이었습니다.

이전 상태와 현재 상태 비교

모든 데이터 세트를 제 위치에 배치한 후에는 고객이 쿼리를 시작하게 되었습니다. 여기에서 고객 경험이 크게 향상되었습니다.

이전에는 사용자가 SQL 클라이언트를 다운로드하고 사용자 이름과 암호를 요청하여 설정한 다음 데이터를 추출하기 위해 SQL을 익혀야 했습니다. 이제 사용자가 자동으로 프로비저닝된 IAM 역할을 통해 AWS Management Console에 로그인하여 브라우저에서 Athena를 사용해 쿼리를 실행하기만 하면 됩니다. 또는 SQL을 건너뛰고 싶다면 기존의 Active Directory 서버를 통해 관리되는 계정으로 Amazon QuickSight 계정을 사용할 수 있습니다.

Active Directory와의 통합은 큰 이점을 가져다 주었습니다. 저희는 계정이 생성될 때까지 기다리거나 별도의 자격 증명을 관리하지 않고도 사용자가 사용을 시작할 수 있도록 하고 싶었습니다. 저희는 이미 회사 전체에서 Active Directory를 사용하여 여러 리소스에 액세스하고 있습니다. Amazon QuickSight Enterprise Edition으로 업그레이드한 덕분에 기존 AD 그룹 및 자격 증명을 사용하여 액세스를 관리할 수 있었습니다.

마이그레이션 결과

저희의 기존 데이터 웨어하우스는 5년에 걸쳐 개발되었습니다. 그런데 AWS Glue를 사용하여 약 3개월 만에 서버리스 데이터 레이크로 재구축했습니다.

결국 초반에는 단순히 다른 관계형 데이터베이스로 마이그레이션하는 것보다 많은 노력이 필요했습니다. 또한 저희가 상대적으로 익숙하지 않았던 제품(특히 AWS Glue)을 많이 사용했기 때문에 더 많은 불확실성 문제도 해결해야 했습니다.

하지만 마이그레이션이 완료된 후 몇 달 동안 데이터 웨어하우스 사용자로부터 새로운 도구에 대한 고무적인 피드백을 받았습니다. 사용자들은 다음과 같은 이점에 놀라움을 금치 못했습니다.

Athena의 빠른 속도.
Amazon QuickSight의 직관적이고 아름다운 인터페이스. 별도로 설치할 필요가 없다는 점에 특히 만족했습니다. CEO조차 사용하기 시작할 정도였으니까요.
Athena와 AWS Glue Data Catalog는 진정한 빅 데이터 플랫폼의 성능 향상을 가져오면서도 최종 사용자에게는 관계형 데이터베이스의 모양과 느낌을 그대로 유지합니다.

요약

운영의 관점에서 볼 때 이 투자는 이미 성과를 거두었습니다. 실제로 운영 비용이 90% 가까이 절감되었습니다.

개인적으로, 저는 최근에 서버리스 인프라 덕분에 3주 휴가를 떠날 수 있었는데 휴가 기간 동안 한 번도 호출을 받지 않았다는 것은 놀라운 일이었습니다. 또한 저를 비롯한 BI 엔지니어들은 S3 중심 아키텍처를 통해 Amazon EMR, Amazon SageMaker, Amazon Redshift Spectrum 및 Lambda와 같은 다른 서비스와 원활하게 통합함으로써 새로운 기술을 실험할 수 있게 되었습니다. 흥미로운 점은 저희가 이 서비스를 도입하는 동안에도 AWS의 서비스는 함께 성장하고 있었다는 것 입니다. (예: AWS Glue의 Amazon CloudWatch 지표 지원 개시 및 Athena의 뷰 기능 출시).

저는 저희와 함께 계속 성장하는 기술에 투자했다는 것을 기쁘게 생각합니다. 그리고 이 야심찬 마이그레이션을 달성한 우리 팀을 대단히 자랑스럽게 생각합니다. 저희의 경험이 다른 엔지니어가 자신의 데이터 레이크를 구축하는 데 동기부여가 되기를 희망합니다.

추가 정보는 다음의 유사한 AWS 빅 데이터 블로그 게시물을 참조하십시오.

Chaya Carey는 Woot.com의 데이터 엔지니어입니다. Woot에서 데이터 웨어하우스 및 기타 확장 가능한 데이터 솔루션을 관리합니다. 여가 시간에는 시애틀의 바, 레스토랑, 서적 및 비디오 게임에 열정을 쏟고 있습니다.

Karthik Odapally는 AWS의 수석 솔루션스 아키텍트입니다. 클라우드에서 경제적이고 확장성이 뛰어난 솔루션을 구축하는 데 열정을 쏟고 있습니다. 여가 시간에는 가족과 PNW의 친구들을 위해 쿠키와 컵케잌을 만들곤 합니다. 빈티지 경주용 자동차도 좋아합니다.