뮤직카우의 Amazon RDS와 Amazon Redshift 간 CDC 파이프라인 Zero-ETL로 쉽게 구축하기

2016년 설립된 뮤직카우는 세계 최초의 음악수익증권 플랫폼입니다. 음악수익증권은 누구나 매월 저작권으로부터 발생하는 수익을 받아볼 수 있고, 자유로운 거래로 추가 수익을 창출할 수 있는 자산입니다.

뮤직카우는 음악수익증권 투자라는 혁신적 비즈니스 모델을 통해 ‘문화금융’이라는 새로운 가치를 만들었습니다. 투자자들에게는 매력적인 투자 대안을, 음악 팬들에게는 좋아하는 노래를 들을수록 수익이 쌓이는 음악 소비 문화의 새로운 패러다임을 제시하고 있습니다. 또, 아티스트들에게는 새로운 창작 자금 유입 경로를 확보할 수 있도록 지원함으로써 음악생태계에 지속가능한 ‘선순환 구조’를 구축해 나가고 있습니다.

미국 서비스 데이터플랫폼의 필요성

뮤직카우가 미국 서비스를 준비하면서 미국 서비스의 지표를 분석하기 위한 데이터플랫폼 또한 구축이 필요하였습니다. 이 때, 두 가지 요구사항이 존재 하였습니다.

모든 리소스를 클라우드로 구축
DB의 데이터 변경을 준 실시간으로 DW(Data Warehouse) 에 반영

한국 뮤직카우의 서비스는 AWS와 IDC에 구축하는 하이브리드 클라우드 방식으로 인프라를 구성하였습니다. 특히, 데이터플랫폼 인프라는 데이터의 처리 및 조회는 IDC 내에 구축한 서비스를 통해 구성하였고 데이터의 적재(DW)를 Amazon Redshift로 구성을 하였습니다.

<그림1. 한국 뮤직카우의 ETL 프로세스>

또한, 모든 분석 및 데이터 파이프라인은 전일 데이터를 기준으로 진행하였기 때문에 매일 새벽 DB테이블을 배치 선택하여 Amazon Redshift에 적재 하는 방식으로 진행하여 실시간 데이터 변경 반영(Change Data Capture, CDC)이 필요하지 않았습니다.

미국 서비스는 반대로 언제든 인프라의 관리를 미국 조직에 이관을 할 수 있기 위한 100퍼센트의 퍼블릭 클라우드 구성이 필요하였습니다. 서비스 런칭 이후 사용자 증가량(DAU, MAU) 및 거래량의 변화를 실시간으로 모니터링 해야 하는 요구사항이 있었습니다. 이를 해결하기 위해 DW를 통한 준 실시간 데이터 플랫폼을 구성하여 대시보드를 구성하고자 했습니다. 그러나 당시 개발 인력은 데이터 엔지니어 한 명과 지원해줄 DBA 한 명 뿐이었고 제한된 인적 자원과 리소스를 통해 효율적인 CDC 프로세스 구축이 필요했습니다.

Amazon Redshift Zero ETL 소개

Amazon Redshift Zero-ETL은 AWS의 완전관리형 데이터 웨어하우스인 Amazon Redshift와 Amazon Aurora, Amazon RDS 등 다양한 운영 데이터 소스를 간편하게 연결해주는 통합 기능입니다.

기존의 ETL(Extract, Transform, Load) 방식에서는 데이터를 추출하고, 변환하고, 적재하는 여러 단계를 수동으로 구성해야했습니다. 반면, Zero-ETL은 이 과정을 자동화하거나 생략함으로써 데이터 통합 속도를 크게 높이고, 소스 데이터베이스에 미치는 부하를 최소화할 수 있습니다.

복잡한 ETL 코드를 작성하지 않아도, 운영 데이터베이스의 변경 사항이 Amazon Redshift로 자동 복제되어 준 실시간에 가까운 분석 환경을 구축할 수 있습니다.

<그림 2. Zero-ETL 데이터 통합 흐름>

Zero-ETL를 활용한 CDC 구축

AWS 환경에서 변경 데이터 캡처(CDC) 시스템을 구축할 때 많은 기업이 AWS DMS를 활용합니다. DMS는 단순히 데이터베이스를 이전하는 것뿐만 아니라, 원본 데이터의 변경 사항을 지속적으로 복제하는 CDC 기능을 제공하기 때문입니다. 뮤직카우 또한 과거 DMS를 성공적으로 사용했던 경험을 바탕으로, 미국 서비스의 신규 데이터 플랫폼을 구축하는 데 이 서비스를 다시 활용하고자 했습니다. 그러나 플랫폼 구축을 앞두고 새로운 기능인 Amazon Redshift Zero ETL을 소개받아, 기존에 고려했던 DMS와 Zero ETL의 장단점을 세 가지 측면에서 비교해 보았습니다.

