제퍼넷 로고

Amazon Devices가 서버리스 분석을 사용하여 실시간 수요 및 공급 예측을 확장하고 최적화한 방법

시간

Amazon 디바이스는 매일 글로벌 배송, 재고, 용량, 공급, 판매, 마케팅, 생산자 및 고객 서비스 팀의 수십억 건의 거래를 처리하고 분석합니다. 이 데이터는 Amazon 고객의 요구를 충족하기 위해 장치의 재고를 조달하는 데 사용됩니다. 매년 두 자릿수 성장률을 보이는 데이터 볼륨과 2021년 코로나XNUMX 팬데믹으로 인해 전 세계 물류가 혼란에 빠지면서 거의 실시간으로 데이터를 확장하고 생성하는 것이 더욱 중요해졌습니다.

이 게시물은 여러 소스와 다양한 형식의 데이터를 자동으로 소비하는 AWS 기반 서버리스 데이터 레이크로 마이그레이션한 방법을 보여줍니다. 또한 데이터 과학자와 엔지니어가 AI 및 기계 학습(ML) 서비스를 사용하여 지속적으로 데이터를 공급하고 분석할 수 있는 더 많은 기회를 만들었습니다.

과제 및 설계 문제

주로 사용되는 레거시 아키텍처 아마존 엘라스틱 컴퓨트 클라우드 (Amazon EC2) 다양한 내부 이기종 데이터 소스 및 REST API의 조합으로 데이터를 추출합니다. 아마존 단순 스토리지 서비스 (Amazon S3) 데이터를 로드하고 아마존 레드 시프트 추가 분석 및 구매 주문 생성을 위해.

우리는 이 접근 방식으로 인해 몇 가지 결함이 발생했으며 따라서 다음 영역에서 개선을 이끌어 냈습니다.

  • 개발자 속도 – 런타임 실패의 주요 원인인 스키마의 통합 및 검색 부족으로 인해 개발자는 종종 운영 및 유지 관리 문제를 처리하는 데 시간을 할애했습니다.
  • 확장성 – 이러한 데이터 세트의 대부분은 전 세계에서 공유됩니다. 따라서 데이터를 쿼리하는 동안 확장 제한을 충족해야 합니다.
  • 최소한의 인프라 유지 보수 – 현재 프로세스는 데이터 소스에 따라 여러 컴퓨팅에 걸쳐 있습니다. 따라서 인프라 유지 관리를 줄이는 것이 중요합니다.
  • 데이터 소스 변경에 대한 대응 – 현재 시스템은 다양한 이기종 데이터 저장소 및 서비스에서 데이터를 가져옵니다. 이러한 서비스에 대한 모든 업데이트에는 몇 달의 개발자 주기가 필요합니다. 이러한 데이터 소스에 대한 응답 시간은 주요 이해 관계자에게 매우 중요합니다. 따라서 고성능 아키텍처를 선택하려면 데이터 기반 접근 방식을 취해야 합니다.
  • 스토리지 및 중복성 – 이기종 데이터 저장소 및 모델로 인해 다양한 비즈니스 이해 관계자 팀의 다양한 데이터 세트를 저장하는 것이 어려웠습니다. 따라서 비교할 증분 및 차등 데이터와 함께 버전 관리를 사용하면 보다 최적화된 계획을 생성할 수 있는 놀라운 기능을 제공할 것입니다.
  • 도망자 및 접근성 – 물류의 변동성으로 인해 일부 비즈니스 이해관계자 팀은 주문형 데이터를 분석하고 구매 주문에 대한 실시간에 가까운 최적의 계획을 생성해야 합니다. 따라서 거의 실시간으로 액세스하고 분석하기 위해 데이터를 폴링하고 푸시해야 합니다.

구현 전략

이러한 요구 사항을 기반으로 전략을 변경하고 솔루션을 식별하기 위해 각 문제를 분석하기 시작했습니다. 구조적으로 우리는 서버리스 모델을 선택했고 데이터 레이크 아키텍처 액션 라인은 우리가 개선의 일부라고 판단한 모든 아키텍처 격차와 까다로운 기능을 나타냅니다. 운영 관점에서 우리는 다음을 사용하여 데이터 수집을 위한 새로운 공유 책임 모델을 설계했습니다. AWS 접착제 데이터를 추출하도록 Amazon EC2에서 설계된 내부 서비스(REST API) 대신. 우리는 또한 사용 AWS 람다 데이터 처리를 위해. 그런 다음 우리는 선택했습니다 아마존 아테나 우리의 쿼리 서비스로. 데이터 소비자를 위한 개발자 속도를 더욱 최적화하고 개선하기 위해 아마존 DynamoDB 데이터 레이크에 상륙하는 다양한 데이터 소스에 대한 메타데이터 저장소로 사용됩니다. 이 두 가지 결정은 우리가 내린 모든 설계 및 구현 결정의 원동력이 되었습니다.

