AWS는 Amazon Aurora PostgreSQL 내부의 운영 데이터와 함께 데이터 레이크에 저장된 Apache Iceberg 및 Apache Parquet 데이터를 직접 쿼리할 수 있는 기능을 추가했다고 발표했다. 새로운 기능을 통해 애플리케이션은 PostgreSQL 구문과 기존 도구를 사용해 최신 레코드와 과거 데이터를 하나의 쿼리로 결합할 수 있으며, ETL 파이프라인을 통해 데이터를 데이터베이스로 복사할 필요가 없다.
실제로 무엇이 달라졌나?
이 기능은 Aurora PostgreSQL 내부에 직접 임베드된 DuckDB 엔진을 기반으로 한다. 이에 따라 하나의 쿼리에서 커밋되지 않은 쓰기를 포함한 운영 데이터를 읽고, Amazon S3의 Iceberg 테이블 또는 Parquet 파일도 읽을 수 있다. 또한 AWS Glue Data Catalog, Amazon S3 및 S3 Tables와 Glue의 federation 메커니즘을 통한 Iceberg REST Catalog 호환 카탈로그를 지원한다.
사용자는 Aurora PostgreSQL 클러스터를 생성하고 AuroraAnalytics 기능이 포함된 IAM 역할을 연결한 다음 aurora_analytics 확장을 활성화해야 한다. 이후 외부 데이터를 가리키는 foreign table을 생성하거나 IMPORT FOREIGN SCHEMA을 사용해 메타데이터에서 데이터 스키마를 추론하여 여러 테이블을 자동으로 생성할 수 있다.
이 소식이 중요한 이유
기존에는 Aurora의 최신 트랜잭션과 S3의 과거 레코드를 결합하는 애플리케이션이 일반적으로 reverse ETL을 통해 데이터를 복사해야 했으며, 이로 인해 동기화 작업과 운영 비용, 엔지니어링 복잡성이 추가됐다. 이제는 쿼리 자체를 실행하는 동안 이러한 통합을 수행할 수 있다. 이는 과거 맥락이 필요한 대시보드, 트랜잭션을 이전 기록과 연결하는 애플리케이션, 운영 데이터베이스와 데이터 레이크에 분산된 데이터를 다루는 시스템에 유용하다.
이 점은 인공지능 에이전트를 사용하는 애플리케이션에서 더욱 중요하다. 에이전트가 사전에 어떤 데이터 세트를 필요로 할지 예측하고 이를 운영 데이터베이스로 복사하기 어렵기 때문이다. 직접 액세스를 사용하면 각 사용 사례마다 복사본을 만들지 않고도 이용 가능한 데이터의 범위를 확장할 수 있다.
성능 및 액세스 옵션
Aurora는 필터를 데이터 소스로 푸시하고 읽는 열을 줄이는 등의 최적화를 적용하며, 자주 사용하는 데이터는 Aurora 인스턴스 내부에 임시로 저장한다. 각 쿼리의 동작은 aurora_analytics_stat_statements() 함수를 통해 확인할 수 있다. 이 함수는 검사한 행 수, S3에서 읽은 데이터 용량, 캐시 활용 횟수 등의 지표를 제공한다.
쿼리는 클러스터 내 여러 Aurora 인스턴스에서 실행할 수 있으며, 라이터와 읽기 전용 복제본도 포함된다. 이를 통해 분석적 스캔 작업을 운영 부하에서 분리할 수 있다. 반면 밀리초의 1,000분의 1 수준의 시간이 필요한 경우에는 CREATE TABLE AS SELECT, INSERT INTO ... SELECT 또는 MERGE INTO를 사용해 데이터를 기본 Aurora 테이블로 구체화할 수 있다. 구체화로 발생하는 쓰기 작업은 라이터 인스턴스에서 실행된다.
가용성 및 비용
이 기능은 Aurora PostgreSQL 17 버전에서 17.11부터, 18 버전에서 18.6부터 지원된다. 모든 AWS 상용 리전과 AWS GovCloud (US) 리전에서 제공되며, 기능 자체에 대한 추가 요금은 없다. 비용은 쿼리가 사용하는 Aurora 컴퓨팅 증가분과 데이터 레이크 파일을 읽기 위한 Amazon S3 요청 요금에 따라 달라진다.
certi.news의 해석: 핵심적인 변화는 새로운 스토리지 형식을 추가한 것이 아니라 운영 데이터베이스와 데이터 레이크 사이의 거리를 줄였다는 데 있다. 그러나 이것이 워크로드 설계에 관한 고려 사항을 없애는 것은 아니다. 직접 쿼리는 데이터에 유연하게 액세스하는 데 적합하지만, 응답 시간이 매우 짧아야 하는 경우에는 여전히 구체화가 필요하다. 또한 Aurora 컴퓨팅과 S3 요청 사용량은 쿼리 패턴과 데이터 규모에 따라 측정해야 할 요소로 남는다.