Day 1 - Amazon Redshift: 분산/정렬 키와 워크로드 최적화

Redshift 아키텍처 개요

Amazon Redshift 는 페타바이트급 컬럼형 MPP(Massively Parallel Processing) 데이터웨어하우스다. 클러스터는 리더 노드 하나와 여러 컴퓨트 노드로 구성된다.

클라이언트(SQL) ──► 리더 노드 : 파싱 · 실행 계획 · 결과 취합
                        │
        ┌───────────────┼───────────────┐
   컴퓨트 노드 1    컴퓨트 노드 2    컴퓨트 노드 3
   [슬라이스][슬라이스] ...            ← 슬라이스 = 병렬 처리의 최소 단위

• 리더 노드는 쿼리를 계획해 컴퓨트 노드에 나눠 주고, 돌아온 중간 결과를 합친다.
• 각 컴퓨트 노드는 여러 슬라이스로 나뉜다. 테이블의 행은 슬라이스에 나뉘어 저장되고, 슬라이스마다 자기 몫을 동시에 처리한다.
• 저장은 컬럼 단위다. 컬럼 하나의 값들이 1MB 블록에 모여 압축되므로 "수억 행에서 컬럼 몇 개만 집계"하는 쿼리가 빠르다.

💡 관련 이론: MPP 의 성능은 가장 느린 슬라이스가 정한다. 모든 슬라이스가 끝나야 쿼리가 끝나기 때문이다. 한 슬라이스에 데이터가 몰리면(스큐) 나머지 슬라이스가 놀고 있어도 쿼리는 그 슬라이스를 기다린다. 분산 키 설계의 목표는 "고르게 나누되, 조인할 행끼리는 같은 곳에"다.

분산 스타일 (Distribution Style)

테이블의 행이 슬라이스에 어떻게 놓이는지를 정한다.

-- KEY 분산: 지정 컬럼의 값이 같으면 같은 슬라이스에 배치
CREATE TABLE orders (
  order_id   BIGINT,
  customer_id BIGINT,
  amount     DECIMAL(12,2)
)
DISTSTYLE KEY
DISTKEY (customer_id);
 
-- ALL 분산: 테이블 전체를 모든 노드에 복제 (작은 차원 테이블용)
CREATE TABLE dim_region (region_id INT, region_name VARCHAR(50))
DISTSTYLE ALL;
 
-- EVEN 분산: 라운드로빈으로 균등 분배 (조인 키가 명확치 않을 때)
CREATE TABLE event_log (event_id BIGINT, payload VARCHAR(2000))
DISTSTYLE EVEN;

조인에서 벌어지는 일이 분산 스타일을 고르는 기준이다.

• 두 테이블이 같은 컬럼을 DISTKEY 로 가지면 조인할 행이 이미 같은 슬라이스에 있다. 네트워크로 행을 옮기지 않는 코로케이티드 조인이 된다.
• 한쪽이 ALL 이면 모든 노드에 사본이 있으므로 역시 옮길 것이 없다.
• 그 외에는 조인 직전에 한쪽(또는 양쪽) 테이블의 행을 조인 키 기준으로 슬라이스 사이에 다시 뿌린다. EXPLAIN 에서 DS_DIST_NONE·DS_DIST_ALL_NONE 은 재분배 없음, DS_BCAST_INNER(안쪽 테이블을 전 노드로 복사)·DS_DIST_BOTH(양쪽 재분배)는 비용이 큰 신호다.

DISTKEY 는 테이블당 컬럼 하나다. 여러 테이블과 조인하는 팩트 테이블은 가장 크고 가장 자주 조인하는 상대의 키를 고르고, 나머지 작은 차원은 ALL 로 둔다.

