aws2026년 5월 12일

Amazon Redshift, 통합 데이터 레이크 쿼리 엔진을 탑재한 AWS Graviton 기반 RG 인스턴스 출시 | Amazon Web Services (새 탭에서 열림)

Amazon Redshift의 새로운 RG 인스턴스는 AWS Graviton 기반으로, 기존 RA3보다 데이터 웨어하우스 워크로드를 최대 2.2배 빠르게 처리하면서 vCPU당 가격은 30% 낮춘다. 또한 데이터 웨어하우스와 Amazon S3 데이터 레이크를 하나의 엔진에서 SQL로 조회할 수 있어, Apache Iceberg는 최대 2.4배, Apache Parquet은 최대 1.5배 향상된 성능을 제공한다. 이를 통해 대규모 AI 에이전트 쿼리와 저지연 분석 workload의 비용과 운영 복잡성을 함께 줄이는 것이 핵심이다. ## 데이터 웨어하우스와 데이터 레이크를 함께 처리해야 하는 배경 - 기업은 구조화되고 자주 조회되는 데이터는 데이터 웨어하우스에, 대규모·다양한 데이터는 비용 효율적인 데이터 레이크에 저장하는 방식으로 운영하고 있다. - AI 에이전트가 사람보다 훨씬 많은 쿼리를 실행하면서 쿼리 처리량과 운영 비용이 급증하고 있다. - Redshift는 BI 대시보드, ETL, 실시간 분석, 자율형 AI 에이전트처럼 빠른 응답이 필요한 workload를 대상으로 성능 개선을 이어 왔다. - 2026년 3월에는 신규 쿼리 성능을 최대 7배 높여 BI와 ETL 응답 시간을 단축했다고 설명한다. ## AWS Graviton 기반 RG 인스턴스 - RG 인스턴스는 AWS Graviton 프로세서 기반의 새로운 Amazon Redshift 인스턴스 제품군이다. - RA3 대비 데이터 웨어하우스 workload를 최대 2.2배 빠르게 처리한다. - vCPU당 가격은 RA3보다 30% 낮다. - 고빈도 쿼리와 낮은 지연 시간이 중요한 분석 및 agentic AI workload에 적합하다. - 기존 RA3 인스턴스와 `ra3.xlplus`, `ra3.4xlarge` 및 대응하는 `rg.xlarge`, `rg.4xlarge` 구성을 비교할 수 있다. ## 통합 데이터 레이크 쿼리 엔진 - Redshift의 단일 SQL 엔진으로 데이터 웨어하우스 테이블과 Amazon S3 데이터 레이크를 함께 조회할 수 있다. - Apache Iceberg 데이터 조회 성능은 RA3 대비 최대 2.4배, Apache Parquet은 최대 1.5배 빠르다. - 데이터 레이크 쿼리는 별도의 Spectrum 서비스가 아니라 Redshift 클러스터 노드에서 실행된다. - 기존 외부 테이블, 스키마, 쿼리 문법과 Spectrum 쿼리를 그대로 사용할 수 있어 애플리케이션 코드 수정이나 외부 테이블 재생성이 필요 없다. ## 비용 및 보안상의 변화 - 데이터 웨어하우스와 데이터 레이크를 각각 별도 시스템으로 운영할 필요가 줄어든다. - 데이터 레이크 쿼리가 VPC 내부에서 실행되므로 네트워크 경계를 단순하게 유지할 수 있다. - 기존 IAM 역할을 그대로 사용할 수 있다. - Spectrum의 데이터 스캔 요금인 TB당 5달러가 발생하지 않아 전체 Redshift 비용을 낮출 수 있다. - 실제 절감액은 쿼리량, 데이터 레이크 스캔 규모, 인스턴스 구성에 따라 달라지므로 AWS Pricing Calculator로 산정해야 한다. ## 마이그레이션 방법 - AWS Management Console, AWS CLI, AWS API를 통해 새 RG 클러스터를 생성하거나 기존 클러스터를 이전할 수 있다. - 통합 데이터 레이크 쿼리 엔진은 기본적으로 활성화된다. - **Elastic Resize** - 호환되는 구성에서 인플레이스 마이그레이션을 수행한다. - 약 10~15분의 다운타임이 발생한다. - **Snapshot and Restore** - RA3 스냅샷으로 RG 클러스터를 새로 생성한다. - 마이그레이션 과정에서 클러스터 설정을 변경하려는 경우 적합하다. - 마이그레이션 경로를 통해 비용, 호환성, 실행 계획을 확인하고 자동화할 수 있다. ## 리전 및 요금 옵션 - RG 인스턴스는 미국, 캐나다, 유럽, 아시아 태평양, 남아메리카의 여러 AWS 리전에서 제공된다. - 한국 리전(서울)도 지원 대상에 포함되어 있다. - Provisioned Redshift에서는 약정 없는 시간 단위 온디맨드 요금제와 비용 절감을 위한 Reserved Instance를 선택할 수 있다. - 제공 리전은 변경될 수 있으므로 실제 도입 전 AWS 리전별 지원 현황을 확인해야 한다. 실제로 도입할 때는 기존 RA3 workload의 쿼리 패턴과 S3 데이터 스캔량을 기준으로 RG의 성능·비용을 비교하는 것이 좋다. 호환 가능한 클러스터라면 Elastic Resize를 우선 검토하고, 설정 변경이나 검증이 필요하면 Snapshot and Restore 방식을 사용하는 것이 적절하다.

