빅 데이터

AppsFlyer가 Amazon Athena로 이전하여 대화형 워크로드를 현대화하고 비용을 80% 절감한 방법 | 아마존 웹 서비스

플라톤에 의해 재발행

시간 2024 년 8 월 8 일

조회수 : 89

이 게시물은 AppsFlyer의 Nofar Diamant 및 Matan Safri와 공동으로 작성되었습니다.

AppsFlyer 마케터가 마케팅 활동의 효과를 측정하고 이를 더 넓은 마케팅 세계와 통합하여 매일 100억 건에 달하는 방대한 양의 이벤트를 관리할 수 있도록 하는 개인 정보 보호에 초점을 맞춘 선도적인 측정 솔루션을 개발합니다. AppsFlyer는 디지털 마케팅 담당자가 심층 분석을 활용하여 앱 설치로 이어지는 다양한 소비자 상호 작용을 정확하게 식별하고 크레딧을 할당할 수 있도록 지원합니다.

AppsFlyer가 제공하는 제품 중 하나는 Audiences Segmentation 제품입니다. 이를 통해 앱 소유자는 사용자의 행동과 인구통계를 기반으로 사용자를 정확하게 타겟팅하고 다시 참여시킬 수 있습니다. 여기에는 추정 기능이라고 하는 특정 사용자 세그먼트 내의 잠재 고객 규모를 실시간으로 추정하는 기능이 포함됩니다.

사용자에게 잠재 고객 규모에 대한 실시간 추정을 제공하기 위해 AppsFlyer 팀은 원래 오픈 소스 분산 데이터베이스인 Apache HBase를 사용했습니다. 그러나 워크로드가 23TB로 증가함에 따라 응답 시간과 안정성에 대한 서비스 수준 계약(SLA)을 충족하기 위해 HBase 아키텍처를 재검토해야 했습니다.

이 게시물에서는 AppsFlyer가 어떻게 Audiences Segmentation 제품을 현대화했는지 살펴봅니다. 아마존 아테나. Athena는 AWS에서 제공하는 강력하고 다양한 서버리스 쿼리 서비스입니다. 사용자가 저장된 데이터를 쉽게 분석할 수 있도록 설계되었습니다. 아마존 단순 스토리지 서비스 (Amazon S3) 표준 SQL 쿼리를 사용합니다.

파티션 투영, 정렬, 병렬 쿼리 실행, 쿼리 결과 재사용 등 AppsFlyer가 사용하는 다양한 최적화 기술에 대해 알아봅니다. 우리는 팀이 직면한 과제와 낮은 지연 시간 요구 사항이 있는 사용 사례에서 Athena의 진정한 잠재력을 발휘하기 위해 채택한 전략을 공유합니다. 또한 새로운 Athena 아키텍처로의 성공적인 전환을 가져온 철저한 테스트, 모니터링 및 롤아웃 프로세스에 대해 논의합니다.

잠재고객 세분화 레거시 아키텍처 및 현대화 동인

오디언스 세분화에는 AppsFlyer UI에서 타겟 오디언스를 정의하는 작업이 포함되며, 이는 각각 노드와 리프로 설정된 작업과 원자적 기준이 있는 방향성 트리 구조로 표시됩니다.

다음 다이어그램은 AppsFlyer 오디언스 관리 콘솔의 오디언스 세분화와 설명된 트리 구조로의 변환의 예를 보여줍니다. 두 개의 원자 기준을 리프로 하고 이들 사이의 설정 작업을 노드로 사용합니다.

사용자에게 잠재 고객 규모에 대한 실시간 추정을 제공하기 위해 AppsFlyer 팀은 다음과 같은 프레임워크를 사용했습니다. 세타 스케치, 이는 개별 요소를 계산하기 위한 효율적인 데이터 구조입니다. 이러한 스케치는 확장성과 분석 기능을 향상시킵니다. 이러한 스케치는 원래 HBase 데이터베이스에 저장되었습니다.

HBase는 수평 확장성을 통해 상용 하드웨어 전반에 걸쳐 대량의 데이터를 처리하도록 설계된 오픈 소스 분산형 컬럼형 데이터베이스입니다.

원래 데이터 구조