다음 다이어그램은 아키텍처를 보여줍니다.

아치

다음 섹션에서는 프로세스 흐름을 따라 이동하면서 아키텍처의 각 구성 요소를 자세히 살펴봅니다.

ETL용 AWS Glue

새로운 비즈니스의 데이터 소스 규모를 지원하면서 고객 요구 사항을 충족하려면 다양한 데이터 소스를 쿼리할 때 높은 수준의 민첩성, 확장성 및 응답성을 확보하는 것이 중요했습니다.

AWS Glue는 분석 사용자가 여러 소스의 데이터를 쉽게 검색, 준비, 이동 및 통합할 수 있게 해주는 서버리스 데이터 통합 ​​서비스입니다. 분석, ML 및 애플리케이션 개발에 사용할 수 있습니다. 또한 작성, 작업 실행 및 비즈니스 워크플로 구현을 위한 추가 생산성 및 DataOps 도구가 포함됩니다.

AWS Glue를 사용하면 70개 이상의 다양한 데이터 원본을 검색 및 연결하고 중앙 집중식 데이터 카탈로그에서 데이터를 관리할 수 있습니다. ETL(추출, 변환 및 로드) 파이프라인을 시각적으로 생성, 실행 및 모니터링하여 데이터를 데이터 레이크에 로드할 수 있습니다. 또한 Athena를 사용하여 카탈로그화된 데이터를 즉시 검색하고 쿼리할 수 있습니다. 아마존 EMR아마존 레드시프트 스펙트럼.

AWS Glue를 사용하면 다양한 데이터 스토어의 데이터에 쉽게 연결하고, 필요에 따라 데이터를 편집 및 정리하고, 통합 보기를 위해 데이터를 AWS 프로비저닝 스토어에 로드할 수 있습니다. AWS Glue 작업은 클라이언트의 리소스와 데이터 레이크에서 데이터를 추출하기 위해 요청 시 예약하거나 호출할 수 있습니다.

이러한 작업의 일부 책임은 다음과 같습니다.

  • 소스 엔터티를 데이터 엔터티로 추출 및 변환
  • 더 나은 카탈로그 작성을 위해 연도, 월, 일을 포함하도록 데이터를 강화하고 더 나은 쿼리를 위해 스냅샷 ID를 포함합니다.
  • Amazon S3에 대한 입력 검증 및 경로 생성 수행
  • 소스 시스템을 기반으로 인증된 메타데이터 연결

내부 서비스에서 REST API를 쿼리하는 것은 우리의 핵심 과제 중 하나이며 최소한의 인프라를 고려하여 이 프로젝트에서 사용하고 싶었습니다. AWS Glue 커넥터는 요구 사항과 목표를 준수하는 데 도움이 되었습니다. REST API 및 기타 데이터 소스에서 데이터를 쿼리하기 위해 PySpark 및 JDBC 모듈을 사용했습니다.

AWS Glue는 다양한 연결 유형을 지원합니다. 자세한 내용은 다음을 참조하십시오. AWS Glue의 ETL에 대한 연결 유형 및 옵션.

랜딩 존으로 S3 버킷

추가 처리 및 최적화된 추출된 데이터의 즉각적인 랜딩 존으로 S3 버킷을 사용했습니다.

AWS Glue ETL 트리거로서의 Lambda

S3 버킷에서 S3 이벤트 알림을 활성화하여 데이터를 추가로 분할하는 Lambda를 트리거했습니다. 데이터는 InputDataSetName, Year, Month 및 Date로 분할됩니다. 이 데이터 위에서 실행되는 모든 쿼리 프로세서는 더 나은 비용 및 성능 최적화를 위해 데이터의 하위 집합만 스캔합니다. 데이터는 CSV, JSON 및 Parquet와 같은 다양한 형식으로 저장할 수 있습니다.

원시 데이터는 종종 중복되거나 잘못된 데이터 유형이 있기 때문에 최적의 계획을 생성하는 대부분의 사용 사례에 적합하지 않습니다. 가장 중요한 것은 데이터가 여러 형식으로 되어 있지만 우리는 데이터를 신속하게 수정했고 Parquet 형식을 사용하여 상당한 쿼리 성능 향상을 관찰했습니다. 여기에서 성능 팁 중 하나를 사용했습니다. Amazon Athena를 위한 10가지 성능 튜닝 팁.