DB부터 DW까지의 모든 인프라를 AWS 내에서 구성하면 Amazon RDS와 Amazon Redshift간 추가 파이프라인 없이 바로 CDC를 적용할 수 있는 Zero-ETL 을 구성했고 DMS에 비해 어떤 장점이 있는지 아래 3가지 항목으로 비교해 봤습니다.

항목	DMS	Zero-ETL
비용	– 온디맨드 인스턴스 또는 서버리스를 통해 데이터 변경 반영하며 사용 비용 발생 – 데이터 전송 비용 스토리지 비용 등 추가 비용 발생 가능	– 추가 비용 없음
관리의 용이성	– 데이터 양에 따른 Scaling 고려 필요 – 소스와 타겟 데이터베이스 종류에 따른 네트워크 및 권한 설정 필요	– Amazon RDS 설정 및 Amazon Redshift 권한 설정 이후 추가 설정 필요 없음
빠른 장애 복구	– 마이그레이션 중지 발생시 원인 파악 및 수동 대응 필요 (예: OOM에 따른 마이그레이션 정지시 수동 Scaling 필요)	– CDC 중단 발생시 Zero-ETL 자체적으로 Checkpoint 비교를 통해 자동 복구

이러한 비교 검토를 거쳐, 이번에는 데이터 플랫폼 아키텍처에는 Zero ETL를 최종 선정했습니다.

<그림3. 최종 데이터플랫폼 아키텍처 (간단 도식)>

Zero-ETL 구축기

데이터플랫폼 아키텍처를 코드 기반 관리 및 배포를 위해 Terraform을 활용하여 Amazon Redshift 및 Zero-ETL 구축을 진행하였고 Amazon RDS for MYSQL은 DBA의 도움으로 Zero-ETL을 위한 설정을 구성하였습니다.

1. Amazon RDS for MySQL 설정

Zero-ETL이 정상적으로 동작하기 위해서는, Amazon RDS for MySQL의 파라미터 그룹 설정을 변경하여 데이터 변경 이력이 바이너리 로그(binary log)에 상세히 기록되도록 만들어야 합니다.

Parameter	설정값	설명
binlog_format	ROW	– DML 을 통해 실제로 변경된 행 단위의 데이터 값을 로그에 기록 – 데이터 변경 사항 정확히 추적 및 무결성 보장
binlog_row_image	FULL	– 모든 칼럼 정보를 binary log에 포함 – BLOB 등의 대용량 칼럼이 자주 변경되는 테이블은 리소스 소모가 심할 수 있어 주의 필요
binlog_row_value_options	NOT PARTIAL_JSON	– 모든 JSON 필드가 binary log에 포함 – BLOB와 마찬가지로 JSON 필드가 복잡하거나 클수록 리소스 소모가 심할 수 있음
binlog_transaction_compression	OFF	– binary log를 실시간으로 스트리밍 하기 위한 설정 – binary log에서 row 단위 이벤트를 압축없이 기록

2. Amazon Redshift 설정 및 권한 부여

Amazon Redshift 측에서도 몇 가지 설정이 필요합니다.

항목	설명
노드 타입	– 온디맨드 클러스터로 구축시 RA 타입의 인스턴스로 구축 – Serverless는 바로 사용 가능
암호화	– 온디맨드 클러스로 구축시 스토리지 암호화 설정 필요 – Serverless는 생성시 자동으로 스토리지 암호화
대소문자 구분	– 대소문자 구분 허용 필요

Terraform 코드로는 다음과 같이 설정을 해줍니다.

Amazon Redshift Cluster

resource "aws_redshift_parameter_group" "parameter_group" {
  name   = "example-parameter-group"
  family = "redshift-1.0"
  
  # 대소문자 구분 활성화
  parameter {
    name  = "enable_case_sensitive_identifier"
    value = "true"
  }
}

resource "aws_redshift_cluster" "redshift_cluster" {
  cluster_identifier = "redshift-cluster"
  database_name      = "dbname"
  master_username    = "username"
  master_password    = "password"
node_type          = "ra3.large" # RA 인스턴스 사용
encrypted          = true # 암호화 설정
cluster_parameter_group_name = aws_redshift_parameter_group.parameter_group.name # 생성한 파라미터 그룹 할당
}

