Amazon Redshift FAQ

Amazon Redshift Serverless는 Amazon Redshift의 서버리스 옵션으로, 데이터 웨어하우스 인프라를 설정하고 관리할 필요 없이 몇 초 안에 분석을 더 효율적으로 실행하고 확장할 수 있습니다. Redshift Serverless를 사용하면 데이터 분석가, 개발자, 비즈니스 전문가, 데이터 사이언티스트를 비롯한 모든 사용자가 데이터 웨어하우스에서 데이터를 단순히 로드하고 쿼리하는 방법으로 데이터에서 인사이트를 얻을 수 있습니다.

AWS Management Console에서 몇 단계만으로 ‘configure Amazon Redshift Serverless(Amazon Redshift Serverless 구성)’를 선택해 데이터 쿼리를 시작할 수 있습니다. 샘플 쿼리와 함께 데이터, 센서스(census) 데이터, 벤치마크 데이터 세트와 같은 사전 로드된 샘플 데이터 세트를 활용하면 분석을 바로 시작할 수 있습니다. 데이터베이스, 스키마, 테이블을 생성하고 Amazon S3로부터 데이터를 로드하거나, Amazon Redshift 데이터 공유를 통해 데이터에 액세스하거나, Redshift가 프로비저닝한 기존 클러스터 스냅샷으로부터 복원할 수 있습니다. 또한 Amazon S3 데이터 레이크에서 Parquet나 ORC와 같은 개방형 형식의 데이터를 직접 쿼리하거나 Amazon Aurora, Amazon RDS PostgreSQL, MySQL과 같은 운영 데이터베이스에서 데이터를 쿼리할 수도 있습니다. 시작 안내서를 참조하세요.

데이터 웨어하우스 관리 경험이 없어도 클러스터를 설정, 구성, 관리하거나 웨어하우스를 튜닝하는 데 대해 걱정할 필요가 없습니다. 데이터에서 의미 있는 인사이트를 도출하거나 데이터를 통해 핵심적인 비즈니스 결과를 제공하는 데 집중할 수 있습니다. 비용을 관리 가능하게 유지하면서 사용한 부분에 대해서만 지불하면 됩니다. 사용자는 Amazon Redshift의 최고의 성능, 다양한 SQL 기능, 데이터 레이크 및 운영 데이터 웨어하우스와의 긴밀한 통합, 내장된 예측 분석 및 데이터 공유 기능에서 이점을 얻을 수 있습니다. 데이터 웨어하우스의 미세 제어가 필요하다면 Redshift 클러스터를 프로비저닝할 수 있습니다.

복잡한 조인, Amazon S3 데이터 레이크 및 운영 데이터베이스의 데이터에 대한 직접 쿼리, 구체화된 뷰, 저장 프로시저, 반정형 데이터 지원, ML과 같은 Amazon Redshift의 다양한 분석 기능과 전체적인 고성능을 계속해서 이용할 수 있습니다. Amazon Redshift와 통합된 모든 관련 서비스(Amazon Kinesis, AWS Lambda, Amazon QuickSight, Amazon SageMaker, Amazon EMR, AWS Lake formation, AWS Glue 등)는 Amazon Redshift Serverless에서도 계속 작동합니다.

모든 분석 사용 사례를 변함없이 실행할 수 있습니다. 간단한 시작 워크플로, 자동 확장, 사용량에 따른 비용 지불을 제공하는 Amazon Redshift Serverless는 계속 변화하고 예측할 수 없는 컴퓨팅 수요를 가진 임시적 비즈니스 분석 워크로드와 간헐적이거나 산발적인 워크로드를 빠르게 시작할 필요가 있는 개발 및 테스트 환경을 실행하는 데 있어 이전보다 더욱 효율적이고 저렴해졌습니다.

Amazon S3, Amazon RDS, Amazon DynamoDB, Amazon EMR, AWS Glue, AWS Data Pipeline 및 Amazon EC2 또는 온프레미스의 모든 SSH 지원 호스트를 비롯하여 다양한 데이터 소스에서 Amazon Redshift로 데이터를 로드할 수 있습니다. Amazon Redshift는 데이터 웨어하우스 클러스터에 데이터를 모을 수 있는 속도를 최대화하기 위해 각 컴퓨팅 노드에 데이터를 병렬로 로드합니다. 클라이언트는 ODBC 또는 JDBC를 사용하여 Amazon Redshift에 연결한 다음 'Insert' SQL 문을 사용하여 데이터를 삽입할 수 있습니다. 그러한 방법은 SQL Insert 문이 단일 리더 노드를 통해 로드하는 반면 각 컴퓨팅 노드에 데이터를 병렬로 로드하기 때문에 S3 또는 DynamoDB를 사용하는 것보다 더 느리게 처리될 수 있습니다. Amazon Redshift에 데이터를 로드하는 방법에 대한 자세한 내용은 시작 안내서를 참조하세요.

