SafeGraph가 Amazon EKS에서 Amazon EMR을 사용하여 안정적이고 효율적이며 사용자 친화적인 Apache Spark 플랫폼을 구축한 방법

이것은 SafeGraph의 기술 책임자인 Nan Zhu의 게스트 게시물입니다. 및 Dave Thibault, 수석 솔루션스 아키텍트 – AWS

SafeGraph 는 브랜드 제휴, 고급 카테고리 태깅, 영업 시간, 사람들이 해당 장소와 상호 작용하는 방식과 같은 세부 속성을 사용하여 41만 개 이상의 글로벌 관심 지점(POI)을 큐레이팅하는 지리 공간 데이터 회사입니다. 우리는 Apache Spark를 기본 데이터 처리 엔진으로 사용하며 매일 방대한 양의 데이터에서 실행되는 1,000개 이상의 Spark 애플리케이션을 보유하고 있습니다. 이러한 Spark 애플리케이션은 데이터 변환, 기계 학습(ML) 모델 추론에서 운영 작업에 이르는 비즈니스 로직을 구현합니다.

SafeGraph는 기존 Spark 공급업체에서 최적이 아닌 Spark 환경을 발견했습니다. 그들의 비용은 오르고 있었다. 그들의 작업은 스팟 인스턴스 종료로 인해 빈번한 재시도를 겪게 됩니다. 개발자는 문제 해결 및 작업 구성 변경에 너무 많은 시간을 할애했지만 비즈니스 가치 코드를 전달하는 데는 시간이 부족했습니다. SafeGraph는 비용을 제어하고 개발자 반복 속도를 개선하며 작업 안정성을 개선해야 했습니다. 결국 SafeGraph는 Amazon EKS의 Amazon EMR 요구 사항을 충족하고 이전 Spark 관리 서비스 공급업체에 비해 50% 절감을 실현했습니다.

우리 제품에 대한 Spark 애플리케이션을 구축하는 것이 나무를 자르는 것과 같다면 날카로운 톱이 중요합니다. Spark 플랫폼은 톱입니다. 다음 그림은 Spark로 작업할 때 엔지니어링 워크플로를 강조 표시하며 Spark 플랫폼은 워크플로의 각 작업을 지원하고 최적화해야 합니다. 엔지니어는 일반적으로 Spark 애플리케이션 코드를 작성하고 빌드하는 것으로 시작한 다음 컴퓨팅 인프라에 애플리케이션을 제출하고 마지막으로 Spark 애플리케이션을 디버깅하여 루프를 닫습니다. 또한 플랫폼 및 인프라 팀은 엔지니어링 워크플로우의 세 단계를 지속적으로 운영하고 최적화해야 합니다.

Spark 플랫폼을 구축할 때 각 작업에는 다양한 과제가 있습니다.

• 안정적인 종속성 관리 – 복잡한 Spark 애플리케이션은 일반적으로 많은 종속성을 가져옵니다. Spark 애플리케이션을 실행하려면 모든 종속성을 식별하고, 충돌을 해결하고, 종속 라이브러리를 안정적으로 패킹하고, Spark 클러스터로 배송해야 합니다. 종속성 관리는 특히 PySpark 애플리케이션으로 작업할 때 엔지니어에게 가장 큰 과제 중 하나입니다.
• 신뢰할 수 있는 컴퓨팅 인프라 – Spark 애플리케이션을 호스팅하는 컴퓨팅 인프라의 안정성은 전체 Spark 플랫폼의 기반입니다. 불안정한 리소스 프로비저닝은 엔지니어링 효율성에 부정적인 영향을 미칠 뿐만 아니라 Spark 애플리케이션의 재실행으로 인해 인프라 비용도 증가합니다.
• Spark 애플리케이션을 위한 편리한 디버깅 도구 – 디버깅 도구는 엔지니어가 Spark 애플리케이션을 빠르게 반복하는 데 핵심적인 역할을 합니다. Spark 기록 서버(SHS)에 대한 고성능 액세스는 개발자 반복 속도를 위한 필수 요소입니다. 반대로 SHS 성능이 좋지 않으면 개발자 속도가 느려지고 소프트웨어 회사에 판매되는 제품 비용이 증가합니다.
• 관리 가능한 Spark 인프라 – 성공적인 Spark 플랫폼 엔지니어링에는 Spark 배포 버전 관리, 컴퓨팅 리소스 SKU 관리 및 최적화 등과 같은 여러 측면이 포함됩니다. Spark 서비스 공급업체가 플랫폼 팀이 사용할 올바른 기반을 제공하는지 여부에 따라 크게 달라집니다. 예를 들어 배포 버전 및 컴퓨팅 리소스에 대한 잘못된 추상화는 플랫폼 엔지니어링의 ROI를 크게 줄일 수 있습니다.