이번 포스팅에서는 중점적으로 events 테이블은 처음에 HBase에 저장된 가장 큰 테이블입니다. 테이블에는 스키마가 있습니다. date | app-id | event-name | event-value | sketch 그리고 다음과 같이 분할되었습니다. date 및 app-id.

다음 다이어그램은 AppsFlyer 추정 시스템의 높은 수준의 원래 아키텍처를 보여줍니다.

이 아키텍처에는 소스 데이터 세트에서 스케치 파일을 생성하는 작업을 시작한 다음 이러한 파일을 HBase로 가져오는 Airflow ETL 프로세스가 포함되어 있습니다. 그런 다음 사용자는 API 서비스를 사용하여 HBase를 쿼리하고 UI에 설정된 대상 세그먼트 기준에 따라 사용자 수 추정치를 검색할 수 있습니다.

이전 HBase 아키텍처에 대해 자세히 알아보려면 다음을 참조하세요. 응용 확률 – Theta 스케치를 사용하여 대규모 비정형 이벤트 세트 계산.

시간이 지남에 따라 워크로드는 HBase 구현이 원래 설계된 크기를 초과하여 스토리지 크기가 23TB에 도달했습니다. 응답 시간과 안정성에 대한 AppsFlyer의 SLA를 충족하려면 HBase 아키텍처를 재검토해야 한다는 것이 분명해졌습니다.

앞서 언급한 것처럼 사용 사례의 초점은 고객과 UI의 일상적인 상호 작용을 수반하므로 빠른 응답 시간과 상당한 수의 일일 요청을 처리하는 기능을 제공하는 UI 표준 SLA를 준수하는 동시에 현재 데이터 볼륨과 잠재적인 미래 확장.

또한 HBase의 운영 및 유지 관리와 관련된 높은 비용으로 인해 기존 시스템 아키텍처를 크게 복잡하게 만들지 않고 관리되고 간단하며 비용 효율적인 대안을 찾는 것이 목표였습니다.

팀은 AWS 전문가와의 철저한 팀 토론 및 상담을 통해 Amazon S3 및 Athena를 사용하는 솔루션이 가장 비용 효율적이고 간단한 선택이라는 결론을 내렸습니다. 주요 관심사는 쿼리 대기 시간과 관련이 있었고 팀은 전반적인 고객 경험에 부정적인 영향을 미치지 않도록 특히 주의했습니다.

다음 다이어그램은 Athena를 사용하는 새로운 아키텍처를 보여줍니다. 주목하세요 import-..-sketches-to-hbase 및 HBase가 생략되었으며 Amazon S3의 쿼리 데이터에 Athena가 추가되었습니다.

성능 향상을 위한 스키마 설계 및 파티션 프로젝션

이 섹션에서는 새로운 아키텍처의 스키마 설계 프로세스와 팀이 파티션 프로젝션을 포함하여 사용한 다양한 성능 최적화 방법에 대해 논의합니다.

파티션 축소를 위한 데이터 병합

Athena를 사용하여 대상 세분화를 지원할 수 있는지 평가하기 위해 초기 개념 증명이 수행되었습니다. 범위는 3시부터 도착하는 이벤트로 제한되었습니다. app-ids (약 3GB의 데이터)로 분할됨 app-id 과 별 date, HBase 구현에 사용된 것과 동일한 파티셔닝 스키마를 사용합니다. 팀이 10,000개의 전체 데이터세트를 포함하도록 규모를 확장함에 따라 app-ids 1개월 기간(약 150GB의 데이터에 도달) 동안 팀은 특히 상당한 기간에 걸쳐 있는 쿼리의 경우 더 느린 쿼리를 확인하기 시작했습니다. 팀은 심층 분석을 통해 Athena가 AWS Glue 데이터 카탈로그에서 로드한 많은 수의 파티션(7.3만 개)으로 인해 쿼리 계획 단계에서 상당한 시간을 소비했다는 사실을 발견했습니다. Athena를 AWS Glue와 함께 사용하는 방법에 대한 자세한 내용은 다음을 참조하세요. AWS Glue와의 통합).

