Amazon Redshift-Snowflake 마이그레이션 가이드¶

1단계: 계획 및 설계¶

이 초기 단계는 성공적인 마이그레이션의 기반을 마련하는 데 매우 중요합니다. 이 단계를 서두르면 크리프와 예산 초과가 발생하며 마감 날짜를 놓치게 됩니다. 철저한 계획을 수립하면 모든 이해관계자가 정렬되고 프로젝트 목표가 명확하게 정의됩니다.

실행 가능한 단계:

• Redshift 환경에 대한 철저한 평가 수행:

  • 인벤토리 및 분석: Redshift 클러스터의 모든 데이터베이스, 스키마, 테이블, 뷰, 저장 프로시저, 사용자 정의 함수(UDFs)를 카탈로그화합니다. Redshift 시스템 테이블(SVV_TABLE_INFO, PG_PROC 등)을 사용하여 메타데이터를 수집합니다.

  • 워크로드 분석: Redshift의 STL_QUERY 및 SVL_QUERY_SUMMARY 뷰를 사용하여 쿼리 패턴, 사용자 동시성, 성능 병목 상태를 식별합니다. 이 데이터는 Snowflake 가상 웨어하우스 전략을 설계하는 데 매우 중요합니다.

  • 종속성 식별: 모든 업스트림 데이터 소스(ETL/ELT 작업) 및 다운스트림 컨슈머(BI 도구, 애플리케이션, 데이터 과학 노트북)를 매핑합니다.

• 마이그레이션 범위 및 전략 정의:

  • 워크로드 우선 순위 지정: 비즈니스 영향과 기술적 복잡성을 기준으로 워크로드를 분류합니다. 빠른 성공과 추진력을 확보하기 위해 영향력은 높고 복잡성은 낮은 워크로드부터 시작합니다.

  • 마이그레이션 접근 방식 선택: 더 빠른 마이그레이션을 위한 “리프트 앤 시프트” 접근 방식이나 데이터 모델과 파이프라인을 현대화 및 최적화하기 위한 아키텍처 재구성 접근 방식 중에서 결정합니다.

• 프로젝트 계획 개발:

  • 팀 구성: 명확한 역할과 책임(예: 프로젝트 관리자, 데이터 엔지니어, DBA, 보안 관리자, 비즈니스 분석가)을 갖춘 마이그레이션 팀을 구성합니다.

  • 타임라인 만들기: 9단계 각각에 대해 현실적인 타임라인과 마일스톤을 정의합니다.

  • 성공 메트릭 정의: 명확한 KPIs를 설정하여 비용 절감, 쿼리 성능 개선, 사용자 만족도와 같은 마이그레이션의 성공을 측정합니다.

2단계: 환경 및 보안¶

탄탄한 계획이 수립했다면, 다음 단계는 Snowflake 환경을 준비하고 보안 태세를 복제하는 것입니다. Redshift에서 마이그레이션할 때의 주요 이점은 두 플랫폼이 일반적으로 동일한 클라우드 공급자(AWS)에서 실행되어 데이터 전송을 간소화된다는 점입니다.

실행 가능한 단계:

• Snowflake 계정 설정:

  • 에디션 및 클라우드 공급자 선택: 요구 사항을 충족하는 Snowflake 에디션(예: Standard, Enterprise, Business Critical)을 선택합니다. AWS를 클라우드 공급자로 선택하고 현재 S3 버킷과 동일한 리전을 선택하여 데이터 전송 비용과 대기 시간을 최소화합니다.

  • 웨어하우스 전략 설계: 1단계의 워크로드 분석을 기반으로 초기 가상 웨어하우스를 만듭니다. 다양한 워크로드(예: WH_LOADING, WH_TRANSFORM, WH_BI_ANALYTICS)를 분리하여 리소스 경합을 방지합니다. 티셔츠 사이즈(예: X-Small, Small)로 시작하여 성능 테스트를 기반으로 크기를 조정합니다.

• 보안 모델 구현:

  • Redshift 사용자 및 그룹을 Snowflake 역할로 매핑: Redshift의 사용자 및 그룹 권한을 Snowflake의 역할 기반 액세스 제어(RBAC) 모델로 변환합니다. 기능 역할(예: SYSADMIN ,SECURITYADMIN) 및 액세스 역할(예: BI_READ_ONLY, ETL_READ_WRITE)의 계층 구조를 생성합니다.

  • 네트워크 정책 및 인증 구성: 신뢰할 수 있는 IP주소로 액세스를 제한하는 네트워크 정책을 설정합니다. Okta 또는 Azure AD와 같은 ID 공급자를 통한 페더레이션 인증(SSO) 등의 인증 방법을 구성합니다.

3단계: 데이터베이스 코드 변환¶

이 단계에는 Redshift의 DDL, DML 및 프로시저 코드를 Snowflake와 호환되도록 변환합니다. 자동화 도구를 사용하면 이 프로세스를 가속화할 수 있지만, SQL 언어 및 플랫폼 아키텍처의 차이로 인해 수동 검토 및 조정이 필수적입니다.

실행 가능한 단계:

