클러스터 크기 조정 클러스터 일시 중지 및 다시 시작 클러스터 이름 변경 클러스터 종료 및 삭제

Amazon Redshift에서 클러스터 관리 개요

클러스터를 생성한 후에는 클러스터에 대해 몇 가지 작업을 수행할 수 있습니다. 이러한 작업으로는 크기 조정, 일시 중지, 다시 시작, 이름 바꾸기 및 삭제가 있습니다.

Amazon Redshift에서 클러스터 크기 조정

데이터 웨어하우징 용량 및 성능 요건이 변화를 거듭하면서 클러스터의 크기 조정을 통해 Amazon Redshift의 컴퓨팅 및 스토리지 옵션을 최대한 활용할 수 있게 되었습니다.

크기 조정 작업에는 두 가지 유형이 있습니다.

탄력적 크기 조정 - 클러스터에 노드를 추가하거나 클러스터에서 노드를 제거할 수 있습니다. 또한 DS2 노드를 RA3 노드로 변경하는 등, 노드 유형을 변경할 수 있습니다. 탄력적 크기 조정 작업은 일반적으로 몇 분 안에 빠르게 완료됩니다. 따라서 이를 첫 번째 옵션으로 사용하는 것이 좋습니다. 탄력적 크기 조정을 수행하면, 각 노드에 메모리와 디스크 공간이 할당되어 있는 파티션인 데이터 슬라이스가 재배포됩니다. 탄력적 크기 조정은 다음과 같은 경우에 적합합니다.
- 기존 클러스터에서 노드를 추가하거나 줄이지만 노드 유형은 변경하지 않음 - 이를 일반적으로 인플레이스 크기 조정이라고 합니다. 이 유형의 크기 조정을 수행하면 실행 중인 일부 쿼리는 성공적으로 완료되지만 다른 일부 쿼리는 작업의 일부로서 삭제될 수 있습니다. 탄력적 크기 조정은 몇 분 안에 완료됩니다.
- 클러스터의 노드 유형 변경 - 노드 유형을 변경하면 스냅샷이 생성되고 데이터가 소스 클러스터에서 새 노드 유형으로 구성된 클러스터로 재배포됩니다. 완료되면 실행 중인 쿼리가 삭제됩니다. 인플레이스 크기 조정과 마찬가지로 빠르게 완료됩니다.
클래식 크기 조정 - 노드 유형, 노드 수 또는 두 가지 모두를 탄력적 크기 조정과 유사한 방식으로 변경할 수 있습니다. 클래식 크기 조정은 완료하는 데 시간이 더 걸리지만 마이그레이션할 노드 수 또는 유형의 변경 폭이 탄력적 크기 조정의 범위를 벗어나는 경우에 유용할 수 있습니다. 예를 들어 노드 수가 매우 큰 폭으로 변경되는 경우에 적용될 수 있습니다.

탄력적 크기 조정

동일한 유형의 노드를 추가하거나 제거할 경우, 탄력적 크기 조정 작업의 단계는 다음과 같습니다.

탄력적 크기 조정 시 클러스터 스냅샷이 생성됩니다. 이 스냅샷에는 적절한 경우 항상 노드에 대한 no-backup 테이블이 포함됩니다. (RA3와 같은 일부 노드 유형에는 no-backup 테이블이 없습니다.) 자동 스냅샷을 비활성화해 클러스터에 최신 스냅샷이 없는 경우 백업 작업에 시간이 오래 걸릴 수 있습니다. (크기 조정 작업을 시작하기 전에 시간을 최소화하기 위해 자동화된 스냅샷을 활성화하거나 크기 조정을 시작하기 전에 수동 스냅샷을 생성하는 것이 좋습니다.) 탄력적 크기 조정을 시작하고 스냅샷 작업이 진행 중인 경우 스냅샷 작업이 몇 분 내에 완료되지 않으면 크기 조정이 실패할 수 있습니다. 자세한 내용은 Amazon Redshift 스냅샷 및 백업 섹션을 참조하세요.
이 작업은 클러스터 메타데이터를 마이그레이션합니다. 클러스터를 몇 분간 사용할 수 없습니다. 대부분의 쿼리가 일시적으로 중지되고 연결은 열린 상태로 유지됩니다. 하지만 일부 쿼리를 삭제하지 못할 수도 있습니다. 이 단계는 짧습니다.
세션 연결이 복구되고 쿼리가 다시 시작됩니다.
탄력적 크기 조정은 백그라운드에서 노드 슬라이스로 데이터를 다시 분산합니다. 클러스터는 읽기 및 쓰기 작업에 사용할 수 있지만 일부 쿼리의 경우 실행 시간이 길어질 수 있습니다.
작업이 완료되면 Amazon Redshift에서 이벤트 알림을 보냅니다.

탄력적 크기 조정을 사용하여 노드 유형을 변경하는 경우 동일한 유형의 노드를 추가하거나 제거할 때와 유사하게 작동합니다. 먼저 스냅샷이 생성됩니다. 새로운 대상 클러스터는 스냅샷의 최신 데이터를 사용하여 프로비저닝되고, 데이터는 백그라운드에서 새 클러스터로 전송됩니다. 이 기간 동안 데이터는 읽기 전용입니다. 크기 조정이 거의 끝나가면 Amazon Redshift가 새 클러스터를 가리키도록 엔드포인트를 업데이트하고, 소스 클러스터의 모든 연결이 종료됩니다.

