제퍼넷 로고

GoDaddy 데이터 플랫폼이 Amazon EMR 서버리스를 채택하여 60% 이상의 비용 절감과 50% 이상의 성능 향상을 달성한 방법 | 아마존 웹 서비스

시간

이 게시물은 GoDaddy의 Brandon Abear, Dinesh Sharma, John Bush, Ozcan IIikhan과 공동으로 작성한 게스트 게시물입니다.

에서 GoDaddy 온라인에서 성공할 수 있는 모든 도움과 도구를 제공하여 일상적인 기업가에게 힘을 실어줍니다. 전 세계적으로 20만 명이 넘는 고객을 보유하고 있는 GoDaddy는 사람들이 자신의 아이디어를 말하고, 전문적인 웹사이트를 구축하고, 고객을 유치하고, 업무를 관리하기 위해 찾아오는 곳입니다.

GoDaddy는 데이터 기반 회사라는 자부심을 갖고 있습니다. 데이터에서 귀중한 통찰력을 끊임없이 추구하는 것은 비즈니스 결정을 촉진하고 고객 만족을 보장합니다. 효율성에 대한 우리의 약속은 흔들리지 않으며 일괄 처리 작업을 최적화하기 위한 흥미로운 계획을 착수했습니다. 이 여정에서 우리는 개선 기회의 7개 계층이라고 부르는 구조화된 접근 방식을 확인했습니다. 이 방법론은 효율성을 추구하는 데 있어서 우리의 지침이 되었습니다.

이번 포스팅에서는 우리가 어떻게 운영 효율성을 향상시켰는지 논의합니다. Amazon EMR 서버리스. 벤치마킹 결과와 방법론, EMR 서버리스와 고정 용량의 비용 효율성에 대한 통찰력을 공유합니다. EC2의 Amazon EMR 다음을 사용하여 조정된 데이터 워크플로의 임시 클러스터 Apache Airflow용 Amazon 관리형 워크플로 (아마존 MWAA). 우리는 EMR 서버리스가 뛰어난 분야에서 채택하기 위한 전략을 공유합니다. 우리의 연구 결과에 따르면 60% 이상의 비용 절감, 50% 더 빠른 Spark 워크로드, 개발 및 테스트 속도의 XNUMX배 향상된 속도, 상당한 탄소 배출량 감소 등 상당한 이점이 있는 것으로 나타났습니다.

배경

2020년 말, GoDaddy의 데이터 플랫폼은 AWS 클라우드 여정을 시작하여 800PB의 데이터가 포함된 2.5노드 Hadoop 클러스터를 데이터 센터에서 EC2의 EMR로 마이그레이션했습니다. 이러한 리프트 앤 시프트 접근 방식은 온프레미스 환경과 클라우드 환경 간의 직접적인 비교를 촉진하여 AWS 파이프라인으로의 원활한 전환을 보장하고 데이터 검증 문제와 마이그레이션 지연을 최소화했습니다.

2022년 초까지 우리는 빅 데이터 워크로드를 EC2의 EMR로 성공적으로 마이그레이션했습니다. AWS FinHack 프로그램에서 배운 모범 사례를 사용하여 리소스 집약적인 작업을 미세 조정하고 Pig 및 Hive 작업을 Spark로 전환했으며 22.75년에 배치 워크로드 지출을 2022% 줄였습니다. 그러나 작업이 많아 확장성 문제가 발생했습니다. . 이로 인해 GoDaddy는 체계적인 최적화 여정에 착수하여 보다 지속 가능하고 효율적인 빅 데이터 처리를 위한 기반을 구축했습니다.

7개 계층의 개선 기회

운영 효율성을 추구하는 과정에서 다음 그림과 같이 배치 처리 작업 내에서 최적화를 위한 7가지 고유한 기회 계층을 식별했습니다. 이러한 계층은 정확한 코드 수준 향상부터 보다 포괄적인 플랫폼 개선까지 다양합니다. 이러한 다층적 접근 방식은 더 나은 성능과 더 높은 효율성을 지속적으로 추구하는 우리의 전략적 청사진이 되었습니다.

7개 계층의 개선 기회