• ALL 은 "작은 테이블"보다 "천천히 변하는 테이블" 에 맞는 선택이다. 쓰기가 노드 수만큼 반복되기 때문이다. 공식 문서는 아주 작은 차원 테이블은 쿼리 중 재분배 비용이 원래 낮아 ALL 의 이득이 크지 않다고도 적는다. 시험에서는 "작은 차원 테이블 + 조인 재분배 제거 = ALL"로 묻는다.
• AUTO 가 스타일을 바꾸는 작업은 백그라운드에서 일어난다.

⚠️ 함정: DISTKEY 를 조인 키라는 이유만으로 고르면 스큐가 난다. 값이 몇 개뿐이거나(status, country) 한 값에 행이 몰린 컬럼(NULL 이 대부분인 컬럼, 한 대형 고객이 주문의 절반을 차지하는 customer_id)은 한 슬라이스를 무겁게 만든다. SVV_TABLE_INFO 의 skew_rows 가 크면 키를 바꾸거나 EVEN 으로 간다.

-- 테이블별 분산 스타일, 정렬 키, 스큐, 미정렬 비율 확인
SELECT "table", diststyle, sortkey1, skew_rows, unsorted, stats_off
FROM svv_table_info
ORDER BY skew_rows DESC;

정렬 키 (Sort Key)

정렬 키는 디스크에 행을 정렬해 저장한다. Redshift 는 컬럼 데이터를 1MB 블록에 담고 블록마다 최소·최대값을 메타데이터로 둔다(zone map). 범위 조건이 걸리면 최소·최대 범위가 조건과 겹치지 않는 블록을 통째로 건너뛴다.

CREATE TABLE sales (
  sale_date  DATE,
  region     VARCHAR(20),
  amount     DECIMAL(12,2)
)
DISTKEY (region)
COMPOUND SORTKEY (sale_date, region);

• 5년치를 날짜로 정렬해 두고 한 달을 조회하면 블록의 대부분을 읽지 않는다. 정렬되어 있지 않으면 값이 블록마다 흩어져 최소·최대 범위가 넓어지고, 건너뛸 블록이 없어진다.
• zone map 은 정렬 키가 없어도 존재한다. 정렬 키가 하는 일은 건너뛸 수 있게 값을 모아 주는 것이다.

• SORTKEY AUTO 로 두면 Redshift 가 쿼리 패턴을 보고 정렬 키를 고른다. 공식 문서의 기본 권장이 이것이다.
• 정렬 키에 함수를 씌운 조건(WHERE TRUNC(sale_ts) = ...)은 블록 건너뛰기를 무력화한다. 컬럼을 그대로 비교한다.
• 동시성 스케일링은 INTERLEAVED 정렬 키 테이블의 쿼리를 받지 못한다.

RA3, 관리형 스토리지, Redshift Serverless

• RA3 의 핵심은 "스토리지가 찼다고 컴퓨팅을 늘릴 필요가 없다"는 것이다. 데이터 공유, 제로 ETL 대상, 쓰기 작업의 동시성 스케일링이 RA3·Serverless 를 요구한다.
• Serverless 의 용량 단위는 RPU 다(1 RPU = 메모리 16GB). 기본 용량의 기본값은 128 RPU 이고 4 RPU 부터 설정할 수 있다. 쿼리가 없으면 컴퓨팅 요금이 나가지 않는다. 최대 용량·최대 RPU-시간 한도로 비용 상한을 건다.
• 현행 가격 페이지는 RA3 와 함께 RG 라는 새 노드 타입을 현 세대로 안내한다. 시험 자료는 대체로 RA3 대 DC2 구도로 설명한다.

Redshift Spectrum

데이터를 Redshift 에 적재하지 않고 S3 의 파일을 외부 테이블로 직접 조회한다.

-- Spectrum 외부 스키마 + S3 데이터와 내부 테이블 조인
CREATE EXTERNAL SCHEMA spectrum_ext
FROM DATA CATALOG DATABASE 'datalake_db'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftSpectrumRole';
 
