RESOURCES

Amazon Redshift 는 표준 SQL을 사용하여 데이터 웨어하우스, 운영 데이터베이스 및 데이터 레이크에서 엑사바이트 규모의 데이터를 처리할 수 있는 인기있는 클라우드 데이터 웨어하우스입니다. Amazon Redshift는 다양한 워크로드 및 사용 사례에 사용할 수 있는 DC2(고밀도 컴퓨팅) 및 RA3과 같은 다양한 노드 유형을 제공합니다. DS2에서 RA3으로 마이그레이션할 때의 이점에 대한 자세한 내용은 관리형 스토리지가 있는 새로운 Amazon Redshift RA3 노드로 클라우드 데이터 웨어하우스 확장 및 비용 절감 및 Amazon Redshift 벤치마킹: RA3 대 DS2 인스턴스 유형 비교를 참조하세요.

 

많은 고객이 컴퓨팅 집약적 워크로드에 DC2 노드를 사용합니다. 증가하는 워크로드, 즉 컴퓨팅을 스토리지에서 분리하여 필요에 따라 적절한 크기로 조정하는 것은 자연스러운 일입니다. 관리형 스토리지가 있는 RA3 노드를 사용하면 컴퓨팅 및 관리형 스토리지를 독립적으로 확장하고 비용을 지불하여 데이터 웨어하우스를 최적화할 수 있습니다. Amazon Redshift 관리형 스토리지는 빠른 로컬 스토리지를 위해 각 RA3 노드에 대용량 고성능 SSD를 사용하고 장기 내구성 스토리지를 위해 Amazon S3를 사용합니다. 

 

노드의 데이터가 대형 로컬 SSD의 크기 이상으로 증가하는 경우 Amazon Redshift 관리형 스토리지는 자동으로 해당 데이터를 Amazon S3로 오프로드합니다. RA3 노드는 각 데이터 블록에 대한 액세스 빈도를 추적하고 가장 인기 있는 블록을 캐시합니다. 블록이 캐시되지 않은 경우 큰 네트워킹 대역폭과 정확한 저장 기술은 몇 초 안에 데이터를 반환합니다. 또한 클러스터 간 데이터 공유 및 교차 가용 영역 클러스터 재배치와 같은 기능을 찾고 있다면 RA3으로 마이그레이션하는 것이 유리합니다. DC2의 많은 고객은 증가하는 성능 요구 사항 및 비즈니스 사용 사례를 충족하기 위해 RA3으로 마이그레이션함으로써 이점을 얻었습니다.

 

마이그레이션의 첫 번째 단계로 항상 시스템의 올바른 로드를 찾아 워크로드를 충족하고 최고의 비용 및 성능 이점을 제공하는 RA3 노드 수를 결정하는 것이 좋습니다. 이 평가를 위해 간단한 재생 도구를 사용하여 가상 분석을 수행하고 다양한 시나리오에서 워크로드가 어떻게 수행되는지 평가할 수 있습니다. 예를 들어 도구를 사용하여 RA3과 같은 새로운 인스턴스 유형에서 실제 워크로드를 벤치마킹하거나, 새로운 기능을 평가하거나, 다양한 클러스터 구성을 평가할 수 있습니다. 올바른 클러스터 유형을 선택 하기 위해 워크로드에 대한 다양한 노드 유형을 비교 하고 Simple Replay 유틸리티를 사용하여 RA3의 올바른 구성을 선택할 수 있습니다.

 

클러스터 유형과 노드에 대해 알았다면 이제 다음 질문은 최소 다운타임으로 또는 현재 워크로드를 방해하지 않고 현재 워크로드를 RA3으로 마이그레이션 하는 방법입니다.  오늘 포스팅에서는 가동 중지 시간을 최소화하면서 이를 수행하는 접근 방식을 알아보겠습니다.

 

 

Amazon Redshift 클러스터 크기 조정

 