예약 노드(예: DS2 예약 노드)가 있는 경우 크기 조정을 수행할 때 RA3 예약 노드로 업그레이드할 수 있습니다. 탄력적 크기 조정을 수행할 때 또는 콘솔을 사용하여 스냅샷에서 복원할 때 이 작업을 수행할 수 있습니다. 콘솔 가이드에서는 이 프로세스를 안내합니다. RA3 노드로 업그레이드에 대한 자세한 내용은 RA3 노드 유형으로 업그레이드를 참조하세요.

탄력적 크기 조정은 테이블을 정렬하지 않고 디스크 공간을 회수하지 않기 때문에 vacuum 작업을 대신할 수 없습니다. 자세한 내용은 테이블 Vacuum을 참조하십시오.

탄력적 크기 조정에는 다음과 같은 제약이 적용됩니다.

탄력적 크기 조정 및 데이터 공유 클러스터 - 데이터 공유의 생산자인 클러스터에서 노드를 추가하거나 뺄 때 Amazon Redshift가 클러스터 메타데이터를 마이그레이션하는 동안에는 소비자로부터 연결할 수 없습니다. 마찬가지로 탄력적 크기 조정을 수행하고 새 노드 유형을 선택하면 연결이 끊어지고 새 대상 클러스터로 전송되는 동안에는 데이터 공유를 사용할 수 없습니다. 두 가지 유형의 탄력적 크기 조정 모두에서 생산자는 몇 분 동안 사용할 수 없습니다.
공유 스냅샷에서 데이터 전송 - 공유 스냅샷에서 데이터를 전송하는 클러스터에서 탄력적 크기 조정을 실행하려면 클러스터에 대해 하나 이상의 백업을 사용할 수 있어야 합니다. Amazon Redshift 콘솔 스냅샷 목록, describe-cluster-snapshots CLI 명령 또는 DescribeClusterSnapshots API 작업에서 백업을 볼 수 있습니다.
플랫폼 제한 사항 - 탄력적 크기 조정은 EC2-VPC 플랫폼을 사용하는 클러스터에만 사용할 수 있습니다. 자세한 내용은 클러스터 생성 시 EC2-VPC 사용 섹션을 참조하세요.
스토리지 고려 사항 - 새 노드 구성에 기존 데이터를 위한 충분한 스토리지가 있는지 확인합니다. 노드를 추가하거나 구성을 변경해야 할 수 있습니다.
소스와 대상 클러스터 크기 비교 - 탄력적 크기 조정으로 크기를 조정할 수 있는 노드 수 및 노드 유형은 소스 클러스터의 노드 수와 크기 조정된 클러스터에 대해 선택한 노드 유형에 따라 결정됩니다. 사용 가능한 구성을 확인하려면 콘솔을 사용합니다. 또는 action-type resize-cluster 옵션과 함께 describe-node-configuration-options AWS CLI 명령을 사용할 수 있습니다. Amazon Redshift 콘솔을 사용한 크기 조정에 대한 자세한 내용은 클러스터 크기 조정 섹션을 참조하세요.

다음 예제 CLI 명령은 사용 가능한 구성 옵션을 설명합니다. 이 예에서 mycluster라는 클러스터는 dc2.large 8노드 클러스터입니다.
```
aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-cluster
```
이 명령은 각 옵션의 권장 노드 유형, 노드 수, 디스크 사용률이 포함된 옵션 목록을 반환합니다. 반환되는 구성은 특정 입력 클러스터에 따라 다를 수 있습니다. resize-cluster CLI 명령의 옵션을 지정할 때 반환되는 구성 중 하나를 선택할 수 있습니다.

추가 노드의 한도 - 탄력적 크기 조정에는 클러스터에 추가할 수 있는 노드에 대한 제한이 있습니다. 예를 들어 dc2 클러스터는 노드 수의 최대 2배까지 탄력적 크기 조정을 지원합니다. 설명을 위해 4노드 dc2.8xlarge 클러스터에 노드를 하나 추가하여 5노드 클러스터로 만들거나 8개가 될 때까지 노드를 더 추가할 수 있습니다.

참고

증가 한도 원래 노드 유형을 기반으로 합니다. 크기 조정이 탄력적 크기 조정의 증가 한도를 초과하는 경우 일반 크기 조정을 사용합니다.

일부 ra3 노드 유형의 경우 노드 수를 기존 수의 최대 4배까지 늘릴 수 있습니다. 특히 클러스터가 ra3.4xlarge 또는 ra3.16xlarge 노드로 구성되어 있다고 가정합니다. 그런 다음 탄력적 크기 조정을 사용하여 8노드 클러스터의 노드 수를 32개로 늘릴 수 있습니다. 또는 한도 미만의 값을 선택할 수 있습니다. (클러스터를 4배씩 확장하는 기능은 소스 클러스터 크기에 따라 달라진다는 점에 유의하세요.) 클러스터에 ra3.xlplus 노드가 있는 경우 제한은 2배입니다.

모든 ra3 노드 유형은 기존 수의 1/4로 노드 수 감소를 지원합니다. 예를 들어 ra3.4xlarge 노드가 있는 클러스터의 크기를 12개 노드에서 3개 또는 최솟값 이상으로 줄일 수 있습니다.