이로 인해 팀은 파티션 인덱싱을 조사하게 되었습니다. Athena 파티션 인덱스 파티션 열에 메타데이터 인덱스를 생성하는 방법을 제공하여 Athena가 파티션 수준에서 데이터 스캔을 정리할 수 있도록 하여 Amazon S3에서 읽어야 하는 데이터 양을 줄일 수 있습니다. 파티션 인덱싱은 쿼리 계획 단계에서 파티션 검색 시간을 단축했지만, 필요한 쿼리 대기 시간 SLA를 충족할 만큼 개선 효과가 크지 않았습니다.

파티션 인덱싱의 대안으로 팀은 데이터 세분성을 일별에서 월별로 줄여 파티션 수를 줄이는 전략을 평가했습니다. 이 방법은 Theta Sketch 통합 기능을 사용하여 일별 스케치를 월별 복합 스케치로 병합하여 일별 데이터를 월별 집계로 통합했습니다. 예를 들어, 한 달 범위의 데이터를 취하면 한 달에 30개의 데이터 행을 갖는 대신 팀에서는 해당 행을 단일 행으로 통합하여 행 수를 효과적으로 97% 줄였습니다.

이 방법을 사용하면 초기에 약 30~10초가 소요되었던 파티션 검색 단계에 필요한 시간이 15% 크게 줄어들었으며, 스캔해야 하는 데이터의 양도 줄었습니다. 그러나 UI의 응답성 표준을 기반으로 예상되는 대기 시간 목표는 여전히 이상적이지 않았습니다.

게다가 병합 프로세스로 인해 데이터의 정밀도가 실수로 손상되어 다른 솔루션을 모색하게 되었습니다.

향상 승수로서의 파티션 투영

이 시점에서 팀은 탐색하기로 결정했습니다. Athena의 파티션 프로젝션.

Athena의 파티션 프로젝션을 사용하면 파티션의 메타데이터를 프로젝션하여 쿼리 효율성을 높일 수 있습니다. 사전에 데이터베이스 카탈로그에 파티션을 명시적으로 정의할 필요 없이 필요에 따라 파티션을 가상으로 생성하고 검색합니다.

이 기능은 많은 수의 파티션을 처리할 때나 스트리밍 데이터의 경우처럼 파티션이 빠르게 생성될 때 특히 유용합니다.

앞서 설명했듯이 이 특정 사용 사례에서 각 리프는 다음을 포함해야 하는 쿼리로 변환되는 액세스 패턴입니다. date 범위 app-id및 event-name. 이로 인해 팀은 다음을 사용하여 투영 열을 정의하게 되었습니다. 날짜 유형 위한 date 및 순위 주입형 for app-id 및 event-name.

카탈로그에서 모든 파티션 메타데이터를 스캔하고 로드하는 대신 Athena는 쿼리에서 구성된 규칙과 값을 사용하여 쿼리할 파티션을 생성할 수 있습니다. 이렇게 하면 즉시 파티션을 생성하여 카탈로그에서 파티션을 로드하고 필터링할 필요가 없습니다.

프로젝션 프로세스는 많은 수의 파티션으로 인해 발생하는 성능 문제를 방지하고 쿼리 실행 중 파티션 검색으로 인한 대기 시간을 제거하는 데 도움이 되었습니다.

파티션 프로젝션은 파티션 수와 쿼리 런타임 간의 종속성을 제거했기 때문에 팀은 추가 파티션을 실험할 수 있었습니다. event-name. 세 개의 열로 분할(date, app-id및 event-name) 스캔한 데이터의 양을 줄여 데이터만 분할한 파티션 프로젝션을 사용한 성능에 비해 쿼리 성능이 10% 향상되었습니다. date 및 app-id.

다음 다이어그램은 스케치 파일 생성의 상위 수준 데이터 흐름을 보여줍니다. 스케치 작성 과정을 중심으로(write-events-estimation-sketches)를 3개의 파티션 필드가 있는 Amazon S20에 추가하면 스케치 파일 수가 증가하여(Amazon S3에 XNUMX배 더 많은 스케치 파일 쓰기) 프로세스가 원래 아키텍처에 비해 두 배 더 오래 실행되었습니다.

이로 인해 팀은 event-name 두 개의 파티션으로 분할하고 절충합니다. date 및 app-id, 결과적으로 다음과 같은 파티션 구조가 생성됩니다.

s3://bucket/table_root/date=${day}/app_id=${app_id}

