들어가며
이전 글에서는 Amazon Redshift의 기본 개념과 데이터 웨어하우스의 역할, 그리고 OLAP 서비스와 Redshift 아키텍처를 살펴보았습니다.
이번 글에서는 Redshift를 실제 운영할 때 자주 접하게 되는 기능인 Redshift Spectrum, Durability(내구성), Scaling(확장)에 대해 알아보겠습니다. 특히 대용량 데이터를 어떻게 효율적으로 조회하고, 장애 상황에서도 데이터를 안전하게 보호하며, 증가하는 분석 요청에 대응하는지 중심으로 살펴보겠습니다.
1. Redshift Spectrum이란?
Amazon Redshift Spectrum은 S3에 저장된 데이터를 Redshift로 적재하지 않고도 SQL로 직접 조회할 수 있는 기능입니다.
일반적으로 데이터를 분석하려면 먼저 Redshift 내부로 데이터를 적재해야 합니다.
하지만 Spectrum을 사용하면 데이터를 이동하지 않고도 S3의 데이터를 바로 조회할 수 있습니다.
즉, 데이터 이동 시간을 줄이고 S3에 저장된 데이터를 그대로 분석할 수 있습니다.
2. 왜 Spectrum을 사용할까?
데이터 레이크에는 수년간의 로그나 원본 데이터가 저장되는 경우가 많습니다.
예를 들어
- 웹 로그
- IoT 센서 데이터
- CloudTrail 로그
- 애플리케이션 로그
등이 모두 S3에 저장되어 있다고 가정해보겠습니다. 이 데이터를 모두 Redshift로 적재하면
- 저장 공간 증가
- 적재 시간 증가
- 비용 증가
와 같은 문제가 발생할 수 있습니다.
Spectrum을 사용하면 필요한 데이터만 SQL로 조회하여 분석할 수 있습니다.
3. Spectrum 동작 구조
Spectrum은 Redshift와 S3가 함께 동작하는 구조입니다.
실행 과정은 다음과 같습니다.
- 사용자가 SQL을 실행합니다.
- Redshift가 SQL을 분석합니다.
- S3의 데이터를 Spectrum이 읽습니다.
- 필요한 결과만 사용자에게 반환합니다.
이 과정에서 AWS Glue Data Catalog를 함께 사용하는 경우가 많으며, S3 데이터의 스키마 정보를 관리할 수 있습니다.
4. Durability란?
Durability는 장애가 발생하더라도 데이터를 안전하게 보존하는 능력을 의미합니다.
Redshift는 데이터의 안정성을 위해 다양한 내구성 기능을 제공합니다.
4-1) Amazon S3 자동 백업
Redshift는 데이터를 Amazon S3에 자동으로 백업합니다.
노드 장애가 발생하더라도 S3에 저장된 백업 데이터를 이용하여 클러스터를 복구할 수 있습니다.
즉,
Redshift
↓
자동 백업
↓
Amazon S3
형태로 데이터가 보호됩니다.
4-2) Auto Snapshot
Redshift는 일정 주기마다 자동으로 스냅샷을 생성합니다.
스냅샷은 특정 시점의 데이터를 저장하는 기능으로,
- 장애 복구
- 실수로 삭제한 데이터 복원
- 특정 시점 복구
등에 활용됩니다. 필요하다면 사용자가 수동 스냅샷을 생성할 수도 있습니다.
4-3) Single AZ 구조
Redshift 클러스터는 Single Availability Zone(AZ) 에 생성됩니다.
즉, 하나의 AZ에서 Leader Node와 Compute Node가 동작합니다.
하지만 데이터를 S3에 자동으로 백업하고 스냅샷을 관리하기 때문에 장애가 발생하더라도 새로운 클러스터를 생성하여 데이터를 복원할 수 있습니다.
즉,
- 실행 환경 → Single AZ
- 데이터 보호 → S3 백업 및 Snapshot
이라는 구조를 사용합니다.
Redshift가 Single AZ인 이유는 대용량 데이터를 병렬 처리하는 과정에서 노드 간 통신 속도가 매우 중요하기 때문입니다. 여러 AZ에 노드를 분산하면 네트워크 지연이 증가하여 분석 성능이 떨어질 수 있으므로, Redshift는 성능을 우선해 Single AZ에서 실행하고, 데이터 보호는 S3 자동 백업과 스냅샷으로 보완하는 구조를 사용합니다.
5. Scaling이란?
서비스가 성장하면 분석해야 하는 데이터와 사용자가 계속 증가합니다. Redshift는 이러한 상황에 대응하기 위해 다양한 확장 기능을 제공합니다.
5-1) Elastic Resize
Elastic Resize는 클러스터의 노드 수를 빠르게 늘리거나 줄이는 기능입니다.
2 Nodes
↓
4 Nodes
처럼 비교적 짧은 시간 안에 확장할 수 있습니다.
주기적인 분석 업무나 일시적인 트래픽 증가에 적합합니다.
5-2) Classic Resize
Classic Resize는 노드 수뿐 아니라 노드 타입까지 변경할 수 있는 확장 방식입니다.
RA3
↓
DC2
처럼 클러스터 자체를 변경하는 경우 사용됩니다.
Elastic Resize보다 시간이 오래 걸리지만 더 큰 구조 변경이 가능합니다.
5-3) Concurrency Scaling
동시에 많은 사용자가 SQL을 실행하면 기존 클러스터만으로는 처리 시간이 길어질 수 있습니다.
Concurrency Scaling은 이러한 상황에서 추가 클러스터를 자동으로 생성하여 읽기 요청을 분산 처리합니다.
사용자 증가
↓
추가 Cluster 생성
↓
동시 SQL 처리
이를 통해 여러 사용자가 동시에 분석을 수행하더라도 안정적인 성능을 유지할 수 있습니다.
6. 언제 활용할까?
| 기능 | 활용 사례 |
| Redshift Spectrum | S3에 저장된 로그 분석 |
| 자동 백업 | 장애 복구 |
| 자동 스냅샷 | 특정 시점 복원 |
| Elastic Resize | 분석량 증가 대응 |
| Classic Resize | 클러스터 구성 변경 |
| Concurrency Scaling | 동시 사용자 증가 대응 |
7. 마치며
이번 글를 정리하며 Redshift는 단순히 데이터를 저장하고 분석하는 데이터 웨어하우스가 아니라, 대규모 분석 환경을 안정적으로 운영하기 위한 다양한 기능을 제공한다는 점을 이해할 수 있었습니다.
특히 Redshift Spectrum을 이용하면 S3에 저장된 데이터를 Redshift로 적재하지 않고도 SQL로 직접 분석할 수 있어 데이터 레이크와 데이터 웨어하우스를 효율적으로 함께 활용할 수 있다는 점을 알게 되었습니다. 또한 자동 백업과 스냅샷을 통해 장애 상황에서도 데이터를 안전하게 보호할 수 있으며, Elastic Resize와 Concurrency Scaling 같은 확장 기능을 통해 데이터 증가와 사용자 증가에도 유연하게 대응할 수 있다는 점도 배울 수 있었습니다.
이러한 기능들을 함께 활용하면 Redshift를 단순한 분석 데이터베이스가 아닌, 대규모 데이터 분석 플랫폼의 핵심 구성 요소로 활용할 수 있다는 점을 이해할 수 있었습니다.
'Data Engineering > AWS' 카테고리의 다른 글
| Amazon Redshift - WLM, VACUUM, SQA (0) | 2026.07.02 |
|---|---|
| Amazon Redshift - Distribution Style 이해 (0) | 2026.07.02 |
| Amazon Redshift란? (0) | 2026.07.02 |
| Amazon DocumentDB란? (0) | 2026.07.01 |
| Aurora란? (0) | 2026.07.01 |