ETL용 AWS Glue 작업

우리는 더 나은 데이터 분리 및 접근성을 원했기 때문에 성능을 더욱 향상시키기 위해 다른 S3 버킷을 선택했습니다. 동일한 AWS Glue 작업을 사용하여 데이터를 필요한 S3 버킷으로 추가 변환하고 로드하고 추출된 메타데이터의 일부를 DynamoDB로 로드했습니다.

메타데이터 저장소로서의 DynamoDB

이제 데이터가 있으므로 다양한 비즈니스 이해 관계자가 데이터를 추가로 사용합니다. 이로 인해 데이터 레이크에 있는 원본 데이터와 버전이라는 두 가지 질문이 남습니다. 소비자가 데이터를 효과적으로 쿼리할 수 있도록 최신 세부 정보를 제공하는 DynamoDB를 메타데이터 스토어로 선택했습니다. 시스템의 모든 데이터 세트는 메타데이터 저장소에서 검색할 수 있는 스냅샷 ID로 고유하게 식별됩니다. 클라이언트는 API를 사용하여 이 데이터 저장소에 액세스합니다.

데이터 레이크로서의 Amazon S3

더 나은 데이터 품질을 위해 동일한 AWS Glue 작업을 사용하여 보강된 데이터를 다른 S3 버킷으로 추출했습니다.

AWS 글루 크롤러

크롤러는 스키마 변경에 대응할 수 있게 해주는 "비밀 소스"입니다. 프로세스 전반에 걸쳐 우리는 가능한 한 스키마에 구애받지 않는 각 단계를 선택하여 스키마 변경이 AWS Glue에 도달할 때까지 흐를 수 있도록 했습니다. 크롤러를 사용하면 스키마에 발생하는 불가지론적 변경 사항을 유지할 수 있습니다. 이를 통해 Amazon S3에서 데이터를 자동으로 크롤링하고 스키마와 테이블을 생성할 수 있었습니다.

AWS Glue 데이터 카탈로그

데이터 카탈로그는 카탈로그를 Amazon S3에서 데이터의 위치, 스키마 및 런타임 지표에 대한 인덱스로 유지하는 데 도움이 되었습니다. 데이터 카탈로그의 정보는 각 테이블이 단일 데이터 저장소를 지정하는 메타데이터 테이블로 저장됩니다.

SQL 쿼리용 Athena

Athena는 표준 SQL을 사용하여 Amazon S3의 데이터를 쉽게 분석할 수 있게 해주는 대화형 쿼리 서비스입니다. Athena는 서버리스이므로 관리할 인프라가 없으며 실행한 쿼리에 대해서만 비용을 지불합니다. 우리는 운영 안정성과 개발자 속도 향상을 주요 개선 요소로 고려했습니다.

다음을 생성하여 사용자가 값과 쿼리를 연결하여 Athena에서 데이터를 가져올 수 있도록 Athena를 쿼리하는 프로세스를 추가로 최적화했습니다.

  • An AWS 클라우드 개발 키트 (AWS CDK) 템플릿을 생성하여 Athena 인프라 및 AWS 자격 증명 및 액세스 관리 모든 계정에서 데이터 레이크 S3 버킷 및 데이터 카탈로그에 액세스할 수 있는 (IAM) 역할
  • 클라이언트가 IAM 역할, 쿼리, 데이터 형식 및 출력 위치를 제공하여 Athena 쿼리를 시작하고 선택한 버킷에서 실행되는 쿼리의 상태 및 결과를 가져올 수 있는 라이브러리입니다.

Athena를 쿼리하는 것은 XNUMX단계 프로세스입니다.

  • 쿼리 실행 시작 – 이렇게 하면 쿼리 실행이 시작되고 실행 ID를 가져옵니다. 사용자는 쿼리 출력이 저장될 출력 위치를 제공할 수 있습니다.
  • GetQuery 실행 – 실행이 비동기적이기 때문에 쿼리 상태를 가져옵니다. 성공하면 S3 파일에서 또는 다음을 통해 출력을 쿼리할 수 있습니다. API.

쿼리 실행을 시작하고 결과를 가져오는 도우미 메서드는 라이브러리에 있습니다.

데이터 레이크 메타데이터 서비스

