HAQM S3 Tables이 압축을 사용하여 쿼리 성능을 최대 3배까지 개선하는 방법

이 글은 AWS Storage Blog에 게시된 How HAQM S3 Tables use compaction to improve query performance by up to 3 times by Aliaa Abbas, Anupriti Warade, and Jacob Tardieu 를 한국어 번역 및 편집하였습니다.

오늘날 페타바이트 규모의 데이터를 관리하는 기업들은 비용 효율성을 유지하면서 적시에 인사이트를 확보하기 위해 스토리지와 데이터 처리 과정을 최적화 해야 합니다. 고객들은 향상된 스토리지와 쿼리 성능을 위해 주로 Apache Parquet를 선택합니다. 또한 고객들은 스키마 진화, 타임 트래블, ACID 트랜잭션과 같은 데이터베이스 수준의 기능을 활용하기 위해 Apache Iceberg를 사용하여 Parquet 데이터셋을 관리합니다. 고객들은 실시간 스트리밍, 변경 데이터 캡처(CDC), 로그 분석 사용 사례 등에서 생성된 데이터셋을 저장하기 위해 Iceberg를 사용합니다. 이러한 워크로드는 빈번하고 세분화된 업데이트를 수반하며, 이로 인해 Iceberg 데이터셋 내에 수많은 작은 파일들이 생성됩니다.

데이터 파일의 수가 증가함에 따라, 이러한 데이터셋을 읽는 다운스트림 애플리케이션의 쿼리 성능도 부정적인 영향을 입을 수 있습니다. 여러 개의 작은 Parquet 파일로 분산된 데이터셋은 쿼리 엔진이 쿼리당 많은 수의 작은 데이터 읽기를 수행하게 하며, 각 읽기에는 고정된 오버헤드가 발생합니다. 따라서, 세분화된 쓰기 작업으로 인해 작은 파일의 수가 증가하면 읽기 요청의 수가 급격히 늘어나 전체 쿼리 성능에 영향을 줄 수 있습니다.

작은 Parquet 파일들을 더 큰 파일로 통합하면 쿼리 엔진이 더 적은 요청으로 더 큰 데이터 범위를 읽을 수 있어, 전체적인 읽기 처리량이 향상됩니다. 컴팩션이라고 알려진 이 프로세스는 여러 작은 파일에 접근할 때 발생하는 오버헤드를 줄임으로써 스토리지 효율성을 최적화하고 쿼리 성능을 개선합니다. 하지만 대규모 테이블에 대한 컴팩션 수행은 리소스 집약적이며 효과적으로 관리하기 어려울 수 있습니다. AWS re:Invent 2024에서 우리는 Apache Iceberg 표준을 사용하여 대규모 표 형식 데이터를 저장하고 관리하기 위해 특별히 설계된 HAQM S3 Tables를 소개했습니다. S3 Tables는 스냅샷 관리 및 참조되지 않는 파일 제거와 같은 다른 유지보수 작업과 함께 자동으로 컴팩션을 수행합니다.

S3 Tables의 자동 컴팩션이 가져오는 성능상의 이점을 보여주기 위해, 자체 관리 환경에서 흔히 볼 수 있는 범용 버킷의 컴팩션 되지 않은 Iceberg 테이블과 테이블 버킷의 완전 관리형 테이블 간의 쿼리 성능을 비교하는 테스트를 수행했습니다. 이 포스트에서 우리는 테스트 결과를 분석하고 S3 Tables의 성능 상 이점에 대해 알아보겠습니다.

성능 테스트 환경 설정

빈번하고 세분화된 업데이트가 발생하는 실제 시나리오를 시뮬레이션 하기 위해, 1MB 파일로 분할된 3TB TPC-DS 데이터셋을 사용했습니다. 이는 고속으로 증분 데이터 수집이 발생하는 워크로드의 전형적인 특징입니다. Parquet 데이터 스토리지 최적화가 쿼리 성능에 미치는 영향을 평가하기 위해 TPC-DS에서 IO 집약적인 8개의 쿼리 하위 집합을 선택했습니다. 테스트는 각각 16 vCPU, 128GB 메모리, 600GB SSD 스토리지를 갖춘 9개의 r5dn.4xlarge 인스턴스(1개의 프라이머리, 8개의 코어)로 구성된 HAQM EMR 7.5.0 클러스터에서 실행되었습니다. 이 설정을 통해 범용 버킷의 컴팩션되지 않은 Iceberg 테이블과 테이블 버킷의 컴팩션된 테이블 간의 성능을 비교할 수 있었습니다. 테스트는 두 단계로 진행되었습니다: 범용 버킷의 컴팩션되지 않은 Iceberg 테이블에 대한 기준 측정과 테이블 버킷의 컴팩션된 테이블에 대한 성능 테스트입니다. 각 단계에서 5번의 테스트를 반복 수행하고 평균 쿼리 실행 시간을 계산했습니다.