Amazon Redshift 클러스터의 크기를 조정하거나 DC2에서 RA3으로 마이그레이션하는 방법에는 세 가지가 있습니다.

 

• 탄력적 크기 조정 – 옵션으로 사용할 수 있는 경우 탄력적 크기 조정을 사용하여 노드 유형, 노드 수 또는 둘 다를 변경할 수 있습니다. 노드 수만 변경하면 쿼리가 일시적으로 일시 중지되고 연결이 열린 상태로 유지됩니다. 탄력적 크기 조정에는 10~15분이 소요될 수 있습니다. 크기 조정 작업 중 클러스터는 읽기 전용입니다.
• 클래식 크기 조정 – 클래식 크기 조정을 사용하여 노드 유형, 노드 수 또는 둘 다를 변경합니다. 탄력적 크기 조정을 통해 사용할 수 없는 구성으로 크기를 조정할 때 이 옵션을 선택할 수 있습니다. 크기 조정 작업은 데이터 크기에 따라 2시간 이상 또는 며칠이 소요될 수 있습니다. 크기 조정 작업 중 소스 클러스터는 읽기 전용입니다.
• 스냅샷, 복원 및 크기 조정 – 클래식 크기 조정 중에 클러스터를 계속 사용할 수 있도록 하려면 기존 클러스터의 복사본을 만든 다음 새 클러스터의 크기를 조정합니다. 스냅샷을 만든 후 원본 클러스터에 데이터를 쓰는 경우 마이그레이션이 완료된 후 데이터를 수동으로 복사해야 합니다.

 

 

크기 조정을 위한 체크포인트

 

동일한 노드 유형으로 탄력적 크기 조정을 사용하여 클러스터 크기를 조정하면 작업에서 새 클러스터를 생성하지 않아서 결과적으로 작업이 빠르게 완료됩니다. 그러나 크기 조정의 경우 크기 조정 지연을 일으키는 하나 이상의 문제가 있을 수 있습니다.

 

• 데이터 볼륨 – 클래식 크기 조정 또는 스냅샷 및 복원 작업을 완료하는 데 필요한 시간은 원본 클러스터의 워크로드, 변환되는 테이블의 수 및 볼륨, 컴퓨팅 노드 전체에 데이터가 얼마나 균등하게 분산되어 있는지, 슬라이스, 소스 및 대상 클러스터의 노드 구성 등에 따라 다릅니다.
• 스냅샷 – 자동 스냅샷은 보존 기간이 만료되거나 자동 스냅샷을 비활성화하거나 클러스터를 삭제할 때 자동으로 삭제됩니다. 자동 스냅샷을 유지하려는 경우 수동 스냅샷에 복사할 수 있습니다. 크기 조정 작업에 사용되는 마이그레이션 전에 클러스터의 수동 스냅샷을 만들 수 있지만 스냅샷이 캡처된 시점의 라이브 데이터는 포함되지 않을 수 있습니다.
• 크기 조정 중 클러스터를 사용할 수 없음 – 크기 조정에 소요되는 시간을 대략적으로 아는 것이 중요합니다. 이렇게 하려면 테스트 계정의 스냅샷에서 클러스터를 만들 수 있습니다. 그러나 특히 크기 조정 중에 클러스터를 쿼리하려는 경우 크기 조정 시간이 다를 수 있기 때문에 이는 단지 아이디어를 제공할 뿐입니다. 클러스터가 업무 외 시간을 최소화하거나 0시간으로 거의 항상 활성 상태인 경우 클러스터가 이 기간 동안 라이브 데이터를 업데이트하고 이 데이터에 대한 읽기 요청을 제공할 수 없기 때문에 크기 조정이 어려울 수 있습니다.
• 클러스터 엔드포인트 보존 – 탄력적 크기 조정 및 클러스터 크기 조정을 통해 노드 유형, 노드 수 또는 둘 다를 변경할 수 있지만 엔드포인트는 유지됩니다. 스냅샷 크기 조정을 사용하면 새 클러스터 엔드포인트가 생성되며 엔드포인트를 교체하려면 애플리케이션을 변경해야 할 수 있습니다.
• 조정 – 원본으로 대상 클러스터 데이터의 유효성을 검사하여 마이그레이션이 데이터 손실 없이 완료되었는지 확인하고 데이터 품질을 보장합니다. 테이블 수준의 조정이 충분하지 않으므로 원본에서 레코드도 복사되었는지 확인해야 합니다. 일치하는 레코드 수 검사를 실행한 다음 데이터의 정확성을 위해 체크섬을 사용하여 데이터 유효성을 검사할 수 있습니다.

 

 