Redshift 자동 복사는 고객 개입 없이 Amazon S3 폴더를 추적하고 새 파일을 모아서 복사 문을 자동화하는 기능을 제공합니다. 자동 복사를 사용하지 않으면 복사 문이 기존 파일에 대한 파일 모으기 프로세스를 즉시 시작합니다. 자동 복사는 기존 복사 명령을 확장하며 1/ 새 파일에 대해 지정된 Amazon S3 경로를 모니터링하여 파일 모으기 프로세스를 자동화하고, 2/ 복사 구성을 재사용하여 반복적인 모으기 작업을 위해 새 복사 문을 만들고 실행할 필요성을 줄이고, 3/ 데이터 중복을 피하기 위해 로드된 파일을 추적하는 기능을 제공합니다.

시작하려면 고객은 연결된 IAM 역할을 사용하여 Redshift 클러스터/서버리스 엔드포인트에서 액세스할 수 있는 Amazon S3 폴더를 갖고 있고 대상으로 사용할 Redshift 테이블을 생성해야 합니다. Amazon S3 경로와 Redshift 테이블이 준비되면 고객은 복사 명령을 사용하여 복사 작업을 생성할 수 있습니다. 복사 작업이 생성되면 Redshift는 백그라운드에서 지정된 Amazon S3 경로를 추적하기 시작하고 사용자 정의 복사 문을 시작하여 새 파일을 대상 테이블에 자동으로 복사합니다.

주요 사용 사례로 1/ Amazon EMR 및 AWS Glue를 사용하여 데이터 모으기 및 변환 파이프라인(배치 및 스트리밍)의 일부로 Amazon Redshift에 데이터를 액세스하고 로드하는 Apache Spark 작업을 실행하는 고객, 2/ Amazon SageMaker를 사용하여 Apache Spark로 기계 학습을 수행하고 특성 추출 및 변환을 위해 Amazon Redshift에 저장된 데이터에 액세스해야 하는 고객, 3/ Apache Spark를 사용하여 Amazon Redshift의 데이터에 대한 대화형 분석을 수행하는 Amazon Athena 고객이 있습니다.

Baikal은 다음과 같은 이점을 제공합니다.

• 인증되지 않은 Apache Spark 버전을 설정하고 유지 관리하는 수작업 단계에 대해 걱정할 필요 없이 Amazon Redshift의 데이터에 대해 Spark 애플리케이션을 시작하고 실행할 수 있어 사용이 간편합니다.
• Amazon EMR, AWS Glue, Amazon Athena, Amazon SageMaker와 같은 다양한 AWS 서비스에서 Amazon Redshift와 함께 Apache Spark를 최소한의 구성으로 편리하게 사용할 수 있습니다.
• Amazon Redshift에서 Apache Spark 애플리케이션을 실행하는 동안 향상된 성능 제공합니다.

Amazon Aurora Zero-ETL to Amazon Redshift는 작성 후 몇 초 만에 Amazon Aurora의 트랜잭션 데이터를 Amazon Redshift에서 사용할 수 있게 완전관리형 솔루션을 제공하므로 Amazon Aurora 및 Amazon Redshift 고객은 페타바이트 규모의 트랜잭션 데이터에 대해 실시간에 가까운 분석 및 기계 학습을 실행할 수 있습니다. Amazon Aurora Zero-ETL to Amazon Redshift를 사용하면 고객은 Amazon Redshift로 분석하려는 데이터가 포함된 Amazon Aurora 테이블을 선택하기만 하면 됩니다. 이 기능은 스키마와 데이터를 Amazon Redshift로 원활하게 복제합니다. 이를 통해 복잡한 데이터 파이프라인을 구축하고 관리할 필요가 줄어들기 때문에 고객이 애플리케이션 개선에 집중할 수 있습니다. Amazon Aurora Zero-ETL to Amazon Redshift를 통해 고객은 여러 Amazon Aurora 데이터베이스 클러스터의 데이터를 동일한 Amazon Redshift 인스턴스로 복제하여 여러 애플리케이션에서 포괄적인 인사이트를 획득하는 동시에 핵심 분석 자산을 통합하여 상당한 비용 절감 효과를 얻고 운영 효율성을 높일 수 있습니다. Amazon Aurora Zero-ETL to Amazon Redshift를 통해 고객은 구체화된 뷰, 데이터 공유, 여러 데이터 스토어 및 데이터 레이크에 대한 연동 액세스와 같은 Amazon Redshift의 핵심 분석 및 기계 학습 기능에 액세스할 수도 있습니다. 이를 통해 고객은 실시간에 가까운 분석과 핵심 분석을 결합하여 비즈니스 의사 결정을 알리는 시간에 민감한 인사이트를 효과적으로 도출할 수 있습니다. 또한 고객은 트랜잭션에 Amazon Aurora를 사용하고 분석에 Amazon Redshift를 사용하여 공유 컴퓨팅 리소스가 없으므로 성능이 뛰어나고 운영상 안정적인 솔루션을 제공합니다.

Amazon Redshift와 Amazon Aurora 제로 ETL 통합은 트랜잭션 분석을 위한 두 서비스 간의 원활한 통합을 제공합니다.

스트리밍 데이터는 스트림을 쿼리할 때 시간 가변성 관계의 발전을 캡처한다는 점에서 기존 데이터베이스 테이블과 다릅니다. 반면에 테이블은 이 시간 가변성 관계의 특정 시점 스냅샷을 캡처합니다. Amazon Redshift의 고객은 일반 테이블에서 작업하고 'ELT'와 같은 기존 배치 모델을 사용하여 데이터의 다운스트림 처리(즉, 변환)를 수행하는 데 익숙합니다. 고객이 ELT 워크플로를 지원하기 위해 쿼리된 시간까지 누적된 스트림의 특정 시점 뷰를 가능한 한 빨리 구체화할 수 있도록 AWS는 Redshift 구체화된 뷰(MV)를 사용하는 방법을 제공합니다.

