PostgreSQL을 기반으로 자동하지만 OLTP(온라인 트랜잭션 처리)에는 사용되지 않으며 OLAP(온라인 분석 처리)을 할 때 사용
성능이 매우 뛰어나 다른 데이터 웨어하우스에 비해서 열 배 더 성능이 좋으며 데이터를 페타바이트 크기까지 확장이 가능
데이터는 행 대신 열에 저장되기 때문에 열 형식 스토리지 데이터라고 함
대량 병렬 쿼리 실행 엔진인 MPP 덕분에 고성능
사용한 만큼 과금
인스턴스 종류에 따라서 Redshift 클러스터의 일부로 프로비저닝하며 쿼리를 수행하는 SQL 인터페이스가 존재
좋은 데이터웨어하우스이므로 비즈니스 인텔리전스, BI 도구로 대시보드나 쿼리를 수행해야 하는 경우 Redshift와 호환됨 예) QuickSight, Tableau는 Redshift와 통합될 수 있음
Athena와 비교하면 Redshift로 더 빠른 쿼리가 가능하고 더 많은 데이터를 결합할 수 있고 더 빠른 집계를 할 수 있음
예) 분석과 데이터 웨어하우징
Redshift Continued…
S3나 DynamoDB, DMS 등의 데이터베이스에 복사 명령을 하여 Redshift에 데이터를 불러올 수 있음
Redshift의 클러스터 내에 노드당 최대 128 컴퓨트 노드를 얻고 노드당 최대 128TB의 공간을 얻음 즉, 1노드 = 128 컴퓨트 노드 = 128TB의 공간
Redshift는 두 가지 노드가 존재 1) 리더 노드 : 쿼리 계획 및 쿼리 결과 집계에 사용 2) 컴퓨트 노드 : 쿼리를 수행하고 결과를 리더로 돌려보내는 역할
Redshift Spectrum은 S3에 대해서 직접 쿼리를 수행할 때 사용되며 처음부터 데이터를 불러올 필요가 없음
백업과 복구 기능이 존재
Redshift 클러스터는 보안을 위해 VPC에 배포되며, 보안 및 Redshift 레벨의 API에 IAM을 사용 가능, KMS도 가능
데이터베이스 모니터링 가능
데이터를 복사하면 VPC를 통해 직접 Redshift로 옮길 수 있는 Redshift 향상된 VPC 라우팅이 존재 즉, 복사 명령과 불러오기 명령, 취소 명령이 공용 인터넷 대신 S3를 통과하여 직접 VPC로 전달되는 것
Redshift – Snapshots & DR
Redshift는 다중 가용 영역이 없으며 모든 클러스터가 단일 가용 영역에 있음 그러므로 재해 복구 전략을 위해 스냅샷이 있어야 함
스냅샷은 클러스터에서 특정 기간의 백업이며 S3에 내부적으로 저장되며 변경 사항만 저장해서 증가시킬 있으며 저장 공간이 아주 큼
새 Redshift 클러스터에 스냅샷을 복원시킬 수 있으며, 스냅샷 클래스에는 두 가지 모드가 존재 1) 수동으로 가져오기 (수동 스냅샷) : 수동으로 삭제할 때까지 스냅샷이 보존됨 2) 자동화하기 (자동 스냅샷) : 8시간마다 혹은 예약된 작업의 5GB마다 스냅샷이 이루어짐 Redshift는 스냅샷 설정 모드에 관계없이 클러스터의 스냅샷을 자동으로 복사하여 AWS 리전으로 보내 재해 복구 전략을 제공
예) 기존의 Redshift 클러스터가 있고 두 번째 리전이 있을 때 스냅샷 스냅샷을 하면 자동으로 새로운 리전에 복사되며, 복사된 스냅샷으로부터 Redshift 클러스터를 복구할 수 있음
Loading data into Redshift
Redshift에 데이터를 흡수하는 세 가지 방법
Amazon Kinesis Data Firehose S3 버킷에 데이터 쓰기를 하면 Firehose는 자동으로 S3 복사 명령을 내려 다른 소스에서 데이터를 수신한 뒤에 Redshift로 전송
S3 using COPY command 복사 명령은 수동으로 쓸 수 있으며, S3에 데이터를 불러와서 Redshift에서 복사 명령을 내려 S3 버킷으로부터 데이터를 복사 이 때 Redshift 클러스터에 IAM 역할을 사용 인터넷을 사용해 S3 버킷이 인터넷을 통해 공용화되는 것을 이용할 경우 데이터 플로우는 이터넷을 통해 Redshift 클러스터로 들어오므로 VPC 라우팅이 일어나지 않음 만약 네트워크를 가상 사설 클라우드 안에서 비공개로 유지하고 싶다면 VPC 라우팅을 활성화해서 VPC를 통해 데이터 플로우를 얻을 수 있음
복사 명령
EC2 Instance JDBC driver JDBC 드라이버를 사용해서 Redshift 클러스터에 데이터 삽입이 가능 예1) 애플리케이션이 있고 Redshift 클러스터에 데이터를 쓰기 할 EC2 인스턴스가 있다면 이를 사용 예2) Redshift에 큰 배치의 데이터를 쓰기할 때 적합하며 한 번에 한 행을 쓰는 데이터베이스에는 매우 비효율적
Redshift Spectrum
S3에 데이터가 있고 Redshift로 분석하고 싶지만 Redshift에 먼저 데이터를 불러오지 않는 것 즉, Redshift 클러스터에 먼저 데이터를 불러오지 않고 Redshift Spectrum에서 수행해 데이터를 S3에서 Redshift로 불러오지 않은 상태에서 프로비저닝할 수 있으므로 Redshift의 처리 능력을 끌어올릴 수 있음
쿼리를 시작하려면 Redshift 클러스터를 미리 준비해야 함 쿼리를 시작하면 쿼리가 Redshift Spectrum의 수천 개 노드에 제출되고 이것이 S3의 데이터 상에서 쿼리를 수행
예) Redshift 클러스터에 리더 노드가 하나 있고 컴퓨트 노드가 여럿 있으며, 분석하려는 데이터는 S3 안에 존재할 때 Redshift 클러스터에 쿼리를 수행하면 S3에서 데이터를 읽는 곳이자 집계를 수행하는 곳인 Redshift Spectrum으로 수 천개의 노드로 쿼리가 제출된 후 작업이 완료되면 Redshift 클러스터에 결과를 돌려보내고 쿼리를 시작했던 위치로 돌려주면 됨
Redshift for Solutions Architect
Operations RDS와 비슷하므로 장애 조치나 유지 관리 작업을 실행할 때 아주 작은 다운타임이 발생하며 읽기나 EC2 인스턴스 확장, EBS 복구로 인해 수동 개입이 필요할 수 있어 변화가 생기면 애플리케이션도 변경해줘야 함
Security IAM 보안, VPC 네트워킹, KMS 암호화, SSL 암호화 사용
Reliability 신뢰성과 관련하여 자동 복구 기능, 교차 리전 간 스냅샷의 자동 복제 기능 제공
Performance 다른 비슷한 데이터 웨어하우징 솔루션 및 압축과 비교하여 10배 더 좋은 성능을 가짐
Cost 프로비저닝된 노드당 비용이 청구되지만 다른 데이터 웨어하우스의 10분의 1에 해당하는 요금으로 저렴
