Search

Amazon S3 Tables 개발팀에게 직접 묻다. (미공개 자료 포함)

Amazon S3 Tables 개발팀에게 직접 묻다. (미공개 자료 포함)

AWS re:Invent 2024 - Store tabular data at scale with Amazon S3 Tables (STG367-NEW) : 세션 영상 및 영상 요약

세션 중 QR코드로 소개된 문서

AWS 발표 문서 요약 정리

AWS S3 테이블: 분석 워크로드에 최적화된 새로운 스토리지 솔루션

AWS가 새롭게 선보인 Amazon S3 테이블은 분석 워크로드를 위해 최적화된 스토리지 솔루션입니다.
이 혁신적인 기능은 데이터 분석가와 엔지니어들에게 큰 이점을 제공할 것으로 기대됩니다.

S3 테이블의 주요 특징

1.
성능 향상: 자체 관리 테이블 스토리지와 비교하여 최대 3배 빠른 쿼리 성능과 초당 10배 더 많은 트랜잭션을 처리할 수 있습니다.
2.
Apache Iceberg 포맷 지원: 일일 구매 거래, 스트리밍 센서 데이터, 광고 노출 등의 테이블 형식 데이터를 Apache Iceberg 포맷으로 저장합니다.
3.
다양한 쿼리 엔진 호환: Amazon Athena, Amazon EMR, Apache Spark 등 인기 있는 쿼리 엔진과 쉽게 연동됩니다.

테이블 버킷, 테이블, 네임스페이스

테이블 버킷: S3의 세 번째 버킷 유형으로, 분석 웨어하우스 역할을 합니다.
테이블: 구조화된 데이터셋으로, 자동 관리 기능을 제공합니다.
네임스페이스: 테이블을 논리적으로 그룹화하는 데 사용됩니다.

자동 테이블 유지 관리

S3 테이블은 다음과 같은 유지 관리 작업을 자동으로 수행합니다:
1.
압축(Compaction): 작은 테이블 객체들을 더 큰 객체로 결합하여 쿼리 성능을 개선합니다.
2.
스냅샷 관리: 테이블 스냅샷의 수명주기를 관리합니다.
3.
참조되지 않는 파일 제거: 불필요한 객체를 자동으로 삭제합니다.

구현 및 사용

S3 테이블은 AWS CLI, AWS Management Console, API를 통해 생성하고 관리할 수 있습니다.
Apache Spark를 사용한 데이터 조작 예시도 제공됩니다.

주요 고려사항

AWS 통합: AWS Glue Data Catalog와의 통합은 현재 프리뷰 상태입니다.
보안: 모든 객체는 자동으로 암호화되며, 퍼블릭 액세스가 차단됩니다.
가용 지역: 현재 US East (Ohio, N. Virginia)와 US West (Oregon) 리전에서 사용 가능합니다.

결론

Amazon S3 테이블은 대규모 데이터 분석 워크로드를 위한 강력한 솔루션을 제공합니다.
자동화된 관리 기능과 향상된 성능으로 데이터 분석가들의 작업 효율성을 크게 개선할 것으로 기대됩니다.

참고) 실제 s3 테이블 버킷 사용자의 비용 비교

스토리지 비용

S3 Tables: 월 GB당 $0.0265
표준 S3: 월 GB당 $0.023
1TB 데이터 레이크의 경우, 두 옵션의 비용 차이는 미미합니다(월 약 $3 차이).

운영 비용

데이터 접근 및 유지보수 작업에 대해 1,000 요청당 $0.005의 비용이 발생합니다.

압축 비용

처리된 GB당 $0.05의 비용이 발생하며, 이는 고빈도 워크로드, 특히 실시간 사용 사례에서 상당히 누적될 수 있습니다.
고처리량 환경에서는 이 비용을 신중히 평가해야 합니다.

현실적인 가격 예시

전형적인 사용 시나리오를 통해 S3 Tables의 비용을 분석해보겠습니다.

시나리오 설정

데이터 수집: 일일 ETL 작업으로 1,000개의 작은 파일(각 5MB)과 3개의 메타데이터 파일(각 10KB) 작성
테이블 크기: 1TB 데이터, 평균 객체 크기 100MB로 최적화
쿼리: 월 500,000 GET 요청
압축: 쿼리 성능 최적화를 위한 자동 압축 활성화

US-West (Oregon)

지역 기준 월간 비용 분석:

1. 스토리지 비용

스토리지 요금: GB당 $0.0265
총 스토리지: 1TB = 1,024GB
비용: 1,024GB × $0.0265/GB = $27.14

2. 요청 비용