레이어는 다음과 같습니다.

  • 코드 최적화 – 코드 로직을 개선하고 더 나은 성능을 위해 최적화할 수 있는 방법에 중점을 둡니다. 여기에는 선택적 캐싱, 파티션 및 프로젝션 정리, 조인 최적화, 기타 작업별 튜닝을 통한 성능 향상이 포함됩니다. AI 코딩 솔루션을 사용하는 것도 이 프로세스의 필수적인 부분입니다.
  • 소프트웨어 업데이트 - 최신 버전의 오픈 소스 소프트웨어(OSS)로 업데이트하여 새로운 기능과 개선 사항을 활용하세요. 예를 들어 Spark 3의 적응형 쿼리 실행은 상당한 성능 및 비용 개선을 제공합니다.
  • 사용자 정의 Spark 구성 - 리소스 활용도, 메모리 및 병렬성을 극대화하기 위해 사용자 지정 Spark 구성을 조정합니다. 다음과 같이 작업 규모를 적절하게 조정하면 상당한 개선을 이룰 수 있습니다. spark.sql.shuffle.partitions, spark.sql.files.maxPartitionBytes, spark.executor.coresspark.executor.memory. 그러나 이러한 사용자 지정 구성은 특정 Spark 버전과 호환되지 않으면 비생산적일 수 있습니다.
  • 리소스 프로비저닝 시간 - 임시 EMR 클러스터와 같은 리소스를 시작하는 데 걸리는 시간 아마존 엘라스틱 컴퓨트 클라우드 (아마존 EC2). 이 시간에 영향을 미치는 일부 요소는 엔지니어의 통제 범위를 벗어나지만 최적화할 수 있는 요소를 식별하고 해결하면 전체 프로비저닝 시간을 줄이는 데 도움이 될 수 있습니다.
  • 작업 수준에서 세분화된 확장 - 작업 내 각 단계의 요구 사항에 따라 CPU, 메모리, 디스크, 네트워크 대역폭과 같은 리소스를 동적으로 조정합니다. 여기서의 목표는 리소스 낭비를 초래할 수 있는 고정된 클러스터 크기를 방지하는 것입니다.
  • 워크플로의 여러 작업에 걸쳐 세분화된 크기 조정 - 각 작업마다 고유한 리소스 요구 사항이 있다는 점을 감안할 때 고정된 리소스 크기를 유지하면 동일한 워크플로 내의 특정 작업에 대해 과소 또는 과잉 프로비저닝이 발생할 수 있습니다. 전통적으로 가장 큰 작업의 크기에 따라 다중 작업 워크플로의 클러스터 크기가 결정됩니다. 그러나 워크플로 내의 여러 작업과 단계에 걸쳐 리소스를 동적으로 조정하면 보다 비용 효율적인 구현이 가능합니다.
  • 플랫폼 수준 향상 – 이전 레이어의 향상된 기능은 특정 작업이나 워크플로만 최적화할 수 있습니다. 플랫폼 개선은 전사 차원의 효율성 달성을 목표로 합니다. 핵심 인프라 업데이트 또는 업그레이드, 새로운 프레임워크 도입, 각 작업 프로필에 적절한 리소스 할당, 서비스 사용량 균형 조정, Savings Plans 및 Spot Instances 사용 최적화, 기타 포괄적인 변경 구현 등 다양한 수단을 통해 이를 달성할 수 있습니다. 모든 작업과 워크플로우 전반에 걸쳐 효율성을 높입니다.

레이어 1~3: 이전의 비용 절감

온프레미스에서 AWS 클라우드로 마이그레이션한 후 우리는 주로 다이어그램에 표시된 처음 3개 계층에 비용 최적화 노력을 집중했습니다. 가장 비용이 많이 드는 레거시 Pig 및 Hive 파이프라인을 Spark로 전환하고 Amazon EMR용 Spark 구성을 최적화함으로써 상당한 비용 절감을 달성했습니다.

