다시 만든 데이터 웨어하우스 Redshift (Redshift Re-invented, SIGMOD 2022)

출처

참고 이 페이지는 원문 번역이 아니라 한국어 해설이에요. 정확한 표현과 수치는 원문을 확인하세요.

한눈에

• 문제: 2013년 출시 당시의 Redshift 는 계산과 저장이 한 노드에 묶인 클러스터형 데이터 웨어하우스였습니다. 고객의 데이터와 동시 사용자 수가 늘면서 성능, 확장성, 쉬운 사용, 다른 서비스와의 연결이라는 네 가지 요구가 커졌습니다.
• 제안: 쿼리마다 C++ 코드를 생성해 컴파일하는 실행 엔진, S3 를 바탕으로 한 관리형 스토리지(RMS), 필요할 때 클러스터를 덧붙이는 동시성 확장, 클러스터 간 데이터 공유, 머신러닝 기반 자동 튜닝을 단계적으로 더했습니다.
• 결과: 튜닝하지 않은 3TB TPC-DS 에서 다른 클라우드 데이터 웨어하우스 대비 최대 3배 좋은 가격 대비 성능을 보였다고 보고합니다(그림 3(a)).
• 지금의 의미: 논문 하나에 Redshift 의 주요 기능 이름이 거의 모두 등장하므로, 제품 구조를 한 번에 이해하기 좋은 지도입니다.

왜 나왔나

논문 시점에 Redshift 는 26개 리전, 84개 가용 영역에서 수만 고객이 쓰며 매일 엑사바이트 규모의 데이터를 처리했습니다. 출시 초기에는 빠른 컬럼 저장 MPP 엔진이 강점이었지만, 이후 고객 요구는 "더 빠르게" 만이 아니었습니다. 저장 용량과 계산 능력을 따로 늘리고 싶고, 아침마다 몰려드는 수백 명의 분석가를 감당해야 하고, 인덱스나 분산 키를 튜닝할 사람이 없고, 데이터 레이크와 운영 데이터베이스와 머신러닝을 함께 쓰고 싶어 했습니다. 논문은 이 네 가지 요구를 축으로 지난 10년의 변화를 정리합니다.

핵심 아이디어

성능과 실행 엔진 (2절)

클러스터는 리더 노드 하나와 여러 컴퓨트 노드로 이루어집니다(그림 1). 리더는 쿼리를 구문 분석하고, 데이터 이동 비용까지 고려하는 비용 기반 최적화기로 계획을 세웁니다(그림 2). 테이블은 분산 키에 따라 컴퓨트 노드에 나뉘거나 모든 노드에 복제되므로, 같은 키로 조인하면 데이터를 섞지 않아도 됩니다.

실행 방식이 독특합니다. 리더는 쿼리 계획 조각마다 그 쿼리 전용 C++ 코드를 생성해 컴파일하고, 바이너리를 컴퓨트 노드로 보냅니다(그림 4). 해석 실행의 오버헤드가 없는 대신 컴파일 시간이 문제인데, 이를 위해 클러스터 밖에 여러 클러스터가 공유하는 컴파일 캐시 서비스를 두었습니다. 그 결과 함대 전체 캐시 적중률이 99.60% 에서 99.95% 로 올랐고, 로컬 캐시에서 놓친 것의 87% 를 외부 캐시에서 찾았습니다.

그 밖에 SIMD 를 쓰는 벡터화 스캔, 프리페치, AZ64 라는 자체 인코딩(3TB TPC-H 에서 LZO 보다 42% 개선), 실행 중 크기를 정하고 효과 없으면 끄는 블룸 필터, 그리고 Nitro 칩과 FPGA 를 쓰는 클러스터 밖 캐시 및 연산 계층 AQUA 를 소개합니다.

저장 계층 (3절)

RA3 인스턴스부터는 데이터의 원본이 Redshift Managed Storage(RMS) 에 있습니다. RMS 는 S3 를 바탕으로 연간 99.999999999% 내구성을 제공하고, 컴퓨트 노드의 로컬 SSD 는 압축된 컬럼 블록을 캐시하는 역할을 합니다(그림 5). 자주 쓰는 블록은 2단계 클럭 캐시로 승격하며, 재수화(rehydration) 가 20% 만 진행되어도 로컬 디스크 적중률이 80% 를 넘는다고 합니다. 로그 기반 커밋 프로토콜로 커밋 성능을 40% 높였고, 스냅숏 격리 위에 직렬화 가능성 인증기를 얹어 직렬화 격리를 제공합니다.