다음 표에는 탄력적 크기 조정을 지원하는 각 노드 유형에 대한 증가 및 감소 제한이 나열되어 있습니다.

원래 노드 유형	증가 한도	감소 한도
ra3.16xlarge	4x(예: 노드 4개에서 16개로)	기존 수의 1/4까지(예: 노드 16개에서 4개로)
ra3.4xlarge	4x	기존 수의 1/4까지
ra3.xlplus	2x(예: 노드 4개에서 8개로)	기존 수의 1/4까지
dc2.8xlarge	2x	기존 수의 1/2까지(예: 노드 16개에서 8개로)
dc2.large	2x	기존 수의 1/2까지
ds2.8xlarge	2x	기존 수의 1/2까지
ds2.xlarge	2x	기존 수의 1/2까지

참고

RA3 클러스터의 크기를 조정할 때 레거시 노드 유형 선택 - RA3 노드가 있는 클러스터에서 DC2 또는 DS2와 같은 다른 노드 유형으로 크기를 조정하려고 하면 콘솔에 유효성 검사 경고 메시지가 나타나고 크기 조정 작업이 완료되지 않습니다. 이는 레거시 노드 유형으로의 크기 조정이 지원되지 않기 때문에 발생합니다. 이는 고객이 더 이상 사용되지 않거나 곧 사용되지 않을 노드 유형으로 크기를 조정하는 것을 방지하기 위한 것입니다. 이는 탄력적 크기 조정과 클래식 크기 조정 모두에 적용됩니다.

클래식 크기 조정

클래식 크기 조정은 클러스터 크기 또는 노드 유형의 변경 폭이 탄력적 크기 조정에서 지원되지 않는 경우를 처리합니다. 클래식 크기 조정을 수행하면 Amazon Redshift는 대상 클러스터를 생성하고 원본 클러스터에서 대상 클러스터로 데이터와 메타데이터를 마이그레이션합니다.

RA3로 클래식 크기 조정을 수행하면 가용성이 향상될 수 있습니다.

대상 노드 유형이 RA3일 때 클래식 크기 조정 기능이 향상되었습니다. 원본 및 대상 클러스터 간의 백업 및 복원 작업을 사용하여 이를 수행합니다. 크기 조정이 시작되면 원본 클러스터가 재시작되며 몇 분간 사용할 수 없습니다. 그 후에는 백그라운드에서 크기 조정 작업을 하는 동안 클러스터의 읽기 및 쓰기 작업을 사용할 수 있습니다.

클러스터 검사

RA3으로 클러스터의 클래식 크기 조정을 수행할 때 최상의 성능과 결과를 얻으려면 이 체크리스트를 완료하십시오. 체크리스트를 따르지 않으면 읽기 및 쓰기 작업 수행 기능과 같은 RA3 노드를 사용한 클래식 크기 조정의 일부 이점을 얻지 못할 수 있습니다.

데이터 크기는 400TB 미만이어야 합니다. 데이터 크기를 확인하려면 스냅샷을 만들고 크기를 확인합니다. 또한 다음 쿼리를 실행하여 크기를 확인할 수 있습니다.
```
SELECT
sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks,
sum(size) as total_blocks,
((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist
FROM svv_table_info;
```
svv_table_info 테이블은 슈퍼 사용자에게만 표시됩니다.
대상 클러스터의 노드 유형은 RA3이어야 하며 대상 클러스터에는 두 개 이상의 노드가 있어야 합니다. 단일 노드 클러스터에 대한 클래식 크기 조정은 대상 노드 유형이 RA3인 경우에도 훨씬 더 오랜 시간이 걸립니다.
클래식 크기 조정을 시작하기 전에 10시간 이상 경과하지 않은 수동 스냅샷이 있는지 확인하십시오. 그렇지 않은 경우 스냅샷을 만듭니다.
클래식 크기 조정을 수행하는 데 사용된 스냅샷은 테이블 복원이나 다른 용도로는 사용할 수 없습니다.
클러스터는 VPC에 속해야 합니다.

RA3으로 클래식 크기 조정에 따른 정렬 및 배포 작업

RA3으로 클래식 크기 조정을 수행하는 동안 Even 배포로 마이그레이션된 배포 Key 테이블은 백그라운드 작업을 사용하여 원래 배포 스타일로 다시 변환됩니다. 이 기간은 데이터 크기와 클러스터의 사용량에 따라 달라집니다. 쿼리 워크로드는 데이터 마이그레이션보다 실행 우선 순위가 높습니다. 자세한 내용은 배포 스타일을 참조하세요. 이 마이그레이션 과정에서는 데이터베이스에 대한 읽기와 쓰기가 모두 동작합니다. 하지만 쿼리 성능이 저하될 수 있습니다. 그러나 동시성 확장은 쿼리 워크로드에 리소스를 추가하여 성능을 높일 수 있습니다. svl_restore_alter_table_progress 뷰의 결과를 사용하여 데이터 마이그레이션의 진행 상황을 확인할 수 있습니다. 모니터링에 대한 자세한 내용은 다음과 같습니다.

클러스터 크기가 완전히 조정되면 다음과 같은 정렬 동작이 발생합니다.