예를 들어 기존 Pig 작업은 완료하는 데 10시간이 걸렸으며 가장 비용이 많이 드는 EMR 작업 상위 10개에 포함되었습니다. TEZ 로그 및 클러스터 지표를 검토한 결과, 처리 중인 데이터 볼륨에 대해 클러스터가 과도하게 프로비저닝되었으며 대부분의 런타임 동안 활용도가 낮은 상태로 유지되었음을 발견했습니다. Pig에서 Spark로 전환하는 것이 더 효율적이었습니다. 변환에 사용할 수 있는 자동화된 도구는 없었지만 다음을 포함하여 수동으로 최적화되었습니다.

  • 불필요한 디스크 쓰기 감소, 직렬화 및 역직렬화 시간 절약(계층 1)
  • Airflow 작업 병렬화를 Spark로 대체하여 Airflow DAG(레이어 1)를 단순화했습니다.
  • 중복된 Spark 변환 제거(계층 1)
  • 적응형 쿼리 실행(계층 2)을 사용하여 Spark 3에서 2으로 업그레이드됨
  • 편향된 조인 문제 해결 및 더 작은 차원 테이블 최적화(계층 3)

그 결과 작업 비용이 95% 감소했고, 작업 완료 시간도 1시간으로 단축됐다. 그러나 이 접근 방식은 노동 집약적이었고 수많은 작업에 확장할 수 없었습니다.

레이어 4~6: 적합한 컴퓨팅 솔루션 찾기 및 채택

2022년 말, 이전 수준의 최적화에서 중요한 성과를 거둔 후 우리의 관심은 나머지 레이어를 향상시키는 쪽으로 옮겨졌습니다.

일괄 처리 상태 이해

우리는 Amazon MWAA를 사용하여 클라우드에서 대규모로 데이터 워크플로를 조정합니다. 아파치 에어 플로우 프로세스 및 작업의 순서를 프로그래밍 방식으로 작성, 예약 및 모니터링하는 데 사용되는 오픈 소스 도구입니다. 워크 플로우. 이번 포스팅에서는 용어를 워크플로우 Amazon MWAA에서 조정하는 작업으로 구성된 DAG(방향성 비순환 그래프)를 참조하여 같은 의미로 사용됩니다. 각 워크플로에는 순차 또는 병렬 작업이 있으며, DAG에는 두 작업이 조합되어 있습니다. create_emrterminate_emr 워크플로 실행 전반에 걸쳐 고정된 컴퓨팅 용량을 사용하여 임시 EMR 클러스터에서 실행되는 작업입니다. 워크로드의 일부를 최적화한 후에도 다음 그림과 같이 워크플로에서 가장 리소스 집약적인 작업을 기반으로 하는 컴퓨팅 리소스의 과잉 프로비저닝으로 인해 활용도가 낮은 최적화되지 않은 워크플로가 여전히 많이 있었습니다.

이는 정적자원할당의 비실용성을 부각시켰고, 동적자원할당(DRA) 시스템의 필요성을 인식하게 만들었습니다. 솔루션을 제안하기 전에 우리는 일괄 처리를 철저히 이해하기 위해 광범위한 데이터를 수집했습니다. 프로비저닝 및 유휴 시간을 제외한 클러스터 단계 시간을 분석하면 워크플로의 절반 이상이 20분 이내에 완료되고 10%만이 60분 이상 걸리는 오른쪽으로 치우친 분포라는 중요한 통찰력이 드러났습니다. 이 배포를 통해 우리는 빠른 프로비저닝 컴퓨팅 솔루션을 선택하여 워크플로 런타임을 대폭 단축했습니다. 다음 다이어그램은 일괄 처리 계정 중 하나에 있는 EC2 임시 클러스터의 EMR 단계 시간(프로비저닝 및 유휴 시간 제외)을 보여줍니다.

또한 워크플로의 단계 시간(프로비저닝 및 유휴 시간 제외) 분포를 기준으로 워크플로를 세 그룹으로 분류했습니다.

  • 빠른 실행 – 지속 시간은 20분 이내
  • 중간 실행 – 20~60분 동안 지속됩니다.
  • 장기적으로 – 60분을 초과하며 종종 몇 시간 이상 소요됩니다.

우리가 고려해야 할 또 다른 요소는 보안, 작업 및 비용 격리, 특수 목적 클러스터와 같은 이유로 임시 클러스터를 광범위하게 사용하는 것이었습니다. 또한 피크 시간과 활용도가 낮은 기간 사이에 리소스 요구 사항에 상당한 차이가 있었습니다.