주요한 사용 사례는 다음과 같습니다.

• 읽기 워크로드 격리를 제공하고 요금을 최적화하기 위해 중앙 ETL 클러스터가 데이터를 다수의 BI/분석 클러스터와 공유합니다.
• 데이터 공급자가 데이터를 외부 소비자와 공유합니다.
• 고객, 제품과 같은 일반적인 데이터 집합을 다른 비즈니스 그룹 간에 공유하고 광범위한 분석 및 데이터 과학을 위해 협업합니다.
• 관리를 간소화하기 위해 데이터 웨어하우스를 분산합니다.
• 개발, 테스트, 프로덕션 환경 간에 데이터를 공유합니다.
• 다른 AWS 분석 서비스의 Redshift 데이터에 액세스합니다.

교차 데이터베이스 쿼리를 사용하면 연결된 데이터베이스에 관계 없이 액세스 권한이 있는 모든 Redshift 데이터베이스에서 데이터를 원활하게 쿼리하고 조인할 수 있습니다. 여기에는 클러스터의 로컬 데이터베이스와 함께 원격 클러스터에서 사용 가능한 공유 데이터 세트가 포함될 수 있습니다. 교차 데이터베이스 쿼리는 멀티 테넌트 구성을 지원하기 위해 별도의 데이터베이스로 데이터를 구성하는 유연성을 제공합니다.

AWS Data Exchange를 이용하면 AWS 고객이 AWS에서 서드 파티 데이터를 안전하고 더 효율적으로 교환하고 사용할 수 있습니다. 거의 모든 산업에서 데이터 분석가, 제품 관리자, 포트폴리오 관리자, 데이터 사이언티스트, 금융시장 분석가, 임상시험 기술자, 개발자는 분석을 실시하고, ML을 훈련하고, 데이터에 기반한 의사결정을 내리기 위해 더 많은 데이터에 접근하길 원합니다. 그러나 다수의 공급자로부터 데이터를 검색할 수 있는 하나의 장소가 없고 공급자가 데이터를 제공하는 방식에 일관성이 없기 때문에 이들은 배송된물리적인 미디어, FTP 자격 증명, 맞춤형 API 호출 등을 이용하는 현실입니다. 반대로 많은 조직은 자신의 데이터를 연구나 상업적 목적으로 제공하려 하지만 데이터 전달, 자격 부여, 결제 기술을 구축하고 유지하기가 어렵고 비용이 많이 듭니다. 이러한 점은 가치 있는 데이터의 공급을 더욱 저해하고 있습니다.

Amazon Redshift Serverless는 데이터 웨어하우스 용량을 자동으로 프로비저닝하고 기본 리소스를 지능적으로 확장합니다. Amazon Redshift Serverless는 몇 초 만에 용량을 조정하여 가장 까다롭고 변동성이 큰 워크로드에 대해서도 일관된 고성능과 단순화된 운영을 제공합니다. 동시성 확장 기능을 사용하면 일관성 있게 빠른 쿼리 성능을 유지하면서 무제한으로 동시 사용자 및 동시 쿼리를 지원할 수 있습니다. 동시성 확장 기능을 활성화하면 Amazon Redshift는 클러스터의 쿼리 대기열이 증가할 경우 클러스터 용량을 자동으로 추가합니다.

수동 확장을 위해 쿼리 성능을 향상하거나 CPU, 메모리 또는 I/O 초과 사용률에 대응하려는 경우 AWS Management Console이나 ModifyCluster API를 통해 탄력적 확장을 사용하여 데이터 웨어하우스 클러스터의 노드 수를 늘릴 수 있습니다. 데이터 웨어하우스 클러스터를 수정하는 경우 요청한 변경 사항이 즉시 적용됩니다. Redshift 데이터 웨어하우스 클러스터의 컴퓨팅 사용률, 스토리지 사용률 및 읽기/쓰기 트래픽에 대한 지표는 AWS Management Console 또는 Amazon CloudWatch API를 통해 무료로 확인할 수 있습니다. 또한 Amazon CloudWatch의 사용자 지정 지표 기능을 사용하여 사용자 정의 지표를 추가할 수 있습니다.

Amazon Redshift Spectrum에서는 여러 Redshift 클러스터를 실행하여 Amazon S3에 있는 같은 데이터를 액세스할 수 있습니다. 서로 다른 클러스터를 다양한 사용 사례에 사용할 수 있습니다. 예를 들어 한 클러스터를 표준 보고에 사용하고 다른 클러스터를 데이터 과학 쿼리에 사용할 수 있습니다. 마케팅 팀에서는 운영 팀과 별개로 자체 클러스터를 사용할 수 있습니다. Redshift Spectrum은 쿼리 실행을 공유 리소스 풀의 여러 Redshift Spectrum 작업자에게 자동으로 분산하여 Amazon S3의 데이터를 읽고 처리하며, 결과를 Redshift 클러스터로 가져와서 나머지 작업을 처리합니다.