크기 조정으로 인해 클러스터의 슬라이스가 더 많아지면 KEY 분배 테이블은 부분적으로 정렬되지 않지만 EVEN 테이블은 정렬된 상태로 유지됩니다. 또한 크기 조정 직후에는 정렬되는 데이터의 양에 대한 정보가 최신 상태가 아닐 수도 있습니다. 키 복구 후 자동 vacuum이 시간이 지남에 따라 테이블을 정렬합니다.
크기 조정으로 인해 클러스터의 슬라이스 수가 줄어들면 KEY 분포 테이블과 EVEN 분포 테이블은 부분적으로 정렬되지 않습니다. 자동 vacuum은 시간이 지남에 따라 테이블을 정렬합니다.

자동 테이블 vacuum 작업에 대한 자세한 내용은 테이블 Vacuuming을 참조하세요. 컴퓨팅 노드의 슬라이스에 대한 자세한 내용은 데이터 웨어하우스 시스템 아키텍처를 참조하십시오.

대상 클러스터가 RA3인 경우의 클래식 크기 조정 단계

클래식 크기 조정은 대상 클러스터 유형이 RA3이고 이전 섹션에 설명된 사전 요구 사항을 충족한 경우 다음 단계로 구성됩니다.

원본 클러스터에서 대상 클러스터로 마이그레이션을 시작합니다. 새로운 대상 클러스터가 프로비저닝되면 Amazon Redshift가 크기 조정이 시작되었다는 이벤트 알림 메시지를 보냅니다. 그러면 기존 클러스터가 다시 시작되고 모든 연결이 닫힙니다. 기존 클러스터가 데이터 공유 생산자 클러스터인 경우 소비자 클러스터와의 연결도 끊어집니다. 다시 시작하는 데 몇 분이 걸립니다.

BACKUP NO에서 생성한 테이블 또는 구체화된 뷰와 같은 데이터베이스 관계는 클래식 크기 조정 중에는 유지되지 않는다는 점에 유의하십시오. 자세한 내용은 구체화된 뷰 생성을 참조하세요.
다시 시작한 후에는 데이터베이스를 읽고 쓸 수 있습니다. 또한 데이터 공유가 재개되며 이 작업에는 몇 분이 더 걸립니다.
데이터가 대상 클러스터로 마이그레이션됩니다. 대상 노드 유형이 RA3인 경우 데이터 마이그레이션 중에 읽기 및 쓰기가 가능합니다.
크기 조정 프로세스가 거의 끝나가면 Amazon Redshift가 엔드포인트를 대상 클러스터로 업데이트하고, 소스 클러스터의 모든 연결이 종료됩니다. 대상 클러스터는 데이터 공유를 위해 생산자가 됩니다.
크기 조정이 완료됩니다. Amazon Redshift에서 이벤트 알림을 전송합니다.

Amazon Redshift 콘솔에서 크기 조정 진행률을 볼 수 있습니다. 클러스터 크기 조정에 걸리는 시간은 데이터 크기에 따라 다릅니다.

참고

대상 클러스터가 RA3일 때 클래식 크기 조정 모니터링

KEY 배포를 포함하여 진행 중인 프로비저닝된 클러스터의 클래식 크기 조정을 모니터링하려면 svl_restore_alter_table_progress를 사용하십시오. 변환 중인 테이블의 완료율을 보여 줍니다. 데이터에 액세스하려면 수퍼 사용자여야 합니다. 다음은 샘플 쿼리를 나타냅니다.


select * from svl_restore_alter_table_progress;

결과는 다음과 같습니다.


  tbl   | progress |                          message                          
--------+----------+-----------------------------------------------------------
 105614 | ABORTED  | Abort:Table no longer contains the prior dist key column.
 105610 | ABORTED  | Abort:Table no longer contains the prior dist key column.
 105594 | 0.00%    | Table waiting for alter diststyle conversion.
 105602 | ABORTED  | Abort:Table no longer contains the prior dist key column.
 105606 | ABORTED  | Abort:Table no longer contains the prior dist key column.
 105598 | 100.00%  | Restored to distkey successfully.

클래식 크기 조정을 수행할 때 필요하지 않은 테이블을 드롭합니다. 이렇게 하면 기존 테이블을 더 빠르게 배포할 수 있습니다.

대상 클러스터가 RA3가 아닌 경우의 클래식 크기 조정 단계

예를 들어 대상 노드 유형이 RA3가 아닌 DS2 등인 경우 클래식 크기 조정은 다음과 같이 구성됩니다.

원본 클러스터에서 대상 클러스터로 마이그레이션을 시작합니다. 새로운 대상 클러스터가 프로비저닝되면 Amazon Redshift가 크기 조정이 시작되었다는 이벤트 알림 메시지를 보냅니다. 그러면 기존 클러스터가 다시 시작되고 모든 연결이 닫힙니다. 기존 클러스터가 데이터 공유 생산자 클러스터인 경우 소비자 클러스터와의 연결도 끊어집니다. 다시 시작하는 데 몇 분이 걸립니다.

