계정 조정은 재무제표의 완전성과 정확성을 보장하는 중요한 단계입니다. 특히 기업은 화해해야 한다. 대차 대조표 중대한 또는 중대한 왜곡이 포함될 수 있는 계정. 회계사는 계정의 총계정원장에 있는 각 계정을 검토하고 나열된 잔액이 완전하고 정확한지 확인합니다. 불일치가 발견되면 회계사는 조사하고 적절한 시정 조치를 취합니다.
Amazon FinTech 조직의 일환으로 우리는 Amazon 내부 회계팀이 계정 조정을 수행할 수 있도록 지원하는 소프트웨어 플랫폼을 제공합니다. 조정 프로세스를 최적화하기 위해 이러한 사용자에게는 필요에 따라 확장할 수 있는 능력과 최소 몇 MB에서 100GB 이상에 이르는 다양한 파일 크기를 처리할 수 있는 능력을 갖춘 고성능 변환이 필요합니다. 단일 기계에 데이터를 맞추거나 합리적인 시간 내에 하나의 단일 프로그램으로 데이터를 처리하는 것이 항상 가능한 것은 아닙니다. 이 계산은 프로그래밍 논리와 기본 세부 정보(데이터 배포, 내결함성 및 예약)를 분리할 수 있는 실용적인 서비스를 제공할 수 있을 만큼 빠르게 수행되어야 합니다.
분산 데이터 처리 솔루션을 사용하면 데이터 세트의 요소 그룹에 걸쳐 동일한 기능을 가진 여러 시스템 또는 스레드에서 이러한 동시 계산을 수행할 수 있습니다. 이를 통해 우리는 다음을 포함하여 AWS 서비스를 기반으로 하는 조정 서비스를 재창조하게 되었습니다. 아마존 EMR 그리고 아파치 스파크 다음을 사용하는 분산 처리 프레임워크 파이 스파크. 이 서비스를 통해 사용자는 최대 100억 건의 트랜잭션이 포함된 100GB 이상의 파일을 30분 이내에 처리할 수 있습니다. 조정 서비스는 데이터 처리의 강자로 자리 잡았으며 이제 사용자는 다음과 같은 다양한 작업을 원활하게 수행할 수 있습니다. 피벗, JOIN (Excel VLOOKUP 작업과 유사) 산수 운영 및 배우기, 방대한 데이터 세트를 조정하기 위한 다양하고 효율적인 솔루션을 제공합니다. 이러한 향상된 기능은 분산 데이터 처리 솔루션의 채택을 통해 달성된 확장성과 속도를 입증합니다.
이 게시물에서는 Amazon EMR을 통합하여 대규모 금융 조정 프로세스를 실행할 수 있는 가용성과 확장성이 뛰어난 시스템을 구축한 방법을 설명합니다.
마이그레이션 전 아키텍처
다음 다이어그램은 이전 아키텍처를 보여줍니다.
우리의 레거시 서비스는 다음과 같이 구축되었습니다. Amazon 탄력적 컨테이너 서비스 (Amazon ECS) 켜기 AWS 파게이트. Python을 사용하여 데이터를 순차적으로 처리했습니다. 그러나 병렬 처리 기능이 부족하여 더 큰 데이터 세트를 지원하기 위해 클러스터 크기를 수직으로 늘려야 하는 경우가 많았습니다. 맥락상 5개의 작업이 포함된 50GB의 데이터를 처리하는 데 약 3시간이 걸렸습니다. 이 서비스는 다음에서 메시지를 폴링하는 XNUMX개의 ECS 인스턴스로 수평 확장되도록 구성되었습니다. 아마존 단순 대기열 서비스 (Amazon SQS), 변환 요청을 제공했습니다. 수평적 확장이 가능하도록 각 인스턴스는 vCPU 4개와 30GB 메모리로 구성되었습니다. 그러나 프로세스가 순차적으로 발생하여 데이터 덩어리를 선택했기 때문에 성능에 대한 용량을 확장할 수 없었습니다. 아마존 단순 스토리지 서비스 (Amazon S3) 처리용. 예를 들어 두 파일을 결합하는 VLOOKUP 작업에서는 출력을 얻기 위해 두 파일을 메모리 청크 단위로 읽어야 했습니다. 이는 데이터 세트를 처리하는 데 오랜 시간을 기다려야 했기 때문에 사용자에게 장애물이 되었습니다.
아키텍처 재구축 및 현대화의 일환으로 우리는 다음을 달성하고자 했습니다.
- 고 가용성 – 데이터 처리 클러스터는 9%의 가용성을 제공하는 고가용성이어야 합니다.
- 처리량 – 서비스는 하루에 1,500번의 실행을 처리해야 합니다.
- 숨어 있음 – 100GB의 데이터를 30분 이내에 처리할 수 있어야 합니다.
- 이질 – 클러스터는 몇 MB에서 수백 GB에 이르는 파일로 다양한 워크로드를 지원할 수 있어야 합니다.
- 쿼리 동시성 – 구현에는 최소 10도의 동시성을 지원하는 기능이 필요합니다.
- 작업 신뢰성 및 데이터 일관성 – 서비스 수준 계약(SLA) 위반을 방지하려면 작업이 안정적이고 일관되게 실행되어야 합니다.
- 비용 효율적이고 확장 가능 – 워크로드에 따라 확장 가능해야 하며 비용 효율적이어야 합니다.
- 보안 및 규정 준수 – 데이터의 민감도를 고려하여 세분화된 액세스 제어와 적절한 보안 구현을 지원해야 합니다.
- 모니터링 – 솔루션은 클러스터 및 작업에 대한 엔드투엔드 모니터링을 제공해야 합니다.
Amazon EMR을 선택해야 하는 이유
Amazon EMR은 다음과 같은 오픈 소스 프레임워크를 사용하여 페타바이트 규모의 데이터 처리, 대화형 분석 및 기계 학습(ML)을 위한 업계 최고의 클라우드 빅 데이터 솔루션입니다. 아파치 스파크, 아파치 하이브및 프레스토 악장. 이러한 프레임워크 및 관련 오픈 소스 프로젝트를 사용하면 분석 목적 및 BI 워크로드용 데이터를 처리할 수 있습니다. Amazon EMR을 사용하면 Amazon S3 및 기타 AWS 데이터 스토어와 데이터베이스에서 대량의 데이터를 변환하고 이동할 수 있습니다. 아마존 DynamoDB.
Amazon EMR의 주목할만한 장점은 PySpark를 통한 병렬 처리를 효과적으로 사용한다는 것입니다. 이는 기존 순차 Python 코드에 비해 상당한 개선이 이루어졌습니다. 이 혁신적인 접근 방식은 Apache Spark 클러스터의 배포 및 확장을 간소화하여 대규모 데이터 세트에 대한 효율적인 병렬화를 가능하게 합니다. 분산 컴퓨팅 인프라는 성능을 향상시킬 뿐만 아니라 전례 없는 속도로 방대한 양의 데이터를 처리할 수 있게 해줍니다. 라이브러리를 갖춘 PySpark는 Excel과 유사한 작업을 용이하게 합니다. 데이터 프레임, DataFrames의 상위 수준 추상화는 복잡한 데이터 조작을 단순화하여 코드 복잡성을 줄입니다. 자동 클러스터 프로비저닝, 동적 리소스 할당 및 다른 AWS 서비스와의 통합이 결합된 Amazon EMR은 배치 처리에서 ML에 이르기까지 다양한 워크로드에 적합한 다용도 솔루션임이 입증되었습니다. PySpark 및 Amazon EMR의 고유한 내결함성은 노드 오류가 발생하는 경우에도 견고성을 촉진하여 AWS에서 병렬 데이터 처리를 위한 확장 가능하고 비용 효율적인 고성능 선택이 됩니다.
Amazon EMR은 기본 기능 이상으로 기능을 확장하여 다양한 요구 사항을 충족할 수 있는 다양한 배포 옵션을 제공합니다. 그것이든 EC2의 Amazon EMR, EKS의 Amazon EMR, Amazon EMR 서버리스및 AWS Outposts의 Amazon EMR을 사용하면 특정 요구 사항에 맞게 접근 방식을 조정할 수 있습니다. Spark 작업을 위한 서버리스 환경을 원하는 사람들을 위해 AWS 접착제 실행 가능한 옵션이기도 합니다. Spark를 포함한 다양한 오픈 소스 프레임워크를 지원하는 것 외에도 Amazon EMR은 배포 모드 선택에 유연성을 제공합니다. 아마존 엘라스틱 컴퓨트 클라우드 (Amazon EC2) 인스턴스 유형, 확장 메커니즘 및 다양한 비용 절감 최적화 기술을 제공합니다.
Amazon EMR은 클라우드에서 강력한 빅 데이터 솔루션을 찾는 조직에 탁월한 기능을 제공하는 역동적인 힘으로 자리잡고 있습니다. 원활한 통합, 강력한 기능 및 적응성을 통해 AWS에서 데이터 분석 및 ML의 복잡성을 탐색하는 데 없어서는 안 될 도구입니다.
재설계된 아키텍처
다음 다이어그램은 새롭게 디자인된 아키텍처를 보여줍니다.
이 솔루션은 클라이언트가 변환 구성을 제출하여 처리할 S3 데이터 세트 위치와 함께 작업 세트를 정의할 수 있는 API 계약에 따라 작동합니다. 요청은 Amazon SQS를 통해 대기열에 추가된 후 Lambda 함수를 통해 Amazon EMR로 전달됩니다. 이 프로세스는 전용 EMR 클러스터에서 Spark 프레임워크 구현을 위한 Amazon EMR 단계 생성을 시작합니다. Amazon EMR은 장기 실행 클러스터 수명 동안 무제한의 단계를 수용하지만 동시에 실행되거나 보류될 수 있는 단계는 256개뿐입니다. 최적의 병렬화를 위해 단계 동시성은 10으로 설정되어 10개의 단계가 동시에 실행될 수 있습니다. 요청이 실패하는 경우 Amazon SQS 배달 못한 편지 대기열 (DLQ)는 이벤트를 유지합니다. Spark는 효율적인 쿼리 계획을 위해 Excel과 유사한 작업을 PySpark 코드로 변환하여 요청을 처리합니다. 탄력적 DataFrames는 입력, 출력 및 중간 데이터를 메모리에 저장하여 처리 속도를 최적화하고, 디스크 I/O 비용을 줄이고, 워크로드 성능을 향상시키고, 최종 출력을 지정된 Amazon S3 위치에 제공합니다.
우리는 대기 시간과 처리량이라는 두 가지 차원으로 SLA를 정의합니다. 지연 시간은 결정적 데이터 세트 크기와 데이터 세트에서 수행되는 작업 수에 대해 하나의 작업을 수행하는 데 걸리는 시간으로 정의됩니다. 처리량은 서비스가 한 작업의 대기 시간 SLA를 위반하지 않고 수행할 수 있는 최대 동시 작업 수로 정의됩니다. 서비스의 전반적인 확장성 SLA는 탄력적인 컴퓨팅 리소스의 수평적 확장과 개별 서버의 수직적 확장의 균형에 따라 달라집니다.
최소한의 지연 시간과 높은 성능으로 하루에 1,500개의 프로세스를 실행해야 했기 때문에 다양한 파일 크기 처리를 지원하기 위해 관리형 조정이 활성화된 EC2 배포 모드에서 Amazon EMR을 통합하기로 결정했습니다.
EMR 클러스터 구성은 다양한 선택 사항을 제공합니다.
- EMR 노드 유형 – 기본, 코어 또는 작업 노드
- 인스턴스 구매 옵션 – 온디맨드 인스턴스, 예약 인스턴스 또는 스팟 인스턴스
- 구성 옵션 – EMR 인스턴스 집합 또는 균일한 인스턴스 그룹
- 확장 옵션 - 오토 스케일링 또는 Amazon EMR 관리형 확장
다양한 워크로드를 기반으로 EMR 인스턴스 집합을 구성했습니다(모범 사례는 참조). 신뢰성). 또한 Amazon EMR 관리형 확장을 사용하여 코어 및 작업 노드를 확장하기로 결정했습니다(확장 시나리오는 다음을 참조하세요). 노드 할당 시나리오). 마지막으로 메모리 최적화를 선택했습니다. AWS 그래비톤 인스턴스는 최대 Spark 워크로드의 비용은 30% 절감되고 성능은 최대 15% 향상됩니다..
다음 코드는 클러스터 구성의 스냅샷을 제공합니다.
퍼포먼스
Amazon EMR로 마이그레이션하면서 우리는 최소 273B에서 최대 88.5GB에 이르는 다양한 데이터 세트를 처리할 수 있는 시스템 성능을 달성할 수 있었습니다. p99 491초(약 8분)입니다.
다음 그림은 처리되는 다양한 파일 크기를 보여줍니다.
다음 그림은 대기 시간을 보여줍니다.
순차 처리와 비교하기 위해 53만 개의 레코드가 포함된 두 개의 데이터 세트를 가져와 49개의 다른 Excel과 유사한 작업과 함께 서로에 대해 VLOOKUP 작업을 실행했습니다. 기존 서비스에서는 처리하는 데 26일이 걸렸는데, 새 서비스에서는 처리하는 데 5분이 걸렸습니다. 이러한 개선은 성능 측면에서 이전 아키텍처에 비해 거의 300배 더 뛰어납니다.
고려
이 솔루션을 고려할 때 다음 사항에 유의하세요.
- 적절한 크기의 클러스터 – Amazon EMR은 크기 조정이 가능하지만 클러스터 크기를 적절하게 조정하는 것이 중요합니다. 적절한 크기 조정은 클러스터 크기가 작은 경우 느린 클러스터를 완화하고, 클러스터 크기가 너무 큰 경우 비용이 높아지는 것을 완화합니다. 이러한 문제를 예측하려면 워크로드에 필요한 노드 수와 유형을 계산하면 됩니다.
- 병렬 단계 – 단계를 병렬로 실행하면 고급 워크로드를 실행하고, 클러스터 리소스 활용도를 높이며, 워크로드를 완료하는 데 걸리는 시간을 줄일 수 있습니다. 한 번에 실행할 수 있는 단계 수는 구성 가능하며 클러스터가 시작될 때와 클러스터가 시작된 후 언제든지 설정할 수 있습니다. 단일 공유 클러스터에서 여러 작업이 실행되는 경우 작업당 CPU/메모리 사용량을 고려하고 최적화해야 합니다.
- 작업 기반 임시 EMR 클러스터 – 해당하는 경우 탁월한 격리를 제공하고 각 작업이 전용 환경 내에서 작동하는지 확인하는 작업 기반 임시 EMR 클러스터를 사용하는 것이 좋습니다. 이 접근 방식은 리소스 활용도를 최적화하고 작업 간 간섭을 방지하며 전반적인 성능과 안정성을 향상시킵니다. 일시적인 특성으로 인해 효율적인 확장이 가능하며 다양한 데이터 처리 요구 사항에 맞는 강력하고 격리된 솔루션을 제공합니다.
- EMR 서버리스 – EMR 서버리스는 클러스터 관리 및 운영을 처리하지 않으려는 경우 이상적인 선택입니다. EMR Serverless 내에서 사용 가능한 오픈 소스 프레임워크를 사용하여 애플리케이션을 쉽게 실행할 수 있어 간단하고 번거롭지 않은 환경을 제공합니다.
- 아마존 EKS의 EMR – EKS 기반 Amazon EMR은 더 빠른 시작 시간, 향상된 확장성으로 컴퓨팅 용량 문제를 해결하는 등 뚜렷한 이점을 제공합니다. 이는 Graviton 및 스팟 인스턴스 사용자에게 특히 유용합니다. 더 광범위한 컴퓨팅 유형을 포함하면 비용 효율성이 향상되어 맞춤형 리소스 할당이 가능해집니다. 또한 다중 AZ 지원으로 가용성이 향상됩니다. 이러한 강력한 기능은 다양한 컴퓨팅 시나리오에서 향상된 성능, 비용 최적화 및 안정성을 통해 빅 데이터 워크로드를 관리하기 위한 강력한 솔루션을 제공합니다.
결론
이 게시물에서는 Amazon이 확장성과 성능을 높이기 위해 Amazon EMR을 사용하여 대규모 금융 조정 프로세스를 최적화한 방법을 설명했습니다. 추가 요청이나 데이터 세트를 처리하기 위해 수직 확장에 의존하는 모놀리식 애플리케이션이 있는 경우 이를 Apache Spark와 같은 분산 처리 프레임워크로 마이그레이션하고 컴퓨팅을 위해 Amazon EMR과 같은 관리형 서비스를 선택하면 런타임을 줄여 전달 속도를 낮추는 데 도움이 될 수 있습니다. SLA는 총 소유 비용(TCO)을 줄이는 데도 도움이 될 수 있습니다.
이 특정 사용 사례에 Amazon EMR을 채택함에 따라 데이터 혁신 여정에서 더 많은 가능성을 탐색해 보시기 바랍니다. EMR 서버리스 또는 EKS 기반 Amazon EMR과 같은 다른 동적 Amazon EMR 배포 옵션과 함께 AWS Glue를 평가하여 고유한 사용 사례에 맞는 최고의 AWS 서비스를 찾아보세요. 데이터 혁신 여정의 미래에는 앞으로 더 탐구해야 할 흥미로운 가능성과 발전이 있습니다.
저자에 관하여
지샨 케트라팔 그는 Amazon의 수석 소프트웨어 개발 엔지니어로서 기업의 IT 일반 통제, 재무 보고, 거버넌스, 위험 및 규정 준수에 대한 통제권을 담당하는 클라우드 컴퓨팅 서버리스 아키텍처를 기반으로 핀테크 제품을 개발합니다.
삭티 미슈라 그는 AWS의 수석 솔루션 아키텍트로서 고객이 데이터 아키텍처를 현대화하고 데이터 보안, 접근성, 거버넌스 등을 포함한 엔드투엔드 데이터 전략을 정의하도록 돕습니다. 그 사람은 책의 저자이기도 하다. Amazon EMR로 빅 데이터 분석 간소화. 직장 밖에서 Sakti는 새로운 기술을 배우고, 영화를 보고, 가족과 함께 장소를 방문하는 것을 즐깁니다.
- SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
- PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
- PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
- 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
- PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
- 출처: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/