SafeGraph에서 우리는 앞서 언급한 모든 문제를 경험했습니다. 이를 해결하기 위해 우리는 시장을 조사했고 EKS의 EMR 위에 새로운 Spark 플랫폼을 구축하는 것이 우리의 장애물에 대한 해결책이라는 것을 알았습니다. 이 게시물에서는 최신 Spark 플랫폼을 구축하는 여정과 EKS의 EMR이 이를 위한 강력하고 효율적인 기반 역할을 하는 방법을 공유합니다.

신뢰할 수 있는 Python 종속성 관리

사용자가 Spark 애플리케이션 코드를 작성하고 빌드하는 데 있어 가장 큰 문제 중 하나는 특히 PySpark 애플리케이션의 경우 종속성을 안정적으로 관리하는 데 어려움을 겪는 것입니다. 대부분의 ML 관련 Spark 애플리케이션은 PySpark로 구축되었습니다. 이전 Spark 서비스 공급업체에서 Python 종속성을 관리하기 위해 지원되는 유일한 방법은 휠 파일을 이용하는 것이었습니다. 인기에도 불구하고 휠 기반 종속성 관리는 취약합니다. 다음 그림은 휠 기반 종속성 관리에서 직면하는 두 가지 유형의 안정성 문제를 보여줍니다.

• 고정 해제된 직접 종속성 – .whl 파일이 특정 직접 종속성(이 예에서는 Pandas)의 버전을 정확히 지정하지 않으면 항상 최신 버전을 업스트림에서 가져옵니다. 여기에는 잠재적으로 주요 변경 사항이 포함될 수 있으며 Spark 애플리케이션이 중단될 수 있습니다.
• 고정되지 않은 전이 종속성 – 두 번째 유형의 안정성 문제는 우리가 통제할 수 없는 것입니다. .whl 파일을 빌드할 때 직접 종속성 버전을 고정했지만 직접 종속성 자체가 전이적 종속성 버전(이 예에서는 MLFlow)을 정확히 지정하지 못할 수 있습니다. 이 경우 직접 종속성은 잠재적으로 주요 변경 사항을 포함하고 파이프라인을 중단시킬 수 있는 이러한 전이적 종속성의 최신 버전을 항상 가져옵니다.

우리가 만난 또 다른 문제는 모든 Spark 응용 프로그램 초기화에 대해 휠 파일이 참조하는 모든 Python 패키지를 불필요하게 설치하는 것이었습니다. 이전 설정에서는 종속성 변경이 없더라도 시작 시 모든 Spark 애플리케이션에 대한 휠 파일을 설치하기 위해 설치 스크립트를 실행해야 했습니다. 이 설치는 Spark 애플리케이션 시작 시간을 3-4분에서 최소 7-8분으로 연장합니다. 특히 엔지니어가 변경 사항을 적극적으로 반복할 때 속도 저하가 실망스럽습니다.

EKS에서 EMR로 이동하면 다음을 사용할 수 있습니다. pex (Python EXecutable) Python 종속성을 관리합니다. .pex 파일은 다음과 같은 정신으로 실행 가능한 Python 환경에서 PySpark 애플리케이션의 모든 종속성(직접 및 전이 포함)을 압축합니다. 가상 환경.

다음 그림은 앞에서 설명한 휠 파일을 .pex 파일로 변환한 후의 파일 구조를 보여줍니다. 휠 기반 워크플로와 비교할 때 더 이상 전이적 종속성 풀링 또는 자동 최신 버전 가져오기가 없습니다. 모든 버전의 종속성은 .pex 파일을 빌드할 때 xyz, abc 등으로 고정됩니다. .pex 파일이 주어지면 휠 기반 종속성 관리에서 더 이상 속도 저하 또는 취약성 문제로 고통받지 않도록 모든 종속성이 수정됩니다. .pex 파일을 구축하는 비용도 일회성 비용입니다.

안정적이고 효율적인 리소스 프로비저닝

