Amazon Redshift 기초: 데이터 웨어하우스 언제 사용해야 할까?
Amazon Redshift의 핵심 개념과 RDS, Athena와의 차이점을 비교하고, 데이터 웨어하우스가 필요한 시나리오를 알아봅니다.
관련 시험 도메인
- Domain 3: Design High-Performing Architectures
핵심 요약 (BLUF)
Amazon Redshift는 PB 규모의 데이터를 컬럼 기반으로 저장하고 복잡한 분석 쿼리(OLAP)를 빠르게 처리하는 데이터 웨어하우스입니다. OLTP(트랜잭션)는 RDS, S3 임시 쿼리는 Athena, 대규모 분석/BI는 Redshift를 선택합니다.
시험 팁
시험 핵심: "데이터 웨어하우스, OLAP, BI, PB 규모 분석" → Redshift, "OLTP, 트랜잭션" → RDS, "S3 서버리스 쿼리" → Athena
Redshift는 언제 사용해야 할까?
적합한 경우
- 비즈니스 인텔리전스(BI): 복잡한 집계, 조인 쿼리
- 데이터 웨어하우스: 여러 소스의 데이터를 통합 분석
- PB 규모 분석: 대용량 데이터에 대한 분석 쿼리
- 정기 보고서: 일별/주별/월별 대시보드
- ETL 후 분석: S3 → Redshift로 데이터 적재 후 분석
부적합한 경우
- OLTP 워크로드: 실시간 트랜잭션 → RDS/Aurora
- 임시(Ad-hoc) S3 쿼리: 간단한 S3 분석 → Athena
- NoSQL: 키-값/문서 데이터 → DynamoDB
- 실시간 스트리밍 분석: 밀리초 지연 → Kinesis Data Analytics
Redshift 핵심 특징
컬럼 기반 스토리지
행(Row) 기반 (RDS):
ID | Name | Age | City
1 | Kim | 30 | Seoul
2 | Lee | 25 | Busan
3 | Park | 35 | Seoul
→ 한 행의 모든 컬럼을 함께 저장
→ 특정 행 조회에 유리 (OLTP)
컬럼(Column) 기반 (Redshift):
ID: 1, 2, 3
Name: Kim, Lee, Park
Age: 30, 25, 35
City: Seoul, Busan, Seoul
→ 같은 컬럼의 값을 함께 저장
→ 집계 쿼리에 유리 (SUM, AVG, COUNT)
→ 높은 압축률
시험 팁
컬럼 기반 = 분석에 최적: SELECT AVG(age) FROM users 같은 쿼리 시, age 컬럼만 읽으면 되므로 행 기반보다 훨씬 빠릅니다.
MPP (Massively Parallel Processing)
┌──────────────────────────────────────┐
│ Leader Node │
│ (쿼리 파싱, 실행 계획, 결과 집계) │
└──────────┬───────────────────────────┘
│
┌─────┼─────┬─────────┐
▼ ▼ ▼ ▼
┌─────┐┌─────┐┌─────┐┌─────┐
│Comp ││Comp ││Comp ││Comp │
│Node1││Node2││Node3││Node4│
│ ││ ││ ││ │
│슬라이스││슬라이스││슬라이스││슬라이스│
└─────┘└─────┘└─────┘└─────┘
→ 쿼리를 병렬로 분할 실행
노드 유형
| 유형 | 특징 | 사용 사례 |
|---|---|---|
| RA3 | 스토리지/컴퓨트 분리, 관리형 스토리지 | 대부분의 워크로드 (권장) |
| DC2 | SSD 기반, 빠른 로컬 스토리지 | 500GB 이하 소규모 |
| DS2 | HDD 기반, 대용량 | 레거시 (RA3로 마이그레이션 권장) |
Redshift Serverless
클러스터 관리 없이 자동으로 용량을 프로비저닝합니다.
| 항목 | Redshift 프로비저닝 | Redshift Serverless |
|---|---|---|
| 인프라 관리 | 노드 수, 유형 직접 설정 | 자동 |
| 과금 | 노드 시간 기반 | RPU(Redshift Processing Unit) 사용량 |
| 확장 | 수동 리사이즈 / Elastic Resize | 자동 |
| 적합한 경우 | 예측 가능한 워크로드 | 간헐적/가변적 워크로드 |
Redshift Spectrum
Redshift에서 S3의 데이터를 직접 쿼리합니다 (데이터 로드 불필요).
[Redshift 클러스터]
│
├── 내부 테이블 (Redshift 스토리지)
│
└── 외부 테이블 (S3 데이터) ← Spectrum
│
▼
[S3: 로그, 이력 데이터]
→ 데이터를 Redshift에 적재하지 않고 S3에서 직접 쿼리
시험 팁
Redshift Spectrum vs Athena: 둘 다 S3 데이터를 쿼리하지만, Spectrum은 Redshift 클러스터가 필요하고 내부 테이블과 조인 가능. Athena는 완전 서버리스.
Redshift vs RDS vs Athena
| 항목 | RDS/Aurora | Redshift | Athena |
|---|---|---|---|
| 유형 | OLTP (트랜잭션) | OLAP (분석) | 서버리스 쿼리 |
| 스토리지 | 행(Row) 기반 | 열(Column) 기반 | S3 (자체 저장 X) |
| 데이터 규모 | GB ~ TB | TB ~ PB | S3에 의존 |
| 쿼리 유형 | INSERT/UPDATE/SELECT | 복잡한 집계/조인 | 임시(Ad-hoc) 쿼리 |
| 인프라 | 관리형 인스턴스 | 클러스터 / Serverless | 완전 서버리스 |
| 과금 | 인스턴스 시간 | 노드 시간 / RPU | 스캔 데이터량 ($5/TB) |
| 사용 사례 | 앱 백엔드, CRUD | BI, 대시보드, 보고서 | S3 로그 분석 |
Redshift 기능 요약
| 기능 | 설명 |
|---|---|
| Enhanced VPC Routing | 모든 COPY/UNLOAD 트래픽을 VPC 경유 |
| 스냅샷 | 자동/수동 백업, 다른 리전으로 복사 가능 |
| Federated Query | RDS/Aurora의 데이터를 직접 쿼리 |
| 데이터 공유 | 클러스터 간 데이터 공유 (데이터 복사 불필요) |
| Concurrency Scaling | 쿼리 급증 시 자동 확장 |
| 암호화 | KMS/HSM으로 저장 데이터 암호화 |
SAA-C03 시험 출제 포인트
- ✅ OLAP vs OLTP: "분석 쿼리 = Redshift, 트랜잭션 = RDS"
- ✅ 컬럼 기반: "집계 쿼리에 최적화된 컬럼 스토리지"
- ✅ Spectrum: "S3 데이터를 Redshift에서 직접 쿼리"
- ✅ Athena와 차이: "Athena = 서버리스 임시 쿼리, Redshift = 지속적 분석"
- ✅ Enhanced VPC Routing: "데이터 전송을 VPC 내부로 강제"
시험 팁
시험 문제 예시: "여러 소스의 데이터를 통합하여 PB 규모의 BI 보고서를 생성해야 합니다. 적합한 서비스는?" → 정답: Amazon Redshift (OLAP, PB 규모, BI 분석)
자주 묻는 질문 (FAQ)
Q: Redshift와 Athena 중 무엇을 사용해야 하나요?
간헐적인 S3 데이터 임시 쿼리는 Athena가 적합합니다. 여러 소스의 데이터를 통합하여 지속적으로 복잡한 분석을 수행하려면 Redshift가 적합합니다.
Q: Redshift Serverless와 프로비저닝 중 무엇을 선택해야 하나요?
워크로드가 예측 가능하고 지속적이면 프로비저닝이 비용 효율적이며, 간헐적이고 가변적이면 Serverless가 적합합니다.
Q: Redshift는 실시간 데이터를 처리할 수 있나요?
Redshift Streaming Ingestion으로 Kinesis Data Streams의 데이터를 실시간에 가깝게 수집할 수 있습니다. 하지만 밀리초 수준의 실시간 분석에는 Kinesis Data Analytics가 더 적합합니다.
Q: Redshift에 데이터를 어떻게 로드하나요?
COPY 명령으로 S3, DynamoDB, EMR에서 데이터를 로드합니다. S3에서 COPY가 가장 일반적이고 빠른 방법입니다. INSERT는 소량 데이터에만 사용하세요.
Q: Redshift 비용을 절감하려면?
Reserved Instance(1년/3년 약정)로 최대 75% 절감, Concurrency Scaling 무료 크레딧 활용, 불필요한 스냅샷 삭제, RA3 노드로 스토리지 비용 분리 등을 고려하세요.