고정 크기 클러스터 대신 EC2의 EMR에 대한 관리형 확장을 잠재적으로 사용하여 몇 가지 비용 이점을 얻을 수 있습니다. 그러나 EMR 서버리스로 마이그레이션하는 것이 우리 데이터 플랫폼에 있어 보다 전략적인 방향인 것으로 보입니다. 잠재적인 비용 이점 외에도 EMR 서버리스는 최신 Amazon EMR 버전으로의 원클릭 업그레이드, 단순화된 운영 및 디버깅 환경, 출시 시 최신 세대로의 자동 업그레이드와 같은 추가 이점을 제공합니다. 이러한 기능은 대규모 플랫폼 운영 프로세스를 종합적으로 단순화합니다.

EMR 서버리스 평가: GoDaddy의 사례 연구

EMR 서버리스는 Apache Spark 및 Apache Hive와 같은 빅 데이터 프레임워크를 실행할 때 클러스터를 구성, 관리 및 확장하는 복잡성을 제거하는 Amazon EMR의 서버리스 옵션입니다. EMR 서버리스를 통해 기업은 비용 효율성, 더 빠른 프로비저닝, 단순화된 개발자 경험, 가용 영역 장애에 대한 향상된 복원력 등 다양한 이점을 누릴 수 있습니다.

EMR Serverless의 잠재력을 인식하고 실제 생산 워크플로를 사용하여 심층적인 벤치마크 연구를 수행했습니다. 이 연구의 목적은 EMR 서버리스 성능과 효율성을 평가하는 동시에 대규모 구현을 위한 채택 계획을 수립하는 것이었습니다. EMR Serverless가 워크로드를 효과적으로 처리할 수 있음을 보여주는 결과는 매우 고무적이었습니다.

벤치마킹 방법론

우리는 데이터 워크플로우를 총 단계 시간(프로비저닝 및 유휴 시간 제외)을 기준으로 빠른 실행(0~20분), 중간 실행(20~60분), 장기 실행(60분 이상)의 세 가지 범주로 나눴습니다. 우리는 EMR 배포 유형(Amazon EC2와 EMR 서버리스)이 두 가지 주요 지표인 비용 효율성과 전체 런타임 속도 향상에 미치는 영향을 분석했으며, 이는 전반적인 평가 기준으로 사용되었습니다. 사용 편의성과 탄력성을 공식적으로 측정하지는 않았지만 평가 프로세스 전반에 걸쳐 이러한 요소가 고려되었습니다.

환경을 평가하는 개략적인 단계는 다음과 같습니다.

  1. 데이터 및 환경을 준비합니다.
    1. 각 직업 카테고리에서 3~5개의 무작위 생산 직업을 선택하세요.
    2. 생산에 방해가 되지 않도록 필요한 조정을 수행합니다.
  2. 테스트 실행:
    1. 며칠에 걸쳐 또는 여러 번의 반복을 통해 스크립트를 실행하여 정확하고 일관된 데이터 포인트를 수집합니다.
    2. EC2 및 EMR Serverless에서 EMR을 사용하여 테스트를 수행합니다.
  3. 데이터 및 테스트 실행 검증:
    1. 동일한 데이터 처리를 보장하기 위해 입력 및 출력 데이터세트, 파티션, 행 수를 검증합니다.
  4. 측정항목 수집 및 결과 분석:
    1. 테스트에서 관련 측정항목을 수집하세요.
    2. 결과를 분석하여 통찰력과 결론을 도출합니다.

벤치 마크 결과

우리의 벤치마크 결과는 런타임 속도 향상과 비용 효율성 측면에서 세 가지 작업 범주 모두에서 상당한 개선을 보여주었습니다. 이러한 개선은 빠른 작업에서 가장 두드러졌으며, 이는 더 빠른 시작 시간으로 인해 직접적으로 발생했습니다. 예를 들어 고정 컴퓨팅 용량의 EC20 임시 클러스터의 EMR에서 실행되는 2분(클러스터 프로비저닝 및 종료 포함) 데이터 워크플로우는 EMR 서버리스에서 10분 만에 완료되어 더 짧은 런타임과 비용 이점을 제공합니다. 전반적으로 EMR 서버리스로의 전환은 다음 그림에서 볼 수 있듯이 작업 범위 전반에 걸쳐 상당한 성능 향상과 대규모 비용 절감을 제공했습니다.