SELECT d.region, SUM(s.amount)
FROM spectrum_ext.raw_events s   -- S3 의 외부 테이블
JOIN dim_region d ON s.region_id = d.region_id  -- Redshift 내부 테이블
WHERE s.dt = '2026-06-26'        -- 외부 테이블의 파티션 컬럼 → 프루닝
GROUP BY d.region;

• 외부 테이블의 정의는 Glue Data Catalog(또는 Hive 메타스토어)에 있다. Athena 가 쓰는 테이블을 그대로 쓴다.
• 조건 필터링과 집계 같은 무거운 작업은 클러스터와 별개인 Spectrum 계층으로 내려가 처리된다. 클러스터 자원을 적게 쓰고, 여러 클러스터가 같은 S3 데이터를 사본 없이 조회한다.
• 과금은 스캔한 바이트 기준이다(쿼리당 최소 10MB). 그래서 Athena 와 똑같이 파티션·Parquet·압축이 곧 비용이다.
• 외부 테이블은 읽기 전용이다. UPDATE 같은 변경은 지원하지 않는다.
• 클러스터와 버킷은 같은 리전이어야 한다.
• 핫 데이터는 Redshift 에, 오래된 대용량 이력은 S3 + Spectrum 에 두고 뷰로 합쳐 보는 것이 레이크하우스 패턴이다.

WLM, 동시성 스케일링, SQA

워크로드 관리(WLM) 는 쿼리를 큐에 넣고 큐마다 자원을 나눠 준다.

• 수동 WLM 의 기본 큐는 동시 실행 5 로 시작한다. 슬롯을 늘리면 슬롯당 메모리가 줄어, 메모리 안에서 끝나던 쿼리가 디스크에 중간 결과를 쓰며 느려진다. "동시성을 올렸더니 더 느려졌다"의 원인이다.
• 쿼리는 사용자 그룹이나 쿼리 그룹 레이블(SET query_group TO 'critical_dashboards';)로 큐에 배정된다.
• 쿼리 모니터링 규칙(QMR): 실행 시간·스캔 행 수 같은 지표가 임계를 넘는 쿼리를 기록(log)·중단(abort)하거나, 수동 WLM 에서는 다른 큐로 이동(hop), 자동 WLM 에서는 우선순위를 변경한다. 폭주 쿼리 방어 장치다. 큐 단위 WLM 타임아웃은 더 이상 권장되지 않고 QMR 로 대체한다.
• SQA(Short Query Acceleration): 짧게 끝날 쿼리를 긴 쿼리 뒤에 줄 세우지 않고 먼저 처리한다. 짧은 쿼리 전용 큐를 따로 만들 필요가 없어진다.

동시성 스케일링은 큐에 쿼리가 쌓이면 임시 클러스터를 자동으로 붙여 대기 중인 쿼리를 그쪽에서 돌린다.

• WLM 큐의 동시성 스케일링 모드를 auto 로 켠다. 붙일 수 있는 클러스터 수는 max_concurrency_scaling_clusters(기본 1)로 정한다.
• 읽기 쿼리뿐 아니라 COPY·INSERT·DELETE·UPDATE·CTAS 같은 쓰기 작업도 지원한다(쓰기는 RA3 계열에서만).
• 과금은 임시 클러스터가 실제로 쿼리를 돌린 시간만, 초 단위다. 메인 클러스터가 하루 가동되면 1시간의 무료 크레딧이 쌓이고 최대 30시간까지 누적된다. 그래서 하루 한 번 짧게 몰리는 피크는 대개 추가 비용 없이 흡수된다.
• 받지 못하는 쿼리: INTERLEAVED 정렬 키 테이블, 임시 테이블, Python·Lambda UDF 를 쓰는 쿼리, DISTSTYLE ALL 테이블에 대한 쓰기 등.

동시성 스케일링은 "스토리지와 메인 클러스터는 그대로 두고 처리 용량만 잠깐 빌리는" 모델이다. 매일 아침 대시보드 갱신처럼 짧고 주기적인 폭증에 맞는다. 하루 종일 큐가 차 있다면 그것은 폭증이 아니라 용량 부족이므로 클러스터를 키우거나(리사이즈) 쿼리·키 설계를 고쳐야 한다.