리소스 프로비저닝은 Spark 플랫폼이 Spark 애플리케이션에 대한 컴퓨팅 리소스를 가져오는 프로세스이며 전체 Spark 플랫폼의 기반입니다. 클라우드에서 Spark 플랫폼을 구축할 때 비용 최적화를 위해 스팟 인스턴스를 사용하면 리소스 프로비저닝이 훨씬 더 어려워집니다. 스팟 인스턴스는 온디맨드 가격에 비해 최대 90% 할인된 가격으로 사용할 수 있는 예비 컴퓨팅 용량입니다. 그러나 특정 인스턴스 유형에 대한 수요가 갑자기 증가하면 이러한 수요 충족을 우선적으로 처리하기 위해 스팟 인스턴스 종료가 발생할 수 있습니다. 이러한 종료로 인해 이전 버전의 Spark 플랫폼에서 다음과 같은 몇 가지 문제가 발생했습니다.

• 신뢰할 수 없는 Spark 애플리케이션 – 스팟 인스턴스 종료가 발생하면 재시도된 컴퓨팅 단계로 인해 Spark 애플리케이션의 런타임이 크게 연장되었습니다.
• 손상된 개발자 경험 – Spot 인스턴스의 불안정한 공급은 Spark 애플리케이션의 예측할 수 없는 성능과 낮은 성공률로 인해 엔지니어들 사이에 불만을 야기하고 개발 반복을 지연시켰습니다.
• 비싼 인프라 청구서 – 작업 재시도로 인해 클라우드 인프라 비용이 크게 증가했습니다. 우리는 더 비싸게 사야 했다 아마존 엘라스틱 컴퓨트 클라우드 (Amazon EC2) 인스턴스는 용량이 더 크고 여러 가용 영역에서 실행되어 문제를 완화하지만 교차 가용 영역 트래픽의 높은 비용을 지불했습니다.

EKS 또는 기타 타사 소프트웨어 제품의 EMR과 같은 Spark 서비스 공급자(SSP)는 사용자와 스팟 인스턴스 풀 사이의 중간 역할을 하며 스팟 인스턴스의 충분한 공급을 보장하는 핵심 역할을 합니다. 다음 그림에 표시된 것처럼 사용자는 SSP를 통해 작업 오케스트레이터, 노트북 또는 서비스로 Spark 작업을 시작합니다. SSP는 AWS와 같은 클라우드 서비스의 스팟 인스턴스 풀에서 미사용 인스턴스에 액세스하는 내부 기능을 구현합니다. 스팟 인스턴스를 사용하는 모범 사례 중 하나는 인스턴스 유형을 다양화하는 것입니다(자세한 내용은 다음을 참조하십시오. EC2 스팟 인스턴스를 사용한 비용 최적화). 특히 SSP가 인스턴스 다양화를 달성하기 위한 두 가지 주요 기능이 있습니다.

• SSP는 AWS의 스팟 인스턴스 풀에 있는 모든 유형의 인스턴스에 액세스할 수 있어야 합니다.
• SSP는 사용자가 Spark 애플리케이션을 시작할 때 가능한 한 많은 인스턴스 유형을 사용할 수 있는 기능을 제공해야 합니다.

우리의 마지막 SSP는 이 두 가지 점에 대한 예상 솔루션을 제공하지 않습니다. 제한된 스팟 인스턴스 유형 세트만 지원하며 기본적으로 Spark 작업을 시작할 때 단일 스팟 인스턴스 유형만 선택할 수 있습니다. 결과적으로 각 Spark 애플리케이션은 작은 용량의 스팟 인스턴스로만 실행되며 스팟 인스턴스 종료에 취약합니다.

EKS의 EMR 사용 Amazon Elastic Kubernetes 서비스 (Amazon EKS) AWS에서 스팟 인스턴스에 액세스하기 위한 것입니다. Amazon EKS는 사용 가능한 모든 EC2 인스턴스 유형을 지원하여 훨씬 더 큰 용량 풀을 제공합니다. 우리는 Amazon EKS 관리형 노드 그룹 및 노드 선택기 및 오염 여러 인스턴스 유형으로 구성된 노드 그룹에 각 Spark 애플리케이션을 할당합니다. EKS에서 EMR로 전환한 후 다음과 같은 이점을 관찰했습니다.