BACKUP NO에서 생성한 테이블 또는 구체화된 뷰와 같은 데이터베이스 관계는 클래식 크기 조정 중에는 유지되지 않는다는 점에 유의하십시오. 자세한 내용은 구체화된 뷰 생성을 참조하세요.
다시 시작한 후에는 데이터베이스를 읽기 전용으로 사용할 수 있습니다. 데이터 공유가 재개되는 데 몇 분 정도 더 걸립니다.
데이터가 대상 클러스터로 마이그레이션됩니다. 데이터베이스는 읽기 전용으로 유지됩니다.
크기 조정 프로세스가 거의 끝나가면 Amazon Redshift가 엔드포인트를 대상 클러스터로 업데이트하고, 소스 클러스터의 모든 연결이 종료됩니다. 대상 클러스터는 데이터 공유를 위해 생산자가 됩니다.
크기 조정이 완료됩니다. Amazon Redshift에서 이벤트 알림을 전송합니다.

Amazon Redshift 콘솔에서 크기 조정 진행률을 볼 수 있습니다. 클러스터 크기 조정에 걸리는 시간은 데이터 크기에 따라 다릅니다.

참고

대상 클러스터가 RA3가 아니거나 이전 섹션에서 자세히 설명한 RA3 대상 클러스터의 사전 요구 사항을 충족하지 않는 경우 많은 양의 데이터가 포함된 클러스터의 크기를 조정하는 데 며칠 또는 몇 주가 걸릴 수 있습니다.

또한 클래식 크기 조정 후에는 클러스터에 사용된 스토리지 용량이 늘어날 수 있습니다. 이는 클래식 크기 조정으로 인해 클러스터에 추가 데이터 슬라이스가 있을 때 발생하는 일반적인 시스템 동작입니다. 클러스터의 노드 수가 동일하게 유지되는 경우에도 이러한 추가 용량 사용이 발생할 수 있습니다.

탄력적 크기 조정 vs 클래식 크기 조정

다음 표에서는 두 크기 조정 유형의 동작을 비교합니다.

탄력적 크기 조정 vs 클래식 크기 조정
동작	탄력적 크기 조정	클래식 크기 조정	설명
시스템 데이터 보존	탄력적 크기 조정은 시스템 로그 데이터를 유지합니다.	클래식 크기 조정은 시스템 테이블과 데이터를 유지하지 않습니다.	소스 클러스터에 감사 로깅이 활성화되어 있으면 크기 조정 후에 Amazon S3 또는 CloudWatch에서 계속해서 로그에 액세스할 수 있습니다. 이러한 로그는 데이터 정책에 따라 보관하거나 삭제할 수 있습니다.
노드 유형 변경	노드 유형이 변경되지 않는 경우의 탄력적 크기 조정: 인플레이스 크기 조정 및 대부분의 쿼리가 유지됩니다. 새 노드 유형을 선택한 경우의 탄력적 크기 조정: 새 클러스터가 생성됩니다. 크기 조정 프로세스가 완료되면 쿼리가 삭제됩니다.	클래식 크기 조정: 새 클러스터가 생성됩니다. 크기 조정 프로세스 중에 쿼리가 삭제됩니다.
세션 및 쿼리 보존	탄력적 크기 조정은 소스 클러스터와 대상의 노드 유형이 동일할 때 세션과 쿼리를 유지합니다. 새 노드 유형을 선택하면 쿼리가 삭제됩니다.	클래식 크기 조정은 세션과 쿼리를 유지하지 않습니다. 쿼리가 삭제됩니다.	쿼리가 삭제되면 성능이 어느 정도 저하될 수 있습니다. 따라서 사용량이 적은 시간대에 크기 조정 작업을 수행하는 것이 가장 좋습니다.
크기 조정 작업 취소	탄력적 크기 조정은 취소할 수 없습니다.	Amazon Redshift 콘솔의 클러스터 세부 정보에서 [크기 조정 취소(Cancel resize)]를 선택하여 완료되기 전에 기존 크기 조정 작업을 취소할 수 있습니다.	크기 조정 취소에 걸리는 시간은 취소 시 크기 조정 작업의 단계에 따라 달라집니다. 취소하는 경우 취소 작업이 완료될 때까지 클러스터를 사용할 수 없습니다. 크기 조정 작업이 마지막 단계에 있는 경우에는 취소할 수 없습니다. RA3 클러스터에 대한 클래식 크기 조정의 경우 취소할 수 없습니다.

크기 조정 예약

클러스터의 크기 조정 작업을 예약하여 사용량이 많을 것으로 예상되는 경우 스케일 업하거나 비용 절감을 위해 스케일 다운할 수 있습니다. 예약은 탄력적 크기 조정과 클래식 크기 조정 모두에 적용됩니다. 이제 Amazon Redshift 콘솔에서 일정을 설정할 수 있습니다. 자세한 내용은 콘솔을 사용한 클러스터 관리에서 클러스터 크기 조정 섹션을 참조하세요. AWS CLI 또는 Amazon Redshift API 작업을 사용하여 크기 조정을 예약할 수도 있습니다. 자세한 내용은 AWS CLI Command Reference의 create-scheduled-action 또는 Amazon Redshift API Reference의 CreateScheduledAction을 참조하세요.

스냅샷, 복원 및 크기 조정

