BLOG
Launchmetrics는 브랜드 성과 클라우드 도구와 인텔리전스를 제공하여 패션, 럭셔리 및 미용 소매 경영진이 글로벌 전략을 최적화할 수 있도록 지원합니다. Launchmetrics는 기존에는 온프레미스 전체 인프라를 운영했으나 데이터 수집을 확장하는 동시에 고객에게 개선되고 빠른 인사이트를 제공하기 위해 AWS 클라우드에서 아키텍처를 구축하게 되었습니다.
오늘 포스팅에서는 Launchmetrics가 Amazon Web Services(AWS)를 사용하여 온라인 소셜 및 인쇄 미디어용 웹을 크롤링하는 방법을 설명드리고자 합니다. 수집된 데이터를 사용하여 Launchmetrics는 고객에게 처방적 분석 및 통찰력을 제공할 수 있습니다. 결과적으로 고객은 브랜드의 추진력을 이해하고 청중과 상호 작용하여 제품을 성공적으로 출시할 수 있습니다.
아키텍처 개요
Launchmetrics의 플랫폼 아키텍처는 아래 그림 1에 나와 있으며 세 가지 계층으로 구성되어 있습니다.
- 크롤링
- 데이터 지속성
- 처리
크롤링 계층은 Auto Scaling 그룹을 통해 시작된 여러 Amazon Elastic Compute Cloud(Amazon EC2) 스팟 인스턴스로 구성됩니다. 스팟 인스턴스는 장기 약정 없이 시간당 또는 초 단위로 청구되는 컴퓨팅 인스턴스인 온디맨드 인스턴스와 비교하여 할인된 요금으로 미사용 Amazon EC2 용량을 활용합니다. Launchmetrics는 스팟 인스턴스를 많이 활용 합니다. 크롤링 계층은 여러 미디어 소스(그림 1에서 숫자 1로 표시)에서 데이터 검색, 처리 및 저장을 담당합니다.
데이터 지속성 계층은 Amazon Kinesis Data Streams 및 Amazon Simple Queue Service(Amazon SQS)의 두 가지 구성 요소로 구성됩니다. Kinesis Data Streams는 크롤링 계층에서 수집하는 데이터를 저장하고 Amazon SQS는 전체 프로세스의 메타데이터를 저장합니다. 이러한 맥락에서 메타데이터는 Launchmetrics가 데이터 수집 시기와 데이터 처리 시작 여부에 대한 통찰력을 얻는 데 도움이 됩니다. 이것은 스팟 인스턴스가 중단되는 경우의 핵심 정보이며 나중에 더 자세히 설명합니다.
세 번째 계층인 Processing도 스팟 인스턴스를 사용하고 데이터 지속성 계층에서 데이터를 가져오는 역할을 합니다(그림 1에서 숫자 2로 표시됨). 그런 다음 분석 및 기계 학습 모델 모두에 독점 알고리즘을 적용하여 소비자 통찰력을 생성합니다. 이러한 통찰력은 Amazon Aurora 클러스터와 Amazon OpenSearch Service 클러스터로 구성된 데이터 계층(표시되지 않음)에 저장됩니다 .
이러한 계층 분리를 통해 Launchmetrics는 분리된 아키텍처를 사용할 수 있으며, 여기서 각 구성 요소는 독립적으로 확장될 수 있고 더 안정적입니다. 크롤링 및 데이터 처리 계층 모두 용량의 최대 90%에 대해 스팟 인스턴스를 사용합니다.
EC2 스팟 인스턴스를 사용한 데이터 처리
Launchmetrics가 워크로드를 AWS 클라우드로 마이그레이션하기로 결정했을 때 스팟 인스턴스가 주요 동인 중 하나였습니다. 스팟 인스턴스는 약정 없이 큰 할인을 제공하기 때문에 Launchmetrics는 1200개 이상의 브랜드를 추적할 수 있었고 10억 명이 넘는 최종 사용자가 되었습니다. 매일 500,000개 이상의 인플루언서 프로필, 800만 개의 문서, 약 7,000만 개의 소셜 미디어 댓글을 추적합니다.
스팟 인스턴스를 통한 비용 절감 외에도 Launchmetrics는 아키텍처 설계 측면에서 부수적인 이점을 얻었습니다. 결과적으로 스택 아키텍처도 더 느슨하게 결합되었습니다.
모든 Launchmetrics Auto Scaling 그룹의 구성은 다음과 같습니다.
- 스팟 할당 전략: 비용 최적화
- 용량 재조정: true
- 3개의 가용 영역
- 다양한 인스턴스 유형 목록
Launchmetrics는 Auto Scaling 그룹을 사용하여 SQS 대기열에 있는 항목 수에 따라 작업자 인스턴스를 확장하여 인스턴스 효율성을 높일 수 있습니다. Launchmetrics의 플랫폼에 있는 것과 같은 데이터 처리 워크로드는 M5, M5a, C5 및 C5a와 같은 여러 인스턴스 유형 의 예시적인 사용입니다. 스팟 인스턴스를 채택할 때 Launchmetrics는 다른 인스턴스 유형이 여유 용량에 액세스할 수 있다고 간주했습니다. 결과적으로 Launchmetrics는 더 적은 비용으로 더 많은 리소스가 포함된 인스턴스를 사용하기 때문에 워크로드의 성능이 향상됨을 발견했습니다.
SQS 대기열을 사용하여 데이터 처리 워크로드를 분리함으로써 중단이 도착하면 프로세스가 중지됩니다. Auto Scaling 그룹이 대체 스팟 인스턴스를 시작하면 클라이언트가 영향을 받지 않고 데이터가 손실되지 않습니다. 모든 프로세스는 새 스팟 인스턴스가 보류 중인 데이터 처리를 재개하는 데이터 체크포인트를 거칩니다. 스팟 인스턴스를 통해 관련 운영 비용을 최대 75%까지 절감할 수 있었습니다.
스팟 중단 및 서비스 중단을 처리하는 능력에 대한 자신감을 높이기 위해 Launchmetrics는 AWS Fault Injection Simulator를 사용하여 스팟 중단과 같은 아키텍처의 결함을 시뮬레이션하는 방법을 모색하고 있습니다. AWS Fault Injection Simulator 에서 이 서비스가 작동하는 방식에 대해 자세히 알아보십시오 . 이제 스팟 중단 시작 페이지가 지원됩니다.
보고 데이터 인사이트
다양한 미디어 소스의 데이터를 처리한 후 AWS는 더 높은 품질의 데이터 통찰력을 더 빠르게 생성할 수 있도록 Launchmetrics를 지원했습니다. 이전의 온프레미스 아키텍처는 실행 시간 범위가 5-6분이었지만 AWS 기반 아키텍처는 1분 미만이 소요되었습니다.
이는 Amazon EC2가 온프레미스 정적 집합과 비교하여 제공하는 탄력성과 가용성 컴퓨팅 용량으로 인해 가능합니다. 또한, Launchmetrics는 Amazon Aurora 또는 Amazon OpenSearch Service와 같은 AWS 관리형 서비스를 사용하여 일부 관리 및 운영 작업을 AWS로 오프로드하여 차별화되지 않은 활동에 시간을 사용하기보다 핵심 비즈니스에 집중하고 독점 솔루션을 개선할 수 있습니다.
지속적 배포 파이프라인 구축
Launchmetrics가 많은 구성 요소를 사용하여 소프트웨어를 어떻게 변경하는지 알아보겠습니다.
두 컴퓨팅 계층인 크롤링 및 처리는 Auto Scaling 그룹을 통해 시작된 독립 실행형 EC2 인스턴스와 Amazon Elastic Container Service(Amazon ECS) 클러스터의 일부인 EC2 인스턴스로 구성됩니다. 현재 Launchmetrics 워크로드의 70%는 여전히 Auto Scaling 그룹으로 실행되고 30%는 컨테이너화되어 Amazon ECS에서 실행됩니다. 이러한 작업 그룹 각각에 대해 배포 프로세스가 다르기 때문에 이는 중요합니다.
Auto Scaling 그룹에서 실행되는 워크로드의 경우 AWS CodePipeline을 사용하여 다음을 포함하는 전체 프로세스를 조정합니다.
I. AWS CodeBuild를 사용하여 새 Amazon 머신 이미지(AMI) 생성
II. CodeBuild에서 Terraform을 사용하여 새로 빌드된 AMI 배포
Amazon ECS에서 실행되는 컨테이너식 워크로드의 경우 Launchmetrics도 CodePipeline을 사용하여 다음과 같이 프로세스를 조정합니다.
III. 새 컨테이너 이미지를 생성하고 Amazon Elastic Container Registry에 저장
IV. 작업 정의에서 컨테이너 이미지 변경 및 CodeBuild를 사용하여 Amazon ECS 서비스 업데이트
결론
이번 포스팅에서는 Launchmetrics가 EC2 스팟 인스턴스를 사용하여 비용을 절감하는 동시에 고객을 위한 고품질 데이터 통찰력을 제공하는 방법을 살펴보았습니다. 또한 중단을 처리하는 데 아키텍처 분리가 얼마나 중요한지, 스팟 인스턴스 모범 사례를 따르면 더 많은 예비 용량에 대한 액세스 권한을 부여할 수 있는 이유도 함께 알아보았습니다.
이 아키텍처를 사용하여 Launchmetrics는 고객을 위한 더 빠른 데이터 기반 통찰력을 생성하고 혁신 능력을 향상시켰습니다. 그들은 계속해서 애플리케이션을 컨테이너화하고 있으며 2023년 말까지 스팟 인스턴스가 있는 Amazon ECS에서 워크로드의 100%를 실행할 것으로 예상됩니다.
EC2 스팟 인스턴스 중단 처리에 대한 자세한 내용은 EC2 스팟 인스턴스 중단 처리를 위한 AWS 모범 사례 블로그 게시물을 참조하십시오. 마찬가지로 AWS Fault Injection Simulator에 대해 자세히 알아보고 아키텍처에 어떤 이점이 있는지 알아보려면 카오스 엔지니어링 및 AWS Fault Injection Simulator를 사용하여 전자 상거래 웹 사이트 안정성 향상 을 참조하십시오.
메가존클라우드 TechBlog는 AWS BLOG 영문 게재 글이나 관련 기사 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.