경우에 따라 다릅니다. 동시성 확장 기능을 사용하면 동시성 확장 시 클러스터에서 읽기 및 쓰기를 완전히 사용할 수 있습니다. 탄력적 크기 조정을 사용할 경우에는 크기 조정 기간에 4~8분 동안 클러스터를 사용할 수 없습니다. 관리형 스토리지에서 Redshift RA3 스토리지 탄력성 기능을 통해 클러스터를 완전히 사용할 수 있으며, 관리형 스토리지와 컴퓨팅 노드 간에 데이터가 자동으로 이동합니다.

탄력적 크기 조정은 쿼리 처리량(throughput)을 관리하기 위해 단일 Redshift 클러스터에서 노드를 몇 분 내에 추가하거나 제거합니다. 예를 들어 하루의 특정 시간대 또는 월말 보고 업무를 위한 ETL 워크로드를 정시에 완료하려면 Amazon Redshift 리소스가 추가로 필요할 수 있습니다. 동시성 확장은 클러스터 리소스를 추가하여 전반적인 쿼리 동시성을 높입니다.

아니요. 동시성 확장은 대규모로 확장 가능한 Amazon Redshift 리소스 풀로서, 고객은 직접 액세스할 수 없습니다.

Amazon Redshift는 AWS Single Sign-On(SSO), 다중 인증, 열 수준 액세스 제어, 행 수준 보안, 역할 기반 액세스 제어 및 Amazon Virtual Private Cloud(VPC)를 위한 기본 제공 ID 관리 및 페더레이션을 통해 업계 최고 수준의 보안을 지원합니다. Amazon Redshift를 사용하면 전송 중과 저장 시에 데이터가 암호화됩니다. 모든 Amazon Redshift 보안 기능은 추가 비용 없이 즉시 사용 가능한 상태로 제공되며, 가장 까다로운 보안, 개인 정보 보호 및 규정 준수 요구 사항을 지원할 수 있습니다. AWS는 ISO 27001, SOC, HIPAA/HITECH, FedRAMP 등 어떤 제공업체보다 많은 보안 표준 및 규정 준수 인증을 지원하는 이점을 제공합니다.

예. Amazon Redshift는 역할 기반 액세스 제어를 지원합니다. 행 수준 액세스 제어를 통해 하나 이상의 역할을 사용자에게 할당하고 역할별로 시스템 및 객체 권한을 할당할 수 있습니다. 즉시 사용 가능한 시스템 역할(루트 사용자, dba, 운영자 및 보안 관리자)을 사용하거나 역할을 직접 만들 수 있습니다.

AWS Lambda 사용자 정의 함수(UDF)를 통해 Amazon Redshift에서 AWS Lambda 함수를 UDF로 사용하고 Redshift SQL 쿼리에서 호출할 수 있습니다. 이 기능을 사용하면 SQL 쿼리용 사용자 지정 확장을 작성하여 다른 서비스 또는 타사 제품과 더 긴밀하게 통합할 수 있습니다. Protegrity와 같은 공급업체와 통합하여 외부 토큰화, 데이터 마스킹, 데이터 식별 또는 식별 취소를 수행하고, 쿼리 시간에 사용자의 권한 및 그룹에 따라 민감한 데이터를 보호하거나 보호 해제하는 Lambda UDF를 작성할 수 있습니다.

동적 데이터 마스킹 지원을 통해 고객은 데이터 마스킹 정책을 관리하여 민감한 데이터를 쉽게 보호하고 세분화된 액세스를 제어할 수 있습니다. 모든 사용자에게 노출할 수 없는 민감한 데이터를 갖고 있는 여러 사용자와 객체가 포함된 애플리케이션이 있다고 가정합니다. 다양한 사용자 그룹에 부여할 다양한 세분화된 보안 수준을 제공해야 합니다. Redshift Dynamic Data Masking은 고객이 일관되고, 형식을 보존하며, 되돌릴 수 없는 마스킹된 데이터 값을 정의할 수 있도록 구성할 수 있습니다. 기능이 정식 출시되면 즉시 사용을 시작합니다. 보안 관리자는 몇 가지 명령만으로 정책을 생성하고 적용할 수 있습니다.

예. Microsoft Azure Active Directory, Active Directory Federation Services, Okta, Ping Federate 또는 기타 SAML 호환 ID 제공업체와 같은 회사 ID 제공업체를 사용하려는 고객은 Single Sign-On을 제공하도록 Amazon Redshift를 구성할 수 있습니다. Microsoft Azure Active Directory(AD) ID를 사용하여 Amazon Redshift 클러스터에 사인온할 수 있습니다. 따라서 Redshift에서 Azure Active Directory ID를 복제하지 않고도 Redshift에 사인온할 수 있습니다.

예. Amazon Redshift 클러스터에 인증할 때 추가적인 보안을 위해 다중 인증(MFA)을 사용할 수 있습니다.

