HeatWave Autopilot으로 쿼리 성능을 자동 최적화하는 원리는 무엇인가요?
핵심 요약: HeatWave Autopilot이 데이터 배치, 쿼리 플랜, 클러스터 크기를 ML로 자동 최적화하는 원리를 설명해요. 메모리 예측 98.4%, TPC-H/TPC-DS 24TB 기준 40% 성능 향상 지표를 다뤄요.
이전 글에서 MySQL HeatWave의 아키텍처와 기존 MySQL과의 차이를 다뤘어요. 이번에는 HeatWave 운영의 핵심인 Autopilot을 깊이 살펴볼게요.
HeatWave를 처음 도입한 고객사에서 가장 많이 받는 질문이 있어요. "인메모리 MPP 엔진이라면 데이터 배치, 인코딩, 클러스터 크기를 직접 튜닝해야 하는 거 아닌가요?" 기존 분석 DB를 운영해 본 팀이라면 당연히 드는 걱정이에요. Redshift의 Distribution Key 설계, BigQuery의 파티셔닝 전략처럼 수동 최적화에 시간을 쏟아야 했던 경험이 있으니까요.
HeatWave Autopilot은 이 문제를 ML 모델로 해결해요. 데이터 배치부터 쿼리 플랜 개선, 클러스터 크기 추천까지 18개 이상의 자동화 기능이 내장돼 있어요. 마치 숙련된 DBA가 24시간 모니터링하면서 최적화 작업을 수행하는 것과 비슷한데, 사람보다 일관되고 빠르게 동작해요.
이 글에서는 Autopilot의 ML 기반 자동화 메커니즘, 각 기능의 동작 원리, 실제 SQL 사용법, 그리고 "DBA 없이도 운영 가능한가?"에 대한 현실적인 답변을 다룰게요.
Autopilot의 ML 기반 자동화 메커니즘
Autopilot은 단순한 규칙 기반 자동화가 아니에요. Oracle이 사전 학습시킨 ML 모델이 HeatWave 클러스터 내부에서 동작하면서, 사용자 워크로드에 맞게 지속적으로 적응해요.
동작 방식은 네 단계로 이루어져요.
첫째, 데이터 샘플링이에요. 테이블 데이터를 샘플링해서 컬럼별 분포, 카디널리티, NULL 비율 같은 통계 정보를 수집해요. 전체 데이터를 스캔하지 않고 샘플링으로 처리하기 때문에 오버헤드가 작아요.
둘째, ML 모델 추론이에요. 수집된 통계를 기반으로 학습된 모델이 최적의 설정값을 예측해요. 인코딩 방식, 데이터 배치 전략, 필요한 메모리 크기 등을 결정하는 거예요.
셋째, 자동 적용이에요. 예측된 설정을 클러스터에 자동으로 반영해요. 별도의 DBA 승인이나 수동 작업 없이 즉시 적용돼요.
넷째, 피드백 루프예요. 적용 후 실제 쿼리 실행 결과를 수집해서 모델을 개선해요. 시간이 지날수록 해당 워크로드에 더 정확하게 최적화되는 구조예요.
운영하면서 계속 느낀 건, 이 피드백 루프가 Autopilot의 핵심 가치라는 거예요. 초기 설정이 완벽하지 않더라도 시간이 지나면서 워크로드 패턴을 학습하고 점점 더 정확해져요.
Auto Data Placement. 메모리 예측 정확도 98.4%
Auto Data Placement는 HeatWave 클러스터의 여러 노드에 데이터를 어떻게 분배할지 ML로 결정하는 기능이에요.
분산 처리 시스템에서 데이터 배치는 성능에 직접적인 영향을 줘요. 잘못된 배치는 노드 간 데이터 셔플링을 유발하고, 이건 네트워크 병목으로 이어져요. 기존 분석 DB에서는 이걸 수동으로 설계해야 했어요. Redshift의 Distribution Key를 잘못 선택하면 쿼리 성능이 10배 이상 차이 나는 경우도 있었어요.
Autopilot의 Auto Data Placement는 쿼리 패턴을 분석해서 최적의 데이터 분배 전략을 자동으로 결정해요. Oracle 공식 벤치마크 기준으로 메모리 예측 정확도가 98.4%예요. 수동으로 파티셔닝 전략을 설계하는 것보다 훨씬 정확하게 최적화해줘요.
-- Autopilot이 데이터 배치를 자동으로 최적화하며 테이블 로드
ALTER TABLE orders SECONDARY_ENGINE=RAPID;
ALTER TABLE orders SECONDARY_LOAD;
-- 로드 후 배치 상태 확인
SELECT * FROM performance_schema.rpd_table_statistics
WHERE TABLE_NAME = 'orders'\G실제 프로젝트에서 만난 사례를 하나 공유할게요. 한 고객사에서 수동으로 파티셔닝을 설계한 후 HeatWave에 로드했는데, Autopilot이 추천한 배치와 비교하니 쿼리 응답 시간이 30% 이상 차이가 났어요. 결국 Autopilot 추천을 따르기로 결정했어요.
Auto Query Plan Improvement. 시간이 지날수록 빨라지는 쿼리
Auto Query Plan Improvement는 Autopilot에서 가장 체감 효과가 큰 기능이에요. 쿼리 실행 후 실제 성능 데이터를 수집하고, 이를 기반으로 향후 동일하거나 유사한 쿼리의 실행 계획을 자동으로 개선해요.
기존 데이터베이스의 쿼리 옵티마이저는 통계 정보 기반으로 실행 계획을 세워요. 하지만 통계가 오래되거나 데이터 분포가 편향되면 최적이 아닌 계획을 선택하는 경우가 많아요. DBA가 주기적으로 통계를 갱신하고, 힌트를 추가하고, 실행 계획을 수동으로 검토해야 했어요.
Auto Query Plan Improvement는 이 과정을 자동화해요. 쿼리가 실행될 때마다 실제 처리 시간, 스캔한 행 수, 메모리 사용량 같은 런타임 통계를 수집해요. 이 데이터가 쌓이면 ML 모델이 더 나은 실행 계획을 생성해요.
TPC-H/TPC-DS 24TB 벤치마크에서 이 기능만으로 40% 성능 향상을 보였어요. 워크로드가 반복될수록 효과가 커지는 구조라서, 정기 리포트나 대시보드 쿼리처럼 패턴이 일정한 워크로드에서 특히 효과적이에요.
-- Auto Query Plan Improvement 활성화 (세션 레벨)
SET SESSION use_secondary_engine_optimization = ON;
-- 글로벌 레벨 활성화
SET GLOBAL use_secondary_engine_optimization = ON;
-- 개선된 쿼리 플랜 확인
EXPLAIN FORMAT=TREE
SELECT l_returnflag, l_linestatus,
SUM(l_quantity) AS sum_qty,
SUM(l_extendedprice) AS sum_base_price
FROM lineitem
WHERE l_shipdate <= DATE_SUB('1998-12-01', INTERVAL 90 DAY)
GROUP BY l_returnflag, l_linestatus
ORDER BY l_returnflag, l_linestatus\G처음엔 이 기능의 효과를 의심했어요. "정말 자동으로 쿼리가 빨라지나?" 하지만 실제로 2주간 운영한 후 동일 쿼리의 응답 시간을 비교해 보니, 복잡한 조인 쿼리에서 평균 25–35% 개선이 확인됐어요.
Autopilot 전체 기능 목록
Autopilot에는 18개 이상의 자동화 기능이 포함돼 있어요. 주요 기능을 정리하면 다음과 같아요.
| 기능 | 역할 | 핵심 지표 |
|---|---|---|
| Auto Data Placement | 노드 간 데이터 최적 분배 | 정확도 98.4% |
| Auto Encoding | 컬럼별 최적 인코딩 방식 선택 | 정확도 96.9% |
| Auto Query Plan Improvement | 쿼리 실행 계획 자동 개선 | 24TB 기준 40% 향상 |
| Auto Provisioning | 최적 클러스터 크기(노드 수) 추천 | 샘플링 기반 예측 |
| Auto Shape Prediction | 워크로드에 적합한 노드 Shape 추천 | 비용 대비 성능 최적화 |
| Auto Compression | 데이터 압축 방식 자동 최적화 | 메모리 사용량 절감 |
| Auto Scheduling | 동시 쿼리 간 리소스 할당 최적화 | 경합 최소화 |
| Auto Error Recovery | 노드 장애 시 자동 복구 및 재로드 | 가용성 유지 |
| Auto Change Propagation | InnoDB 변경사항 HeatWave 자동 반영 | 실시간 동기화 |
| Auto Parallel Loading | 데이터 로드 시 병렬 처리 자동 설정 | 로딩 시간 단축 |
Auto Encoding은 각 컬럼의 데이터 특성(카디널리티, 분포, NULL 비율)을 분석해서 Dictionary, Run-Length, Delta 등 최적의 인코딩을 자동 선택해요. 정확도가 96.9%라는 건, 100개 컬럼 중 97개에서 수동 튜닝과 동일하거나 더 나은 인코딩을 선택한다는 의미예요.
Auto Compression은 Auto Encoding과 함께 동작하면서 메모리 사용량을 최소화해요. 원본 데이터 대비 20–30% 수준으로 압축되는 경우가 일반적이에요.
Auto Error Recovery는 운영 안정성 측면에서 중요해요. HeatWave 노드에 장애가 발생하면 자동으로 해당 노드의 데이터를 다른 노드에서 복구하고 재로드해요. 별도의 장애 대응 프로세스 없이 클러스터 가용성이 유지돼요.
실제 사용 방법. SQL 명령어와 OCI Console
Autopilot 기능은 대부분 기본 활성화 상태예요. 별도 설정 없이 HeatWave 클러스터를 생성하면 자동으로 동작해요. 하지만 명시적으로 Autopilot 리포트를 실행하거나 설정을 조정할 수 있어요.
Auto Provisioning으로 클러스터 크기 추천 받기
-- 특정 스키마에 대한 최적 노드 수 추천
CALL sys.heatwave_autopilot_report(
JSON_OBJECT(
"target_schema", JSON_ARRAY("mydb"),
"auto_enc", "ON",
"auto_dp", "ON"
)
);
-- 추천 결과 확인
SELECT * FROM sys.heatwave_autopilot_report\G이 명령어를 실행하면 Autopilot이 대상 스키마의 테이블을 샘플링하고, Auto Encoding과 Auto Data Placement를 함께 고려해서 필요한 노드 수를 추천해줘요. 실제 데이터를 로드하기 전에 비용을 예측할 수 있어서 유용해요.
HeatWave Advisor로 종합 최적화 리포트 받기
-- HeatWave Advisor 실행 (종합 최적화 추천)
CALL sys.heatwave_advisor(JSON_OBJECT('target_schema', 'mydb'));
-- Advisor 리포트 확인
SELECT * FROM sys.heatwave_advisor_report\GHeatWave Advisor는 Autopilot의 여러 기능을 종합해서 최적화 추천을 제공해요. 어떤 테이블을 로드해야 하는지, 인코딩은 어떻게 설정해야 하는지, 노드 수는 적절한지를 한 번에 확인할 수 있어요.
OCI Console에서 Autopilot 관리
OCI Console에서도 Autopilot 설정을 관리할 수 있어요.
경로: OCI Console → MySQL → DB Systems → 해당 인스턴스 선택 → HeatWave Cluster → Autopilot
여기서 Autopilot 활성화 상태를 확인하고, 리포트 이력을 조회하고, 클러스터 크기 변경 추천을 확인할 수 있어요. SQL에 익숙하지 않은 팀원도 Console에서 Autopilot 상태를 모니터링할 수 있다는 점이 운영 편의성을 높여줘요.
Auto Parallel Loading으로 데이터 빠르게 로드하기
-- 스키마 전체 테이블을 HeatWave에 병렬 로드
CALL sys.heatwave_load(JSON_ARRAY("mydb"), NULL);
-- 개별 테이블 로드 (Autopilot이 병렬도 자동 결정)
ALTER TABLE orders SECONDARY_ENGINE=RAPID;
ALTER TABLE orders SECONDARY_LOAD;Auto Parallel Loading은 데이터를 HeatWave 클러스터에 로드할 때 최적의 병렬 처리 수준을 자동으로 결정해요. 테이블 크기, 노드 수, 현재 클러스터 부하를 고려해서 병렬도를 조절하기 때문에 수동으로 설정하는 것보다 안정적이에요.
DBA 없이도 운영 가능한가요?
이 질문에 대한 현실적인 답변을 드릴게요.
결론부터 말하면, "일상적인 운영 부담은 크게 줄어들지만, 전문 지식이 전혀 필요 없는 건 아니에요."
Autopilot이 해결해주는 영역은 명확해요. 데이터 배치 최적화, 인코딩 선택, 쿼리 플랜 개선, 클러스터 크기 추천, 장애 복구 같은 반복적이고 전문적인 튜닝 작업을 자동화해줘요. 기존에 DBA가 주기적으로 수행하던 작업의 70–80%를 대체한다고 볼 수 있어요.
하지만 여전히 사람의 판단이 필요한 영역이 있어요.
초기 아키텍처 설계가 첫 번째예요. 어떤 테이블을 HeatWave에 로드할지, Lakehouse와 인메모리를 어떻게 조합할지는 비즈니스 요구사항을 이해하는 사람이 결정해야 해요.
비용 최적화 의사결정도 마찬가지예요. Autopilot이 "노드 4개가 최적"이라고 추천해도, 예산 제약이나 비용 대비 성능 트레이드오프는 사람이 판단해야 해요.
보안 및 접근 제어 설정은 Autopilot의 범위 밖이에요. Data Masking 규칙, 감사 로그 설정, 네트워크 보안 그룹 구성은 여전히 수동으로 관리해야 해요.
쿼리 호환성 검증도 필요해요. 새로운 분석 쿼리가 HeatWave에서 처리되는지, InnoDB로 폴백되는지 확인하는 작업은 개발팀이 해야 해요.
저희가 운영한 고객사 중에서 전담 DBA 없이 HeatWave를 운영하는 곳이 있어요. 대신 백엔드 개발자 1명이 HeatWave 기본 개념을 학습하고, Autopilot 리포트를 주기적으로 확인하는 방식으로 운영하고 있어요. 소규모 팀에서는 이 방식이 충분히 동작해요.
다만 대규모 워크로드(수십 TB 이상)나 복잡한 멀티테넌트 환경에서는 HeatWave에 대한 깊은 이해를 가진 엔지니어가 필요해요. Autopilot이 추천하는 설정이 항상 비즈니스 맥락에 맞는 건 아니니까요.
도입 시 알아야 할 트레이드오프
Autopilot이 강력하지만, 도입 전에 알아야 할 현실적인 제약도 있어요.
Autopilot의 학습 기간이 필요해요. Auto Query Plan Improvement는 쿼리 실행 이력이 쌓여야 효과가 나타나요. 도입 직후 1–2주는 학습 기간으로 봐야 해요. 이 기간 동안은 수동 최적화 대비 큰 차이를 느끼기 어려울 수 있어요.
추천을 무조건 수용할 필요는 없어요. Auto Provisioning이 "노드 8개"를 추천해도, 실제 워크로드 패턴이나 예산을 고려해서 "노드 4개로 시작하고 필요 시 확장"하는 전략이 더 적합할 수 있어요. Autopilot은 성능 최적화 관점에서 추천하지, 비용 최적화까지 고려하지는 않아요.
워크로드 변화에 적응하는 데 시간이 걸려요. 갑자기 쿼리 패턴이 바뀌면(예: 새로운 대시보드 추가) Autopilot이 새 패턴을 학습하는 데 며칠이 걸릴 수 있어요. 이 기간 동안 일시적으로 성능이 최적이 아닐 수 있어요.
모니터링은 여전히 필요해요. Autopilot이 자동으로 최적화해주더라도, 클러스터 상태와 쿼리 성능을 모니터링하는 체계는 갖춰야 해요. OCI Console의 Performance Hub나 Grafana 연동을 통해 이상 징후를 조기에 감지하는 게 좋아요.
핵심 요약
- HeatWave Autopilot은 ML 기반 자동화 시스템으로, 데이터 샘플링 → ML 추론 → 자동 적용 → 피드백 루프의 4단계로 동작해요.
- Auto Data Placement는 98.4% 정확도로 노드 간 데이터 배치를 최적화하고, Auto Encoding은 96.9% 정확도로 컬럼별 인코딩을 자동 선택해요.
- Auto Query Plan Improvement는 쿼리 실행 이력을 학습해서 실행 계획을 자동 개선해요. TPC-H/TPC-DS 24TB 기준 40% 성능 향상을 보였어요.
- "DBA 없이 운영 가능"은 일상적 튜닝 작업의 70–80%를 자동화한다는 의미예요. 초기 설계, 비용 판단, 보안 설정은 여전히 사람이 필요해요.
- Autopilot은 학습 기간(1–2주)이 필요하고, 추천을 무조건 수용하기보다 비즈니스 맥락과 함께 판단해야 해요.
FAQ
Q. Autopilot을 별도로 활성화해야 하나요?
HeatWave 클러스터를 생성하면 Autopilot은 기본 활성화 상태예요. 별도 설정 없이 자동으로 동작해요. Auto Query Plan Improvement만 세션 레벨에서 SET SESSION use_secondary_engine_optimization = ON으로 명시적 활성화가 필요한 경우가 있어요.
Q. Autopilot의 추천을 무시하고 수동 설정을 사용할 수 있나요?
가능해요. Autopilot은 추천을 제공하지만 강제하지 않아요. sys.heatwave_autopilot_report로 추천을 확인한 후, 비즈니스 맥락에 맞게 수동으로 다른 설정을 적용할 수 있어요. 다만 대부분의 경우 Autopilot 추천을 따르는 게 성능 면에서 유리해요.
Q. Auto Query Plan Improvement의 효과를 확인하는 방법은 무엇인가요?
동일 쿼리를 시간 간격을 두고 실행하면서 EXPLAIN FORMAT=TREE로 실행 계획 변화를 관찰할 수 있어요. Performance Schema의 쿼리 통계 테이블에서 평균 응답 시간 추이를 확인하는 것도 좋은 방법이에요. 보통 2주 정도 운영하면 반복 쿼리에서 개선 효과가 나타나기 시작해요.
Q. Autopilot 때문에 추가 비용이 발생하나요?
Autopilot은 HeatWave 클러스터에 기본 포함된 기능이에요. 별도 라이선스나 추가 비용 없이 사용할 수 있어요. Autopilot이 추천하는 노드 수를 늘리면 클러스터 비용이 증가하지만, 이건 Autopilot 자체의 비용이 아니라 인프라 확장 비용이에요.
Q. 소규모 데이터(수 GB)에서도 Autopilot 효과가 있나요?
효과가 있지만 체감은 작을 수 있어요. Autopilot의 진가는 데이터가 수십 GB 이상이고 쿼리 패턴이 복잡할 때 나타나요. 소규모 데이터에서는 수동 최적화와 Autopilot의 차이가 크지 않을 수 있어요. 다만 데이터가 성장하면서 자동으로 최적화가 따라온다는 점에서 초기부터 활성화해두는 게 좋아요.
운영하면서 계속 느낀 건, Autopilot의 가장 큰 가치는 "최적화를 잊어도 된다"는 안심감이라는 거예요. 기존에는 분기마다 통계 갱신하고, 쿼리 플랜 리뷰하고, 파티셔닝 전략을 재검토해야 했어요. Autopilot이 이 부담을 가져가면서 팀이 비즈니스 로직에 집중할 수 있게 됐어요.
다음 글에서는 HeatWave의 고가용성 설계와 Aurora 대비 HA 아키텍처 차이를 다룰게요. Autopilot 도입을 검토하고 있다면, MySQL HeatWave란 무엇이고, 기존 MySQL과 어떻게 다른가요?에서 HeatWave 기본 아키텍처를 먼저 확인해보세요.