역사적으로 우리는 장기 워크플로를 조정하는 데 더 많은 시간을 투자했습니다. 흥미롭게도 이러한 작업에 대한 기존 사용자 지정 Spark 구성이 EMR Serverless로 항상 잘 변환되지는 않는다는 사실을 발견했습니다. 결과가 중요하지 않은 경우 일반적인 접근 방식은 실행기 코어와 관련된 이전 Spark 구성을 삭제하는 것이었습니다. EMR 서버리스가 이러한 Spark 구성을 자율적으로 관리하도록 허용함으로써 우리는 종종 향상된 결과를 확인했습니다. 다음 그래프는 EMR 서버리스와 EC2의 EMR을 비교할 때 작업당 평균 런타임 및 비용 개선을 보여줍니다.

직업별 개선

다음 표는 Amazon EMR(EC2의 EMR 및 EMR 서버리스)의 다양한 배포 옵션에서 실행되는 동일한 워크플로에 대한 결과의 샘플 비교를 보여줍니다.

메트릭 EC2의 EMR
(평균)
EMR 서버리스
(평균)
EC2의 EMR과 비교
EMR 서버리스
총 실행 비용($) 5.82 달러 2.60 달러 55%
총 실행 시간(분) 53.40 39.40 26%
프로비저닝 시간(분) 10.20 0.05 .
프로비저닝 비용($) $ 1.19 . .
단계 시간(분) 38.20 39.16 -3 %
단계 비용($) $ 4.30 . .
유휴 시간(분) 4.80 . .
EMR 릴리스 라벨 emr-6.9.0 .
하둡 배포 아마존 3.3.3 .
스파크 버전 스파크 3.3.0 .
Hive/HCatalog 버전 하이브 3.1.3, HCatalog 3.1.3 .
작업수행 유형 불꽃 .

EMR 서버리스 성능 평가에 대한 AWS Graviton2

워크로드에 대해 EMR Serverless를 통해 뛰어난 결과를 확인한 후 우리는 AWS 그래비톤2 EMR 서버리스 내의 (arm64) 아키텍처. AWS는 벤치마킹 TPC-DS 2TB 규모를 사용하는 Graviton3 EMR 서버리스의 Spark 워크로드는 전반적인 가격 대비 성능이 27% 향상되었습니다.

통합 이점을 더 잘 이해하기 위해 우리는 매일 GoDaddy의 프로덕션 워크로드를 사용하여 자체 연구를 실시한 결과 Graviton23.8를 사용할 때 다양한 작업에서 가격 대비 성능이 2%라는 놀라운 향상을 보였습니다. 이 연구에 대한 자세한 내용은 다음을 참조하세요. GoDaddy 벤치마킹 결과 Amazon EMR 서버리스에서 AWS Graviton24를 사용하여 Spark 워크로드의 가격 대비 성능이 최대 2% 향상되었습니다..

EMR 서버리스 채택 전략

우리는 배포 링을 통해 EMR 서버리스의 단계적 출시를 전략적으로 구현하여 체계적인 통합을 가능하게 했습니다. 이러한 점진적 접근 방식을 통해 개선 사항을 검증하고 필요한 경우 EMR 서버리스의 추가 채택을 중단할 수 있습니다. 이는 문제를 조기에 발견할 수 있는 안전망이자 인프라를 개선하는 수단의 역할을 했습니다. 이 프로세스는 데이터 엔지니어링 및 DevOps 팀의 팀 전문 지식을 구축하는 동시에 원활한 운영을 통해 변경 영향을 완화했습니다. 또한 긴밀한 피드백 루프를 조성하여 즉각적인 조정이 가능하고 효율적인 EMR 서버리스 통합을 보장했습니다.

다음 이미지에 표시된 것처럼 워크플로를 세 가지 주요 채택 그룹으로 나누었습니다.

  • 카나리아 - 이 그룹은 배포 단계 초기에 잠재적인 문제를 감지하고 해결하는 데 도움을 줍니다.
  • 얼리 어답터 - 이는 카나리아 그룹에서 초기 문제를 식별하고 수정한 후 새로운 컴퓨팅 솔루션을 채택하는 두 번째 워크플로 배치입니다.
  • 광범위한 배포 링 - 가장 큰 링 그룹인 이 그룹은 솔루션의 광범위한 배포를 나타냅니다. 이는 이전 두 그룹에서 성공적인 테스트 및 구현 후에 배포됩니다.

반지