Amazon Redshift Serverless

resource "aws_redshiftserverless_namespace" "namespace" {
  namespace_name = "redshift-namespace"
}

resource "aws_redshiftserverless_workgroup" "example" {
  namespace_name = aws_redshiftserverless_namepsace.namespace.name
workgroup_name = "redshift-workgroup"

# 대소문자 구분 활성화
config_parameter {
	parameter_key = "enable_case_sensitive_identifier"
	parameter_value = true
}
}

위 두 코드는 매우 간단한 Terraform 코드들로 추가 설정이 필요합니다.

Amazon Redshift 서비스 설정도 필요하지만, Amazon Redshift 리소스 정책 설정도 중요합니다. 다음과 같은 Terraform 코드를 통해 Amazon RDS로부터 Amazon Redshift까지의 Zero-ETL 생성이 가능하게끔 정책을 정의합니다.

resource "aws_redshift_resource_policy" "zero_etl_policy" {
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AllowRedshiftAuthorizeInboundIntegration"
        Effect = "Allow"
        Principal = {
          Service = "redshift.amazonaws.com"
        }
        Action = [
          "redshift:AuthorizeInboundIntegration"
        ]
        Resource = “Amazon Redshift namespace arn” # 생성한 Amazon Redshift namespace arn 할당
        Condition = {
          StringEquals = {
            "aws:SourceArn" = “Amazon RDS arn” # Zero-ETL을 연결할 Amazon RDS arn 할당
          }
        }
      },
      {
        Sid    = "AllowCreateInboundIntegration"
        Effect = "Allow"
        Principal = {
          AWS = [
            “AWS role or user arn” # Zero-ETL을 생성할 계정 또는 역할 arn 할당
          ]
        }
        Action   = "redshift:CreateInboundIntegration"
        Resource = “Redshift namespace arn” # 생성한 Amazon Redshift namespace arn 할당
      }
    ]
  })
  resource_arn = “Amazon Redshift namespace arn” # 생성한 Amazon Redshift namespace arn 할당
}

주의 : 당시 배포를 진행하였던 Terraform Providers Hashicorp 5.94.1 버전에서는 aws_redshiftserverless_resource_policy의 JSON encode 이슈가 있어 aws_redshift_resource_policy를 사용하여 생성하였습니다.

소스 DB에 따라 aws:SourceArn을 조정해주시면 됩니다.

마지막으로 Terraform을 배포하는 계정 또는 Zero-ETL을 생성하는 역할 또는 계정에 다음 IAM 정책 추가가 필요합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds:CreateIntegration",
                "rds:DeleteIntegration"
            ],
            "Resource": [
                "<DB ARN>", # 소스DB arn
                "arn:aws:rds:<region>:<account_num>:integration:*" # integration(Zero-ETL) arn
            ]
        }
    ]
}

위 설정들을 통해서 Zero-ETL을 연결하기 위한 준비는 완료되었습니다.

Zero-ETL을 생성하기 위한 Terraform 코드는 매우 간단합니다.

resource "aws_rds_integration" "Zero-ETL_example" {
  integration_name = "zero-etl-example"
  source_arn       = “RDS arn” # 소스 Amazon RDS arn
  target_arn       = “Amazon Redshift arn” # 연결할 Amazon Redshift namespace arn

  data_filter = "include: <포함할 테이블 스키마 패턴>,exclude: <제외할 테이블 스키마 패턴>"
	
  # 5.94.1 버전 Terraform/HCL에서 Zero-ETL을 destroy 후 다시 create하는 이슈 방지
  lifecycle {
    prevent_destroy = true
  }
}

Zero-ETL 생성 이후 테이블 추가는 콘솔을 통해서 가능합니다.

3. Zero-ETL 결과 테이블 저장할 데이터 베이스 생성

위와 같이 양쪽 서비스의 설정이 완료되면, Amazon RDS와 Redshift 간의 CDC 파이프라인을 구축할 준비가 끝납니다. 마지막 단계는 Redshift 클러스터 내에서 Zero-ETL을 통해 복제된 데이터를 저장할 전용 데이터베이스를 생성하는 것입니다. 이 작업은 다음 SQL 명령어로 간단히 수행할 수 있습니다.

CREATE DATABASE <DB_NAME> FROM INTEGRATION 'integration_id';

여기서 ‘integration ID’는 Zero-ETL 생성시 부여되는 ID값으로 AWS 콘솔에서 Redshift 서비스 페이지 > 제로 ETL 통합 메뉴에서 확인할 수 있습니다. 이후 해당 DB로 접속을 하면 Zero-ETL로 연결한 테이블을 확인 할 수 있습니다.