• 스팟 인스턴스 종료 빈도가 줄어들었고 Spark 애플리케이션의 런타임이 짧아지고 안정적으로 유지되었습니다.
• 엔지니어는 애플리케이션 동작의 예측 가능성이 향상됨에 따라 더 빠르게 반복할 수 있었습니다.
• 더 이상 비용이 많이 드는 해결 방법이 필요하지 않고 동시에 Amazon EKS의 각 노드 그룹에서 정교한 인스턴스를 선택할 수 있었기 때문에 인프라 비용이 크게 감소했습니다. 여러 가용 영역에서 실행하는 것과 같은 해결 방법 없이 컴퓨팅 비용의 약 50%를 절약하고 동시에 예상 수준의 안정성을 제공할 수 있었습니다.

원활한 디버깅 경험

엔지니어가 Spark 애플리케이션을 편리하게 디버깅할 수 있도록 지원하는 인프라는 엔지니어링 워크플로의 루프를 닫는 데 중요합니다. 아파치 스파크 사용 이벤트 로그 작업 시작 및 완료와 같은 Spark 애플리케이션의 활동을 기록합니다. 이러한 이벤트는 JSON 형식이며 SHS에서 Spark 애플리케이션의 UI를 다시 렌더링하는 데 사용됩니다. 엔지니어는 SHS에 액세스하여 작업 실패 이유 또는 성능 문제를 디버그할 수 있습니다.

SafeGraph 엔지니어의 주요 과제는 SHS의 확장성 문제였습니다. 다음 그림의 왼쪽 부분에 표시된 것처럼 이전 SSP는 모든 엔지니어가 동일한 SHS 인스턴스를 공유하도록 했습니다. 결과적으로 SHS는 많은 엔지니어가 애플리케이션 디버깅을 위해 동시에 액세스하거나 Spark 애플리케이션에 렌더링할 대규모 이벤트 로그가 있는 경우 리소스 압박이 심했습니다. EKS에서 EMR로 이동하기 전에는 SHS가 느려지거나 SHS가 완전히 충돌하는 경우가 자주 발생했습니다.

다음 그림에 표시된 것처럼 Spark 기록 UI를 보기 위한 모든 요청에 ​​대해 EKS의 EMR은 AWS 관리 환경에서 독립적인 SHS 인스턴스 컨테이너를 시작합니다. 이 아키텍처의 이점은 두 가지입니다.

• 다른 사용자와 Spark 애플리케이션은 더 이상 SHS 리소스를 놓고 경쟁하지 않습니다. 따라서 SHS의 속도 저하나 충돌이 발생하지 않습니다.
• 모든 SHS 컨테이너는 AWS에서 관리합니다. 사용자는 확장 가능한 아키텍처를 즐기기 위해 추가 재정 또는 운영 비용을 지불할 필요가 없습니다.

관리 가능한 Spark 플랫폼

엔지니어링 워크플로에서 볼 수 있듯이 Spark 플랫폼 구축은 일회성 노력이 아니며 플랫폼 팀은 Spark 플랫폼을 관리하고 엔지니어 개발 워크플로의 각 단계를 계속 최적화해야 합니다. SSP의 역할은 운영 부담을 최대한 완화할 수 있는 적절한 시설을 제공해야 합니다. 많은 유형의 운영 작업이 있지만 이 게시물에서는 컴퓨팅 리소스 SKU 관리 및 Spark distro 버전 관리라는 두 가지 작업에 중점을 둡니다.

컴퓨팅 리소스 SKU 관리는 사용자가 다양한 크기의 컴퓨팅 인스턴스를 선택할 수 있도록 하는 Spark 플랫폼의 설계 및 프로세스를 나타냅니다. 이러한 설계 및 프로세스는 주로 SSP에서 구현되는 관련 기능에 의존합니다.

다음 그림은 이전 SSP를 사용한 SKU 관리를 보여줍니다.

다음 그림은 EKS에서 EMR을 사용한 SKU 관리를 보여줍니다.

이전 SSP를 사용하면 작업 구성에서 단일 스팟 인스턴스 유형만 명시적으로 지정할 수 있었고 해당 유형이 스팟 용량이 부족하면 작업이 온디맨드로 전환되거나 안정성 문제가 발생했습니다. 이로 인해 플랫폼 엔지니어는 Spark 작업 전체에서 설정을 변경하거나 예산 및 판매 상품 비용에 대해 원치 않는 놀라움을 감수할 수 있는 선택권을 갖게 되었습니다.

EKS의 EMR을 사용하면 플랫폼 팀이 컴퓨팅 SKU를 훨씬 쉽게 관리할 수 있습니다. SafeGraph에서는 사용자와 EKS의 EMR 간에 Spark 서비스 클라이언트를 내장했습니다. Spark 서비스 클라이언트는 사용자에게 서로 다른 리소스 계층(예: 소형, 중형 및 대형)만 노출합니다. 각 계층은 Amazon EKS에 구성된 특정 노드 그룹에 매핑됩니다. 이 디자인은 다음과 같은 이점을 제공합니다.