솔루션 개요

 

마이그레이션을 준비하는 단계는 다음과 같습니다.

 

1. DC2에서 실행되는 기존 프로덕션 Amazon Redshift 클러스터의 스냅샷을 만듭니다.
2. AWS Glue 가 큐레이트된 데이터를 병렬로 쓰는 또 다른 Amazon Simple Storage Service (Amazon S3) 버킷을 생성합니다.
3. 스냅샷을 사용하여 RA3 클러스터를 생성합니다.
4. 마이그레이션된 버킷에서 Amazon S3로 데이터를 로드하도록 AWS Database Migration Service (AWS DMS)를 구성합니다.
5. 두 클러스터(DC 및 RA3)와 다른 모든 다운스트림 애플리케이션 간에 데이터가 동기화되었는지 확인한 후 DC 클러스터를 중지하고 종속 다운스트림 애플리케이션의 끝점을 새로 생성된 RA3 클러스터로 변경합니다.

 

다음은 라이브 워크로드를 나타내는 현재 아키텍처입니다.

 

 

이 솔루션에서 데이터는 3개의 소스 시스템에서 가져오고 원시 S3 버킷에 기록됩니다.

 

• AWS DMS를 통해 RDS 인스턴스에서 데이터 캡처(CDC) 변경(이전 다이어그램의 1)
• 외부 API를 통해 캡처된 이벤트(2)
• 원시 버킷에 복사된 외부 소스의 CSV 파일(3)

 

이러한 소스에는 새 데이터를 푸시하는 패턴이나 간격이 없습니다.

 

몇 분마다 수집된 데이터는 S3 이벤트 트리거에 의해 선택되어 AWS Glue 워크플로 (이전 다이어그램의 4개)를 실행합니다. 작업 및 크롤러를 관리하고 실행하기 위한 오케스트레이션 계층을 제공합니다. 이 워크플로에는 데이터 세트의 메타데이터 스키마와 파티션을 AWS Glue 데이터 카탈로그로 업데이트하는 크롤러(5)가 포함됩니다. 그런 다음 크롤러는 선별된 데이터를 S3 선별된 버킷에 쓰는 AWS Glue 작업을 트리거합니다. 여기에서 다른 AWS Glue 작업이 데이터를 Amazon Redshift로 업로드합니다 (6).

 

이 시나리오에서 워크로드가 중요하고 긴 다운타임을 감당할 수 없다면 그에 따라 마이그레이션을 계획해야 합니다.

 

 

이중 쓰기 및 임시 데이터 큐레이션 파이프라인

 

마이그레이션의 첫 번째 단계로 큐레이트된 S3 버킷에 데이터를 쓰는 AWS Glue 작업으로 병렬 데이터 프로세스 파이프라인이 필요합니다. 다른 S3 버킷을 생성하고 이름을 지정 migrated-curated-bucket하고 AWS Glue 변환 작업을 수정합니다. 다른 변환 작업을 복제하여 새로운 예약 S3 버킷에 병렬로 데이터를 쓸 수도 있습니다.

 