<그림4. Zero-ETL을 테스트하기 위해 생성한 테이블이 연결된 상태 (Redash로 확인)>

Zero-ETL 이 적용된 운영 환경에서 주의사항

운영 환경에서 Zero-ETL을 안정적으로 활용할 수 있을지 검증하기 위해 몇 가지 테스트를 진행했고, 그 결과를 공유하고자 합니다. 본 내용은 2025년 3월에 테스트한 결과이므로, 최신 버전의 Zero-ETL 서비스와는 동작 방식에 차이가 있을 수 있다는 점을 미리 공유드립니다.

1. 테이블이 동기화 진행 상태일 때도 테이블에 접근할 수 있습니다.

Zero-ETL을 통해 연결된 테이블 상태는 SVV_INTEGRATION_TABLE_STATE라는 Amazon Redshift 시스템 테이블을 통해 확인할 수 있습니다. 대부분의 DDL은 Resync 작업 후 동기화가 진행되며, QUERY_ALL_STATES=TRUE 옵션을 사용하면 테이블이 동기화 진행 상태(ResyncRequired, ResyncInitiated 등)에 있더라도 해당 테이블을 조회할 수 있습니다.

2. 데이터 타입이 Redshift 호환 형식으로 변경됩니다.

Zero-ETL 내부적으로 Amazon Redshift에 대응하는 테이블을 생성할 때, 호환되는 데이터 타입으로 변경을 합니다. 저희 서비스 DB에서 주로 사용하는 데이터 타입이 Zero-ETL를 통해 Amazon Redshift에 생성된 테이블에서는 어떻게 대응되는지 표로 정리하였습니다.

Amazon RDS for MYSQL	Amazon Redshift
int	int
decimal	numeric
float	real
double	double precision
datetime	timestamp without time zone
char	varchar
varchar	varchar
text	varchar
enum	varchar
json	super

Amazon Redshift를 구축할 때는 다음과 같은 설정이 필요합니다.

항목	설명
노드 타입	– 온디맨드 클러스터로 구축시 RA 타입의 인스턴스로 구축 – Serverless는 바로 사용 가능
암호화	– 온디맨드 클러스로 구축시 스토리지 암호화 설정 필요 – Serverless는 생성시 자동으로 스토리지 암호화
대소문자 구분	– 대소문자 구분 허용 필요

3. Amazon RDS Failover 발생 시 전체 테이블 재동기화가 수행됩니다.

일반적으로 Zero-ETL이 연결된 Amazon RDS가 셧다운 상태가 되면 Amazon RDS가 재시작하기 전까지는 동기화는 일시정지가 됩니다. (이 때, Amazon Redshift 테이블에 접근은 가능합니다.) 그러나 Multi AZ Amazon RDS의 Failover 재시동 수행시에는 기존에 Zero-ETL에 연결된 인스턴스가 다른 인스턴스로 교체됩니다. 이 때, Zero-ETL 내부에서는 Binlog 체크포인트의 차이로 안하여 모든 테이블에 대한 재동기를 수행하고 재동기 이후에 다시 해당 Amazon RDS 인스턴스와 CDC가 이루어집니다.

Zero-ETL 도입 후기

Zero-ETL은 당시 제한된 시간과 비용을 통해 효율적인 CDC 프로세스 구축을 가능하게 도와줬습니다. 추가적인 서비스 또는 인프라 구축이 불필요하여 사용비용이 없다는 큰 장점 또한 존재합니다. 특히, binlog 체크포인트 기반 자동 장애 복구 프로세스를 통해 관리 포인트도 많이 줄었습니다. 이를 통해 준 실시간적인 대시보드 구성이 필요한 상황에서도 수초 내로의 오차로 실시간 데이터를 보여줄 수 있게 되었습니다.

Zero-ETL은 2023년 11월에 출시된 비교적 새로운 서비스로, 현재도 기능 개선이 활발히 이루어지고 있습니다. 다만, 일부기능은 아직 제공되지 않아 아쉬운 부분이 있을 수 있습니다.

하지만 운영 부담 없이 실시간 CDC 파이프라인을 간단히 구성할 수 있다는 점에서, 현재 시점에서도 실무에 충분히 적용 가능한 강력한 대안입니다. 특히, 제한된 리소스 내에서 빠르게 분석 환경을 구축하려는 스타트업 및 소규모 팀에게는 Zero-ETL이 DMS를 대체할 수있는 현실적인 선택지가 될 수 있습니다.

AWS 기술 블로그