우리는 다음 표에 표시된 것처럼 EMR 서버리스를 채택하기 위해 이러한 워크플로를 세분화된 배포 링으로 세분화했습니다.

반지 # 성함 세부 정보
0 반지 카나리아 비용 절감 혜택을 얻을 것으로 예상되는 채택 위험이 낮은 작업입니다.
1 반지 얼리 어답터 높은 이익을 얻을 것으로 예상되는 낮은 위험의 Quick-run Spark 작업입니다.
2 반지 빠른 실행 나머지 빠른 실행(step_time <= 20분) Spark 작업
3 반지 대규모 작업_EZ 높은 잠재력 이득, 쉬운 이동, 중장기 스파크 작업
4 반지 대규모 작업 잠재적인 이익을 얻을 수 있는 나머지 중장기 Spark 작업
5 반지 하이브 잠재적으로 비용 절감 효과가 더 높은 Hive 작업
6 반지 Redshift_EZ EMR Serverless에 적합한 간편한 마이그레이션 Redshift 작업
7 반지 Glue_EZ EMR 서버리스에 적합한 간편한 마이그레이션 Glue 작업

생산 채택 결과 요약

고무적인 벤치마킹 및 카나리아 채택 결과는 GoDaddy의 EMR 서버리스 채택 확대에 상당한 관심을 불러일으켰습니다. 현재까지 EMR 서버리스 출시가 진행 중입니다. 지금까지 비용을 62.5% 절감하고 전체 배치 워크플로 완료를 50.4% 가속화했습니다.

예비 벤치마크를 기반으로 우리 팀은 빠른 작업으로 인해 상당한 이익을 얻을 것으로 예상했습니다. 놀랍게도 실제 프로덕션 배포는 예상보다 평균 64.4% 더 빠르고 예상 42% 대비 71.8% 저렴했으며 예상 40%보다 저렴했습니다.

놀랍게도 EMR 서버리스의 신속한 프로비저닝과 동적 리소스 할당을 통한 공격적인 확장 덕분에 장기 실행 작업에서도 성능이 크게 향상되었습니다. 리소스가 많은 세그먼트에서 상당한 병렬화가 관찰되었으며, 그 결과 기존 접근 방식에 비해 총 런타임이 40.5% 더 빨라졌습니다. 다음 차트는 직업 범주별 평균 향상을 보여줍니다.

프로덕션 작업 절감

또한 다음 상자수염 도표에서 볼 수 있듯이 장기 작업 범주 내에서 속도 개선에 대한 분산이 가장 높은 것으로 관찰되었습니다.

수염 플롯

EMR 서버리스를 채택한 샘플 워크플로

EMR 서버리스로 마이그레이션된 대규모 워크플로의 경우 마이그레이션 전후의 3주 평균을 비교한 결과 소매 가격 기준으로 75.30% 감소하고 총 런타임이 10% 개선되어 운영 효율성이 향상되는 놀라운 비용 절감 효과가 나타났습니다. 다음 그래프는 비용 추세를 보여줍니다.

빠른 실행 작업은 최소한의 달러당 비용 절감을 실현했지만 가장 큰 비율의 비용 절감 효과를 제공했습니다. 매일 수천 개의 워크플로가 실행되므로 누적된 절감액은 상당합니다. 다음 그래프는 EC2의 EMR에서 EMR Serverless로 마이그레이션된 소규모 워크로드의 비용 추세를 보여줍니다. 3주간의 마이그레이션 전후 평균을 비교해 보면 소매 주문형 가격에서 92.43%의 놀라운 비용 절감과 함께 총 런타임이 80.6% 가속화된 것으로 나타났습니다.

EMR Serverless 2를 채택한 샘플 워크플로

레이어 7: 플랫폼 전반의 개선

우리는 지능형 컴퓨팅 플랫폼을 통해 모든 사용자에게 간단하면서도 강력한 솔루션을 제공하여 GoDaddy의 컴퓨팅 운영을 혁신하는 것을 목표로 합니다. EMR Serverless 및 EMR on EC2와 같은 AWS 컴퓨팅 솔루션을 통해 최적화된 데이터 처리 및 기계 학습(ML) 워크로드 실행을 제공했습니다. ML 기반 작업 브로커는 다양한 매개변수를 기반으로 작업 실행 시기와 방법을 지능적으로 결정하는 동시에 고급 사용자가 사용자 정의할 수 있도록 허용합니다. 또한 ML 기반 컴퓨팅 리소스 관리자는 로드 및 기록 데이터를 기반으로 리소스를 사전 프로비저닝하여 최적의 비용으로 효율적이고 빠른 프로비저닝을 제공합니다. 지능형 컴퓨팅은 고급 사용자를 손상시키지 않으면서 다양한 페르소나에 맞춰 즉시 사용 가능한 최적화 기능을 사용자에게 제공합니다.