탄력적 크기 조정은 Amazon Redshift 클러스터의 크기를 조정할 수 있는 가장 빠른 방법입니다. 탄력적 크기 조정을 선택할 수 없고 클러스터에 대해 거의 일정한 쓰기 액세스가 필요하다면 클래식 크기 조정과 함께 다음 단원에서 설명하는 스냅샷 및 복원 작업을 사용할 수 있습니다. 단, 이 방법을 사용하려면 스냅샷 생성 이후 원본 클러스터에 작성되는 데이터를 전환을 마친 대상 클러스터에 수동으로 복사해야 합니다. 복사에 걸리는 시간에 따라 두 클러스터의 데이터가 동일해질 때까지 이 프로세스를 몇 차례 반복해야 하는 경우도 있습니다. 그런 다음 대상 클러스터로 전환할 수 있습니다. 이때 전체 데이터 집합이 대상 클러스터로 복사될 때까지는 기존 쿼리에 부정적인 영향을 미칠 수도 있습니다. 그러나 데이터베이스에 쓸 수 없는 시간이 최소화됩니다.

스냅샷, 복원 및 클래식 크기 조정 작업에서는 사용되는 프로세스는 다음과 같습니다.

기존 클러스터의 스냅샷을 생성합니다. 기존 클러스터란 원본 클러스터를 말합니다.
스냅샷을 만든 시간입니다. 이렇게 하면 나중에 ETL(추출, 변환, 로드) 프로세스를 다시 실행해 스냅샷 이후 데이터를 대상 데이터베이스로 로드해야 하는 시점을 파악할 수 있습니다.
스냅샷을 새로운 클러스터로 복원합니다. 새로운 클러스터는 대상 클러스터를 말합니다. 대상 클러스터에 샘플 데이터가 존재하는지 확인합니다.
대상 클러스터의 크기를 조정합니다. 대상 클러스터에서 새로운 노드 유형과 노드 수, 그리고 기타 설정을 선택합니다.
원본 클러스터의 스냅샷을 생성한 이후 발생한 ETL 프로세스의 데이터 로드를 확인합니다. 똑같은 순서에 따라 동일한 데이터를 대상 클러스터에 다시 로드해야 할 수도 있습니다. 데이터 로드가 계속되는 경우에는 원본 클러스터와 대상 클러스터의 데이터가 동일해질 때까지 이 프로세스를 몇 차례 반복합니다.
원본 클러스터에서 실행 중인 모든 쿼리를 중단합니다. 이를 위해서는 클러스터를 재부팅하거나, 수퍼유저로 로그인하여 PG_CANCEL_BACKEND 및 PG_TERMINATE_BACKEND 명령을 사용해야 할 수도 있습니다. 클러스터 재부팅이 클러스터 사용을 중단할 수 있는 가장 쉬운 방법입니다.
원본 클러스터 이름을 변경합니다. 예를 들어 이름을 examplecluster에서 examplecluster-source로 바꿉니다.
대상 클러스터 이름을 변경 이전 원본 클러스터의 이름으로 변경합니다. 예를 들어 대상 클러스터 이름을 examplecluster로 바꿉니다. 이 시점부터 examplecluster가 포함된 엔드포인트를 사용하는 애플리케이션이 모두 대상 클러스터에 연결됩니다.
대상 클러스터로 전환을 마친 후 원본 클러스터를 삭제하고 모든 프로세스가 정상적으로 실행되는지 확인합니다.

또는 대상 클러스터로 데이터를 다시 로드하기 전에 소스 및 대상 클러스터의 이름을 바꿀 수 있습니다. 이 방법은 종속 시스템 및 보고서를 대상 클러스터의 시스템 및 보고서로 즉시 업데이트할 필요가 없는 경우에 효과적입니다. 이 경우에는 6단계가 위에서 설명한 프로세스의 끝으로 이동합니다.

이름 변경 프로세스는 애플리케이션에서 동일한 엔드포인트를 사용하여 클러스터에 연결해야 할 때만 필요합니다. 이럴 필요가 없다면 클러스터에 연결되는 모든 애플리케이션을 업데이트하여 이름을 변경하지 않고도 대상 클러스터의 엔드포인트를 사용할 수 있습니다.

클러스터 이름을 재사용하면 몇 가지 이점이 있습니다. 첫째, 기본 클러스터를 변경하더라도 엔드포인트가 바뀌지 않기 때문에 애플리케이션 연결 문자열을 업데이트할 필요가 없습니다. 둘째, Amazon CloudWatch 경보 및 Amazon Simple Notification Service(Amazon SNS) 알림과 같은 관련 항목이 클러스터 이름에 연결됩니다. 이러한 연결은 클러스터에 대해 설정한 것과 동일한 경보와 알림을 계속해서 사용할 수 있음을 나타냅니다. 프로덕션 환경에서는 경보나 알림 같은 관련 항목을 재구성하지 않고도 클러스터 크기를 조정할 수 있는 유연성이 필요하기 때문에 이러한 기능이 많이 사용됩니다.

리더 노드 IP 주소 가져오기

클러스터가 퍼블릭이면서 VPC에 속하면 크기 조정 후에도 리더 노드의 탄력적 IP 주소(EIP)는 변함 없습니다. 클러스터가 프라이빗이면서 VPC에 속하면 크기 조정 후에도 리더 노드의 프라이빗 IP 주소는 변함 없습니다. 클러스터가 VPC에 속하지 않는 경우에는 크기 조정 작업의 일환으로 새로운 퍼블릭 IP 주소가 리더 노드에 할당됩니다.

클러스터의 리더 노드 IP 주소를 가져오려면 다음과 같이 dig 유틸리티를 사용하십시오.


dig mycluster.abcd1234.us-west-2.redshift.amazonaws.com

리더 노드 IP 주소는 아래와 같이 결과에서 ANSWER SECTION 끝에 있습니다.