이 서비스는 맞춤형으로 개발되었으며 DynamoDB와 상호 작용하여 메타데이터(데이터 세트 이름, 스냅샷 ID, 파티션 문자열, 타임스탬프 및 데이터의 S3 링크)를 REST API 형식으로 가져옵니다. 스키마가 검색되면 클라이언트는 Athena를 쿼리 프로세서로 사용하여 데이터를 쿼리합니다.

스냅샷 ID가 있는 모든 데이터 세트가 분할되기 때문에 조인 쿼리는 전체 테이블 스캔이 아니라 Amazon S3에서 파티션 스캔만 수행합니다. 쿼리 인프라를 관리하지 않아도 되기 때문에 Athena를 쿼리 프로세서로 사용했습니다. 나중에 뭔가 더 필요하다고 생각되면 Redshift Spectrum 또는 Amazon EMR을 사용할 수 있습니다.

결론

Amazon Devices 팀은 AWS Glue를 사용하여 데이터 레이크 아키텍처로 이동함으로써 상당한 가치를 발견했습니다. 이를 통해 여러 글로벌 비즈니스 이해 관계자가 보다 생산적인 방식으로 데이터를 수집할 수 있었습니다. 이를 통해 팀은 공급망, 수요 및 예측의 문제를 해결하기 위해 적절한 비즈니스 논리로 거의 실시간으로 다양한 데이터 세트를 분석하여 장치 구매 주문을 위한 최적의 계획을 생성할 수 있었습니다.

운영 관점에서 투자는 이미 성과를 거두기 시작했습니다.

  • 수집, 저장 및 검색 메커니즘을 표준화하여 온보딩 시간을 절약했습니다. 이 시스템을 구현하기 전에 하나의 데이터 세트를 온보딩하는 데 1개월이 걸렸습니다. 새로운 아키텍처 덕분에 15개월도 안 되어 2개의 새로운 데이터 세트를 온보딩할 수 있었고 민첩성이 70% 향상되었습니다.
  • 확장 병목 현상을 제거하여 수천 번의 실행으로 빠르게 확장할 수 있는 동종 시스템을 만들었습니다.
  • 이 솔루션은 데이터 품질 위반이 발견되면 입력을 수락하고 거부하기 전에 스키마 및 데이터 품질 검증을 추가했습니다.
  • 버전이 지정된 입력이 필요한 향후 시뮬레이션 및 백 테스터 사용 사례를 지원하면서 데이터 세트를 쉽게 검색할 수 있습니다. 이렇게 하면 모델 시작 및 테스트가 더 간단해집니다.
  • 이 솔루션은 데이터 수집, 저장 및 검색 사용 사례와 관련하여 유사한 문제가 있는 DIAL의 다른 팀으로 쉽게 확장할 수 있는 공통 인프라를 만들었습니다.
  • 운영 비용이 거의 90% 감소했습니다.
  • 이 데이터 레이크는 당사의 데이터 과학자와 엔지니어가 효율적으로 액세스하여 다른 분석을 수행하고 구매 주문에 대한 정확한 계획을 생성할 미래의 기회로 예측 접근 방식을 가질 수 있습니다.

이 게시물의 단계는 다양한 소스에서 데이터를 수집하고, 자동으로 메타데이터 카탈로그를 생성하고, 데이터 레이크와 데이터 웨어하우스 간에 데이터를 원활하게 공유하고, 이벤트에서 알림을 생성하기 위해 AWS 관리형 서비스를 사용하여 유사한 최신 데이터 전략을 구축하는 계획을 세우는 데 도움이 될 수 있습니다. 오케스트레이션된 데이터 워크플로우 실패의


저자 소개

avinash_kolluri아비나쉬 콜루리 AWS의 선임 솔루션 아키텍트입니다. 그는 Amazon Alexa 및 장치 전반에서 작업하여 최신 분산 솔루션을 설계하고 설계합니다. 그의 열정은 AWS에서 비용 효율적이고 확장성이 뛰어난 솔루션을 구축하는 것입니다. 여가 시간에는 퓨전 레시피 요리와 여행을 즐깁니다.

비풀비풀 베르마 Amazon.com의 수석 소프트웨어 엔지니어입니다. 그는 2015년부터 Amazon에서 근무하면서 Amazon 고객의 삶에 직접적인 영향을 미치고 삶을 개선하는 기술을 통해 실제 문제를 해결하고 있습니다. 여가 시간에는 하이킹을 즐깁니다.

spot_img

최신 인텔리전스

spot_img