이 시나리오에서 라이브 데이터 수집은 30분마다 발생합니다. 추출, 변환 및 로드(ETL) 작업의 반복이 완료되면 Amazon Redshift 클러스터의 수동 스냅샷이 트리거됩니다. 스냅샷이 캡처되면 해당 스냅샷을 사용하여 새 Amazon Redshift 클러스터가 생성됩니다. 클러스터 생성 시간은 스냅샷 볼륨에 따라 다를 수 있습니다.

 

스냅샷 생성에 30분 이상 걸리면 ETL 작업을 중지하고 스냅샷 생성이 완료된 후 다시 시작해야 합니다. 예를 들어, ETL 작업이 오전 8시에 트리거되고 오전 8시 10분에 완료되면 스냅샷 생성은 오전 8시 10분에 시작됩니다. 오전 8시 30분까지 완료되면(다음 ETL 작업은 30분 간격으로 오전 8시 30분에 실행됨) 일정에 따라 ETL 프로세스가 계속됩니다. 그렇지 않으면 작업이 중지되고 스냅샷이 완료된 후 다시 시작됩니다.

이제 스냅샷을 사용하여 새 RA3 redshift 클러스터를 시작합니다. 이 프로세스는 기존 ETL 파이프라인을 일시 중지하지 않고 예약 S3 버킷과 병렬로 선별된 데이터를 쓰기 시작합니다. 다음 다이어그램은 이 업데이트된 워크플로를 보여줍니다.

 

 

이 시점에서 기존 클러스터는 여전히 활성 상태이며 라이브 워크로드를 계속 처리합니다. Amazon Redshift 클러스터 생성에 시간이 걸리더라도(많은 양의 데이터로 인해) 여전히 처리해야 합니다. S3 버킷의 큐레이트된 데이터는 스테이징 예약 역할을 하며 이 데이터는 클러스터가 시작된 후 RA3 클러스터에 로드되어야 합니다.

 

 

누락된 데이터로 새 RA3 클러스터 백필

 

RA3 클러스터가 시작된 후 예약 S3 버킷에서 새로 생성된 클러스터로 캡처된 라이브 데이터를 재생해야 합니다. 재생은 현재 타임스탬프에 대한 스냅샷 캡처 기간 동안만 가능합니다. 이 프로세스를 통해 RA3 클러스터를 기존 라이브 DC2 클러스터와 동기화하려고 합니다.

 

예약 S3 버킷을 소스 엔드포인트 로, 새로 생성된 RA3 클러스터를 대상 엔드포인트 로 사용하여 AWS DMS 마이그레이션 작업을 구성해야 합니다.

AWS DMS는 대상 데이터 저장소에 대한 지속적인 변경 사항을 캡처합니다. 이 프로세스를 지속적인 복제 또는 변경 데이터 캡처(CDC)라고 합니다. AWS DMS는 소스 데이터 스토어에서 진행 중인 변경 사항을 복제할 때 이 프로세스를 사용합니다. 이 프로세스는 데이터베이스 엔진의 기본 API를 사용하여 데이터베이스 로그에 대한 변경 사항을 수집하여 작동합니다. 다음 다이어그램은 이 워크플로를 보여줍니다.

 

 

 

조정 및 전환

 

데이터 조정은 소스와 대상 간의 데이터 검증 프로세스입니다. 이 과정에서 대상 데이터와 원본 데이터를 비교하여 데이터가 변경 없이 완전히 전송되는지 확인합니다. 파이프라인과 처리되는 데이터의 안정성을 보장하려면 종단 간 조정 보고서를 만들어야 합니다. 이 보고서는 일치하는 테이블, 열 및 데이터 레코드의 비율을 확인합니다. 또한 누락된 레코드, 누락된 값, 잘못된 값, 잘못된 형식의 값 및 중복된 레코드를 식별합니다.