적재: COPY 를 제대로 쓰기

COPY sales
FROM 's3://acme-datalake-curated/sales/2026/06/'
IAM_ROLE 'arn:aws:iam::123456789012:role/RedshiftCopyRole'
FORMAT AS PARQUET;

• COPY 는 슬라이스들이 S3 파일을 나눠 읽는 병렬 적재다. 단건 INSERT 를 반복하는 것은 안티패턴이다.
• 분할 가능한 파일(압축하지 않은 CSV, Parquet·ORC)은 Redshift 가 128MB 이상이면 자동으로 쪼개 병렬로 읽는다.
• 분할할 수 없는 파일(gzip 한 CSV, JSON 등)은 직접 나눠야 한다. 압축 후 1MB~1GB 의 비슷한 크기로, 파일 수는 슬라이스 수의 배수로 맞춘다. 큰 gzip 파일 하나는 슬라이스 하나가 혼자 읽어 직렬 적재가 된다.
• 매니페스트 파일로 적재할 파일 목록을 명시하면 프리픽스에 섞인 엉뚱한 파일을 피할 수 있다.
• 빈 테이블에 처음 COPY 할 때 COMPUPDATE 로 컬럼별 압축 인코딩이 자동 선택된다.
• 반대 방향은 UNLOAD 다. 쿼리 결과를 S3 로(Parquet·파티션 지정 가능) 병렬로 내보낸다.

유지보수와 기타 최적화

• UPDATE·DELETE 는 행을 즉시 지우지 않고 삭제 표시만 한다. 대량 삭제 뒤 디스크가 줄지 않고 스캔이 느린 것은 VACUUM 이 아직 돌지 않아서다.
• 통계가 낡으면(stats_off 가 큼) 옵티마이저가 조인 순서와 분산 방식을 잘못 고른다. 대량 적재 뒤에는 통계를 확인한다.
• 머티리얼라이즈드 뷰는 Spectrum 외부 테이블 위에도 만들 수 있어, S3 를 매번 스캔하는 비용을 줄인다. Kinesis Data Streams·MSK 에서 바로 받아 오는 스트리밍 수집도 머티리얼라이즈드 뷰로 구현된다.

증상 → 원인 → 조치

지문 단서 → 정답 판별표

내일은 클러스터 없이 S3 를 SQL 로 조회하는 Athena 와 그 비용 구조를 다룬다.

📖 용어

• MPP : 데이터를 여러 노드에 나눠 동시에 처리하는 구조. Massively Parallel Processing.
• 슬라이스 : 컴퓨트 노드를 나눈 병렬 처리 단위. 테이블의 행이 슬라이스별로 저장된다.
• 분산 키(DISTKEY) : 행을 어느 슬라이스에 둘지 정하는 컬럼. 값이 같으면 같은 슬라이스로 간다.
• 코로케이티드 조인 : 조인할 행이 이미 같은 슬라이스에 있어 재분배 없이 수행되는 조인.
• 스큐(skew) : 데이터가 일부 슬라이스에 몰린 상태. 그 슬라이스가 쿼리 전체를 늦춘다.
• zone map : 블록마다 기록해 둔 최소·최대값. 조건과 겹치지 않는 블록을 건너뛰는 데 쓰인다.
• Redshift Managed Storage(RMS) : RA3·Serverless 가 쓰는, 컴퓨팅과 분리된 관리형 스토리지.
• RPU : Redshift Serverless 의 용량 단위. 사용한 RPU-시간만큼 과금된다.
• WLM : 쿼리를 큐로 나눠 동시성과 메모리를 배분하는 워크로드 관리 기능.
• 외부 테이블 : 데이터는 S3 에 있고 정의만 카탈로그에 있는 테이블. Spectrum 이 읽는다.