BLOG
Pagely는 관리된 WordPress 호스팅 서비스를 제공하는 AWS 고급 기술 파트너입니다. 고객은 사용, 빌링 및 서비스 성능을 지속적으로 향상시키기 위해 노력하고 있습니다. 이러한 고객에게 더 나은 서비스를 제공하기 위해 서비스 팀은 응용 프로그램 서버에 의해 생성된 로그에 엑세스 할 수 있는 더 효율적인 방법을 필요로 합니다.
역사적으로 저희는 요구에 따라 기본적인 통계를 수집한 쉘 스크립트를 이용했습니다. 가장 큰 고객의 로그를 처리 할 때 Amazon EC2 인스턴스에서 실행되는 최적화 되지 않은 프로세스를 사용하여 단 하나의 보고서를 작성하는데 8시간 이상 걸렸습니다. 리소스 제한에 의해 중단되는 경우가 간혹 있었습니다. 레거시 프로레스를 수정하는 데 더 많은 노력을 기울이지 않고 적절한 분석플랫폼을 구현할 때가 되었다고 생각을 했습니다.
고객 로그는 모두 Amazon S3에 압축 JSON 파일로 저장됩니다. 저희는 Amazon Athena를 이용하여 이러한 로그에 대해 SQL 쿼리를 직접 실행합니다. 이 방법은 데이터를 준비할 필요가 없기 때문에 우수한 방법입니다. 저희는 단지 테이블 및 쿼리를 정의하기만 하면 됩니다. JSON은 Amazon Athena에서 지원되는 포맷이지만, 성능 및 비용 면에서 가장 효율적인 포맷은 아닙니다. JSON 파일은 데이터의 각 행에서 하나 또는 두 개의 필드만 반환하는 경우에도 전체적으로 읽기 때문에 필요한 것보다 많은 데이터를 검색합니다. 또한, JSON을 처리하는 것이 효율적이지 않기 때문에 쿼리시간은 더 길어집니다.
최대 규모인 고객의 로그를 조회하는 것은 Athena에서는 이상적이지 않습니다. 30분 쿼리시간이 만료되기 때문입니다. 이 제한을 늘릴 순 있지만, 이미 쿼리는 필요이상의 시간이 소요되었습니다.
이 글에서는 ‘AWS Advanced Consulting 파트너’인 Beyondsoft가 개발한 오픈소스 툴인 ConvergDB를 사용하여 Devops 중심의 데이터 파이프라인을 구축하기 위해 Pagely가 Beyondsoft와 어떻게 협력을 했는지 보여줄 것입니다. 이 파이프라인은 어플리케이션 로그를 Amazon Athena를 사용하여 신속하고 비용 면에서도 효과적으로 쿼리 할 수 있는 최적화된 테이블로 변환하기 위하여 AWS Glue를 사용합니다.
매력적인 Beyondsoft
저희는 엔지니어들이 가능한 한 오버헤드 없이 쉽게 데이터에 액세스할 수 있도록 하기 위해 무언가를 해야 한다는 것을 알고 있었습니다. 쿼리 시간을 줄이기 위해 데이터를 최적의 파일 형식으로 만들고 싶었습니다. 저희는 작은 가게였기 때문에 기술을 자세히 살펴볼 대역폭이 없었습니다. 이러한 격차를 해소하기 위해 저희는 Beyondsoft와 협력하여 데이터 레이크를 최적화하고 보다 효과적으로 관리할 수 있는 최고의 솔루션을 결정합니다.
ConvergDB란?
ConvergDB는 데이터 레이크를 생성하고 이를 관리하기 위한 오픈소스 소프트웨어입니다. 사용자는 원본 및 대상 테이블의 구조를 정의하고 이를 구체적인 클라우드 리소스에 매핑합니다. 그 후, ConvergDB는 AWS에서 필요한 자원을 구축하고 관리하는데 사용된 모든 스크립트를 생성합니다. ConvergDB에서 만든 스크립트는 인프라를 코드로 관리하기 위한 오픈소스 툴인 HashiCorp Terraform의 사용을 통해서 배포됩니다.
ConvergDB를 사용하여 저희는 테이블 생성과 ETL(추출, 변화, 로드)프로세스를 구동하는 메타데이터로 데이터 레이크를 정의할 수 있습니다. 스키마 파일은 로드되는 순간 들어오는 데이터를 변환할 때 사용되는 필드 레벨의 SQL 표현식을 포함하는 테이블의 정의에 사용됩니다. 이 수식은 데이터 파티션에 사용되는 필드 외에도, 계산 필드를 도출하는 데 사용됩니다.
스키마가 정의되면 배치 파일을 사용하여 테이블을 관리하는 데 사용되는 ETL작업에 테이블을 배치 할 수 있습니다. ETL작업 일정은 배치파일에서 구체화되며 런타임에 사용하는 대상 S3 버킷과 AWS Glue DPU의 숫자와 같은 옵션필드에서 지정합니다.
ConvergDB는 명령줄 바이너리이며, 서버에 설치할 필요가 없습니다. 모든 아티팩트는 소스 제어를 사용하여 관리 할 수 있는 파일입니다. ConvergDB 바이너리는 모든 구성 파일을 가져와 데이터 레이크의 배포에 필요한 모든 아티팩트를 포함하는 Terraform 구성을 출력합니다. 이러한 아티팩트는 ETL 스크립트, 테이블 및 데이터베이스 정의 및 작업을 수행하는 데 필요한 IAM 정책이 될 수 있습니다. 또한 Amazon SNS 알림 주제와 ConvergDB ETL 작업에 의해 처리되는 데이터의 양을 나타내는 Amazon CloudWatch 대시 보드도 포함되어 있습니다.
스피드범프(고비 & 해결책)
완벽한 구현은 없습니다. 다음 섹션에서 Beyondsoft 엔지니어인 Jeremy Winters는 저희가 직면한 문제와 해결 방법에 대해 설명합니다.
분할 및 컬럼 형식
Amazon S3에서 SQL 분석 쿼리의 데이터를 구조화하기 위한 주요 모범 사례 중 2 가지는 분할 및 컬럼형 파일 구조입니다.
분할 은 데이터를 효율적으로 검색하는데 가장 적합한 명명 규칙에서 S3의 다른 접두사 또는 폴더에 데이터를 분할하는 프로세스입니다. 그러면 Athena는 실행중인 특정 쿼리에 관련되지 않은 데이터를 스킵 할 수 있습니다.
Apache Parquet은 Hadoop 에코 시스템에서 인기 있는 툴의 컬럼 형식입니다. Parquet 데이터의 열을 파일에서 별도의 연속된 리전에 저장합니다. Athena와 같은 툴은 메타데이터 푸터에 의해 지시되며 쿼리를 수행하는 데 필요한 파일 섹션만 읽습니다. 이 프로세스는 I / O 및 네트워크 데이터 전송의 많은 부분을 제거하는 데 도움이 됩니다.
분할과 Parquet 파일에 의한 I / O 절감은 쿼리 성능을 향상시킬 뿐만 아니라 Athena의 사용 비용을 크게 줄일 수 있습니다.
데이터 레이크 최적화 모범 사례에 대한 자세한 내용은 블로그 게시물의 Amazon Athena의 상위 10가지 성능 튜닝 팁을 참조하십시오.
작은 파일의 문제
Hadoop 에코 시스템 툴에서 발생하는 고전적인 문제를 “작은 파일 문제”라고 합니다. 다수의 작은 파일을 처리하는 시스템의 오버 헤드가 커지고 작업 실행 시간이 급증하면 잠재적으로 실패 할 수 있습니다. Pagely는 3 천만 개의 파일에 약 4TB의 기록을 남겼습니다. 이 파일 중 2,950 만 개가 S3의 1.2TB에 불과했습니다.
이 문제를 분석하기 위해 원본 데이터 버킷에 관한 S3 인벤토리 보고서를 사용했습니다. 이 보고서는 매일 ORC (최적화된 행의 열) 형식으로 제공됩니다. 여기에서 SQL을 사용하여 버킷의 내용을 분석하는 Athena 테이블을 만드는 것은 매우 간단합니다.
Athena를 사용하여 “핫스팟”인 즉, 작은 파일 수가 많은 S3 접두사를 식별했습니다. 저희는 1GB 미만의 데이터로 14,000 개의 접두사를 통합할 수 있다는 것을 발견하였습니다. 그래서 2,950 만 개의 파일이 14,000 개의 파일로 통합되었습니다.
다음 쿼리는 작은 파일 핫스팟을 식별하는 방법입니다. GROUP BY 표현식은 데이터에 적합 할 수 있습니다. 이 예는 버킷의 첫 번째 “폴더”별로 그룹화하는 방법을 보여줍니다.
SELECT
— we are looking at the first string in a / delimited path
— if the key is path/2017-10-10.json it will group on path_to_data
split_part(key,’/’,1) AS prefix
— calculate the total size in mb for all files in prefix
,SUM(size)/CAST(1024*1024 AS DOUBLE) AS mb
— count of objects in the prefix
,COUNT(*) AS object_count
FROM
pagely_gateway_logs
WHERE
— assumes that versioning is disabled
— you should use the latest date after
— refreshing all partitions
dt = ‘2018-03-28-08-00’
GROUP BY
1
HAVING
— only return prefixes with a total size of less than 1 gb
— and a file count greater than 8
SUM(size)/CAST(1024*1024 AS DOUBLE) < 1024
AND
COUNT(*) >= 8
결과는 통합 될 수 있고 결합되어야 하는 개체 경로의 접두사를 보여줍니다. 8개 이상의 파일을 포함한 1GB 미만의 파일은 원본을 대체하여 단일 개체로 통합 될 수 있습니다.
핫스팟이 확인되면 작은 파일을 통합해야 합니다. 위 이미지의 결과는 접두사가 14184 인 파일이 총 502의 파일에 33.7MB로 퍼져 있음을 보여줍니다. 이 많은 작은 파일의 오버 헤드를 줄이기 위해 모든 파일을 하나의 파일로 결합합니다. 우리 파일은 gzip 압축을 사용하고 있습니다. 압축을 풀고, 원본 JSON 데이터를 연결한 다음 재압축하는 것과는 달리 간단한 연결을 통해 결합 할 수 있습니다. Linux cat 명령과 같은 여러 가지 방법으로 이를 수행 할 수 있습니다. 이 명령은 다음 예제와 같습니다.
$ ls -1
14184_file1.gz
14184_file2.gz
14184_file3.gz
$ cat *.gz > combined.gz
$ gzip -d combined.gz
gzip 파일에서 명령을 실행하고 파일을 압축을 푸는 -d 플래그를 사용하여 결과 파일이 유효한 gzip임을 테스트합니다. 일부 사례의 경우, Amazon S3 Multipart Copy API를 사용할 수 있지만, 이 방법은 작은 파일 크기가 적어도 5 MB 이어야 합니다.
Pagely 데이터셋의 경우, 주어진 접두사가 있는 모든 파일을 다운로드 한 후, 단일 gzip에 연결하고 연결된 파일을 업로드한 후, 업로드의 유효성을 검사하여 작은 파일을 삭제하는 쉘 스크립트를 작성했습니다. 이 스크립트는 AWS Fargate 컨테이너를 사용하여 실행되었으며 각각 하나의 접두사를 처리합니다. 이 프로세스의 세부사항은 블로그 게시물이지만 AWS Batch와 같은 서비스를 사용하면 더 쉽게 이를 관리할 수 있습니다. 작은 기록 파일을 연결하는 총 비용은 $27입니다.
과거 데이터
Pagely 로그의 일별 데이터 볼륨은 하루에 수십 기가 바이트이며, 가장 작은 AWS Glue 설정으로 쉽게 처리를 할 수 있습니다. 압축된 (~ 28 TB의 압축되지 않은) 기록 데이터를 4 TB 변환하는 것은 좀 더 어려운 작업이었습니다.
ConvergDB는 데이터를 더 작은 단위로 일괄 처리합니다. 오래 실행된 내역의 변환작업이 실패한 경우, 마지막 배치만 손실되므로 약 1시간의 시간이 손실됩니다. ConvergDB는 자체 상태 추적 매커니즘을 사용하여 장애 발생을 작업의 다음 실행으로 전달합니다. 이 메커니즘은 배치를 다시 처리하기 전에 모든 혼란을 해결합니다. 일괄 처리는 AWS Glue 클러스터의 크기에 따라 ConvergDB 의해 생성되는 ETL 작업의 자동 기능입니다.
Pagely의 사후 배포
중간규모의 애플리케이션(S3에서 수 기가 바이트)이 레거시 보고서를 실행하는 경우 91초가 소요됩니다. 데이터 레이크가 생산된 경우 중간규모의 애플리케이션의 같은 보고서를 Athena에서는 5초가 소요되며, 18배의 성능이 됩니다. 최대 데이터셋 (S3 내의 ~1TB)는 레거시 프로세스로는 실패하게 됩니다. 또한 Athena를 사용하여 기존의 JSON을 직접 쿼리하는 경우에도 충분한 성능을 얻을 수 없습니다. 그러나, Athena을 사용한 새로운 Parquet 기반의 테이블은 24초만에 분석이 완료됩니다.
| Legacy process | Athena with JSON | Athena with Parquet | |
| Medium customer | 1 minute, 31 seconds | 1 minute | 6 seconds |
| Largest customer | > 8 hours | > 30 minutes | 24 seconds |
이런 수치는 분명 중요하지만, 가장 큰 장점은 성능과 비용을 걱정할 필요가 없이 엔지니어는 문제해결에만 집중할 수 있는 것입니다. 쿼리를 작성하는데 단 15분이 소요되며 팀 전체가 새로운 데이터에 액세스 할 수 있습니다. AWS SDK를 통해 Athena에 전송된 쿼리로 사용하여 기존 프로세스를 업그레이드 할 수 있습니다. 이 프로세스는 현재 제 노트북과 같은 경량 컴퓨터에서 실행할 수 있으며 Athena는 무거운 작업을 수행합니다.
원문 URL: https://aws.amazon.com/ko/blogs/big-data/how-pagely-implemented-a-serverless-data-lake-in-aws-to-facilitate-customer-support-analytics/
** 메가존클라우드 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.