AWS Redshift 성능 최적화 전략 정리 (DISTKEY, SORTKEY, VACUUM, ANALYZE, WLM)

 

 

Redshift는 대용량 데이터 분석에 특화된 MPP(Massively Parallel Processing) 아키텍처를 기반으로 설계된 AWS의 데이터 웨어하우스이다.  대용량 데이터에서 쿼리 성능을 최적화하기 위해 DISTKEY, SORTKEY, VACUUM, ANALYZE, WLM 설정을 이해하고 활용하는 것이 매우 중요함.

 

---

 

1. DISTKEY – 데이터를 어떻게 "분산" 할 건지?

 

Redshift는 MPP 구조이기 때문에 데이터를 여러 노드에 어떻게 나누느냐가 쿼리 성능에 직결됨
이를 제어하는 것이 DISTKEY이다.

 

💡 DISTSTYLE 옵션

유형설명

AUTO	Redshift가 자동으로 선택 (권장, 최근 기본값)
EVEN	데이터를 모든 슬라이스에 균등 분산 (JOIN 성능 최적화에는 불리)
KEY	특정 컬럼 기준 분산 – JOIN 대상이 일치할 경우 매우 효과적
ALL	모든 노드에 복제 – 작은 dimension 테이블에만 사용

 

✅ 예제

CREATE TABLE sales (
  user_id INT,
  amount FLOAT,
  sale_date DATE
)
DISTSTYLE KEY
DISTKEY (user_id);  -- 사용자 기준으로 데이터 분산

 

⚠ 실무 팁

 

 

• JOIN이 자주 발생하는 테이블이라면 KEY 사용
• 작은 LOOKUP 테이블은 DISTSTYLE ALL
• skewed distribution 여부는 SVV_DISKUSAGE, SVL_QUERY_REPORT로 진단

 

---

2. SORTKEY – 데이터를 어떤 순서로 "정렬" 할 건지?

 

정렬 키는 WHERE, ORDER BY, GROUP BY, JOIN 성능을 높임.
쿼리에서 자주 필터링하는 컬럼을 기준으로 정렬하면 Redshift는 더 빠르게 데이터를 찾을 수 있음.

 

SORTKEY 유형

유형설명

COMPOUND	기본값. 지정한 순서대로 정렬. 첫 번째 컬럼 중요
INTERLEAVED	여러 컬럼을 고르게 정렬. 다양한 조건 조합에 유리
AUTO (기본값)	Redshift가 자동 최적화. 신규 권장 방식 (기존에는 COMPOUND 사용이 많았음)

 

✅ 예제

CREATE TABLE page_views (
  view_id INT,
  user_id INT,
  view_time TIMESTAMP
)
SORTKEY (view_time);  -- 시간순 분석 최적화

⚠ 실무 팁

• 날짜 기반 필터링이 많은 경우 view_time을 첫 번째로 정렬
• INTERLEAVED는 VACUUM REINDEX로 유지보수 필요
• SVV_TABLE_INFO.unsorted 값이 50% 이상이면 VACUUM SORT ONLY 실행 고려

 

---

3. VACUUM – 정렬 유지 및 공간 회수

Redshift는 UPDATE, DELETE 이후에도 실제 데이터를 삭제하지 않고 마킹만 해두기 때문에, 불필요한 공간과 정렬 손상이 발생.

이를 복구하는 명령이 VACUUM

 

VACUUM 유형

유형설명

FULL	삭제된 로우 정리 + 정렬 유지 (가장 무겁지만 완전함)
DELETE ONLY	삭제된 로우만 정리 (정렬 유지 X)
SORT ONLY	정렬만 수행 (삭제 데이터 X)
REINDEX	INTERLEAVED SORTKEY 전용 정렬 복구

 

✅ 예제

VACUUM FULL my_table;           -- 전체 정리
VACUUM DELETE ONLY my_table;    -- 삭제된 로우만 정리

 

⚠ 실무 팁

• VACUUM 실행 시 I/O 부하 발생 가능 → 업무 시간 외에 실행
• ETL 후 자동화 스케줄 (예: Airflow, cron)
• 쿼리 성능 저하가 느껴지면 SVV_TABLE_INFO.unsorted, stats_off 확인

 

---

 

4. ANALYZE – 통계 정보 최신화로 쿼리 최적화

Redshift의 쿼리 옵티마이저는 통계 정보를 기반으로 실행 계획을 수립

INSERT, DELETE, UPDATE 이후 ANALYZE가 필수임.

 

✅ 예제

ANALYZE sales;                        -- 전체 테이블
ANALYZE sales (user_id, sale_date);  -- 특정 컬럼만

 

⚠ 실무 팁

• 대량의 데이터가 적재된 후 반드시 수행
• 자동 실행도 가능하지만, 정기적으로 수동 실행 권장
• 통계 최신 여부는 SVV_TABLE_INFO.stats_off 값으로 확인 가능 (값이 클수록 오래된 통계)

 

---

 

5. WLM (Workload Management) – 리소스를 효율적으로 나눠 쓰

 

WLM은 쿼리 그룹별로 리소스를 분배하여 병목을 방지하고 우선순위를 정할 수 있게 해줍니다.

대용량 ETL 쿼리와 사용자 조회 쿼리가 같은 자원을 쓰면 문제가 됩니다.

 

 

구성 요소

항목설명

query_group	쿼리 그룹명 (예: etl_query, bi_user 등)
memory_percent_to_use	해당 그룹에 할당할 메모리 비율
concurrency	동시에 실행 가능한 쿼리 수

 

✅ 예시 (JSON)

{
  "queues": [
    {
      "name": "etl",
      "user_group": ["etl_user"],
      "query_group": ["etl_query"],
      "memory_percent_to_use": 70,
      "concurrency": 2
    },
    {
      "name": "default",
      "concurrency": 5,
      "memory_percent_to_use": 30
    }
  ]
}

 

콘솔 → Redshift 클러스터 → WLM 구성 탭에서 설정 가능

 

 

✅ 최종 요약표

항목핵심 목적사용 시점주의사항

DISTKEY	데이터 분산 최적화	테이블 설계 시	skewed 분산 주의
SORTKEY	쿼리 성능 향상 (필터/정렬/조인)	WHERE/ORDER 패턴 확인 후 설계	COMPOUND vs INTERLEAVED 구분
VACUUM	공간 회수 및 정렬 복구	DELETE/UPDATE 이후	낮은 시간대에 실행 권장
ANALYZE	통계 갱신, 실행 계획 최적화	INSERT/UPDATE/DELETE 이후	stats_off ≥ 20% 시 수동 실행
WLM	리소스 분리/관리	성격 다른 쿼리가 동시에 돌 때	잘못된 설정은 병목 유발