대규모 데이터 분석 워크로드를 처리하는 MySQL 인스턴스가 성능 병목에 직면했다면,阿里云 AnalyticDB MySQL로의 마이그레이션이 효과적인 해결책이 될 수 있다. 이 솔루션은 기존 SQL 코드 변경 없이도 복잡한 분석 쿼리 성능을 100배 이상 향상시킬 수 있으며, DTS(Data Transmission Service)를 활용해 무중단으로 데이터를 이전할 수 있다.

마이그레이션이 필요한 시점

• 보고서 쿼리 응답 시간이 30초 이상 소요됨
• GROUP BY와 JOIN이 포함된 쿼리로 인해 전체 인스턴스 부하 증가
• 수억 건 이상의 데이터에서 인덱스 추가로도 성능 개선 한계 도달
• 읽기 전용 복제본을 추가해도 분석 작업 부하를 감당하지 못함

AnalyticDB MySQL은 이러한 OLAP(온라인 분석 처리) 워크로드에 특화되어 있으며, 컬럼 기반 저장 방식과 벡터화 실행 엔진을 통해 빠른 분석 성능을 제공한다.

무중단 마이그레이션 절차

1. AnalyticDB MySQL 클러스터 생성

# 서버리스 모드 권장 (사용량 기반 과금)
aliyun adb CreateDBCluster \
  --RegionId cn-hangzhou \
  --DBClusterCategory MixedStorage \
  --Mode Serverless \
  --ComputeResource 16ACU \
  --StorageResource 24ACU

2. 대상 데이터베이스 및 테이블 구성

AnalyticDB MySQL은 MySQL DDL 문법과 호환되므로 기존 스키마를 그대로 사용할 수 있다:

CREATE TABLE sales_records (
    record_id BIGINT PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    item_id BIGINT NOT NULL,
    created_at DATETIME NOT NULL,
    amount DECIMAL(10,2),
    state TINYINT,
    zone VARCHAR(50),
    INDEX idx_customer (customer_id),
    INDEX idx_created (created_at)
) ENGINE=InnoDB;

자동 인덱스 추천 기능을 활성화하면 시스템이 쿼리 패턴을 분석해 최적의 인덱스를 자동으로 생성한다:

SET adb_config auto_index_recommendation = ON;

3. DTS를 통한 실시간 동기화 설정

{
  "SourceEndpoint": {
    "InstanceType": "RDS",
    "InstanceID": "rm-bp1xxxxx",
    "DatabaseName": "business_db"
  },
  "DestinationEndpoint": {
    "InstanceType": "ADB30",
    "InstanceID": "am-bp1xxxxx",
    "DatabaseName": "business_db"
  },
  "MigrationMode": {
    "StructureInitialization": true,
    "DataInitialization": true,
    "DataSynchronization": true
  },
  "SyncObjects": [
    {
      "SchemaName": "business_db",
      "TableIncludes": [
        {"TableName": "sales_records"},
        {"TableName": "customers"},
        {"TableName": "items"}
      ]
    }
  ]
}

4. 데이터 일관성 검증

-- 원본 MySQL
SELECT COUNT(*) AS total_rows, MAX(record_id) AS latest_id FROM sales_records;

-- 대상 AnalyticDB MySQL (동일 쿼리)
SELECT COUNT(*) AS total_rows, MAX(record_id) AS latest_id FROM sales_records;

두 결과가 일치하고, AnalyticDB MySQL에서 쿼리 응답 시간이 수십 배 빨라지는 것을 확인할 수 있다.

5. 애플리케이션 연결 전환

# 분석용 연결 (AnalyticDB MySQL)
analytics_conn = pymysql.connect(
    host='am-bp1xxxxx.ads.aliyuncs.com',
    port=3306,
    user='report_user',
    password='***',
    database='business_db'
)

# 트랜잭션용 연결 (기존 MySQL)
transaction_conn = pymysql.connect(
    host='rm-bp1xxxxx.mysql.rds.aliyuncs.com',
    port=3306,
    user='app_user',
    password='***',
    database='business_db'
)

SQL 호환성 검증 사례

AnalyticDB MySQL은 다양한 고급 SQL 기능을 지원한다:

-- 윈도우 함수
SELECT customer_id, created_at, amount,
       AVG(amount) OVER (PARTITION BY customer_id ORDER BY created_at ROWS 2 PRECEDING) AS moving_avg
FROM sales_records;

-- CTE (공통 테이블 표현식)
WITH daily_summary AS (
    SELECT DATE(created_at) AS sale_date,
           SUM(amount) AS daily_total
    FROM sales_records
    GROUP BY sale_date
)
SELECT sale_date, daily_total,
       daily_total - LAG(daily_total, 1) OVER (ORDER BY sale_date) AS diff_from_yesterday
FROM daily_summary;

-- JSON 필드 처리
SELECT JSON_UNQUOTE(JSON_EXTRACT(metadata, '$.campaign')) AS campaign_name,
       COUNT(*) AS participation_count
FROM sales_records
WHERE JSON_EXTRACT(metadata, '$.campaign') IS NOT NULL
GROUP BY campaign_name;

-- 중첩 서브쿼리
SELECT * FROM customers
WHERE customer_id IN (
    SELECT customer_id
    FROM sales_records
    GROUP BY customer_id
    HAVING SUM(amount) > 5000
);

주의사항 및 최적화 팁

• AnalyticDB MySQL은 기본적으로 컬럼 기반 저장소이므로, 단일 행 조회는 반드시 기본키를 사용해야 함
• 비정형 조건(WHERE remark = 'text')은 전체 스캔을 유발하므로, 필요한 경우 전문 검색 인덱스 또는 파티션 키 포함 조건 사용
• 분석용 쿼리는 AnalyticDB로, 트랜잭션 처리는 기존 MySQL로 분리하여 HTAP(Hybrid Transactional/Analytical Processing) 아키텍처 구현

자주 묻는 질문

Q: 기존 애플리케이션 코드 수정이 필요한가요?
A: 아니요. MySQL 프로토콜과 JDBC/ODBC 드라이버를 완전히 호환하므로 연결 정보만 변경하면 됩니다.

Q: DTS 동기화 지연과 데이터 유실 가능성은?
A: 일반적으로 밀리초~초 단위 지연이 발생하며, 데이터 유실 없이 최종 일관성을 보장합니다.

Q: 기존 MySQL 인덱스는 어떻게 되나요?
A: AnalyticDB는 자동 인덱스 최적화를 제공하므로 대부분의 경우 수동 인덱스 생성이 불필요합니다.

Q: 마이그레이션 중 서비스 중단이 필요한가요?
A: DTS의 전체+증분 동기화를 사용하면 무중단 마이그레이션이 가능합니다. 1TB 기준 전체 동기화는 약 2~4시간 소요됩니다.

Q: AnalyticDB MySQL은 OLTP 작업에도 적합한가요?
A: 주 용도는 OLAP 분석이며, 고빈도 단일 행 조회는 지원하지만 트랜잭션 처리는 기존 MySQL을 유지하는 것이 권장됩니다.