클러스터 일시 중지 및 다시 시작

특정 시간에만 사용 가능해야 하는 클러스터가 있는 경우 클러스터를 일시 중지하고 나중에 다시 시작할 수 있습니다. 클러스터가 일시 중지되는 동안 온디맨드 결제가 일시 중지됩니다. 클러스터의 스토리지에만 요금이 부과됩니다. 요금에 대한 자세한 내용은 Amazon Redshift 요금 페이지를 참조하세요.

클러스터를 일시 중지하면 Amazon Redshift에서 스냅샷을 생성하고 쿼리를 종료하기 시작한 다음 클러스터를 일시 중지 상태로 만듭니다. 최종 스냅샷을 요청하지 않고 일시 중지된 클러스터를 삭제하면 클러스터를 복원할 수 없습니다. 일시 중지 또는 다시 시작 작업이 시작된 후에는 취소 또는 롤백할 수 없습니다.

AWS CLI 또는 Amazon Redshift API 작업을 사용하여 Amazon Redshift 콘솔에서 클러스터를 일시 중지하고 다시 시작할 수 있습니다.

클러스터를 일시 중지하고 다시 시작하도록 작업을 예약할 수 있습니다. 새 Amazon Redshift 콘솔을 사용하여 일시 중지하고 다시 시작할 반복 일정을 생성하면 선택한 날짜 범위에 대해 2개의 예약된 작업이 생성됩니다. 예약된 작업 이름에는 접미사로 -pause 및 -resume이 붙습니다. 이름의 총 길이는 예약된 작업 이름의 최대 크기 내에 있어야 합니다.

다음 유형의 클러스터는 일시 중지할 수 없습니다.

EC2-Classic 클러스터
활성 상태가 아닌 클러스터(예: 현재 수정 중인 클러스터)
하드웨어 보안 모듈(HSM) 클러스터
자동 스냅샷이 비활성화된 클러스터

클러스터를 일시 중지할 때 다음 사항을 고려하십시오.

클러스터에 대한 연결 또는 쿼리를 사용할 수 없습니다.
Amazon Redshift 콘솔에서 일시 중지된 클러스터의 쿼리 모니터링 정보를 볼 수 없습니다.
일시 중지된 클러스터는 수정할 수 없습니다. 클러스터에서 예약된 작업은 수행되지 않습니다. 여기에는 스냅샷 생성, 클러스터 크기 조정 및 클러스터 유지 관리 작업이 포함됩니다.
하드웨어 지표가 생성되지 않았습니다. 누락된 지표에 대한 경보가 설정된 경우 CloudWatch 경보를 업데이트합니다.
일시 중지된 클러스터의 최신 자동 스냅샷을 수동 스냅샷으로 복사할 수 없습니다.
클러스터가 일시 중지되는 동안에는 일시 중지 작업이 완료될 때까지 클러스터를 다시 시작할 수 없습니다.
클러스터를 일시 중지하면 결제가 일시 중단됩니다. 그러나 일시 중지 작업은 일반적으로 클러스터의 크기에 따라 15분 이내에 완료됩니다.
감사 로그는 보관되고 재개 시 복원되지 않습니다.
클러스터가 일시 중지된 후에는 일시 중지 전에 발생한 문제를 해결하기 위해 추적 및 로그를 사용하지 못할 수 있습니다.
클러스터의 no-backup 테이블은 다시 시작할 때 복원되지 않습니다. no-backup 테이블에 대한 자세한 내용은 스냅샷에서 테이블 제외를 참조하세요.

클러스터를 다시 시작할 때 다음 사항을 고려하십시오.

다시 시작된 클러스터의 클러스터 버전은 클러스터의 유지 관리 기간에 따라 유지 관리 버전으로 업데이트됩니다.
일시 중지된 클러스터와 연결된 서브넷을 삭제하면 호환되지 않는 네트워크가 있을 수 있습니다. 이 경우 최신 스냅샷에서 클러스터를 복원합니다.
클러스터가 일시 중지된 상태에서 탄력적 IP 주소를 삭제하면 새 탄력적 IP 주소가 요청됩니다.
Amazon Redshift에서 이전 탄력적 네트워크 인터페이스로 클러스터를 다시 시작할 수 없는 경우 Amazon Redshift에서 새 인터페이스를 할당하려고 시도합니다.
클러스터를 다시 시작하면 노드 IP 주소가 변경될 수 있습니다. SSH(Secure Shell)에서 COPY 또는 Amazon EMR에서 COPY 지원과 같은 기능에 대해 이러한 새 IP 주소를 지원하도록 VPC 설정을 업데이트해야 할 수 있습니다.
일시 중지되지 않은 클러스터를 다시 시작하려고 하면 다시 시작 작업이 오류를 반환합니다. 다시 시작 작업이 예약된 작업의 일부인 경우 이후의 오류를 방지하기 위해 예약된 작업을 수정하거나 삭제합니다.
클러스터의 크기에 따라 쿼리 처리 전 클러스터를 다시 시작하는 데 몇 분 정도 걸릴 수 있습니다. 또한 다시 시작 완료 후 클러스터를 다시 수화하는 동안 일정 기간 동안 쿼리 성능에 영향을 줄 수 있습니다.

클러스터 이름 변경