• 가격과 용량이 변경되는 경우 노드 그룹의 구성을 업데이트하고 사용자로부터 추상화된 상태로 유지하기가 쉽습니다. 사용자는 아무것도 바꾸거나 느끼지 않고 비용과 운영 오버헤드를 가능한 한 낮게 유지하면서 안정적인 리소스 프로비저닝을 계속해서 즐길 수 있습니다.
• Spark 애플리케이션에 적합한 리소스를 선택할 때 단순화된 구성으로 쉽게 선택할 수 있기 때문에 최종 사용자는 추측 작업을 할 필요가 없습니다.

향상된 Spark distro 릴리스 관리는 EKS의 EMR에서 얻는 또 다른 이점입니다. EKS에서 EMR을 사용하기 전에는 SSP에서 Spark distro의 불투명한 릴리스로 인해 어려움을 겪었습니다. 1~2개월마다 새로운 패치 버전의 Spark distro가 사용자에게 릴리스됩니다. 이러한 버전은 모두 UI를 통해 사용자에게 노출됩니다. 이로 인해 엔지니어는 다양한 버전의 distro를 선택하게 되었으며 그 중 일부는 내부 도구로 테스트되지 않았습니다. 파이프라인, 내부 시스템의 파괴율, 플랫폼 팀의 지원 부담이 크게 증가했습니다. Spark 배포판 릴리스로 인한 위험이 최소화되고 EKS 아키텍처의 EMR을 사용하는 사용자에게 투명해야 합니다.

EKS의 EMR은 고정 버전의 Spark distro가 포함된 안정적인 기본 Docker 이미지를 사용하여 모범 사례를 따릅니다. Spark distro를 변경하려면 Docker 이미지를 명시적으로 다시 빌드하고 롤아웃해야 합니다. EKS의 EMR을 사용하면 내부 도구 및 시스템으로 테스트하고 공식 릴리스를 만들기 전에 사용자에게 새로운 버전의 Spark distro를 숨길 수 있습니다.

결론

이 게시물에서는 EKS의 EMR 위에 Spark 플랫폼을 구축하는 여정을 공유했습니다. SSP인 EKS의 EMR은 Spark 플랫폼의 강력한 기반 역할을 합니다. EKS에서 EMR을 사용하여 종속성 관리, 리소스 프로비저닝 및 디버깅 경험에 이르는 문제를 해결할 수 있었고 스팟 인스턴스 유형 및 크기의 가용성이 높아 컴퓨팅 비용을 50%까지 크게 줄일 수 있었습니다.

귀하의 비즈니스에 적합한 SSP를 선택할 때 이 게시물이 커뮤니티에 통찰력을 공유할 수 있기를 바랍니다. EKS의 EMR에 대해 자세히 알아보기, 이점, 기능 및 시작 방법을 포함합니다.

저자에 관하여

난 주 SafeGraph 플랫폼 팀의 기술 책임자입니다. 그는 팀을 이끌고 SafeGraph 엔지니어링 프로세스의 안정성, 효율성 및 생산성을 개선하기 위해 광범위한 인프라 및 내부 도구를 구축합니다(예: 내부 Spark 에코시스템, 대규모 단일 리포지토리용 CI/CD 등). 그는 또한 참여하고 있습니다. Apache Spark, Apache Iceberg, Gluten 등과 같은 여러 오픈 소스 프로젝트에서

데이브 티볼트 AWS의 독립 소프트웨어 공급업체(ISV) 고객에게 서비스를 제공하는 수석 솔루션 설계자입니다. 그는 서버리스 기술, 기계 학습으로 구축하고 AWS 고객의 비즈니스 성공을 가속화하는 데 열정적입니다. AWS에 합류하기 전에 Dave는 연구, 개발 및 임상 제조 그룹을 위한 IT 및 정보학을 수행하는 생명 과학 회사에서 17년을 보냈습니다. 그는 또한 스노보드 타기, 야외 유화 그리기, 가족과 함께 시간 보내기를 즐깁니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• 플라토 블록체인. Web3 메타버스 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 출처: https://aws.amazon.com/blogs/big-data/how-safegraph-built-a-reliable-efficient-and-user-friendly-spark-platform-with-amazon-emr-on-amazon-eks/