다음 다이어그램은 지능형 컴퓨팅 아키텍처를 개략적으로 보여줍니다.

통찰력 및 권장 모범 사례

다음 섹션에서는 우리가 수집한 통찰력과 예비 및 광범위한 채택 단계에서 개발한 권장 모범 사례에 대해 설명합니다.

인프라 준비

EMR 서버리스는 EMR 내의 배포 방법이지만 잠재력을 최적화하려면 일부 인프라 준비가 필요합니다. 구현에 대한 다음 요구 사항과 실제 지침을 고려하세요.

  • 여러 가용 영역에 걸쳐 대규모 서브넷 사용 – VPC 내에서 EMR 서버리스 워크로드를 실행할 때 서브넷이 여러 가용 영역에 걸쳐 있고 IP 주소로 제한되지 않는지 확인하십시오. 인용하다 VPC 액세스 구성서브넷 계획 모범 사례 자세한 내용은.
  • 최대 동시 vCPU 할당량 수정 - 광범위한 컴퓨팅 요구 사항의 경우 계정당 최대 동시 vCPU 서비스 할당량.
  • Amazon MWAA 버전 호환성 - EMR 서버리스를 채택할 때 GoDaddy의 데이터 파이프라인 조정을 위한 분산형 Amazon MWAA 에코시스템은 서로 다른 AWS 공급자 버전에서 호환성 문제를 일으켰습니다. Amazon MWAA를 직접 업그레이드하는 것이 수많은 DAG를 업데이트하는 것보다 더 효율적이었습니다. 우리는 Amazon MWAA 인스턴스를 직접 업그레이드하고, 문제를 문서화하고, 정확한 업그레이드 계획을 위해 조사 결과와 예상 노력을 공유함으로써 채택을 촉진했습니다.
  • GoDaddy EMR 운영자 - EC2의 EMR에서 EMR Serverless로 수많은 Airflow DAG 마이그레이션을 간소화하기 위해 우리는 기존 인터페이스를 조정하는 맞춤형 연산자를 개발했습니다. 이를 통해 익숙한 튜닝 옵션을 유지하면서 원활한 전환이 가능해졌습니다. 데이터 엔지니어는 간단한 찾기-바꾸기 가져오기를 통해 파이프라인을 쉽게 마이그레이션하고 즉시 EMR Serverless를 사용할 수 있습니다.

예상치 못한 행동 완화

다음은 우리가 겪은 예상치 못한 행동과 이를 완화하기 위해 수행한 조치입니다.

  • Spark DRA 공격적인 확장 - 일부 작업(초기 벤치마크의 8.33%, 생산의 13.6%)의 경우 EMR 서버리스로 마이그레이션한 후 비용이 증가했습니다. 이는 스파크 DRA가 비용보다 성과를 우선시해 과도하게 신입사원을 단기 배정했기 때문이다. 이에 대응하기 위해 다음을 조정하여 최대 실행기 임계값을 설정합니다. spark.dynamicAllocation.maxExecutor, EMR 서버리스 확장 공격을 효과적으로 제한합니다. EC2의 EMR에서 마이그레이션할 때 Spark 기록 UI에서 최대 코어 수를 관찰하여 EMR 서버리스에서 유사한 컴퓨팅 제한을 복제하는 것이 좋습니다. --conf spark.executor.cores--conf spark.dynamicAllocation.maxExecutors.
  • 대규모 작업을 위한 디스크 공간 관리 - 상당한 셔플과 상당한 디스크 요구 사항이 있는 대용량 데이터 볼륨을 처리하는 작업을 EMR 서버리스로 전환하는 경우 다음을 구성하는 것이 좋습니다. spark.emr-serverless.executor.disk 기존 Spark 작업 측정항목을 참조하여 게다가 다음과 같은 구성은 spark.executor.cores 과 결합 spark.emr-serverless.executor.diskspark.dynamicAllocation.maxExecutors 유리한 경우 기본 작업자 크기와 총 연결 스토리지를 제어할 수 있습니다. 예를 들어 상대적으로 디스크 사용량이 적고 셔플이 많은 작업에서는 더 큰 작업자를 사용하여 로컬 셔플 가져오기 가능성을 높이는 것이 도움이 될 수 있습니다.

