BLOG
최근에 뵌 한 고객분이 S3 Standard, S3 Infrequent-Access, S3 One-Zone Infrequent-Access와 같은 다양한 Amazon S3 스토리지 클래스의 이점에 대해 잘 설명하였지만 어떤 티어와 라이프사이클 규칙을 적용해야 하는지에 대해선 확실하게 알고 있지 못하였습니다. 이 고객분과 같은 다른 여러 고객분들 또한 여러 개의 버킷과 다양한 데이터 액세스 패턴을 가지고 있습니다. AWS는 S3 Analytics 리포트를 사용하여 최적의 라이프사이클 정책을 쉽게 결정할 수 있도록 협업하기로 했습니다.
하여 오늘은 AWS가 그간 고객과 일하며 깨달은 것들을 공유해 드리며, analytics 리포트를 보다 쉽게 점검할 수 있는 기술에 대해 설명을 드리는 시간을 가져볼까 합니다.
2016년 11월 Amazon S3 Analytics가 출시되었을 때 사용자는 스토리지 액세스 패턴과 올바른 데이터를 올바른 스토리지 클래스로 전환할 수 있게 되었습니다. 비즈니스 intelligence 툴을 사용하여 데이터를 S3 버킷으로 수동으로 내보내고 사용량과 growth 패턴에 따라 심층적인 insight를 수집할 수도 있었습니다. 이를 통해 스토리지의 비용을 줄이고 사용 성능 패턴을 최적화 할 수 있게 되었습니다.
다음으로 2017년 11월 출시된Amazon QuickSight는 S3 console에서 몇 번의 클릭으로 QuickSight를 사용하면 지정된 S3 버킷에 대한 S3분석을 시각화할 수 있었습니다. 또한 ‘수동으로 내보내기’ 또는 ‘추가 데이터 준비’ 없이 수행이 가능했습니다
그렇다면 이번엔 분석 리포트를 검토하는 전혀 다른 방법에 대해 다루어 보겠습니다. 이 방법은 serverless 쿼리 서비스인 Amazon Athena와 완전 관리형 ETL(추출, 변환, 로드) 데이터 카달로그 서비스인 AWS Glue를 사용합니다. 이러한 서비스는 QuickSight 또는 다른 데이터 베이스 엔진에 로드할 필요 없이 S3 Analytics 리포트에 직접 SQL 쿼리를 실행하는 데 사용됩니다.
이를 통해 모든 버킷에서 한번에 스토리지 클래스 비용 절감을 쉽고 빠르게 할 수 있습니다.
또한 이 방법은 Amazon S3 또는 개별적으로 QuickSight 리포트에 연결하여 검사하는 것보다 훨씬 효율적입니다.
Architecture
아래의 그림은 우리가 구축할 architecture의 개요입니다.
분석하고자 하는 각 Amazon S3 소스 버킷을 구성하여 S3 Analytics 보고서[1]를 중앙 Amazon S3 보고 버킷[2]에 CSV 파일로 전달합니다.
Analytics 리포트가 버킷으로 전달되면 S3 Event Notification이 AWS Glue Crawler[3]을 통하여 AWS Glue Catalog[4] 내의 단일 논리 분석 테이블에 새로운 파티션으로 연결됩니다.
다음으로, 사용자나 애플리케이션은 Amazon Athena에게 SQL 쿼리를 제출합니다[5]. Amazon Athena는 AWS Glue 카탈로그[6]를 사용하여 Amazon S3에서 읽어야 하는 파일을 확인한 다음 쿼리를 실행합니다[7].
아래 가이드에 따라 수동으로 이 정보를 생성해 보십시오. AWS Glue 카탈로그의 데이터베이스 및 테이블 정의와 같은 다른 구성 요소는 코드 서비스로서의 자동화된 인프라인 AWS CloudFormation을 사용하여 생성됩니다.
전제 조건
이 가이드는 Amazon S3 그리고 S3 Analytics 리포트를 생성할 수 있는 한 개 또는 그 이상의 버킷 소스가 있다고 가정합니다. 이 S3에는 이러한 리포터를 전달할 리포트 버킷이 한 개 이상 있어야 합니다. 가지고 있는 버킷이 리포팅 버킷 이여도 괜찮습니다. 단 버킷 소스가 버킷과 동일한 region에 있어야 합니다.
1단계: S3 Analytics 활성화
첫 번째로, 소스 버킷에서 S3 analytics를 활성화 하고 각 리포트가 동일 같은 버킷 및 prefix에 전달되어야 합니다. 이 작업을 수행하는 이유는 AWS Glue crawlers가 일치하는 schemas를 사용하여 동일한 장소의 객체를 Glue Data Catalog에 단일 logical 테이블로 취급할 수 있기 때문입니다.
분석하려는 각각의 소스 버킷에 대하여 How Do I Configure Storage Class Analysis의 가이드를 에 따라 단계별로 진행하십시오.
- Destination bucket을 출력할 수 있도록 버킷을 구성하십시오
- Destination prefix를 값으로 구성하십시오 s3_analytics/bucket=SOURCE_BUCKET.
대상 prefix내 s3_analytics/ 부분은 적어도 하나의 폴더가 있는 한, 부분의 원하는 폴더 또는 시리즈 폴더 일 수 있습니다. bucket=SOURCE_BUCKET 부분은 AWS Glue가 리포트를 올바르게 crawl 하기 위한 요구 사항 입니다. 예를 들어, 만약 weberm-application-data 의 이름을 가진 버킷에게 S3 Analytics를 활성화 하고 werberm-reports 버킷에 리포트를 보내려는 경우 analytics configuration은 다음과 같습니다.
만약 S3 웹 콘솔을 사용하여 S3 Analytics를 구성하는 경우 버킷 정책에 따라 소스 버킷이 리포트를 전달할 수 있도록 자동으로 구성 됩니다. CloudFormation, CLI 또는 SDK방식을 사용하는 경우 적절한 버킷 정책을 구성해야 합니다. 정책에 대한 예제를 보시려면 ‘Click here for an example policy.‘페이지를 확인해 주십시오.
S3 Analytics 보고서는 매일 전달되며 최대 24시간이 걸릴 수도 있습니다. 일단 전달된 후에는 s3://your_report_bucket/s3_analytics/ 폴더의 내용은 아래와 같을 것입니다.
위의 각 폴더에는 Amazon S3 Analytics 리포트가 포함된 single CSV 파일이 표기될 것입니다.
이러한 파일 중 하나를 다운받아 실행 한다면, analytics 리포트가 포함된 것을 볼 수 있을 것입니다. 아래에 예제를 참고하십시오. (참고:모든 행,열 을 표기하지 않음)
2단계: AWS Glue를 사용하여 Crawl(크롤링) 및 Catalog(카탈로그)
추가적으로 완전하게 관리되는 서버리스인 Apache Spark ETL 작업은 AWS Glue Apache Hive Metastore 호환 데이터 카탈로그를 제공합니다. S3의 데이터가 카탈로그에 추가되었을 때, Amazon Athena(Amazon EMR 및 Amazon Redshift Spectrum을 포함한 다른 여러 AWS 서비스)를 사용하여 쿼리를 사용할 수 있습니다.
S3 Analytics 리포트 용으로 미리 정의된 Glue 데이터 베이스와 테이블을 포함한 us-east-1에 CloudFormation 스택을 실행하시려면 ‘이 링크’를 클릭해 주십시오. 스택은 곧 크롤러를 포함하여 각각의 새로운 S3 Analytics 리포트를 자동으로 카탈로그화하여 카탈로그 테이블에 파티션으로 추가될 것입니다.
만약 data lakes를 쉽게 설정, 보호 관리하는 AWS Lake Formation을 사용한다면, 위의 스택은 실패할 수 있습니다. 이는 data lakes 권한을 구성한 방법에 따라 다릅니다. 특히 S3AnalyticsDatabase 스택 리소스를 생성할 때, Insufficient Lake Formation Permission: data lake permissions(불충분한 Lake 권한: data lake 권한 부여 필요) 권한 필요 오류가 표시되면 Lake Formation 관리자는 AWS Lake Formation 카탈로그에서 새로운 데이터베이스를 생성할 수 있도록 권한을 부여해야 합니다. 다음에는, CloudFormation 스택을 배치할 수 있어야 합니다. AWS Lake Formation 그리고 AWS Glue 권한 모델에 관련하여 해당 링크에서 자세하게 확인할 수 있습니다.
3단계: S3 Analytics 리포트 쿼리
Amazon Athena 콘솔을 실행 한 뒤에 좌측 상단의 드롭 다운 박스에서 s3_analytics 데이터베이스를 찾아 클릭하십시오.
AWS Glue 크롤러가 Amazon S3 analytics 리포트와 Glue 카탈로그를 업데이트 하였는지 확인해 줍니다.
>>> Show partitions s3_analytics_report;
소스 버킷 이름이 테이블 파티션으로 표기되는 경우, analytics 리포트가 아래와 같이 성공적으로 카탈로그화 됩니다.
(이미지 6)
기본 SQL을 사용하여 Analytics 리포트를 쿼리할 수 있습니다. 아래의 예시를 참고해 주십시오.
SQL
SELECT bucket, *
FROM s3_analytics
WHERE object_count IS NOT NULL
ORDER BY storage_mb DESC
Amazon Athena 의 예시 결과는 아래와 같습니다.
(이미지 7)
Amazon S3 Analytics 분석 자동화.
위에서 우리는 Athena 웹 콘솔에서 S3 Analytics 데이터에 대해 Amazon Athena SQL 쿼리를 실행하는 방법을 보여주었습니다. 그러나, S3 스토리지 계층 권장 사항이 있는 경우 infrastructure 팀에게 알려주어 스토리지 비용을 절감하는 등 S3 Analytics에 대한 검토 및 응답을 자동화하고 싶어하실 수도 있습니다. 이는 오늘의 주제엔 약간 벗어난 내용이지만 Amazon Athena’s AWS CLI and SDK query capability 기능을 활용하여 해결할 수 있습니다.
Amazon S3 Intelligent Tiering
오늘 블로그 포스팅에선 Amazon S3 Analytics에 초점을 맞추고 있지만, S3가 S3 Intelligent-Tiering(2018년 11월 출시됨)를 제공한다는 점에 주목할 필요가 있습니다. Amazon S3 Intelligent-Tiering은 고객을 위해 출시되었으며 데이터 액세스 패턴이 변경되었을 때 스토리지 비용을 자동으로 최적화하며, 추가적인 성능 임팩트관련 오버헤드가 없습니다. S3 Intelligent-Tiering은 객체를 두 개의 액세스 계층, 즉 빈번한 액세스를 위해 최적화된 계층과 자주 사용하지 않는 액세스를 위해 최적화된 다른 저가(저비용) 계층에 저장합니다.
S3 Intelligent-Tiering은 개체당 작은 월별 모니터링 및 자동화 비용으로 액세스 패턴을 연속 30일 동안 모니터링 하고 이때 액세스하지 않은 개체를 드문 액세스 계층으로 이동시킵니다. S3 Intelligent-Tiering에는 retrieval 비용이 발생하지 않습니다. 드문 액세스 계층의 개체에 나중에 액세스한다면 자동으로 자주 액세스하는 계층으로 이동이 될 것입니다. S3 Intelligent-Tiering에 대한 자세한 내용은 해당 페이지(here)를 참고해 주십시오.
++
비용 및 삭제처리
오늘 보여드린 데모 architecture를 작성하시게 되면 서비스 사용요금이 조금 부과될 것입니다. 예를 들어 지금 글을 쓰는 시점에서 Amazon S3 Analytics는 매월 모니터링 되는 객체 당 $0.10을 청구합니다. 최신 비용에 대한 정보는 다음의 링크들을 클릭하시어 확인해 주십시오. à Amazon S3, Amazon Athena, AWS Glue.
비용 발생을 막기 위해서는 다음 단계들을 통해 삭제처리를 하셔야 합니다.
- 활성화한 버킷에 대하여 Amazon S3 Analytics 리포트를 비활성화 하십시오.
- 중앙 Amazon S3 리포트 버킷으로 전달된 Analytics 리포트를 삭제하십시오.
- 데모 AWS CloudFormation 스택을 삭제하여 AWS Glue 리소스를 삭제하십시오.
글을 마치며…
지금까지 AWS Glue를 사용하여 S3 Analytics 리포트를 단일 logical 테이블로 카탈로그화 하는 방법에 대해 설명해 드렸습니다. 더불어 Amazon Athena를 사용하여 해당 테이블에서 SQL 쿼리를 쉽게 실행하는 방법에 대해서도 알아보았습니다. 이를 통해 사용자는 스토리지 비용을 최소화하며 성능을 최적화 할 수 있는 방법에 도움을 받을 수 있게 됩니다.
원문 URL: https://aws.amazon.com/ko/blogs/storage/query-amazon-s3-analytics-data-with-amazon-athena/
** 메가존 클라우드 TechBlog는 AWS BLOG 영문 게재 글 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 개제하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달드리도록 하겠습니다.