Amazon Redshift는 자동으로 데이터 웨어하우스 클러스터에서 장애가 발생한 노드를 검색하고 해당 노드를 교체합니다. Dense Compute(DC) 및 Dense Storage(DS2) 클러스터에서 데이터는 높은 데이터 내구성을 보장하기 위해 컴퓨팅 노드에 저장됩니다. 노드가 교체되면 데이터가 다른 노드의 미러 복사본으로 새로 고쳐집니다. Amazon S3에 데이터가 저장되고 로컬 드라이브는 데이터 캐시로만 사용되기 때문에 RA3 클러스터와 Redshift 서버리스는 동일한 방식으로 영향을 받지 않습니다. 데이터 웨어하우스 클러스터는 교체 노드가 프로비저닝되고 DB에 추가될 때까지 쿼리 및 업데이트에 사용할 수 없습니다. Amazon Redshift는 교체 노드를 즉각적으로 사용할 수 있게 만들고, 먼저 Amazon S3에서 가장 빈번하게 액세스되는 데이터를 로드하여 가능한 한 빨리 데이터 쿼리 작업을 재개할 수 있게 해 줍니다. 단일 노드 클러스터는 데이터 복제를 지원하지 않습니다. 드라이브 장애가 발생하는 경우 S3의 스냅샷에서 클러스터를 복원해야 합니다. 프로덕션에 최소 두 개의 노드를 사용하는 것이 좋습니다.

Amazon Redshift 데이터 웨어하우스가 단일 AZ 배포이고 클러스터의 가용 영역이 사용 불가능해지면 Amazon Redshift는 데이터 손실 또는 애플리케이션 변경 없이도 클러스터를 다른 AWS 가용 영역(AZ)으로 자동으로 이동합니다. 이를 활성화하려면 클러스터 구성 설정에서 재배치 기능을 활성화해야 합니다.

단일 AZ 배포와 달리 이제 고객은 다중 AZ 배포에서 데이터 웨어하우스를 실행하여 Redshift의 가용성을 개선할 수 있습니다. 다중 AZ 배포를 통해 여러 AWS 가용 영역(AZ)에서 데이터 웨어하우스를 동시에 실행하고 예기치 않은 장애 시나리오에서도 계속 운영할 수 있습니다. 다중 AZ 배포가 하나의 엔드포인트가 있는 단일 데이터 웨어하우스로 관리되기 때문에 비즈니스 연속성을 유지하기 위해 애플리케이션을 변경할 필요가 없습니다. 다중 AZ 배포는 자동 복구 용량을 보장하여 복구 시간을 단축하며 AZ 장애에 대한 최고 수준의 가용성과 복원력이 필요한 비즈니스 크리티컬 분석 애플리케이션을 사용하는 고객을 대상으로 합니다. 또한 이를 통해 고객은 AWS Well-Architected Framework의 신뢰성 원칙 권장 사항을 더 잘 준수하는 솔루션을 구현할 수 있습니다. Amazon Redshift 다중 AZ에 대한 자세한 내용을 알아보려면 여기를 참조하세요.

RPO는 Recovery Point Objective의 약어로 장애 발생 시 데이터 최신성 보장을 설명하는 용어입니다. RPO는 마지막 데이터 복구 지점 이후 허용 가능한 최대 시간입니다. 이는 마지막 복구 지점과 서비스 중단 사이에 허용 가능한 데이터 손실로 간주되는 것을 결정합니다. Redshift 다중 AZ는 RPO = 0을 지원합니다. 즉, 장애 발생 시 데이터가 최신 상태로 유지됩니다. 출시 전 테스트에서 Amazon Redshift 다중 AZ 배포를 통한 RTO는 드물지만 AZ 장애가 발생할 경우 60초 미만인 것으로 나타났습니다.

Redshift 재배치는 모든 새 RA3 클러스터 및 서버리스 엔드포인트에서 기본적으로 사용되며, 이를 통해 대규모 운영 중단 시 데이터 손실이나 추가 비용 없이 다른 AZ에서 데이터 웨어하우스를 다시 시작할 수 있습니다. 재배치 사용은 무료이지만 이는 복구 중인 AZ의 리소스 가용성에 따른 최선의 방법이며 Recovery Time Objective(RTO)가 새 클러스터 시작과 관련된 다른 문제의 영향을 받을 수 있다는 제한 사항이 있습니다. 이로 인해 복구 시간이 10분에서 60분 사이가 될 수 있습니다. Redshift 다중 AZ는 수십 초 단위로 측정된 RTO를 제공하여 고가용성 요구 사항을 지원하며 용량 제한이나 새 클러스터 생성 시 발생할 수 있는 기타 잠재적인 문제의 영향을 받지 않기 때문에 지속적인 운영을 보장합니다.

예. Amazon Redshift는 업계 표준 SQL을 사용하며 표준 JDBC 및 ODBC 드라이버를 사용하여 액세스할 수 있습니다. Amazon Redshift 사용자 지정 JDBC 및 ODBC 드라이버는 Redshift Console의 [클라이언트 연결(Connect Client)] 탭에서 다운로드할 수 있습니다. AWS에서는 주요 BI 및 ETL 공급업체와의 통합을 검증했으며, 이 중 상당수가 데이터 로드 및 분석을 시작하는 데 도움이 되도록 무료 평가판을 제공합니다. 또한, AWS Marketplace로 이동하여 Amazon Redshift와 연동되도록 설계된 솔루션을 몇 분 만에 배포 및 구성할 수 있습니다.