Parquet 파일 형식 사용

새로운 아키텍처에서 팀은 Parquet 파일 형식을 사용했습니다. Apache Parquet는 효율적인 데이터 저장 및 검색을 위해 설계된 오픈 소스 열 기반 데이터 파일 형식입니다. 각 Parquet 파일에는 쿼리 엔진이 불필요한 데이터 로드를 건너뛸 수 있도록 하는 열의 최소값 및 최대값과 같은 메타데이터가 포함되어 있습니다. Athena는 쿼리와 관련 없는 Parquet 파일 섹션을 건너뛰거나 빠르게 탐색할 수 있으므로 이 최적화를 통해 스캔해야 하는 데이터의 양이 줄어듭니다. 결과적으로 쿼리 성능이 크게 향상됩니다.

Parquet는 정렬된 필드를 쿼리할 때 특히 효과적입니다. Athena가 조건자 푸시다운 최적화를 촉진하고 관련 데이터 세그먼트를 신속하게 식별하고 액세스할 수 있기 때문입니다. Parquet 파일 형식의 이 기능에 대해 자세히 알아보려면 다음을 참조하세요. 열 기반 스토리지 형식 이해.

이러한 이점을 인식한 팀은 다음과 같이 정렬하기로 결정했습니다. event-name 정렬되지 않은 데이터에 비해 쿼리 성능이 10% 향상되었습니다. 처음에는 파티셔닝을 시도했습니다. event-name 성능을 최적화하기 위해 노력했지만 이 접근 방식을 사용하면 Amazon S3에 대한 쓰기 시간이 늘어났습니다. 정렬을 통해 수집 오버헤드 없이 쿼리 시간이 개선되는 것으로 나타났습니다.

쿼리 최적화 및 병렬 쿼리

팀은 병렬 쿼리를 실행하면 성능이 더욱 향상될 수 있다는 사실을 발견했습니다. 긴 시간 동안 단일 쿼리를 실행하는 대신 더 짧은 시간 동안 여러 쿼리를 실행했습니다. 이로 인해 솔루션의 복잡성이 증가했음에도 불구하고 평균적으로 약 20% 정도 성능이 향상되었습니다.

예를 들어, 사용자가 앱의 예상 크기를 요청하는 시나리오를 생각해 보세요. com.demo 그리고 이벤트 af_purchase 2024년 2024월부터 3년 60월 말 사이(앞서 설명한 것처럼 분할은 사용자에 의해 정의된 다음 원자 리프로 변환된 다음 날짜 범위에 따라 여러 쿼리로 분류됩니다). 다음 다이어그램은 초기 XNUMX개월 쿼리를 최대 XNUMX일짜리 쿼리 두 개로 나누어 동시에 실행한 후 결과를 병합하는 프로세스를 보여줍니다.

결과 세트 크기 줄이기

성능 병목 현상을 분석하고, 쿼리의 다양한 유형과 속성을 검사하고, 쿼리 실행의 다양한 단계를 분석하는 과정에서 특정 쿼리가 쿼리 결과를 가져오는 속도가 느리다는 것이 분명해졌습니다. 이 문제는 실제 쿼리 실행에서 발생하는 것이 아니라 Amazon S3에서 데이터를 전송하는 동안 발생합니다. 쿼리결과 가져오기 많은 수의 행이 포함된 쿼리 결과로 인해 단계가 발생했습니다(단일 결과에 수백만 개의 행이 포함될 수 있음).

단일 스케치에서 여러 키-값 순열을 처리하는 초기 접근 방식에서는 행 수가 상당히 늘어났습니다. 이를 극복하기 위해 팀에서는 새로운 방법을 도입했습니다. event-attr-key 필드를 사용하여 스케치를 고유한 키-값 쌍으로 분리합니다.

최종 스키마는 다음과 같습니다.

이 리팩토링으로 인해 결과 행이 대폭 줄어들어 작업 속도가 크게 빨라졌습니다. GetQueryResults 프로세스를 통해 전체 쿼리 런타임이 90%까지 눈에 띄게 향상되었습니다.

Athena 쿼리 결과 재사용

