클러스터 크기 조정

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

클러스터 크기를 조정할 때는 노드 수 또는 노드 유형을 현재 클러스터 구성과 다르게 지정합니다. 클러스터가 크기 조정을 진행하는 동안 클러스터에 대한 쓰기 또는 읽기/쓰기 쿼리를 실행할 수 없으며, 오직 읽기 쿼리만 가능합니다.

다른 방법을 사용한 클러스터 크기 조정 프로세스를 포함하여 클러스터 크기 조정에 대한 자세한 내용은 클러스터 크기 조정 단원을 참조하십시오.

클러스터를 삭제하려면

AWS Management Console에 로그인한 후 https://console.aws.amazon.com/redshiftv2/에서 Amazon Redshift 콘솔을 엽니다.
탐색 메뉴에서 클러스터(Clusters)를 선택합니다.
크기를 조정할 클러스터를 선택합니다.
작업(Actions)에서 크기 조정(Resize)을 선택합니다. 클러스터 크기 조정(Resize cluster) 페이지가 표시됩니다.
페이지의 지시 사항을 따릅니다. 이제 특정 시간에 한 번 클러스터의 크기를 조정하거나, 일정에 따라 클러스터의 크기를 늘리거나 줄일 수 있습니다.
선택 사항에 따라 지금 크기 조정(Resize now) 또는 크기 조정 예약(Schedule resize)를 선택합니다.

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

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

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

탄력적 크기 조정

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

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

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

탄력적 크기 조정이 실패할 가능성은 거의 없습니다. 그러나 장애가 발생한 경우 대부분은 수동 개입 없이 자동으로 롤백이 이뤄집니다.

예약 노드(예: DC2 예약 노드)가 있는 경우 크기 조정을 수행할 때 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까지
ra3.large	2x	기존 수의 1/2까지
dc2.8xlarge	2x	기존 수의 1/2까지(예: 노드 16개에서 8개로)
dc2.large	2x	기존 수의 1/2까지

참고

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

클래식 크기 조정

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

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

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

클러스터 검사

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

데이터 크기는 2페타바이트 미만이어야 합니다. 1페타바이트는 1,000테라바이트와 같습니다. 데이터 크기를 확인하려면 스냅샷을 만들고 크기를 확인합니다. 또한 다음 쿼리를 실행하여 크기를 확인할 수 있습니다.
```
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 테이블은 슈퍼 사용자에게만 표시됩니다.
클래식 크기 조정을 시작하기 전에 10시간 이상 경과하지 않은 수동 스냅샷이 있는지 확인하십시오. 그렇지 않은 경우 스냅샷을 만듭니다.
클래식 크기 조정을 수행하는 데 사용된 스냅샷은 테이블 복원이나 다른 용도로는 사용할 수 없습니다.
클러스터는 VPC에 속해야 합니다.

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

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

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

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

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

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

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

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

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

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

참고

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

KEY 배포를 포함하여 진행 중인 프로비저닝된 클러스터의 클래식 크기 조정을 모니터링하려면 SYS_RESTORE_STATE를 사용하세요. 변환 중인 테이블의 완료율을 보여 줍니다. 데이터에 액세스하려면 수퍼 사용자여야 합니다.

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

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

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

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

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

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

참고

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

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

탄력적 크기 조정 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) 알림과 같은 관련 항목이 클러스터 이름에 연결됩니다. 이러한 연결은 클러스터에 대해 설정한 것과 동일한 경보와 알림을 계속해서 사용할 수 있음을 나타냅니다. 프로덕션 환경에서는 경보나 알림 같은 관련 항목을 재구성하지 않고도 클러스터 크기를 조정할 수 있는 유연성이 필요하기 때문에 이러한 기능이 많이 사용됩니다.

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

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

문서 규칙

클러스터 수정

클러스터 이름 변경