AWS 기술 블로그
AWS Lambda와 PyIceberg 로 Amazon S3 Tables 시작하기
2024년 AWS re:Invent에서 Amazon S3 Tables가 새롭게 공개되었습니다. S3 Tables는 Amazon S3에 Apache Iceberg 형식의 테이블을 관리할 수 있는 완전 관리형 기능으로, 데이터 레이크 테이블 관리의 복잡성을 크게 줄여줍니다.
Iceberg를 통해 S3에 저장된 데이터를 마치 데이터베이스 테이블처럼 다룰 수 있으며, Athena, EMR(Spark), Redshift, Glue 등 다양한 분석 엔진과 통합됩니다. 특히 S3 Tables를 활용하면 자체 관리하는 Iceberg 대비 쿼리 성능이 최대 3배 향상되고, 초당 트랜잭션 처리량은 10배까지 증가하여 고빈도 업데이트 및 실시간 데이터 삽입에 유리합니다. 이러한 개선 덕분에 데이터 INSERT(입력)와 SELECT(조회) 작업 모두에서 높은 성능과 확장성을 기대할 수 있습니다.
여기서 INSERT(입력)와 SELECT(조회) 작업에 집중해보면 AWS 분석 서비스 중, Athena, EMR(Spark), Redshift, Glue를 통해서 두 작업이 가능하고 Firehose 통해서 데이터 INSERT(입력) 작업이 가능합니다.
이때, 아래와 같은 요구사항을 충족시키기 위하여 AWS Lambda를 활용하여 Amazon S3 Tables에 데이터 INSERT(입력)와 SELECT(조회) 등의 작업이 필요해질 수 있습니다.
- 이벤트 기반 마이크로 적재, 조회
- 실시간 데이터 추가 및 조회
- 자동 스케일링 통한 동시 처리
이러한 요구사항을 위하여 해당 포스팅에서는 AWS Lambda로 Amazon S3 Tables에 데이터 INSERT(입력)을 가이드합니다. 핵심은 AWS Lambda에 PyIceberg를 올려서 사용할 수 있음을 확인해보고 이를 통해 워크로드에 따라 운영 및 비용 효율적으로 S3 Tables에 대하여 DDL 뿐만아니라 DML 작업을 AWS Lambda를 통해 수행할 수 있음을 확인해 봅니다.
➕ 포스팅 하단에 “Amazon S3 Tables INSERT 및 SELECT 기준 서버리스 서비스별 비교표”를 작성해두었습니다. S3 Tables와 호환되는 다양한 서비스를 비교해보고 워크로드에 최적인 것을 선택해주세요.
1. S3 Tables 기반 Iceberg 테이블 구성
- 테이블 버킷(Table Bucket) 및 네임스페이스(Namespace) 생성
- Amazon S3 콘솔의 메뉴에서 [Table buckets]를 선택합니다.
- [Create table bucket]을 클릭하고 버킷명을 입력하고 생성 합니다.
- 만약, Table buckets에서 [Integration with AWS analytics services]가 활성화 되어 있지 않다면 활성화합니다. (이후에 사용할 Athena, Lake Formation의 통합을 위함입니다.)
- 네임스페이스(Namespace) 및 테이블(Table) 생성
📌 Amazon S3 Tables에서는 테이블을 Amazon S3 REST API, AWS SDK, AWS CLI 또는 통합 쿼리 엔진을 사용하여 테이블을 생성할 수 있습니다. 아래는 Athena를 통해 간단히 생성하는 것을 가이드하며 다른 방법은 해당 링크를 확인하여 주세요.
-
- 생성된 S3 Tables Bucket을 선택합니다.
- [Create table with Athena]를 클릭하고 Namespace name을 입력 후, 생성합니다.
- Athena의 쿼리 결과 저장 S3 Bucket이 지정되어있지 않은 경우, [Settings] 탭에서 설정하여줍니다.
- Athena 쿼리 편집기에 스크린샷과 같이 Table 생성을 위한 SQL이 작성되어 있습니다. 그대로 실행하시거나 SQL를 변경하여 원하는 테이블 스키마로 생성하고 실행 결과를 확인합니다.
2. AWS Lambda에서 PyIceberg 레이어 구성
- 해당 링크에서 Download raw file을 클릭하여
pyiceberg_layer.zip
파일을 다운로드합니다. - Lambda 함수 생성을 원하는 리전에 S3 버킷(General purpose)을 생성하여 다운로드한 레이어 파일을 업로드합니다.
- 업로드된 파일의 Object URL를 복사합니다.
- AWS Lambda 콘솔의 메뉴에서 [Layers]를 선택하고 [Create layer]를 클릭합니다.
- 스크린샷을 참고하여 정보를 입력 후, 레이어를 생성 합니다.
3. AWS Lambda 함수 생성
- AWS Lambda 콘솔의 메뉴에서 [Functions]를 선택하고 [Create function]을 클릭합니다.
- 스크린샷을 참고하여 정보를 입력 후, 함수를 생성합니다
- 함수 편집 뷰의 최하단의 [Layers] 섹션에서 [Add a layer]를 클릭합니다.
- [Custom layers]를 선택하고 앞서 생성한 레이어를 추가해 줍니다.
- 함수의 코드 편집기에서 아래 코드를 복사하여 붙여넣습니다.
-
⚠️
YOUR_ACCOUNT_ID
,YOUR_S3_TABLES_BUCKET_NAME
,YOUR_AWS_REGION
,YOUR_NAMESPACE_NAME
,YOUR_TABLE_NAME
부분을 설정 환경에 맞게 변경해주세요.
-
- 저장 후, 좌측의 [Deploy]를 클릭하여 함수를 배포합니다.
- 함수의 [Configuration] 탭에서 [General configuration]을 필요에 맞게 수정합니다.
-
⚠️ 메모리는 1GB 이상, 실행 시간은 1분 이상으로 조정하시고 테스트 수행 후, 필요에 따라 늘이거나 줄여주시기 바랍니다.
- 좌측의 [Permissions] 탭을 선택하고 함수의 Role name을 클릭합니다.
- 함수 역할 IAM 콘솔에서 [Add permissions → Create inline policy]를 선택합니다. (가이드의 편의를 위해 인라인 정책을 생성하지만 가능한 경우, 관리를 위하여 별도 정책으로 생성하시기 바랍니다.)
- 정책 편집기에서 [JSON] 토글을 활성화하고 아래 정책 JSON을 복사하여 붙여넣습니다.
- [Next] 클릭 후, 정책 이름을 입력하고 [Create policy]를 클릭하여 정책을 생성합니다.
4. S3 Tables 구조 알아보기
앞서 람다 함수의 권한 부여, 그리고 이후 Lake Formation을 통한 권한 부여에 대한 이해를 위해 S3 Tables 구조를 알아봅니다.
먼저, Amazon S3 테이블은 대규모 분석 워크로드에 최적화된 새로운 형태의 S3 스토리지로, Apache Iceberg 표준을 기본적으로 지원하여 Amazon S3에 저장된 테이블 형식 데이터를 효율적으로 관리하고 쿼리할 수 있습니다.
AWS Glue Data Catalog는 S3 기반의 데이터베이스와 테이블의 메타데이터를 관리하는 중앙 저장소 역할을 합니다. Amazon S3 테이블을 Glue Data Catalog와 통합하면, S3 테이블 버킷과 테이블이 Glue Data Catalog의 객체로 매핑되어 등록됩니다. 이 통합을 통해 Amazon Athena, Amazon EMR 등 다양한 AWS 분석 서비스에서 S3 테이블의 데이터를 손쉽게 탐색하고 쿼리할 수 있습니다.
S3 테이블과 Glue Data Catalog의 통합은 AWS Lake Formation 콘솔이나 API를 통해 수행할 수 있습니다. (해당 가이드에서는 1.에서 S3 Tables Bucket 생성 시, 콘솔로 수행) 이 과정에서 S3 테이블 버킷은 Glue Data Catalog 내의 멀티 레벨 카탈로그로 등록되고, 해당 버킷의 네임스페이스는 데이터베이스로, 테이블은 테이블 객체로 매핑됩니다.
<S3 Tables와 AWS Glue Data Catalog의 매핑 관계>
이러한 통합을 통해 조직은 데이터 레이크의 메타데이터를 중앙에서 관리하고, 다양한 분석 엔진과의 호환성을 확보하며, 데이터 거버넌스와 보안 정책을 일관되게 적용할 수 있습니다. 또한, Apache Iceberg의 기능을 활용하여 스키마 진화, 시간 여행 쿼리 등 고급 기능을 지원함으로써 데이터 분석의 유연성과 효율성을 향상시킬 수 있습니다.
위의 PyIceberg를 사용하는 람다 함수에 부여된 AWS Glue 권한은 Amazon S3 테이블과 Glue Data Catalog의 통합으로 인해 필요합니다. 이러한 권한을 통해 람다 함수는 Glue Data Catalog에서 메타데이터를 검색하고 업데이트하여 S3에 저장된 Iceberg 테이블을 효과적으로 관리할 수 있습니다.
❗만약, 향후에 PyIceberg에서 공식적으로 Amazon S3 Tables에 대한 호환성을 지원한다면 S3 Tables 자체 권한 부여로 Glue Data Catalog의 통합을 구성하지 않을 수 있습니다.
5. AWS Lake Formation를 통해 데이터 접근 권한 부여
💡 앞서 설명드린 Data Catalog에 대한 통합 권한 관리를 위하여 AWS Lake Formation을 사용합니다. 람다 함수에 부여된 Identity-based 권한 이외에도 Lake Formation에 의한 데이터 권한 부여가 필요합니다.
<AWS Lake Formation 권한 관리 워크플로>
- 해당 링크를 참고하여 콘솔에서 AWS Lake Formation을 위한 관리자를 생성합니다.
- 관리자 유저로 AWS Lake Formation 콘솔에 접근하여 좌측 메뉴의 [Application integration settings]를 선택하고 [Allow external engines to access data in Amazon S3 locations with full table access] 옵션을 선택합니다. (자체 Integration 서비스가 아닌 Lambda를 Engine으로 사용할 것이기 때문에 필요합니다.)
- Lake Formation 콘솔 좌측 메뉴에서 [Data permissions]를 클릭하고 [Grant]를 클릭합니다.
- 아래 내용을 확인하여 앞서 생성한 람다 함수 역할에 데이터 권한을 부여합니다.
- 앞서 생성한 람다 함수 역할의 이름을 검색하여 IAM Role을 Principal로 추가합니다.
- 아래에 [Named Data Catalog resources]를 선택하고 앞서 생성한 권한을 부여할 S3 Tables Bucket → Database(Namespace) → Table 을 선택합니다.
- [Table permissions]에서 [Super]를 선택하고 [Grant]를 클릭하여 권한 부여를 마무리합니다.
-
💡 Super로 권한 부여하는 이유?
PyIceberg에서는 Table 로드 시, 명시된 모든 권한 부여를 확인합니다. 향후, 별도 권한 구성 기능이 PyIceberg 패키지 단에서 업데이트가 될 수도 있지만 현재는 Table 로드 시점에서의 권한 확인을 위해 Super로의 부여가 필요합니다.
6. 생성한 AWS Lambda 함수 테스트
- 앞서 생성한 AWS Lambda 함수의 콘솔에서 테스트를 수행해봅니다. 만약, 함수의 입력으로 입력 데이터를 전달 받는 경우, 조정하여 테스트를 수행합니다.
- 데이터가 잘 추가되었는지 확인하기 위하여 Athena 콘솔의 Query Editor에서 만든 테이블에 아래 쿼리를 입력하고 실행해봅니다.
7. 마무리
이번 포스팅에서는 AWS Lambda와 PyIceberg를 활용하여 Amazon S3 Tables에 데이터를 입력하는 방법을 살펴보았습니다. 이 접근 방식은 다음과 같은 이점을 제공합니다:
- 이벤트 기반 실시간 데이터 처리
- 서버리스 아키텍처로 인한 관리 부담 감소
- 비용 효율적인 데이터 처리 방식
- 확장성 있는 동시 처리 가능
PyIceberg 레이어를 둔 AWS Lambda에 적절한 권한 설정을 통해 데이터 입력뿐만 아니라 조회, 업데이트, 스냅샷 관리 등 다양한 PyIceberg의 API 작업들을 수행하도록 구성할 수 있습니다. 이를 통해 S3 Tables API나 통합 AWS 서비스에서 지원하지 않는 작업들도 서버리스 환경에서 효율적으로 구현할 수 있습니다.
워크로드 특성에 따라 아래 비교표를 참고하여 Amazon S3 Tables 사용 전, 최적의 서비스 조합을 선택하시기 바랍니다!
[참고] 📌 Amazon S3 Tables INSERT 및 SELECT 기준 서버리스 서비스별 비교표
Amazon S3 Tables INSERT 및 SELECT 기준 서버리스 서비스별 비교표
→ 추가로 블로그 작성 중, Amazon S3 Tables와 호환되는 서버리스 서비스들이 다양하기 때문에 이에 대한 선택을 돕기 위해 작성한 비교표입니다. 포함되지 않은 S3 Tables 호환 서비스로는 Amazon EMR, Amazon Redshift가 있습니다. 실제 프로덕션에 적용되는 경우, 더욱 세밀한 워크로드 분석 수행 후, 이에 적합한 호환 솔루션을 선택하여 S3 Tables를 사용하는 것을 권장드립니다.
구분 | Amazon Athena | AWS Glue (Spark ETL) | AWS Lambda + PyIceberg | Amazon Kinesis Data Firehose |
---|---|---|---|---|
서비스 유형 | 서버리스 SQL 쿼리 엔진 + Spark 세션 | 서버리스 Apache Spark ETL | 서버리스 람다 (Python) | 서버리스 스트리밍 적재 |
데이터 삽입 (INSERT) | 배치 단위 SQL 쿼리로 소규모 데이터 삽입 | 대규모 배치 및 마이크로 배치 적재 | 이벤트 기반 실시간 및 소규모 배치 적재 | 실시간 스트리밍 데이터 적재 |
데이터 조회 (SELECT) | SQL 기반 고성능 인터랙티브 분석 | Spark SQL/DataFrame 기반 ETL 및 분석 | 소규모 데이터 및 메타데이터 조회 | 자체 조회 기능 없음 (Athena 등 별도 연계 필요) |
확장성 | 서버리스 자동 확장 (대규모 병렬 처리 가능) | DPUs 확장 가능 (수백 TB~ 수 PB 처리 가능) | Lambda 동시 실행 가능 (단일 실행당 제한 존재) | 자동 스케일링, 초당 MB~TB 단위 처리 가능 |
비용 산정 방식 | 스캔한 데이터 양(TB당 약 $5) | DPU-Hour 기준 (~$0.44/DPU-hour) | Lambda 실행시간과 메모리 용량 기준 | 데이터 처리량 기준 (GB당 약 $0.029) |
적합한 데이터 규모 | 중간~대규모 데이터셋 조회 (GB~수십 TB), 소규모 적재 | 매우 큰 데이터 (수백 GB~수 PB) | 소규모 (수백 KB ~ 수 MB) | 모든 규모 적재 가능 (소규모 데이터는 버퍼링 필요) |
장점 | – SQL로 편리한 고성능 분석 – 서버리스 및 손쉬운 관리 |
– 강력한 ETL 및 데이터 변환 – 매우 큰 데이터 처리 용이 |
– 서버리스 실시간 처리 가능 – 이벤트 기반 유연성 – 낮은 비용과 지연시간 |
– 실시간 수집 및 자동 배치 적재 – 설정 및 관리 간편 – 포맷 변환 내장 |
단점 | – 실시간 삽입 불가능 – 복잡한 ETL 부적합 |
– 초기 기동 지연 – 관리 복잡성 |
– 대용량 처리 불가 (Lambda 제한) – PyIceberg 의존성 |
– 조회 기능 없음 – 복잡한 변환 제한 – 스키마 고정 |
추천 사용 사례 | – 애드혹 쿼리 – 배치성 데이터 분석 |
– 대용량 배치 ETL – 복잡한 데이터 처리 |
– 실시간 이벤트 수집 – 간단한 변환 및 소규모 적재 |
– 실시간 로그 수집 – 대시보드 연계 소스 |
✅ 서버리스 시나리오 별 추천
- 대용량 배치 ETL 처리 시나리오: AWS Glue로 데이터 변환 후, Amazon Athena로 분석
- 실시간 스트리밍 처리 시나리오: Kinesis Data Firehose로 실시간 적재 → Athena 분석
- 실시간 이벤트 처리 및 간단 변환 시나리오: AWS Lambda + PyIceberg로 데이터 실시간 처리 및 Iceberg 적재 → Athena 조회