관찰(Observations)

테스트 결과는 S3 Tables에 의해 컴팩션 된 데이터셋을 사용할 때 상당한 성능 향상을 보여 주었습니다. 테이블 버킷에서 컴팩션이 활성화된 경우, 최대 3.2배의 쿼리 성능 증가가 관찰 되었으며, 쿼리를 수행 시 테이블 버킷이 범용 버킷의 자체 관리 테이블보다 일관되게 더 나은 성능(1.1배에서 3.2배)을 보였습니다. 전체적으로 8개 쿼리의 총 실행 시간이 약 2.26배 빨라졌습니다. 이러한 개선 효과는 컴팩션을 통해 객체 크기가 커짐으로써 읽기 요청이 감소한 것에서 비롯됩니다.

예를 들어, 컴팩션되지 않은 테이블의 1MB Parquet 객체에 대해 실행된 쿼리들은 테이블 버킷의 512MB Parquet 객체에 대해 실행된 쿼리들과 비교하여 8.5배 더 많은 읽기 요청이 필요했습니다. 작은 객체 크기로 인해 쿼리 엔진은 많은 수의 작은 킬로바이트 범위의 요청을 해야 하며, 이는 본질적으로 덜 효율적입니다. 반면에 컴팩션된 데이터셋은 컴퓨팅 엔진이 더 적은 요청으로 훨씬 더 큰 범위를 읽을 수 있게 해주어, 전체 읽기 처리량을 크게 향상시켰습니다. 실제 성능 향상은 특정 워크로드, 파일 크기, 쿼리 엔진 구성 및 데이터 접근 패턴에 따라 달라질 수 있습니다. 이번 결과는 모든 시나리오에 대한 절대적인 기준이 아닌, 하나의 참고 지표로 받아들여야 합니다.

표 1: 반복 실행에 따른 쿼리 평균 실행 시간(초)

관찰한 바와 같이, 작은 Parquet 파일들을 더 큰 파일로 컴팩션하면 쿼리 성능이 향상되지만, 고객들은 성능이 좋은 데이터 레이크를 유지하기 위해 지속적으로 객체들을 최적화 해야 합니다. 자체 관리 환경에서 대규모 테이블에 대한 정기적인 컴팩션은 복잡한 작업입니다. 이는 종종 전용 컴퓨팅 클러스터와 이러한 테이블을 관리할 수 있는 숙련된 팀을 필요로 하며, 이는 데이터 운영에 상당한 부담을 줄 수 있습니다. S3 Tables는 테이블 버킷에 저장된 테이블에 대해 수동 개입 없이 자동으로 컴팩션을 수행함으로써 이 프로세스를 단순화합니다. 이러한 접근 방식은 추가 인프라나 특별한 관리 없이도 데이터셋이 항상 최적화되도록 보장하여, 고객이 데이터 운영을 간소화하고 운영 복잡성을 크게 줄일 수 있도록 돕습니다.

S3 Tables를 사용하려면 새로운 테이블 버킷을 생성하고 이 버킷 내에 테이블을 만들기만 하면 됩니다. 테이블별 목표 파일 크기는 기본값인 512MB로 설정되지만, 워크로드 요구사항에 따라 64MB에서 512MB 사이로 자유롭게 조정할 수 있습니다. S3는 컴팩션된 객체를 테이블의 가장 최신 스냅샷으로 작성하여 데이터가 최신 상태로 유지되고 효율적으로 구성되도록 돕습니다.

결론

이번 포스트에서는 범용 버킷의 자체 관리형(컴팩션되지 않은) 테이블과 테이블 버킷의 관리형 테이블에 대한 성능 테스트 결과를 알아보았습니다. 자동 컴팩션 기능이 있는 S3 Tables는 S3의 자체 관리형 테이블과 비교하여 스토리지 집약적 워크로드의 쿼리 성능을 최대 3배까지 향상시킬 수 있습니다. HAQM S3 Tables에 대해 더 자세히 알아 보시려면 S3 사용자 가이드를 참조하시기 바랍니다.