🕰️ 최초 작성일 : 2024.10.16 ✒️ 1차 업데이트: 2025.07.03

해당 문서는 Aurora ZeroETL 기능을 활용하여 Redshift 도입 시 발생 할 수 있는 다양한 이슈 케이스와 영향도를 사전에 확인하기 위해 작성한 테스트 자료입니다. ZeroETL의 기능 업데이트로 향후 변경 될 수 있습니다.

결과 요약 - 주요 제약 사항

• ZETL 적용 시 Mysql의 외래키 제약(CASCADE 등)이 적용 된 테이블에 대해서는 Sync Fail이 발생합니다. DMS의 경우 테이블을 복제하지만 CACASDE 이벤트는 타겟(Redshift)에 복제하지 못합니다. 이는 Mysql의 CASCADE 이벤트가 Binlog에 기록되지 않기 때문입니다.
• BLOB, GEOMETRY, POLYGON, POINT, LINSTRING의 데이터 타입을 갖고 있는 테이블은 Sync Fail이 발생합니다.
• Primary Key가 없는 소스 테이블은 Sync Fail이 발생합니다.
• Redshift Serverless는 ZETL을 실시간으로 적용 시 CDC 작업으로 인해 RPU Computing이 계속 사용됩니다.
• ZETL의 Refresh 주기(최대 5일)를 초 단위로 설정할 수 있습니다. 그러나 많은 Lag가 발생 할 시 지정한 시간보다 빠르게 Redshift에 CDC가 적용 될 수 있습니다.
• 대부분의 DDL은 Resync 작업 후 동기화가 진행됩니다. QUERY_ALL_STATES=TRUE로 할 경우 Resync 작업 중에도 Zero-ETL로 동기화하는 테이블을 조회 할 수 있습니다.(기능 업데이트)
• Integration을 생성하는 과정에도 Redshift의 상태는 Modifying으로 변경되지만, 여전히 Target Database 및 Table에 접근이 가능합니다.(기능 업데이트)
• Integration의 성능은 Redshift Cluster 사이즈에 따라 달라 질 수 있습니다. Redshift Cluster의 사이즈가 더 클 수록 높은 성능을 보입니다.
• Aurora 클러스터와 관련된 주요 이벤트들(이름 변경, 삭제, B/G 등)은 Integration을 삭제해야 가능합니다.
• Source Aurora Mysql의 경우 1개의 클러스터 당 5개의 Integration 생성이 가능하고, Target Redshift의 경우 50개의 Integration 생성이 가능합니다. 단일 Integration에서 Data Filtering 패턴은 99개까지 생성 가능합니다.

1. Source에 대한 DDL 영향도 테스트

1.1 TABLE 관련 DDL

1.2 COLUMN 관련 DDL

2. Source에 대한 DML 영향도 테스트

2.1 일반적인 DML

2.2 트리거/프로시저를 통한 DML