Oracle Exadata to Snowflake
모던 데이터웨어하우스로의 마이그레이션
전통적 데이터 웨어하우스 역할을 한 Exadata와 모던 데이터 웨어하우스 Snowflake를 비교하고 이를 마이그레이션 하는 전체 과정을 정리해보려고 한다. 가장 먼저 Exadata를 이해하고 이걸 왜 Snowflake로 마이그레이션 하고자 하는지 배경이 되는 설명부터 마이그레이션의 개괄적인 과정을 이어 설명한다.
Exadata가 뭔데?
오라클에서 만든 빠르고 효율적인 DB 이다. 하드웨어+소프트웨어 상호 튜닝되어 있다. 이걸 오라클에서는 엔지니어드 시스템이라고 부른다.
- 기존에는 소프트웨어만 팔았는데 처리 방식에 한계가 있어서 만듦
- 기존 (DB 서버가 바쁨)
- 쿼리 -> DB서버가 스토리지에 데이터 요청 (from 테이블만 보고 거기 내용 다 긁어옴) -> 데이터 전체를 네트워크 타고 DB서버로 보냄 -> DB서버에서 후처리 (select 컬럼들, where 조건들 적용)
- Exadata (DB 서버랑 스토리지 서버가 분담)
- 쿼리 -> DB서버가 스토리지서버에 데이터 요청 -> 스토리지서버는 스마트스캔 수행 (Full Table Scan 시, 데이터를 읽는 즉시 메모리에서 where 조건과 select 컬럼을 적용하는 스마트스캔(SQL Offloading) 기능 수행) -> 추려진 데이터를 네트워크 타고 DB서버로 보냄 -> DB서버에서 후처리 (더 복잡한 join, sort, aggregation 수행)
- 기존 (DB 서버가 바쁨)
왜 이걸 Snowflake로 바꾸라고 하는건데?
기존의 Exadata는 OLTP와 OLAP 둘 다 잘할 수 있도록 설계되었다. 그래서 하드웨어랑 소프트웨어가 붙어 있다. 그럼 뭐가 문제냐? 데이터가 늘어나면 추가 증설해야하고 줄어들면 이 증설한 자원이 쉬는 상태가 된다.
그래서 OLAP 내용을 snowflake에 이관 하면 필요할 때 필요한 만큼 사용할 수 있게 되는 이점을 누릴 수 있다. 즉, 스토리지-DB가 완전 분리되어 유휴 자원의 걱정이 사라지게 된다.
그래서 왜 스노우플레이크?
Exadata를 운영한 조직은 서버 통제에 익숙할 것이다. 스노우플레이크는 가상 서버 (가상 웨어하우스)를 생성하게 된다. 특정 사이즈로 정의된 컴퓨팅 클러스터를 그냥 하나의 가상 서버로 본다. 이를 팀 단위로 독립 배정하는 식으로 운영한다면 기존 방식과 크게 다르지 않게 통제할 수 있다.
더하여 SQL 호환성이 좋다. 스노우플레이크가 오라클의 SQL(PL/SQL) 구문이나 데이터 타입과 매우 유사한 부분이 많다. 마이그레이션 비용 및 기간과 직결되는 요소로 유리하게 작용할 수 있다.
특정 벤더 종속을 방지하는 멀티클라우드 전략에도 유리하다. 만약 이미 AWS나 Azure를 사용하고 있다면 기존 클라우드 환경과 더불어 사용할 수 있다. (스테이징 스토리지는 외부 클라우드 사용 등)
즉, SQL 친숙한 사용자 많고 / 관리 편의성과 안정적 SQL 성능을 중요시 여긴다면 스노우플레이크가 강자일 것이다.
요약하자면
Exadata에서 Snowflake로의 마이그레이션은
- 기술 측면에는 운영/분석의 완벽한 격리와 관리 부담 해소
- 경영 측면에는 CapEx(자본적 지출)에서 OpEx(운영비용) 모델로 전환. 유휴자원 낭비 줄어듦
- 비즈니스 측면에는 분석 속도 향상과 기획/분석가가 직접 데이터를 다루며 빠르게 인사이트를 낼 수 있다는 점이 유리하게 작용할 것이다.
그럼 기존에 투자한 Exadata 자원은?
Exadata를 폐기하는 것이 아니고, OLTP 전용 머신으로 재정의한다.
리소스 주범인 OLAP를 제거하고 핵심 OLTP 서비스가 더 빠르고 안정적으로 작동될 수 있다.
OLAP 덜어낸 Exadata 자원으로 OLTP 충분히 사용할 수 있을 것이며 이후 비즈니스 성장에 대비하게 되는 것이다. (이건 긍정회로)
마이그레이션 전체 과정
마이그레이션은 (1)철저한 사전 계획으로 시작해 (2)필요한 모든 기술 요소(코드, 데이터)와 (3)검증 및 비상 계획을 미리 준비하고, (4)안정적으로 실제 시스템을 전환한 뒤 (5)운영 및 최적화하는 과정이다.
다음과 같은 순서로 정의할 수 있다.
- 기초 평가 및 전략 계획
- Exadata 환경 분석
- 마이그레이션 하면 핵심적으로 고쳐야 할 부분 파악
- 워크로드별 예상 비용 및 성능
- 도구 선택과 환경설정
- 스키마와 객체 마이그레이션
- DDL 변환 (껍데기 만들기)
- 복잡한 객체 재설계 (수동으로 옮길것들)
- 인덱스 및 제약 조건 변환 전략
- 애플리케이션 및 SQL 코드 재작업
- PL/SQL 분석 및 변환
- 일반적인 SQL 구문 및 함수 재작업 (다운스트림 고려)
- 동적 SQL 및 스크립팅 변환
- 데이터 수집 및 검증
- 데이터 추출 -> 스테이징 및 수집
- 지속 데이터 동기화 CDC 구현
- 데이터 검증
- 테스트
- 기능 테스트 및 결과 비교
- 성능 및 동시성 벤치마킹
- 사용자 인수 테스트
- 전환 하기
- 어떻게 전환할지 선택하기
- 최종 전환 실행 계획 구체적으로 세우기
- 롤백 및 비상 계획
- 운영하기
- 비용 관리, 성능 최적화
- 기존 Exadata 시스템 해체하기
마이그레이션 중 가장 중요한 과정
제일 중요한 과정은
- 기초 평가 및 전략 계획
- 데이터 검증
- 테스트
이유는
- 계획을 잘못 세우면 나머지가 완벽해도 실패한다. 즉, 왜 옮기려는가(근본적 문제)에 대한 명확한 정의가 먼저여야 한다.
- 검증 결과가 틀리면 비즈니스 신뢰를 잃고 실패한다.
이 글에서는 Exadata(오라클 DB 어플라이언스)에서 Snowflake(클라우드 데이터 웨어하우스)로 OLAP 용도의 마이그레이션을 왜, 어떻게 추진해야 하는지 실무적 관점에서 정리했다.
요점은 다음과 같다.
- Exadata OLAP 업무를 Snowflake로 이전하면 비용 효율성, 운영 편의, 성능 확보 및 멀티클라우드 등 다양한 이점을 얻을 수 있음
- 마이그레이션의 7단계 전체 과정 요약
현실적이고 구체적인 고려사항은 다음에 다루도록 한다. 끝!