data-lakeai-agentamazon-s3sql+4

spotify2026년 4월 6일

온라인 포인트 쿼리를 위한 데이터 레이크 인덱싱 | Spotify 엔지니어링 (새 탭에서 열림)

Spotify처럼 대규모 사용자 데이터를 온라인 서비스와 AI 에이전트가 빠르게 조회해야 하는 환경에서는, 모든 데이터를 Bigtable이나 DynamoDB 같은 KV 저장소에 보관하기 어렵습니다. 데이터 레이크의 Parquet 파일과 객체 스토리지는 충분히 빠르지만, Trino·BigQuery 같은 분석 엔진은 단일 행 조회에도 작업 계획과 스케줄링 오버헤드가 발생합니다. Random Access Parquet(RAP)은 외부 인덱스로 키와 파일·행 위치를 직접 연결하고 필요한 바이트만 범위 읽기하여, 데이터 레이크에서 저지연 포인트 조회를 가능하게 합니다. ## 데이터 레이크에서 온라인 조회가 어려운 이유 - 사용자 청취 이력처럼 데이터 규모가 매우 큰 경우, 특정 사용자의 데이터를 찾기 위해 수천 개의 Parquet 파일을 조사해야 합니다. - 예를 들어 90일 동안 하루 1,000개의 파일이 생성되면 조회 후보가 약 90,000개에 달합니다. - Trino와 BigQuery는 분석 처리량에 최적화되어 있어 단일 사용자 조회에도 수 초의 쿼리 계획 및 작업 스케줄링 시간이 발생할 수 있습니다. - GCS나 S3의 읽기 지연 시간이 계속 줄어들고 있으므로, 병목은 저장소보다 저장소 위의 쿼리 엔진과 파일 내부 탐색 과정으로 이동하고 있습니다. ## 기존 파일 필터링의 한계 - 날짜별 파티션 안에서 사용자 ID를 기준으로 해시 버킷을 만들면 파일명만으로 해당 사용자가 들어 있을 가능성이 없는 파일을 제거할 수 있습니다. - 하루 1,000개 버킷을 사용하면 90,000개 파일이 약 90개로 줄어듭니다. - 사용자 ID 컬럼의 Bloom filter를 메타데이터 저장소에 캐시하면 실제 사용자가 활동한 날짜에 해당하는 약 12개 파일까지 후보를 좁힐 수 있습니다. - 하지만 후보 파일 내부에서 실제 행을 찾으려면 다음과 같은 의존적인 읽기가 필요합니다. - Parquet footer 읽기 - row group 메타데이터 파싱 - 키 컬럼 스캔 - column index와 page index 확인 - 값 컬럼의 해당 페이지 읽기 - 각 단계는 이전 읽기의 결과를 기다려야 하므로 클라우드 저장소에서는 파일과 컬럼마다 여러 번의 왕복 지연이 발생합니다. - 파티션, 버킷, Bloom filter는 “읽을 파일”을 줄일 뿐, 파일 내부에서 “읽을 위치”를 직접 알려주지는 못합니다. ## RAP의 핵심 방식 - RAP는 스캔 대신 조회를 사용합니다. - 외부 인덱스가 특정 키를 다음 위치와 직접 매핑합니다. - 해당 Parquet 파일 - 파일 안의 행 번호 - 선택적으로 해당 값의 개수 - 조회 과정은 다음처럼 단순화됩니다. - 키로 외부 인덱스 조회 - 캐시된 파일 메타데이터로 행 번호를 페이지 위치로 변환 - 필요한 컬럼 페이지에 대해 정확한 범위 읽기 수행 - 인덱스 조회는 O(1)에 가깝고, 여러 범위 읽기를 병렬로 실행할 수 있어 종속적인 읽기 체인을 제거합니다. - 이 원리는 클라우드 객체 스토리지뿐 아니라 SSD와 메모리에서도 동일하게 적용됩니다. 저장장치가 빠를수록 절대 지연은 줄지만, 종속 읽기를 제거하는 효과는 유지됩니다. ## 외부 인덱스의 구조와 특성 - RAP는 기존 Parquet 파일을 수정하지 않고도 적용할 수 있습니다. - 인덱스 빌더는 다음 작업을 수행합니다. - 파일 footer와 필요한 컬럼의 페이지 위치 읽기 - 키 컬럼 스캔 - 키와 파일·행 위치의 매핑 생성 - 인덱스 조각 저장 - 새 데이터가 들어오면 기존 인덱스를 수정하기보다 새로운 인덱스 fragment를 append합니다. - 인덱스는 multimap 구조이므로 하나의 키가 여러 파일과 파티션에 존재할 수 있습니다. - 주요 필드는 다음과 같습니다. - `key`: 사용자 ID 또는 복합 키 - `file`: 대상 Parquet 파일 식별자 - `row numbers`: 해당 파일 안의 행 번호 - `value count`: 페이지네이션에 사용할 값 개수 - 일반적으로 테라바이트 데이터를 인덱싱하면 기가바이트 규모의 인덱스가 생성되고, 페타바이트 데이터에서는 테라바이트 규모가 됩니다. - 대규모 인덱스는 해시 버킷으로 자연스럽게 분산할 수 있습니다. - Parquet의 PageIndex나 Bloom filter가 후보를 좁히는 확률적·보조적 장치라면, 외부 인덱스는 키에 대한 정확한 파일과 행 위치를 반환해 스캔 자체를 없앱니다. ## 준비되지 않은 Parquet의 읽기 비용 - 외부 인덱스가 정확한 행을 알려주더라도, 기존 Parquet에서는 해당 행이 포함된 전체 페이지를 읽어야 할 수 있습니다. - 예를 들어 실제 필요한 데이터가 100바이트뿐이어도 페이지 크기가 4MB라면 4MB 전체를 가져와야 합니다. - 따라서 지연 시간과 비용이 중요한 환경에서는 인덱스뿐 아니라 쓰기 시점의 Parquet 레이아웃 최적화도 필요합니다. ## 준비된 Parquet 파일 최적화 RAP를 위해서는 파일 내부 탐색을 돕는 구조보다 최종적으로 읽어야 할 데이터의 양과 읽기 횟수를 줄이는 구조가 중요합니다. ### 키 데이터를 한곳에 모으기 - 키 기준 정렬을 적용하면 같은 키의 행이 파일 안에서 연속적으로 배치되어 필요한 페이지 수가 줄어듭니다. - 해시 버킷을 사용하면 동일한 키가 각 파티션에서 결정적으로 하나의 파일에 배치되도록 보장할 수 있습니다. - Spark, Scio SMB, Iceberg bucket transform 등이 활용될 수 있습니다. - Co-grouping 방식으로 키마다 하나의 행만 만들고, 관련 데이터를 반복 또는 중첩 컬럼에 저장할 수도 있습니다. - 예를 들어 다음 쿼리는 사용자별 청취 이력을 하나의 배열로 묶습니다. ```sql SELECT user_id, ARRAY_AGG(STRUCT(timestamp, track_uri, duration_ms)) FROM streams GROUP BY user_id ``` - 이 방식은 정렬에 의존하지 않고도 키별 데이터를 집중시킬 수 있으며, 사용자별 포인트 조회에 자연스럽습니다. - 파티션을 지나치게 세분화하면 하나의 키가 많은 파일에 분산됩니다. 예를 들어 일별 파티션은 한 사용자의 연간 데이터를 최대 365개 파일에 나눌 수 있으므로, 더 적절한 파티션 단위를 선택하면 조회 시 파일 수를 줄일 수 있습니다. ## 실용적인 적용 방향 RAP는 분석용 Parquet를 별도의 온라인 서빙 시스템으로 복제하지 않고도 온라인 포인트 조회를 지원하는 접근입니다. 먼저 외부 인덱스로 파일·행 위치를 직접 매핑하고, 지연 시간이 중요한 컬럼에는 키 정렬, 해시 버킷, 사용자별 집계와 같은 쓰기 시점 최적화를 적용하는 것이 효과적입니다. 이를 통해 데이터 저장은 한 번만 유지하면서 분석, ML, 노트북, 온라인 서비스, AI 에이전트가 동일한 데이터를 활용할 수 있습니다.

data-lakeapache-parquetrandom-access-parquetpoint-queries+3