• DDL(데이터 정의 언어) 변환:

  • 테이블 및 뷰: Redshift에서 CREATE TABLE 및 CREATE VIEW 문을 추출합니다. Redshift 관련 데이터 타입을 상응하는 Snowflake 데이터 타입으로 변환합니다(부록 2 참조).

  • Redshift 관련 절 제거: DISTSTYLE, DISTKEY 및 SORTKEY와 같은 Redshift 관련 물리적 설계 절을 제거합니다. Snowflake의 아키텍처는 자동으로, 또는 매우 큰 테이블의 논리적 클러스터링 키를 통해 데이터 배포 및 클러스터링을 처리합니다.

• DML(데이터 조작 언어) 및 프로시저 코드 변환:

  • 저장 프로시저 재작성: Redshift는 저장 프로시저에 PL/pgSQL을 사용합니다. 이는 Snowflake Scripting(SQL), JavaScript, Python 또는 Java와 같이 Snowflake에서 지원하는 언어로 수동으로 다시 작성해야 합니다. 대개 코드 변환 프로세스에서 가장 시간이 많이 소요되는 부분입니다.

  • SQL 함수 변환: Redshift 관련 함수를 Snowflake 함수로 매핑합니다. 예를 들어, Redshift의 GETDATE()는 Snowflake의 CURRENT_TIMESTAMP()가 됩니다. 일반적인 함수 매핑은 부록 3을 참조하세요.

  • 유지 관리 명령 바꾸기: VACUUM, ANALYZE 및 REINDEX와 같은 Redshift 관련 명령이 포함된 스크립트는 Snowflake가 이러한 유지 관리 작업을 자동으로 처리하므로 제거해야 합니다.

4단계: 데이터 마이그레이션¶

이 단계에서는 Redshift 클러스터에서 Snowflake 테이블로 과거 데이터를 물리적으로 이동하는 데 중점을 둡니다. 가장 효율적인 방법은 Amazon S3를 중간 스테이징 영역으로 활용하는 것입니다.

실행 가능한 단계:

• Redshift에서 S3로 데이터 언로드:

  • Redshift UNLOAD 명령을 사용하여 테이블에서 지정된 S3 버킷으로 데이터를 내보냅니다. 이는 고도로 병렬화된 작업으로, 클라이언트 도구를 통한 SELECT 쿼리보다 훨씬 빠릅니다.

  • Snowflake에 최적의 로딩 성능을 제공하기 위해 데이터를 Parquet 또는 압축 CSV 형식으로 저장합니다. PARALLEL ON 옵션을 사용하여 여러 파일을 작성합니다.

• S3에서 Snowflake로 데이터 로드:

  • 외부 스테이지 만들기: Snowflake에서 언로드한 데이터가 포함된 S3 버킷을 지정하는 외부 스테이지 오브젝트를 만듭니다.

  • COPY INTO 명령 사용: Snowflake의 COPY INTO<table> 명령을 사용하여 S3 스테이지의 데이터를 대상 Snowflake 테이블로 로드합니다. 이 명령은 성능과 확장성이 뛰어납니다.

  • 확장된 웨어하우스 활용: 초기 데이터 로드 시 더 큰 전용 가상 웨어하우스를 사용하여 프로세스 속도를 높인 후, 비용을 관리하기 위해 이후에 규모를 축소하거나 일시 중단합니다.

**5단계: 데이터 수집¶

과거 데이터가 마이그레이션되었으면, 진행 중인 데이터 수집 파이프라인을 재설계하여 Redshift 대신 데이터를 Snowflake에 직접 공급해야 합니다.

실행 가능한 단계:

• 일괄 ETL 및 ELT 작업 마이그레이션:

  • (AWS Glue, Talend와, Informatica와 같은 도구에서) 기존 ETL 작업을 업데이트하여 Snowflake를 대상으로 지정합니다. 여기에는 연결 세부 정보를 변경하고 Snowflake의 언어를 사용하도록 SQL 재정의를 업데이트하는 작업이 포함됩니다.

• Snowpipe로 지속적인 수집 구현:

  • 연속 데이터 스트림(예: Kinesis 또는 S3에 도달하는 애플리케이션 로그에서)의 경우 Snowpipe를 구성합니다. Snowpipe는 S3에서 Snowflake 테이블로 새 데이터 파일이 도착하는 즉시 효율적으로 자동 로드하여 거의 실시간 수집 솔루션을 제공합니다.

• Snowflake 에코시스템 활용:

  • Kafka 및 Spark와 같은 플랫폼용 Snowflake 네이티브 커넥터를 탐색하여 직접 데이터 스트리밍을 간소화합니다.

6단계: 보고 및 분석¶

이 단계에서는 Snowflake에서 데이터를 쿼리하도록 모든 다운스트림 애플리케이션, 특히 BI 및 보고 도구를 리디렉션합니다.

실행 가능한 단계:

• 연결 드라이버 업데이트: BI 도구(예: Tableau Server, Power BI Gateway)를 호스팅하는 서버에 Snowflake의 ODBC/JDBC 드라이버를 설치하고 구성합니다.