Amazon Redshift Spectrum은 모든 Amazon Redshift 클라이언트 도구를 지원합니다. 이러한 클라이언트 도구는 ODBC 또는 JDBC 연결을 사용하여 계속해서 Amazon Redshift 클러스터 엔드포인트에 연결할 수 있으므로, 변경할 필요가 없습니다.

Redshift 클러스터의 로컬 스토리지에 있는 테이블에 사용하는 것과 정확히 동일한 쿼리 구문 및 동일한 쿼리 기능을 사용하여 Redshift Spectrum에 있는 테이블에 액세스합니다. 외부 테이블은 이를 등록할 때 사용한 CREATE EXTERNAL SCHEMA 명령에 정의된 스키마 이름을 사용하여 참조됩니다.

Amazon Redshift Spectrum은 현재 Avro, CSV, Grok, Amazon Ion, JSON, ORC, Parquet, RCFile, RegexSerDe, Sequence, Text 및 TSV를 비롯한 수많은 오픈 소스 데이터 형식을 지원합니다.<br>Amazon Redshift Spectrum에서는 현재 Gzip 및 Snappy 압축을 지원합니다.

로컬 테이블에서와 마찬가지로 스키마 이름을 사용하여 원하는 테이블을 정확히 선택할 수 있습니다. 쿼리에 schema_name.table_name을 사용하면 됩니다.

예. CREATE EXTERNAL SCHEMA 명령은 Hive Metastore를 지원합니다. 현재 Hive Metastore에 대한 DDL은 지원하지 않습니다.

시스템 테이블 SVV_EXTERNAL_TABLES를 쿼리하여 해당 정보를 받을 수 있습니다.

예. Amazon Redshift ML 기능을 통해 SQL 사용자는 친숙한 SQL 명령을 사용하여 기계 학습(ML) 모델을 생성하고 훈련하며 배포할 수 있습니다. Amazon Redshift ML을 사용하면 완전관리형 ML 서비스인 Amazon SageMaker에서 Amazon Redshift의 데이터를 활용할 수 있습니다. Amazon Redshift는 비지도 학습(K-Means) 및 지도 학습(Autopilot, XGBoost, MLP 알고리즘)을 모두 지원합니다. 또한 AWS Language AI 서비스를 사용하여 사전 구축된 Lambda UDF 함수로 SQL 쿼리의 텍스트 필드를 변환, 수정 및 분석할 수 있습니다. 블로그 게시물을 참조하세요.

Amazon Redshift가 제공하는 데이터 API를 사용하여 모든 유형의 클라우드 네이티브 및 컨테이너화된 기존 서버리스 웹 서비스 기반 애플리케이션 및 이벤트 기반 애플리케이션에서 Amazon Redshift의 데이터에 원활하게 액세스할 수 있습니다. 데이터 API를 사용하면 드라이버를 구성하고 데이터베이스 연결을 관리할 필요가 없기 때문에 Amazon Redshift에 대한 액세스가 간소화됩니다. 대신, 데이터 API에서 제공하는 보안 API 엔드포인트를 호출하기만 하면 Amazon Redshift 클러스터에 대해 SQL 명령을 실행할 수 있습니다. 데이터베이스 연결 관리와 데이터 버퍼링은 데이터 API에서 처리합니다. 데이터 API는 비동기식이므로, 나중에 결과를 검색할 수 있습니다. 쿼리 결과는 24시간 동안 저장됩니다.

데이터 API는 IAM 보안 인증 정보 및 AWS Secrets Manager의 보안 암호 키 사용 모두를 지원합니다. 데이터 API는 AWS Identity and Access Management(IAM) 보안 인증 정보를 연동하므로, API 호출에서 데이터베이스 보안 인증 정보를 전달하지 않고도 Okta 또는 Azure Active Directory와 같은 ID 제공업체나 Secrets Manager에 저장된 데이터베이스 보안 인증 정보를 사용할 수 있습니다.

예. AWS CLI에서 aws redshift-data 명령줄 옵션을 사용하여 데이터 API를 사용할 수 있습니다.

AWS Lambda, AWS Cloud9, AWS AppSync, Amazon EventBridge 등의 다른 서비스에서도 데이터 API를 사용할 수 있습니다.

아니요. 데이터 API 사용에 대한 별도의 요금은 없습니다.

Amazon Aurora MySQL 호환 버전, Amazon Aurora PostgreSQL 호환 버전(미리 보기), Amazon RDS for MySQL, Amazon DynamoDB(한정 평가판)는 Amazon Redshift와의 제로 ETL 통합을 지원합니다.

트랜잭션 데이터에 거의 실시간으로 액세스해야 하는 경우 Amazon Redshift와 Aurora의 제로 ETL 통합을 사용해야 합니다. 제로 ETL 통합을 사용하면 간단한 SQL 명령으로 Amazon Redshift ML을 활용할 수 있습니다.

Amazon Redshift와 Aurora의 제로 ETL 통합은 지원되는 AWS 리전의 Aurora MySQL 3.05 버전(MySQL 8.0.32와 호환 가능) 이상을 위한 Aurora MySQL 호환 에디션에서 사용할 수 있습니다.

Amazon Redshift와 Aurora의 제로 ETL 통합은 미국 동부(오하이오) 리전의 Aurora PostgreSQL 15.4용 Aurora PostgreSQL 호환 에디션에서 사용할 수 있습니다.