계산 확장 (4절)

저장이 분리되자 계산 쪽이 자유로워졌습니다.

• 탄력적 크기 조정(Elastic Resize): 데이터를 옮기지 않고 메타데이터만 바꾸어 노드 수를 조정하고, 블록은 백그라운드에서 S3 에서 채웁니다.
• 동시성 확장(Concurrency Scaling): 대기열이 길어지면 추가 클러스터를 자동으로 붙여 쿼리를 나눠 처리합니다. 그림 6 은 동시 사용자 250명까지 처리량이 늘어나는 모습을 보여줍니다.
• 데이터 공유(Data Sharing): 생산자 클러스터의 데이터를 복사 없이 다른 클러스터가 읽습니다.

자동화 (5절)

• 자동 테이블 최적화(ATO): 워크로드를 관찰해 분산 키와 정렬 키를 추천하고 적용합니다. 그림 7(a) 에서 30TB TPC-H 실행 시간이 23% 줄었습니다.
• 자동 워크로드 관리(AutoWLM): 쿼리마다 실행 시간과 메모리를 머신러닝으로 예측하고, 큐잉 이론을 바탕으로 동시 실행 수를 조절합니다(그림 7(b)). 예측기는 클러스터에서 직접 학습하는 XGBoost 모델입니다.
• 구체화 뷰: 증분 갱신과 자동 쿼리 재작성을 지원합니다. 뷰의 95% 가 15분 안에 갱신되었다고 합니다.
• 서버리스: 고객은 클러스터를 정하지 않고, 쿼리가 실행된 시간만큼 비용을 냅니다.

생태계 연결 (6절)

S3 의 Parquet, ORC 같은 개방형 형식을 직접 질의하는 Redshift Spectrum, SageMaker Autopilot 으로 모델을 만들고 클러스터 안에서 추론하는 Redshift ML(그림 8), PostgreSQL 과 MySQL(Aurora 포함) 을 직접 조회하는 연합 쿼리, 반정형 데이터를 담는 SUPER 형식과 PartiQL, Lambda 를 호출하는 사용자 정의 함수를 다룹니다.

실험과 결과

• 그림 3(a): 튜닝하지 않은 3TB TPC-DS 에서 익명 처리한 경쟁 클라우드 데이터 웨어하우스 세 곳보다 최대 3배 좋은 가격 대비 성능을 보였고, 모두 튜닝한 경우에도 두 번째로 좋은 곳보다 1.5배 좋았다고 합니다.
• 그림 3(b): 데이터를 30TB 에서 1PB 로 늘리면서 컴퓨트 노드도 3개에서 100개로 비례해 늘리자 실행 시간이 거의 평평하게 유지되었습니다.
• 운영 수치: 탄력적 크기 조정과 인스턴스 간 복원은 한 달에 15,000 회 넘게 쓰였고 실패율은 0.0001% 미만이었습니다. SUPER 형식으로 JSON 을 넣으면 쪼갠 테이블에 넣을 때보다 최대 5배 빨랐습니다.

이 논문에는 표가 없고, 모든 수치는 그림과 본문에 있습니다.

지금 AWS 에서는

• Amazon Redshift Serverless, RA3 노드와 Redshift Managed Storage, Concurrency Scaling, Data Sharing, Redshift Spectrum, Redshift ML, 자동 테이블 최적화, 자동 WLM, SUPER 데이터 형식은 모두 지금 Redshift 의 공식 기능 이름입니다.
• 초록에서 언급한 Kinesis 와 MSK 로부터의 스트리밍 수집도 현재 기능으로 제공됩니다.
• 논문 이후 Aurora 같은 운영 데이터베이스의 데이터를 파이프라인 없이 Redshift 로 복제하는 zero-ETL 통합이 추가되었지만, 이 논문에는 나오지 않습니다.

함께 읽기

• 분석과 레이크하우스: 이 사이트의 기능 문서
• Aurora 2017 논문 해설: 연합 쿼리와 zero-ETL 의 출발점이 되는 운영 데이터베이스
• Amazon Science 기사 "Amazon Redshift: Ten years of continuous reinvention"