• 보고서 및 대시보드 리디렉션:

  • BI 도구에서 데이터 소스 연결을 Redshift에서 Snowflake로 변경합니다.

  • 모든 중요한 보고서와 대시보드를 테스트하여 올바르게 작동하는지 확인합니다.

• 쿼리 검토 및 최적화:

  • 일부 대시보드에는 사용자 지정 SQL 또는 데이터베이스별 함수가 포함될 수 있습니다. 이러한 쿼리를 검토하고 리팩터링하여 Snowflake의 SQL 언어 및 해당 성능 기능을 활용합니다. Snowflake의 쿼리 프로필 도구를 사용하여 느리게 실행되는 보고서를 분석하고 최적화합니다.

7단계: 데이터 유효성 검사 및 테스트¶

새 플랫폼에 대한 비즈니스 신뢰를 구축하고 데이터 무결성과 성능이 기대치를 충족하는지 확인하기 위해서는 엄격한 테스트가 필수입니다.

실행 가능한 단계:

• 데이터 유효성 검사 수행:

  • 행 수: Redshift의 소스 테이블과 Snowflake의 대상 테이블 간의 행 수를 비교합니다.

  • 셀 수준 유효성 검사: 중요한 테이블의 경우 집계된 값(SUM(), AVG(), MIN(), MAX())을 비교하거나 주요 열에 체크섬을 사용하여 심층적인 유효성 검사를 수행합니다.

• 쿼리 및 성능 테스트 수행:

  • 벤치마크 쿼리: Redshift와 Snowflake 모두에 대해 대표적인 쿼리 세트를 실행하고 결과와 성능을 비교합니다.

  • BI 도구 성능: Snowflake에 연결된 주요 대시보드의 로딩 시간과 상호 작용을 테스트합니다.

• 사용자 수용 테스트(UAT):

  • 새로운 Snowflake 환경에서 비즈니스 사용자를 참여시켜 보고서의 유효성을 검사하고 일상적인 작업을 수행합니다. 피드백을 수집하고 문제를 해결합니다.

8단계: 배포¶

배포는 Redshift에서 Snowflake로 전환하는 최종 단계입니다. 이 프로세스는 비즈니스 운영 중단을 최소화하기 위해 신중하게 관리해야 합니다.

실행 가능한 단계:

• 전환 계획 개발:

  • 주말 또는 저녁 전환에 대한 이벤트 시퀀스를 정의합니다. 여기에는 Redshift를 가리키는 ETL 작업 중지, 최종 데이터 동기화 수행, 모든 연결 리디렉션, 시스템 상태 유효성 검사 작업이 포함됩니다.

• 최종 데이터 동기화 실행:

  • 마지막 증분 데이터 로드를 한 번 수행하여 테스트 단계 중에 발생한 모든 데이터 변경 사항을 캡처합니다.

• 시작:

  • 모든 프로덕션 데이터 파이프라인과 사용자 연결을 Redshift에서 Snowflake로 전환합니다.

  • Redshift 환경을 해제하기 전에 대체 수단으로 짧은 기간 동안 읽기 전용 상태로 유지합니다.

• Redshift 해제:

  • Snowflake 환경이 프로덕션에서 안정화되고 검증되면 비용이 발생하지 않도록 Redshift 클러스터를 해제할 수 있습니다.

9단계: 최적화 및 실행¶

이 마지막 단계는 새로운 Snowflake 환경에서 성능, 비용 및 거버넌스를 관리하는 지속적인 프로세스입니다. 설정을 지속적으로 개선하여 가치를 극대화하는 것이 목표입니다.

실행 가능한 단계:

• 성능 및 비용 최적화 구현:

  • 웨어하우스를 적절한 크기로 조정: 워크로드 성능을 지속적으로 모니터링하고 가상 웨어하우스 크기를 늘리거나 줄여 최대한 낮은 비용으로 SLAs를 충족합니다.

  • 적극적인 자동 일시 중단 정책 설정: 유휴 컴퓨팅 시간에 대한 비용이 발생하지 않도록 모든 웨어하우스의 자동 일시 중단 시간 제한을 60초로 설정합니다.

  • 클러스터링 키 사용: 매우 큰 테이블(멀티 테라바이트)의 경우 쿼리 패턴을 분석하고 클러스터링 키를 정의하여 고도로 필터링된 쿼리의 성능을 개선합니다.

• 장기적인 FinOps 및 거버넌스 구축:

  • 비용 모니터링: Snowflake의 ACCOUNT_USAGE 스키마 및 리소스 모니터를 통해 크레딧 사용량을 추적하고 예산 초과를 방지합니다.

  • 보안 세분화: 최소 권한의 원칙이 유지되도록 역할과 권한을 정기적으로 감사합니다. 민감한 데이터에 대한 동적 데이터 마스킹 및 행 액세스 정책과 같은 고급 보안 기능을 구현합니다.

부록 1: Snowflake 및 Redshift 아키텍처¶

부록 2: 데이터 타입 매핑¶

부록 3: SQL 및 함수의 차이점¶