PUT 요청
(새 파일용)
일 1,003 파일 × 30일 = 30,090 요청
비용: 30,090 ÷ 1,000 × $0.005 = $0.15
GET 요청
(쿼리용)
월 500,000 요청
비용: 500,000 ÷ 1,000 × $0.0004 = $0.20

3. 모니터링 비용

모니터링 요금: 1,000 객체당 $0.025
객체 수: 1TB ÷ 100MB ≈ 10,240 객체
비용: 10,240 ÷ 1,000 × $0.025 = $0.26

4. 압축 비용

객체 처리
30,000개의 작은 파일 처리 (월간 생성)
비용: 30,000 ÷ 1,000 × $0.004 = $0.12
데이터 처리
30,000 파일 × 5MB = 150GB 데이터 처리
비용: 150GB × $0.05 = $7.50

총 월간 비용

$27.14 (스토리지) + $0.15 (PUT) + $0.20 (GET) + $0.26 (모니터링) + $0.12 (압축 객체) + $7.50 (압축 데이터) = $35.37

결론

중간 규모의 데이터를 다루는 배치 작업을 실행하는 팀에게 S3 Tables는 경쟁력 있는 가격을 제공합니다.
1TB에 대해 월 $35.37 의 비용은 자동화된 유지보수와 성능 향상의 가치에 비하면 무시할 만한 수준입니다.
그러나 고빈도 실시간 워크로드의 경우 다음과 같은 이유로 상당한 비용이 발생할 수 있습니다:
빈번한 PUT/GET 요청
작고 빈번한 쓰기에 대한 높은 압축 요구사항
예를 들어, 압축이 필요한 월 1PB 처리 파이프라인의 경우 데이터 처리 비용만으로 일 약 $60,000 이 발생할 수 있습니다.
실시간 시나리오에서는 쓰기 일괄 처리나 파일 크기 최적화 등의 대안적 비용 전략이 필요할 수 있습니다.

TL;DR

기술 동작 방식 : S3 Inteligent Tiering과 같은 Monitoring 기반
장점
기본 S3 버킷대비 3x 쿼리 성능, 10x TPS 향상
Managed 가능
1.
Compaction
2.
Missing(Orphan) File removing
3.
Snapshot Management
S3만 단독 사용해도 되는 경우 보다 비용 효율적으로 사용가능
비용 관점에서 서비스팀 리서치 결과 최대 30% 비용 절감 효과 확인
Amazon S3 Tables Catalog 는 오픈소스로 제공
현재 시점 단점
1.
US 3개 리전만 지원
2.
S3 Table용 별도 Tiering (≥ S3 Standard Tier) 만 사용 가능
3.
Branch, Tag의 Retain 적용 불가
4.
S3외 AWS 기능과 연결하려면 Amazon S3 Tables Catalog 단독으로는 사용불가
5.
기존 버킷에서 S3 Table 버킷으로 전환 불가
6.
Amazon S3 Tables Catalog 는 SDK(JAR)로만 제공
로드맵
global 리전으로 확장
Glue Catalog 없이 AWS 서비스와 결합
S3 Inteligent Tiering과 결합
Branch, Tag의 Retain 적용
API 및 Python Library 제공 예정
우선 AWS S3 서비스(개발)팀을 만나러 갔을때, 모두 Amazon S3 Tables에 대한 자료가 아래 올라온 자료 하나였기 때문에,
모두 궁금증을 가지고 있었고 관련 세션들도 거의 모든 세션들이 끝난 시점이었기에 현장에서 물어보는 방법 밖에 없었습니다.
일단 Product Manger를 만나 물어보니 가장 중점을 둔 부분은 내부적으로 확인한 결과 30% 비용 축소인 부분 이었습니다.
물론 이또한 S3 Inteligent Tiering과 같이 상당한 비용 절감은 본 케이스와 아닌 케이스가 갈리듯, 평소 관리가 잘된 운영 환경이라면 드라마틱하지는 않겠으나,
관리비용 까지 포함한다면 충분히 사용 고려할 만한 요소로 판단됩니다.
또한 기술적인 비하인드가 어디에도 드러나지 않아, 문의하니 방식은 S3 Inteligent Tiering 처럼 뒤에 Object들에 대한 Monitoring이 수행되는 구조이며,
S3 Inteligent Tiering은 Object의 Access 중심으로 Tier를 구별했다면, S3 Table Bucket의 경우 Iceberg Meta 데이터를 기준으로 Object를 처리한다고 합니다.
대략적인 내용은 위의 상당히 긴 TL;DR을 참조하시면 됩니다.