Amazon Redshift와 Aurora의 제로 ETL 통합은 복잡한 데이터 파이프라인을 구축하고 유지 관리해야 하는 필요성을 없애줍니다. 단일 또는 여러 Aurora 데이터베이스 클러스터의 데이터를 단일 Amazon Redshift 데이터베이스 클러스터로 통합하고, Amazon Redshift를 사용하여 Aurora의 페타바이트급 트랜잭션 데이터에 대해 거의 실시간 분석 및 ML을 실행할 수 있습니다.

Amazon Redshift와 Aurora의 제로 ETL 통합은 Amazon Redshift Serverless 및 Amazon Aurora Serverless v2와 호환됩니다. Aurora Serverless v2와 Amazon Redshift Serverless를 모두 사용하는 경우 데이터 파이프라인용 인프라를 관리할 필요 없이 트랜잭션 데이터에 대해 거의 실시간 분석을 생성할 수 있습니다.

Amazon RDS 콘솔에서 Aurora 소스와 Amazon Redshift 대상을 지정하여 제로 ETL 통합을 생성하고 시작할 수 있습니다. 통합이 생성되면 Aurora 데이터베이스가 Amazon Redshift에 복제되고, 초기 시드가 완료되면 데이터 쿼리를 시작할 수 있습니다. 자세한 내용은 Amazon Redshift와 Amazon Aurora의 제로 ETL 통합에 대한 시작 안내서를 읽어보세요.

Aurora에서 Amazon Redshift로의 제로 ETL 통합은 트랜잭션을 원자적으로 복제하여 소스 Aurora 데이터베이스와 대상 Amazon Redshift 클러스터 간의 데이터 일관성을 보장합니다.
이 통합에서 트랜잭션의 원자성에 대한 몇 가지 요점은 다음과 같습니다.

• Aurora에서 커밋된 트랜잭션만 Amazon Redshift에 복제됩니다. 커밋되지 않았거나 롤백된 트랜잭션은 해당되지 않습니다.
• 통합에서는 2단계 커밋 프로세스를 사용하여 각 트랜잭션을 Amazon Redshift에 원자적으로 적용합니다. 트랜잭션의 모든 데이터 변경 사항이 적용되거나, 오류가 발생하는 경우 아무 것도 적용되지 않습니다.
• 소스와 대상 간에 트랜잭션 일관성이 유지됩니다. 복제 후에는 특정 트랜잭션에 대한 데이터가 Aurora와 Amazon Redshift에서 모두 일관되게 유지됩니다.
• DDL 또는 DML을 통한 스키마 변경도 무결성을 유지하기 위해 원자적으로 적용됩니다.
• 트랜잭션의 원자적 적용은 데이터베이스 간에 부분 트랜잭션이나 일관되지 않은 데이터 상태가 발생하지 않도록 합니다.

Amazon Redshift와 Aurora의 제로 ETL 통합에서는 소스 Aurora 데이터베이스와 대상 Amazon Redshift 클러스터 간의 완전한 트랜잭션 일관성이 유지됩니다.

다음은 스키마 변경이 처리되는 방법에 대한 몇 가지 요점입니다.

• CREATE TABLE, ALTER TABLE, DROP TABLE 같은 DDL 문은 Aurora에서 Amazon Redshift로 자동으로 복제됩니다.
• 통합 중에 복제된 스키마 변경에 맞게 Amazon Redshift 테이블이 확인되고 조정됩니다. 예를 들어 Aurora에 열을 추가하면 Amazon Redshift에 해당 열이 추가됩니다.
• 복제 및 스키마 변경은 소스 데이터베이스와 대상 데이터베이스 간의 지연을 최소화하면서 실시간으로 자동으로 수행됩니다.
• DML 변경이 DDL 변경과 동시에 발생하는 경우에도 스키마 일관성이 유지됩니다.

로컬 Amazon Redshift 데이터베이스에서 구체화된 뷰를 생성하여 제로 ETL 통합을 통해 복제된 데이터를 변환할 수 있습니다. 로컬 데이터베이스에 연결하고 데이터베이스 간 쿼리를 사용하여 대상 데이터베이스에 액세스합니다. 세 부분으로 구성된 표기법(destination-database-name.schema-name.table-name)을 사용하여 정규화된 객체 이름을 사용하거나, 대상 데이터베이스 및 스키마 페어를 참조하는 외부 스키마를 생성하고 두 부분으로 구성된 표기법(external-schema-name.table-name)을 사용할 수 있습니다.

제로 ETL 통합 및 지속적인 데이터 변경 처리는 추가 비용 없이 제공됩니다. 제로 ETL 통합을 생성하고 그 일부로 생성되는 변경 데이터를 처리하는 데 사용한 기존 Amazon RDS 및 Amazon Redshift 리소스에 대한 요금이 부과됩니다. 이러한 리소스에는 다음이 포함될 수 있습니다.

• 향상된 binlog를 활성화하여 사용된 추가 I/O 및 스토리지
• Amazon Redshift 데이터베이스를 시드하기 위한 초기 데이터 내보내기에 드는 스냅샷 내보내기 비용
• 복제된 데이터를 저장하기 위한 추가 Amazon Redshift 스토리지
• 소스에서 대상으로 데이터를 이동하는 데 드는 AZ 사이의 데이터 전송 비용