클러스터에 다른 이름을 사용하고 싶다면 이름을 변경할 수 있습니다. 클러스터 엔드포인트에는 클러스터 이름(클러스터 식별자라고도 함)이 포함되어 있기 때문에 이름 변경을 마치면 엔드포인트도 새로운 이름을 사용하도록 바뀝니다. 예를 들어, examplecluster 클러스터의 이름을 newcluster로 변경하면 엔드포인트도 newcluster 식별자를 사용하도록 바뀝니다. 클러스터에 연결되는 애플리케이션은 모두 새로운 엔드포인트로 업데이트되어야 합니다.

이러한 애플리케이션의 엔드포인트를 변경하지 않고 애플리케이션이 연결되는 클러스터를 변경하고 싶다면 클러스터의 이름을 바꿀 수 있습니다. 이 경우에는 먼저 원래 클러스터 이름을 변경한 후에 두 번째 클러스터를 변경하여 원래 클러스터의 변경 전 이름을 재사용해야 합니다. 이는 클러스터 식별자는 계정 및 리전 내에서 고유해야, 즉 원래 클러스터와 두 번째 클러스터의 이름이 동일할 수 없기 때문입니다. 스냅샷에서 클러스터를 복원할 때 종속된 애플리케이션의 연결 속성을 변경하지 않으려는 경우 이렇게 할 수 있습니다.

참고

원래 클러스터를 삭제할 때 원하지 않는 클러스터 스냅샷까지 삭제되는 경우 사용자 본인에게 책임이 있습니다.

클러스터 이름을 변경할 때는 프로세스를 마칠 때까지 클러스터 상태가 renaming으로 바뀝니다. 클러스터에서 이전에 사용된 DNS 이름은 바로 삭제되지만 캐시는 몇 분 더 남을 수도 있습니다. 이름이 바뀐 클러스터의 새로운 DNS 이름은 약 10분 내에 적용됩니다. 이름이 바뀐 클러스터를 사용하려면 새로운 이름이 적용될 때까지 기다려야 합니다. 클러스터가 재부팅되고 기존 클러스터 연결은 모두 종료됩니다. 이 모든 것이 완료되면 엔드포인트가 새로운 이름을 사용하도록 바뀝니다. 따라서 이름을 변경하기 전에 실행 중인 쿼리를 모두 종료한 후 이름 변경이 완료된 후에 쿼리를 다시 시작해야 합니다.

이름이 변경된 후에도 클러스터 스냅샷은 그대로 유지되며, 클러스터와 연결된 스냅샷 모두 클러스터와 연결된 상태가 지속됩니다. 예를 들어, 프로덕션 데이터베이스 역할을 수행하는 클러스터에 다수의 스냅샷이 있다고 가정하겠습니다. 이때 클러스터 이름을 변경한 후 프로덕션 환경에서 스냅샷으로 교체하더라도 이름이 바뀐 클러스터는 여전히 기존 스냅샷과 연결됩니다.

Amazon CloudWatch 경보와 Amazon Simple Notification Service(Amazon SNS) 이벤트 알림은 클러스터 이름과 연결됩니다. 클러스터 이름을 변경하면 이 경보와 알림도 업데이트해야 합니다. CloudWatch 콘솔에서 CloudWatch 경보를 업데이트하고 [이벤트(Events)] 창의 Amazon Redshift 콘솔에서 Amazon SNS 이벤트 알림을 업데이트할 수 있습니다. 클러스터의 로드 및 쿼리 데이터는 이름 변경 전후의 데이터를 계속해서 표시하지만 성능 데이터는 이름 변경 이후 재설정됩니다.

자세한 내용은 클러스터 수정 섹션을 참조하세요.

클러스터 종료 및 삭제

실행을 중단하여 요금을 지불하지 않으려면 클러스터를 종료할 수 있습니다. 클러스터를 종료할 때는 옵션으로 최종 스냅샷을 생성할 수 있습니다. 최종 스냅샷을 생성하는 경우에는 Amazon Redshift가 종료 전에 클러스터의 수동 스냅샷을 생성합니다. 나중에 클러스터 실행을 재개하여 데이터를 쿼리하고 싶을 때는 이 스냅샷을 복원하면 됩니다.

더 이상 클러스터와 데이터가 필요하지 않다면 최종 스냅샷을 생성하지 않고 종료할 수도 있습니다. 이때는 클러스터와 데이터가 영구적으로 삭제됩니다. 클러스터 종료 및 삭제에 대한 자세한 내용은 클러스터 삭제 단원을 참조하십시오.

최종 수동 스냅샷을 포함한 클러스터의 종료 여부와 상관없이 클러스터가 종료되면 클러스터와 연결된 자동 스냅샷도 모두 삭제됩니다. 하지만 클러스터와 연결된 수동 스냅샷은 모두 유지됩니다. 옵션으로 제공되는 최종 스냅샷을 포함하여 종료 이후 남는 수동 스냅샷은 클러스터 종료 시 실행 중인 다른 클러스터가 없는 경우, 혹은 실행 중인 Amazon Redshift 클러스터에 제공되는 무료 스토리지를 초과하는 경우 Amazon Simple Storage Service 스토리지 요율에 따라 요금이 부과됩니다. 스냅샷 스토리지 요금에 대한 자세한 내용은 Amazon Redshift 요금 페이지를 참조하세요.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

클러스터

사용 한도 관리