결론

이 게시물에서 논의한 것처럼 arm64에 EMR Serverless를 채택한 경험은 압도적으로 긍정적이었습니다. 비용 절감 60%, 배치 Spark 워크로드 실행 속도 50% 향상, 개발 및 테스트 속도의 놀라운 2배 향상 등 우리가 달성한 인상적인 결과는 이 기술의 잠재력에 대해 많은 것을 말해줍니다. 또한, 현재 결과에 따르면 EMR 서버리스에 Graviton60를 널리 채택하면 배치 처리 시 탄소 배출량을 최대 XNUMX%까지 줄일 수 있는 것으로 나타났습니다.

그러나 이러한 결과가 모든 경우에 적용되는 시나리오가 아니라는 점을 이해하는 것이 중요합니다. 귀하가 기대할 수 있는 개선 사항은 워크플로의 특정 특성, 클러스터 구성, 리소스 활용률 수준, 계산 용량의 변동을 포함하되 이에 국한되지 않는 요인에 따라 달라질 수 있습니다. 따라서 우리는 EMR 서버리스 통합을 고려할 때 데이터 중심, 링 기반 배포 전략을 강력히 옹호하며, 이는 이점을 최대한 최적화하는 데 도움이 될 수 있습니다.

특별 감사를 무쿨 샤르마보리스 베를린 벤치마킹에 기여한 공로를 인정합니다. 많은 감사 트래비스 멀스타인 (CDO), 아비짓 쿤두 (엔지니어링 부사장), 빈센트 영 (Eng. 수석 이사) 및 와이 킨 라우 (Sr. Director Data Eng.)의 지속적인 지원에 감사드립니다.


저자에 관하여

브랜든 아베어 GoDaddy 데이터 및 분석(DnA) 조직의 수석 데이터 엔지니어입니다. 그는 빅데이터에 관한 모든 것을 즐깁니다. 여가 시간에는 여행, 영화 감상, 리듬 게임을 즐깁니다.

Dinesh Sharma GoDaddy 데이터 및 분석(DnA) 조직의 수석 데이터 엔지니어입니다. 그는 사용자 경험과 개발자 생산성에 열정을 갖고 있으며 항상 엔지니어링 프로세스를 최적화하고 비용을 절감할 수 있는 방법을 찾고 있습니다. 여가 시간에는 독서를 좋아하고 열렬한 만화 팬입니다.

존 부시 GoDaddy 데이터 및 분석(DnA) 조직의 수석 소프트웨어 엔지니어입니다. 그는 조직이 데이터를 보다 쉽게 ​​관리하고 이를 사용하여 비즈니스를 발전시킬 수 있도록 하는 데 열정을 쏟고 있습니다. 여가 시간에는 하이킹, 캠핑, e바이크 타기를 좋아합니다.

오즈칸 일리칸 GoDaddy의 데이터 및 ML 플랫폼 엔지니어링 이사입니다. 그는 20년 넘게 스타트업부터 글로벌 기업까지 다양한 분야에서 리더십을 발휘해 왔습니다. 그는 고객을 기쁘게 하고 고객이 더 많은 것을 성취할 수 있도록 지원하며 운영 효율성을 높이는 솔루션을 만드는 데 데이터와 AI를 활용하는 데 열정을 갖고 있습니다. 직업 생활 외에 그는 독서, 하이킹, 정원 가꾸기, 자원 봉사, DIY 프로젝트 시작을 즐깁니다.

거친 바르 단 빅 데이터 및 분석을 전문으로 하는 AWS 솔루션스 아키텍트입니다. 그는 빅데이터 및 데이터 과학 분야에서 8년 이상의 경력을 갖고 있습니다. 그는 고객이 모범 사례를 채택하고 데이터에서 통찰력을 발견하도록 돕는 데 열정을 쏟고 있습니다.

spot_img

최신 인텔리전스

spot_img