자세한 내용은 Amazon Aurora 요금을 참조하세요.

Amazon Redshift와 Amazon RDS for MySQL의 제로 ETL 통합과 관련하여 가장 자주 묻는 질문을 보려면 Amazon RDS for MySQL FAQ를 참조하세요. 이 통합의 요금에 대해 자세히 알아보려면 Amazon RDS for MySQL 요금을 참조하세요.

Amazon Redshift RA3 클러스터와 Amazon Redshift Serverless는 Redshift 관리형 스토리지를 사용하여 가용한 데이터의 최신 복사본을 항시 유지합니다. DS2 및 DC2 클러스터는 장애 발생 시 최신 복사본을 이용할 수 있도록 클러스터의 데이터를 미러링합니다. 백업은 모든 Redshift 클러스터 유형에서 자동으로 생성되어 24시간 유지되며, 지난 24시간에 대한 서버리스 복구 지점이 제공됩니다.

무기한 보관할 수 있는 자체 백업을 생성할 수도 있습니다. 이러한 백업은 언제든 생성할 수 있으며, 장기 보관을 위해 Amazon Redshift 자동 백업 또는 Amazon Redshift Serverless 복구 지점을 사용자 백업으로 변환할 수 있습니다.

또한, Amazon Redshift는 재해 복구를 위해 스냅샷 또는 복구 지점을 다른 리전의 Amazon S3에 비동기적으로 복제할 수 있습니다.

DS2 또는 DC2 클러스터에서 무료 백업 스토리지는 데이터 웨어하우스 클러스터의 노드 전체 스토리지 크기로 제한되며 활성 데이터 웨어하우스 클러스터에만 적용됩니다.

예를 들어, 총 8TB의 데이터 웨어하우스 스토리지가 있는 경우 추가 요금 없이 최대 8TB의 백업 스토리지가 제공됩니다. 백업 보존 기간을 1일보다 길게 설정하려는 경우 AWS Management Console 또는 Amazon Redshift API를 사용하여 해당 작업을 수행할 수 있습니다. 자동 스냅샷에 대한 자세한 내용은 Amazon Redshift 관리 안내서를 참조하세요.

Amazon Redshift는 변경된 데이터만 백업하므로 대부분 스냅샷은 적은 양의 무료 백업 스토리지만 사용합니다. 백업을 복원해야 하는 경우, 백업 보존 기간 내 모든 자동 백업에 액세스할 수 있습니다. 복원할 백업을 선택하면 새로운 데이터 웨어하우스 클러스터가 프로비저닝되고 데이터가 해당 데이터 웨어하우스 클러스터로 복구됩니다.

AWS Management Console 또는 ModifyCluster API를 사용하여 RetentionPeriod 파라미터를 수정하면 자동 백업 보존 기간을 관리할 수 있습니다. 자동 백업을 완전히 비활성화하려는 경우 보존 기간을 0으로 설정하면 됩니다(권장하지 않음).

데이터 웨어하우스 클러스터를 삭제할 때 삭제 시 최종 스냅샷을 생성할지 여부를 지정할 수 있습니다. 이렇게 하면 나중에 삭제된 데이터 웨어하우스 클러스터를 복원할 수 있습니다. 이전에 생성한 데이터 웨어하우스 클러스터의 모든 수동 스냅샷은 삭제하도록 선택하지 않는 한 유지되며 표준 Amazon S3 요금이 청구됩니다.

Amazon Redshift 데이터 웨어하우스 클러스터의 컴퓨팅 사용률, 스토리지 사용률 및 읽기/쓰기 트래픽에 대한 지표는 AWS Management Console 또는 Amazon CloudWatch API를 통해 무료로 확인할 수 있습니다. 또한, Amazon CloudWatch의 사용자 지정 지표 기능을 사용하여 추가적인 사용자 정의 지표를 추가할 수 있습니다. AWS Management Console에서는 모든 클러스터의 상태와 성능을 모니터링할 수 있는 모니터링 대시보드를 제공합니다. Amazon Redshift는 AWS Management Console을 통해 쿼리 및 클러스터 성능 정보도 제공합니다. 이 정보를 사용하면 가장 많은 시스템 리소스를 소비하고 있는 사용자 및 쿼리를 확인할 수 있고 쿼리 계획 및 실행 통계를 확인하여 성능 문제를 진단할 수 있습니다. 또한 각 컴퓨팅 노드의 리소스 사용량을 확인하여 모든 노드에서 데이터 및 쿼리의 로드가 균등하게 분배되고 있는지 확인할 수 있습니다.

Amazon Redshift에서는 수정 사항, 개선 사항 및 새로운 기능을 클러스터에 적용하기 위해 정기적으로 유지 관리를 수행합니다. 프로그래밍 방식으로 또는 Redshift 콘솔을 사용하여 클러스터를 수정하여 예약된 유지 관리 기간을 변경할 수 있습니다. 이러한 유지 관리 기간에는 Amazon Redshift 클러스터가 일반 작업에 사용되지 않습니다. 리전별 유지 관리 기간과 일정에 대한 자세한 내용은 Amazon Redshift 관리 안내서의 유지 관리 기간을 참조하세요.