사용자가 필터를 조정하거나 기간을 약간 변경하는 등 쿼리를 미묘하게 조정하는 경우가 많은 Audiences Segmentation GUI의 일반적인 사용 사례를 해결하기 위해 팀은 Athena를 사용했습니다. 쿼리 결과 재사용 특징. 이 기능은 이전 쿼리 결과를 캐싱하고 재사용하여 쿼리 성능을 향상시키고 비용을 절감합니다. 이 기능은 특히 날짜 범위 분할과 관련된 최근 개선 사항을 고려할 때 중추적인 역할을 합니다. 결과를 재사용하고 신속하게 검색하는 기능은 이러한 사소하지만 빈번한 수정에 더 이상 전체 쿼리 재처리가 필요하지 않음을 의미합니다.

그 결과, 반복되는 쿼리 실행의 지연 시간이 최대 80%까지 줄어들었고 더 빠른 통찰력을 제공하여 사용자 경험이 향상되었습니다. 이러한 최적화는 데이터 검색을 가속화할 뿐만 아니라 사소한 변경이 있을 때마다 데이터를 다시 검색할 필요가 없기 때문에 비용을 크게 절감합니다.

솔루션 출시: 테스트 및 모니터링

이 섹션에서는 테스트 및 모니터링을 포함하여 새로운 아키텍처를 출시하는 프로세스에 대해 설명합니다.

Amazon S3 속도 저하 오류 해결

솔루션 테스트 단계에서 팀은 새로 구현된 스키마 내에 구성된 데이터를 사용하여 시스템 내의 다양한 대상을 평가하도록 설계된 자동화 프로세스를 개발했습니다. 방법론에는 HBase에서 얻은 결과와 Athena에서 얻은 결과를 비교 분석하는 작업이 포함되었습니다.

이러한 테스트를 실행하는 동안 팀은 검색된 추정치의 정확성과 대기 시간 변화를 조사했습니다.

이 테스트 단계에서 팀은 한 번에 많은 동시 쿼리를 실행할 때 몇 가지 오류를 경험했습니다. 이러한 실패는 다음으로 인해 발생했습니다. Amazon S3 조절 동시 Athena 쿼리에서 생성된 동일한 접두사에 대한 GET 요청이 너무 많기 때문입니다.

제한(속도 저하 오류)을 처리하기 위해 팀에서는 지수 백오프 전략(동시 재시도를 방지하기 위해 무작위 오프셋으로 대기 시간이 기하급수적으로 증가함)을 사용하여 쿼리 실행을 위한 재시도 메커니즘을 추가했습니다.

출시 준비

처음에 팀은 비용에 민감한 접근 방식으로 1개월 간의 채우기 프로세스를 시작했으며 포괄적인 2년 채우기를 약속하기 전에 정확성 검증을 우선시했습니다.

채우기 프로세스에는 Spark 작업 실행이 포함되었습니다(write-events-estimation-sketches) 원하는 시간 범위에서. 작업은 데이터 웨어하우스에서 읽고, 데이터에서 스케치를 생성하고, 이를 팀이 정의한 특정 스키마의 파일에 썼습니다. 또한 팀에서는 파티션 프로젝션을 사용했기 때문에 파티션이 추가될 때마다 데이터 카탈로그를 업데이트하는 프로세스를 건너뛸 수 있었습니다.

이 단계별 접근 방식을 통해 전체 과거 데이터 세트를 진행하기 전에 솔루션의 정확성을 확인할 수 있었습니다.

초기 단계에서 달성된 정확성에 대한 확신을 바탕으로 팀은 되메우기 프로세스를 체계적으로 확장하여 전체 2년 기간을 포괄하여 철저하고 안정적인 구현을 보장했습니다.

업데이트된 솔루션이 공식 출시되기 전에 안정성을 보호하기 위해 강력한 모니터링 전략이 구현되었습니다. 쿼리 및 API 대기 시간, 오류율, API 가용성과 같은 중요한 측면을 평가하도록 주요 모니터가 구성되었습니다.

데이터가 Amazon S3에 Parquet 파일로 저장된 후 다음 롤아웃 프로세스가 설계되었습니다.

HBase 및 Athena 쓰기 프로세스를 모두 계속 실행하고, HBase에서 읽기를 중지하고, Athena에서 읽기를 시작합니다.
HBase에 쓰기를 중지합니다.
일몰 HBase.