조정 프로세스를 정의하여 두 클러스터가 동기화되어 실행 중인지 확인할 수 있습니다. 이를 위해 간단한 Python 스크립트 또는 셸 스크립트를 만들어 소스 및 대상 클러스터를 쿼리하고, 결과를 가져오고, 비교할 수 있습니다.

 

컷오버는 마이그레이션의 마지막 단계이며 기존 클러스터를 새로 시작된 클러스터로 전환하는 작업을 포함합니다. 이 시점에서 클러스터는 병렬로 실행됩니다. 다음으로 다운스트림 데이터 소비 흐름이 최신 상태인지 확인합니다. 테이블 업데이트가 동기화되도록 DC2 및 RA3 클러스터의 조정 메트릭을 확인합니다.

마이그레이션 데이터 파이프라인에서 전환하는 동안 이중 쓰기를 유지할 수 있습니다. 절단 후 문제를 발견하면 이전 데이터 파이프라인으로 다시 전환할 수 있습니다. 이는 절단까지의 진실 소스입니다. 이 경우 컷오버에는 DC2 클러스터 엔드포인트를 애플리케이션의 새 RA3 클러스터 엔드포인트로 업데이트하는 작업이 포함됩니다. 엔드포인트를 업데이트하려면 낮 동안 비교적 조용한 시간을 확인해야 합니다.

 

 애플리케이션과 사용자에 대해 동일한 엔드포인트를 유지하려면 원래 DC2 클러스터와 동일한 이름으로 새 RA3 클러스터의 이름을 바꿀 수 있습니다. 클러스터 이름을 바꾸려면 Amazon Redshift 콘솔 또는 ModifyCluster API 작업에서 클러스터를 수정합니다. 자세한 내용   은  Amazon Redshift API Reference 의 클러스터 이름 바꾸기  또는  ModifyCluster API 작업 을 참조하십시오.

 

현재까지 AWS DMS는 RA3를 계속 업데이트하고 있습니다. RA3으로 전환한 후에는 DC2 클러스터가 더 이상 작동하지 않으며 RA3에 대한 AWS DMS 복제 작업을 중지할 수 있습니다. 마지막 스냅샷을 일시 중지합니다. RA3 로드에 사용되는 예약 S3 버킷 및 AWS DMS 리소스를 삭제합니다.

 

 

결론

 

오늘 포스팅에서는 데이터 손실을 최소화하거나 전혀 없이 기존 Amazon Redshift 클러스터를 마이그레이션하는 접근 방식을 알아보았습니다. 이를 통해 클러스터는 크기 조정 기간 동안 읽기 및 쓰기 작업을 모두 제공할 수 있습니다. 탄력적 크기 조정은 대상 클러스터에서 동일한 수의 슬라이스를 유지하기 위해 클러스터 크기를 빠르게 조정하는 방법입니다. 슬라이스 매핑은 클러스터 크기를 조정하는 데 필요한 시간을 줄입니다. 탄력적 크기 조정에서 사용할 수 없는 크기 조정 구성을 선택하는 경우 클래식 크기 조정을 선택하거나 스냅샷, 복원 및 크기 조정을 수행할 수 있습니다.

 

RA3 인스턴스의 새로운 기능에 대해 자세히 알아보려면 관리형 스토리지가 있는 Amazon Redshift RA3 인스턴스를 참조하십시오 . Amazon Redshift는 더 나은 가격 대비 성능을 제공하는 동시에 비용을 예측 가능한 상태로 유지하는 데 도움이 됩니다. Amazon Redshift Serverless 는 데이터 웨어하우스 용량을 자동으로 프로비저닝 및 확장하여 까다롭고 예측할 수 없는 워크로드에 고성능을 제공하며 사용한 리소스에 대해서만 비용을 지불합니다. 이는 사용자 정의 요구 사항에 따라 둘 중 하나 또는 둘 다를 선택할 수 있는 더 큰 유연성을 제공합니다. 선택을 마친 후에는 Amazon Redshift에서 Hands -on Lab 을 시도해 보십시오.