Athena를 통한 개선 및 최적화

파티션 프로젝션과 최적화된 데이터 구조를 사용하여 HBase에서 Athena로 마이그레이션하면 쿼리 성능이 10% 향상되었을 뿐만 아니라 필요한 데이터 파티션만 스캔하여 전체 시스템 안정성이 크게 향상되었습니다. 또한 Athena를 통해 서버리스 모델로 전환함으로써 이전 설정에 비해 월별 비용이 80%나 절감되었습니다. 이는 인프라 관리 비용을 없애고 사용량에 따라 비용을 직접 조정함으로써 조직이 보다 효율적인 운영, 향상된 데이터 분석 및 우수한 비즈니스 결과를 얻을 수 있도록 하기 때문입니다.

다음 표에는 팀에서 구현한 개선 사항과 최적화가 요약되어 있습니다.

개선 분야	취한 조치	측정된 개선
Athena 파티션 프로젝션	파티션 수를 제한하지 않고 다수의 파티션에 걸쳐 파티션을 투영합니다. 분할 기준 `event_name` 및 `app_id`	쿼리 성능이 수백 퍼센트 향상되었습니다. 이는 솔루션을 실현할 수 있게 해주는 가장 중요한 개선이었습니다.
파티셔닝 및 정렬	파티셔닝 기준 `app_id` 그리고 정렬 `event_name` 일일 단위로	스케치 계산 작업이 100% 개선되었습니다. 쿼리 성능 지연 시간은 5%입니다.
시간 범위 쿼리	긴 시간 범위 쿼리를 병렬로 실행되는 여러 쿼리로 분할	쿼리 성능이 20% 향상되었습니다.
결과 세트 크기 줄이기	스키마 리팩토링	전체 쿼리 시간이 90% 향상되었습니다.
쿼리 결과 재사용	Athena 쿼리 결과 재사용 지원	주어진 시간에 쿼리가 두 번 이상 실행되어 80% 개선되었습니다.

결론

이 게시물에서는 Athena가 어떻게 AppsFlyer 오디언스 세분화 서비스의 주요 구성 요소가 되었는지 보여주었습니다. 데이터 병합, 파티션 투영, 스키마 재설계, 병렬 쿼리, 마루 파일 형식, 그리고 쿼리 결과 재사용.

우리의 경험이 Athena 기반 애플리케이션의 성능을 향상시키는 데 귀중한 통찰력을 제공하기를 바랍니다. 추가적으로 확인해 보시는 것을 추천드립니다. Athena 성능 모범 사례 추가 지침.

저자에 관하여

노파르 디아망트 현재 사기 방지에 중점을 두고 있는 AppsFlyer의 소프트웨어 팀 리더입니다. 이 영역에 뛰어들기 전에 그녀는 이 게시물의 주제인 AppsFlyer에서 리타겟팅 팀을 이끌었습니다. Nofar는 여가 시간에 스포츠를 즐기고 기술 분야의 여성들을 멘토링하는 데 열정을 쏟고 있습니다. 그녀는 엔지니어링 역할에서 여성의 존재감을 높이고 이들의 성공을 장려함으로써 업계의 성별 인구통계를 변화시키는 데 전념하고 있습니다.

마탄 사프리 AppsFlyer의 리타겟팅 팀에서 빅 데이터에 주력하는 백엔드 개발자입니다. AppsFlyer에 합류하기 전에 Matan은 IDF의 백엔드 개발자였으며 BGU 대학에서 컴퓨터를 전공하여 전기 공학 석사 과정을 마쳤습니다. 여가 시간에는 웨이브 서핑, 요가, 여행, 기타 연주를 즐깁니다.

마이클 펠츠 AWS의 수석 솔루션 아키텍트입니다. 그는 이 직위에서 주요 AWS 고객과 협력하여 혁신적인 클라우드 기반 솔루션 개발을 지원합니다. Michael은 효과적인 클라우드 아키텍처 구축과 관련된 창의성과 문제 해결을 즐깁니다. 또한 그는 SaaS, 분석 및 기타 도메인에 대한 광범위한 경험을 공유하여 고객이 클라우드 전문 지식을 향상시킬 수 있도록 지원하는 것을 좋아합니다.