사례로 알아보는 MariaDB 마이그레이션 현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다. 상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다. MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다. 웨비나 동영상 https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s

1. 사례로 알아보는
오라클 마이그레이션
MariaDB
㈜네오클로바
▶ 2021. 06. 01

2. 네오클로바 - 회사소개
회사명
임직원
대표이사
설립년도
주소
대표전화
홈페이지
주식회사 네오클로바
22명
이 재 중
2011년 11월
서울시 강서구 양천로 583(염창동240-21)
우림 블루나인 B동 1206호
02-539-4880
www.neoclova.co.kr
기업 개요 주요 파트너쉽
주요사업분야 통합유지보수, Red Hat Enterprise Linux, JBoss,
Apache/Tomcat, MySQL/MariaDB/Percona, Accordion
등 솔루션 분야
이메일 info@neoclova.co.kr

3. Next Opensource Cloud Value
DBMS 마이그레이션

4. DBMS 마이그레이션
As-Is 현황 분석 To-Be DBMS 선정 DBMS 마이그레이션 수행
As-Is DBMS 현황을 파악 하고 DBMS 전환 사례
및 기술 트랜드를 조사 하며, 담당자와의 인터뷰
를 통한 현황 파악과 요구사항을 분석 합니다
• 자료 수집
✔업무 중요도 및 업무 요건
✔DB 운영 환경 및 사용 현황
✔서버/스토리지 등 인프라 환경
✔어플리케이션 및 타시스템 연계 현황
• 인터뷰
✔비즈니스 및 IT 전략 등 조사
✔인프라 및 업무별 특성, 제약 사항, 개선
사항, IT 투자 계획
✔수집 자료 내용 보완
• 사례 조사
✔ IT 기술 동향
✔ DBMS 트랜드 및 전환 사례
현황 분석 결과를 기준으로 DBMS를 선정하고
As-Is DBMS 별 To-Be DBMS 를 선정 합니다
To-Be DBMS로의 마이그레이션에 대한 계획을
수립하고 DBMS 전환 수행, 전환 후 최적화 및
안정화를 합니다
• 사전 준비
✔마이그레이션 계획 수립
✔인프라 구성
• 마이그레이션
✔스키마 및 오브젝트 마이그레이션
✔데이터 마이그레이션
✔어플리케이션 수정
✔마이그레이션 단위/통합 테스트
✔운영 전환 및 검증
• 안정화 및 최적화
✔DBMS 안정화 모니터링
✔성능 측정 및 튜닝
✔운영 가이드 및 교육
• DBMS 후보 선정
✔DBMS 트랜드 및 전환사례 분석
✔To-Be DBMS 선정 기준 마련
✔전환 호환성 분석
• To-Be DBMS 선정
✔To-Be DBMS 선정을 위한 기준 정의
✔As-Is DBMS 별 평가 및 To-Be DBMS
선정
• 이행 과제 정의 및 계획 수립
✔To-Be DBMS 전환을 위한 계획 수립
✔이행 과제의 수행 계획 작성
비즈니스 및 IT 전략, 정보기술 시장의 변화 동향, 주요 DBMS vendor사의 정책, DBMS의 기술적 특성을 종합적으로 분석하여 최적의 DBMS를 선정하고
서비스 전환의 위험요소를 최소화해서 마이그레이션을 수행 합니다

5. DBMS 마이그레이션
현행 시스템 분석
마이그레이션 원칙 수립
마이그레이션 과제 정의
마이그레이션 계획 수립
DBMS 표준화 작성
인프라 구성 및 안정화
계획 수립
마이그레이션
단위/통합 테스트
DBMS 전환 전
성능측정
DBMS 모니터링 및
안정화
DBMS 전환 후
성능측정
전환 사후 평가 및
표준화 반영
마이그레이션 계획서
작성
데이터 마이그레이션 및
어플리케이션 수정
DBMS 운영 전환 및
검증
DBMS 최적화
마이그레이션 조직 구성

6. DBMS 마이그레이션

7. Next Opensource Cloud Value
As-Is 현황 분석

8. As-Is 현황 분석
담당파트
DB/서버 스펙 DB 계정 세그먼트 사이즈 테이블 및 LOB 개수
물리DB
서비스명
(SID)
DBMS
Version
(HA 구성)
DB 계정그룹
(업무)
업무대상
(이관유무)
용도 DB 계정수
세그먼트
사이즈 합계
(GB)
테이블 세그먼트
LOB
세그먼트
총 테이블
개수
일반
테이블 개수
파티셔닝 테이블
LOB
개수
파티셔닝
테이블
파티셔닝
세그먼트
공통 NEOCOMM
Oracle 11.2.0.1
(2ea RAC)
SSO X 인프라 모니터링
SSO X DBMS/SYSTEM
공통 O 솔루션 및 기타
공통 O 서비스운영
CSR O 서비스운영
메인 NEOMAIN
Oracle 11.2.0.4
(2ea RAC)
메인 X 인프라 모니터링
메인 X DBMS/SYSTEM
메인 O 솔루션 및 기타
메인 O 서비스운영
네오클로바
NEOCHECKER Oracle 10.2.0.4
DBCHECKER X 인프라 모니터링
DBCHECKER X DBMS/SYSTEM
DBCHECKER O 솔루션 및 기타
DBCHECKER O 서비스운영
NEOMARIA Oracle 11.2.0.3
DBMONSTER X 인프라 모니터링
DBMONSTER X DBMS/SYSTEM
DBMONSTER O 솔루션 및 기타
DBMONSTER O 서비스운영
DBMONSTER O 인프라 운영관리
As-Is 데이터베이스의 테이블 및 오브젝트 현황을 파악

9. As-Is 현황 분석
담당파트
DB/서버 스펙 기타 객체
DB 서비스명
(SID)
DBMS Version
(HA 구성)
Server Version
(Cluster 구성)
CPU
코어수
Memory
사이즈
DB LINK SEQUENCE FUNCTION PROCEDURE VIEW TRIGGER
공통 NEOCOMM
메인 NEOMAIN
네오클로바
NEOCHECKER
NEOMARIA

10. Next Opensource Cloud Value
To-Be DBMS 선정

11. To-Be DBMS 선정
설 명
SQL 수정
• MSSQL의 T-SQL, Oracle의 비표준 SQL 을 표준 Ansi-SQL로 수정 필요 (대소문자 포함)
• 호환 가능한 구문이라도 To-Be DBMS 특성에 맞게 수정해서 사용 해야 할 수 있음
어플리케이션 / 로직 수정
• 어떤 DBMS로 Migration을 하더라도 어플리케이션 소스 수정 및 DB내 업무 로직 (Procedure, Function, Package 등)의 수정 필요
• DB Migration 전에 Pro*C, SSIS등의 업무 로직은 어플리케이션으로 이관하는 것이 유리함

12. To-Be DBMS 선정
설 명
MariaDB
• MySQL 호환으로 사용 가능한 MariaDB, Percona 오픈소스 DBMS
• 많은 사용자를 확보하고 있고 기술 문서 풍부
• Subscription 비용이 적음
• MySQL은 오라클 소유로 오픈소스 정책에 대한 불안감이 있음
• Oracle 호환성과 MSSQL 호환성을 지원하는 MariaDB
• DB Link 대안으로 사용할 수 있는 Connect 스토리지 엔진 기능 지원
• 다양한 HA 지원 (Replication, Galera cluster, MaxScale)

13. MariaDB 전환 검토
구분 항목 요약 상세
핵심 검토
항목
Effort
데이터크기 데이터크기
데이터 사이즈가 클수록 Migration Effort 가 커짐
다운타임 허용시간에 따른 이관방안 고려 필요
Object 개수 Package, SP, Function, Trigger 업무로직이 많을수록 Migration Effort 가 커지며 어플리케이션 변경 필요
DB LINK DB LINK 사용여부 어플리케이션에 구현 하는것이 좋으며 필요한 경우 가능한 아키텍처 검토 필요
추가 검토
항목
가용성/안정성
이중화 구성 RAC, HA, MCCS 등
Replication 방식의 이중화는 가능하지만 Shared DB 구조의 이중화는 불가하므로
OpenSource DBMS의 이중화 방식을 고려한 아키텍처 선정 및 구성 필요
Workload 편차 CPU 최대값/평균값 차이 Scale out 아키텍처로 적절한 분산 아키텍처 검토 필요
업무
업무 중요도 인벤토리상의 업무 중요도 Phase 결정 시 고려사항으로 중요도에 따라서 전환 순서 결정
업무특성 OLTP/OLAP/DM/DW/MIX 업무 특성에 따른 스토리지 엔진 선택 및 Schema 재정의 검토 필요
종속성
Appliance EXADATA, 보안 솔루션 등 Migration 대상에서 제외하거나 대체 방안 검토 필요
패키지 DB SAP, ERP, SAS, 보안제품 등 과 연계 교체 가능 여부 확인 및 호환 가능한 DBMS로 선정
운영
재개발 요건 차세대, 리뉴얼 등 시스템 재개발, 재구축 요건이 있을경우 DB Migration 우선 업무로 고려
기술지원 기술지원의 필요여부
본사 기술지원이 필요한 경우 Enterprise Edition 선택
국내 기술지원만 필요한 경우 Care pack 고려
다운타임 다운타임 허용시간 고려 다운타임 허용 시간에 따른 전환 전략 검토 필요
보안 보안 암호화, 접근제어 등
보안솔루션 호환성 검토 필요
- 예) Oracle TDE vs MariaDB TDE

14. MariaDB 전환 검토
항목 고려사항
DB의 데이터량 DB의 데이터량에 따라 전환 간 발생하는 난이도를 산정. 데이터량이 많을수록 난이도가 높아짐
DB 로직 Procedure, Function, Package 등의 DB 로직이 많이 걸려있는 경우에 전환 난이도가 높아짐
DB Link 데이터베이스 들간의 연결이 많으면 전환 난이도가 높아짐
업무 중요도 업무 중요도가 낮은 DB의 경우 전환 난이도가 낮아짐

15. Next Opensource Cloud Value
MariaDB
마이그레이션 수행

16. 이행 방안 – 추진 절차
• 전체 대상에 대해 계획을 세우고 차수별로 준비, 수행, 안정화 및 최적화를 진행 합니다
• 데이터베이스 전환전에 어플리케이션에서 DB Link 제거, Ansi-SQL 전환을 합니다
• 1차 대상 전환을 수행하면서 습득한 전환 기술과 표준안을 가지고 2차 대상을 진행합니다
• 대상 DBMS 현황 분석
• 전환 원칙 수립
• 전환 과제 정의
• 전환 계획 수립
• 전환 비용 산정
• 오픈소스 DBMS PoC
계획
전환 계획 수립
• 전환 조직 구성
• 오픈소스 DBMS 표준화
작성
• 전환 계획서 작성
• 인프라 구성
• 안정화 계획 수립
• 오픈소스 전환 교육
준비
전환 준비
• 어플리케이션 수정
• DBMS 전환 테스트
• 전환 통합 테스트
• 전환 전 성능 측정
• DBMS 운영 전환
• DBMS 전환 검증
수행
전환 수행
• DBMS 모니터링
• DBMS 안정화
• 전환 후 성능 측정
• DBMS 최적화
• 전환 사후 평가
• 표준화 반영
안정화 / 최적화
시스템 안정화 및
성능 최적화

17. 이행 방안 – PoC
과제 정의
• MariaDB에 대한 기능, 성능, 가용성, 호환성 등의 PoC를 수행
• PoC를 통해 잠재된 문제 및 이슈 사항을 도출
• PoC를 통해 신기술 습득 및 기술 역량 강화
수행 내용
• DBMS별 주요 기능 검증, 어플리케이션 요구 기능 검증
- SQL호환성 (Procedure, Function)
- DB Link 기능 검증
- 온라인 백업 / 복구 및 Export / Import
• TPS 및 QPS 성능 검증
- Oracle Exadata에 대응하는 성능 검증
• 가용성 검증
- Replication을 이용한 아키텍처 구성 검증
- 이중화 또는 Failover에 대한 검증
• PoC 결과 정리
- 기존 운영 환경 대비 변경 해야 하는 어플리케이션 및 DBMS 기술적 요소 파악 및 정리
- DBMS 환경에서 차이가 나는 운영 방법에 대한 요소 파악 및 정리
기대 효과
• 오픈소스 DBMS에 대한 기본 지식 및 구성 경험 확보
• 오픈소스 DBMS와 어플리케이션간의 특성들에 대한 기초적인 경험 확보
• 실제 이행시 최적화 된 구성 및 운영 방안 도출
• 향후 발생 가능한 기술, 기능 및 운영적인 문제점 파악을 통해 사전 해결
방안 마련

18. 데이터 이행 전략
As-Is Database To-Be Database
Oracle Database MariaDB Database
Data Migration
No 전 략 설 명
1 실시간 Data Migration
 Cut Over 시, 이관 대상 서비스의 다운타임 최소화
 기존 서비스에 미치는 영향 최소화
 CDC Tool 인 Attunity CDC 이용
2 As-Is , To-Be Table 1:1 Mapping 원칙
 개발 시간의 단축을 위한 As-Is Layout 그대로를 To-Be 로 이관
 Table 명 Column 명, Type, Precision 등
3 추가되는 Table 의 데이터는 본 이행 이후, 사후 이행
으로 이관
 성능 또는 관리의 효율을 위해 추가되는 테이블 및 데이터는 본 이행
이후, 사후 이행으로 별도 이관 또는 생성
 사후 이행의 대상을 최소화
목 표 : Oracle Database 의 Data 를 MariaDB 로 이관

19. 데이터 이행 전략
No 이 관 대 상 이관 방안
1
 Table 및 Column 의 Comment, Default value
 Sequence
 별도의 Script 를 작성하여 Manually 적용
 Sequence 는 별도 생성
- 중복된 이름은 1개만
- MAX VALUE 는 단위 증가 (예: 999  1000) 하여 생성
2  Package, Stored Procedure , Function  별도로 생성
3  View
 참조하는 Object 사용 가능한 경우에만 CDC Tool 에서 이관 됨. Error 발생시에는 생성되지 않음.
 논리적인 view 로 생성되는 것이 아니라 Table 의 형태로 전환됨
4  암호화 컬럼  Oracle 함수를 이용한 암호화 컬럼 이관 방안
select 'CREATE OR REPLACE SEQUENCE ' || sequence_name ||
' INCREMENT BY ' || increment_by ||
' MAXVALUE ' || max_value ||
' START WITH ' || power ( 10, length(cast(last_number as float) ) ) ||
' CACHE ' || cache_size || ' ' || case cycle_flag when 'Y' then 'CYCLE' else 'NOCYCLE' end || ';'
from dba_sequences
where sequence_owner not in ( 'SYS','SYSTEM','DBSNMP','WMSYS','DMSYS','CTXSYS','XDB','MDSYS','OLAPSYS','EXFSYS','SYSMAN' )
order by sequence_name, sequence_owner, last_number ;
 As-Is Oracle DB 에서 Sequence 를 추출하는 SQL

20. 데이터 이행 대상 목록
1) As-Is Oracle 은 Schema, 즉 User 별로 별도의 Table 을 갖는 구조이나 MariaDB 는 User 가 아닌 Database 별로 Table 생성 하게 됨. 따라서, Table 이름이 중복될 수 있어
이에 대한 처리방안이 필요함
2) Data Cleansing. 불필요한 Data 를 제외하여 이관 시간 단축 및 Disk 공간 확보. 테이블 단위로 Data Migration 여부를 정의하고 이관 대상 Table 이라도 필요한 조건의 Data
만 이관토록 하고자 함
3) Mapping 된 테이블 목록은 CDC Tool 에서 Source DB 와 Destination DB 를 정의하는데 활용된다
4) 테이블 이외의 object( view, function, procedure, package, sequence 등)는 CDC Tool 을 활용할 수 없어 별도로 생성되어야 함
5) 개발환경에서의 Data 이관은 빠른 개발환경 구성을 위하여 하나의 As-Is Oracle Instance 가 그대로 하나의 To-Be MariaDB 로 이관되도록 구성
6) Stage 또는 Production 환경에서의 Data 이관은 As-Is Oracle 테이블 마다 어떤 MariaDB 로 이관 되어야 하는지 정의가 필요함

21. 데이터 이행 - Cleansing
 Data Cleansing 의 구분
- 임시, 불필요한 Table 을 이관 대상에서 제외
- 불필요한 Data 를 이관 대상에서 제외 ( 예, create_date < '20000101' )
- 데이터 정합성을 위한 수정
- 2 차 데이터 이행 시 해당 스크립트 실행
공통
통합
서비스1
서비스2
서비스3
서비스4
공통
메인
서비스1
서비스2
서비스3
서비스4
서비스5
서비스6
서비스7
*) Data 이관 전 As-Is Oracle 에서의
cleansing 이 보다 효과적임
CDC Data Filtering
1) CDC 목록 제외
2) Filtering 조건 지정
3) 2차 이행 스크립트 실행

22. 데이터 이행 - Table
Table Mapping
List 의 작성
SQLines 에서
사용할 List 작성
SQLines 사용
To-Be MariaDB
에 Table 생성
 테이블과 컬럼의 Comment 및 Default Value 들에 대한 확인 필요
 소수점 없는 Number Type 의 Column type 검토 필요
 CLOB 및 XML type 의 변환 검토 필요
 Index 생성 및 row size 등의 Schema 전환 이슈 검토 필요
 MariaDB 테이블 생성 DDL 문은 별도의 Open Source Tool 인 SQLines 를 이용
Column
Default 값 수정
1 2 3 4
1) 이관 대상 Table List 작성하고 각 담당자가 확인
2) 작성된 Table Mapping List 를 기준으로 SQLines 에서 사용할 목록 작성
3) SQLines 툴을 이용하여 To-Be MariaDB 에 테이블 생성 ( 예외 처리 : Max Row Length, Max Index Length )
4) SQLines 툴은 default 값을 이관하지 못하기 때문에 별도의 script 로 각 컬럼의 default 값을 수정
예외 처리

23. 데이터 이행 - Table
 RDBMS 의 차이로 인하여 Table 생성시 발생하는 예외 처리
Limitation Oracle MariaDB
 Max Row Length  4,000 GBytes  65,535 Bytes
 Max Index Length  6,398 Bytes ( 8K Block ) (11g)  3,072 Bytes
1) Max Row Length 예외가 발생하여 MariaDB 에서 테이블이 생성되지 않는 경우, Manual 작업을 통하여 Varchar
컬럼을 longtext 로 변환하고 그래도 테이블 생성이 안되면 다른 Varchar 컬럼을 text data type 으로 변경하여 생성
2) 인덱스 길이에 제한이 있어 문제가 되는 컬럼을 key 에서 제외하고 생성

24. 데이터 이행 - Table
 컬럼의 Default 값에는 Oracle 의 내장 함수 예) SYSDATE , TO_DATE() 등이 포함되어 있는 경우가 있어 tool 을 통한 일괄 변환이 불가하여
Manual 작업을 통하여 설정한다.
1) Oracle 함수를 MariaDB 함수로 수작업 변환 ( 예 , sysdate -> current_datetime )
2) Data 적재 이전에 실행 ( Data 존재시 시간 오래 걸림 )
dba_tab_columns
테이블을
MariaDB로 이관
column default
값 설정 sql 문
작성
오라클 함수를
MariaDB
함수로 전환
1 2 3
alter 문 실행
4

25. 데이터 이행 - Object
 Sequence 는 별도 작업으로 To-Be 에 생성
 각 담당자는 해당 sequence 이관 여부 및 생성 확인
1) Start With 값은 As-Is Oracle current value 보다 1자리수 높은 값으로 일괄 설정 ( 예, 923  1000 )
2) 성능 향상을 위해 cache 값은 조정 가능
3) cycle 또는 nocycle 값 확인
4) 해당 database 에서 show full tables; 명령으로 확인
CREATE OR REPLACE SEQUENCE SQ_NEOCLOVA
INCREMENT BY 1
MAXVALUE 9999999999
START WITH 10000
CACHE 0
NOCYCLE;

26. 데이터 이행 - Object
 View, Function, Procedure 는 별도 생성
 To-Be 개발환경의 View, Function, Procedure 를 DBA 팀에서 export 하여 STAGE 및 PROD DB 에 import
 Definer 및 user grant 권한 확인
To-Be DEVP To-Be STAGE To-Be PROD
* Devp Team Member * DBA
export/import export/import
Creation

27. 데이터 이행 – Data 이행
 CDC 를 통한 이행은 full loading후에 실시간 Transaction Data 적용
 CDC 이행을 위한 Task 생성
*) 2차 데이터 이행은 해당 테이블이 존재하는 DB 서버에서 Shell Script 로 수행
*) DownTime 최소화를 위한 2차 데이터 이행 최적화
SQL Script
CDC Data Sync
1st Data Migration 2nd Data Migration
As-Is Service Down Verification
1차 데이터 이행 2차 데이터 이행
CDC STOP
Full Loading

28. 데이터 이행 – Data 이행
 테이블 별로 full loading 순서 및 동시 실행 최적화
 LOB / snapshot old 등으로 오라클 최적화
 MariaDB InnoDB buffer pool 경합 등에 대한 최적화
 MariaDB Global Variables 최적화
 Table Partition 성능에 따른 최적화
 Data 이행 전 Index 전략 결정 및 최적화
 Batch 등에서 사용하는 임시 테이블들은 Transaction 동기화 제외
 MariaDB 이행 후 Data size 확인 및 적절한 Disk 산정

29. 데이터 이행 – Data 이행
 MariaDB Replication 구성에 따른 Data 동기화 검토
 Replica 서버의 Schema 백업 / 복원
 Full loading을 병렬로 하면서 Replica 서버의 Replication 동기화 지연 발생 확인
 Full 백업 / 복원 방식으로 Replication 구성 검토
 Multi-source Replication 사용 검토 ( GTID, log_slave_updates, expire_logs_days)
 Replication Binary / Relay log 파일 사이즈 확인
 2차 데이터 이행 중 임시로 필요한 테이블은 create temporary table 이용
 Primary Key 없는 테이블 동기화 지연

30. 데이터 이행 – 검증
구분 분류 항목 해결 방안
물리적 요소 검증
단일 항목 검증
코드 불일치
 코드 데이터들의 정확한 적용 여부
 정의된 제약조건들의 적용 여부 검증
룰 적용 불일치 (일자포함)
 주민등록번호, 사업자(법인)등록번호, 전화번호
 정해진 룰을 벗어난 : 일자, 시간 불일치 확인
오류 및 비정형 데이터
 정의된 규칙에 벗어나는 경우 (모든 필드 통일 필요)
 자리 수 초과에 따른 문자 절단 컬럼
테이블 적합성 RI 검증
 Referential Integrity 관계 검증 (테이블 간 정보연계성 누락 방지)
 유일성 제약 조건 확인 및 활성화 (중복 데이터 검증)
논리적 요소 검증
상관 관계 검증 데이터 값
 이관 후 데이터 간의 연관 관계
 이관 규칙 준수 여부
 상태 데이터, 최종일자 데이터 검증
통계적 검증 코드, 건수, 합계
 엔터티 / 코드 별 전체 건수 검증
 특정 항목 건수 검증
APP 검증 업무 프로세싱  서비스 단위 별 항목 조회

31. 데이터 이행 – 검증
 Schema 검증은 Table Name, Column Name, Data Type, Column Length , View , Procedure, Function, Sequence 들에 대한 검증
 As-Is 오라클의 Dictionary 정보인 dba_tab_columns 를 To-Be MariaDB 와 비교
 To-Be 의 information_schema.columns 정보와 비교하여 일치 여부 검증 ( 테이블명, 컬럼명, data type, length )
 View, Procedure, Function 은 각 담당자가 검증
공통
통합
서비스1
서비스2
서비스3
서비스4
공통
메인
서비스1
서비스2
서비스3
서비스4
서비스5
서비스6
서비스7
dba_tab_columns information_schema
.columns
Compare

32. 데이터 이행 – 검증
 Migration 후, As-Is 와 To-Be Data 의 일치 여부를 각각의 Database 에서 Table 단위로 검증
- 각 개발팀에서 별도로 샘플링 하여 진행 방안 검토
 각 Table 별 건수, 각 Column 의 length 합계 후 비교
 As-Is 오라클에서는 Parallel 사용
공통
통합
서비스1
서비스2
서비스3
서비스4
공통
메인
서비스1
서비스2
서비스3
서비스4
서비스5
서비스6
서비스7
건수,
컬럼length 합
건수,
컬럼length 합
Compare

33. 데이터 이행 – 성능 최적화
1
2
3
4
5
6

34. 데이터 이행 – 성능 최적화
 MaxScale : Read/Write split
- 사용자 변수 Master routing (@rownum)
- nvl() 함수 Master routing (MaxScale 버전별 MariaDB 최신 함수 적용 여부)
 Slow Query
- subquery : join 쿼리로 변경
- sysdate() 함수 : now() 사용
- REGEXP 관련 함수 확인
- view를 이용한 join : table join으로 변경
- CTE 쿼리의 DB cache 적용 검토

35. 데이터 이행 – 이슈 대응
구분 예상 이슈 해결 방안
운영 데이터 분리
 테이블 구조 변경으로 인한 데이터 변경 / 생성
 테이블 분리 시 확인 안 되는 테이블
 데이터 표준 체계 준수
 To-Be 모델의 적용 여부 확인
데이터 Cleansing 작업
 중복 데이터의 발견
 데이터 값의 오류 발견
 데이터의 손실
 현업 담당자와 협의 하여 단일화 정리
 현업 담당자와 협의 하여 오류 수정, 삭제
 오류의 원인을 파악하여 프로그램 오류인 경우 담당자에게 통보하여
수정
운영 업무의 변경  업무 변경에 따른 테이블의 구조 변경
 변경 되는 테이블을 형상 관리하고 변경되는 사항을 주기적으로 이행
하여 완료 시 까지 반영
이행 기술의 오류  이행 프로그램에 의한 오류
 이행 프로그램을 충분히 테스트하고 이행 해야 함
 파일럿 시스템을 통해서 이행 기술의 검증 수행
 테스트 이행 과정을 통해서 이행 검증
고려 사항
 일정 내에 데이터의 이행 및 검증까지 원활히 이루어질 수 있도록 이행 환경이 조기에 구축 되어야 함
 원활한 데이터 cleansing 작업을 위해서 현업의 적극적인 협조가 동반 되어야 함
 단기간에 많은 데이터를 동시에 이관 해야 함으로 주요 이행 데이터에 누락 방지를 위해서 철저한 관리 필요
 중복, Non-Mapping 데이터의 발견 시 처리 방안과 명확한 요건 정리가 필요

36. Next Opensource Cloud Value
MariaDB 마이그레이션

37. 오픈소스 MariaDB
MariaDB 는 개방성과 커뮤니티 보존을
위해 개발되었다 . 그 결과 우리는 더욱
빠른 속도로 미래의 애플리케이션을
준비할 수 있게되었다 .
Michael “Monty” Widenius
설립자 & CTO of MariaDB
MySQL 의 창시자
오픈소스의
철학
“
”

38. MariaDB Architecture

39. MariaDB MaxScale
•BSL
•다양한 기능 지원
- Proxy
- Query Routing
- Replication Monitoring
- Database Sharding
- HA
https://mariadb.com/kb/en/maxscale/

40. MariaDB 마이그레이션
 MariaDB Server는 오픈소스 생태계에서 20년 넘게 개발되고 다양한 운영 환경에서 검증을 거쳐왔으며, 대규모 트랜잭션 및 분석 워크로드 모두를 위한 엔터프라이즈
오픈소스 데이터베이스입니다. MariaDB Server는 데이터 저장 및 액세스를 위한 엔터프라이즈급 통합 제품군 인 MariaDB 플랫폼의 기반이 됩니다.
 MariaDB 플랫폼은 Oracle 데이터베이스와의 호환성(예: PL/SQL 호환성), 임시 테이블(Temporal tables), 샤딩, 포인트-인-타임 (point-in-time) 롤백 및 투명한 데이터
암호화를 포함, 상용 데이터베이스에서 볼 수 있는 엔터프라이즈 기능을 동일하게 갖춘 유일한 오픈소스 데이터베이스입니다. 그리고 이 모든 것을 Oracle보다 훨씬
낮은 총소유비용(TCO)으로 누릴 수 있습니다.
 도이치뱅크, 싱가포르개발은행(DBS), 나스닥, 레드햇(Red Hat), 서비스나우(ServiceNow), 버라이즌(Verizon) 및 월그린(Walgreens)과 같은 기업들로부터 신뢰받고 있는
MariaDB 플랫폼은, 훨씬 저렴한 비용으로 상용 데이터베이스에 요구되는 핵심 요구사항들을 충족시킵니다. DBS 은행을 예로 들면, 자사의 핵심 애플리케이션들을
MariaDB 플랫폼으로 이관함으로써 90%에 달하는 데이터베이스 비용을 절감했습니다.

41. MariaDB 마이그레이션
 MariaDB로 수십억 절감하기
아래의 각 데이터베이스별 비용은, 엔터프라이즈 데이터베이스에 요구되는 기본적인 최소한의 구성을 고려하여 기능별로 제시된 정가를 사용하여 계산되었습니다.
 3개의 온프레미스 서버에서 각각 2개의 16코어 프로세서를 사용하여 3년간 운영한 경우:
• Oracle의 경우 MariaDB 플랫폼보다 총비용이 84배 더 높음
• Oracle의 경우 MariaDB 플랫폼보다 연간 소요비용이 33배 높음
• MariaDB 플랫폼을 선택한 기업은 3년간 900만 달러 이상을 절감할 수 있음
• Oracle을 MariaDB로 교체 시 연간 110만 달러를 절약할 수 있습니다
 3개의 클라우드 인스턴스에서 각각 16개의 코어(하이퍼스레딩: 32개)로 3년간 운영한 경우:
• Oracle의 경우 MariaDB 플랫폼보다 총비용이 72~151배 더 높음
• Oracle의 경우 MariaDB 플랫폼보다 연간 소요비용이 60~72배 더 높음
• MariaDB 플랫폼을 선택한 기업은 3년간 760~1,630만 달러를 절약할 수 있음
• Oracle을 MariaDB로 교체 시 연간 210~250만 달러를 절약할 수 있음

42. MariaDB 마이그레이션

43. MariaDB 고객 사례
Primary
Replica
replication
Read/Write Split
auto failover
쇼핑몰 솔루션
Web / WAS
주문 상품
L4 L4

44. MariaDB 고객 사례
replication
Multi-source replication
Read/Write Split
auto failover
웹서비스 : log_slave_updates / semi-sync replication / GTID / read_only / replicate_do_db / binlog_format
Web / WAS
L4 L4
공통 메인서비스

45. MariaDB 고객 사례
replication
Read/Write Split
auto failover
모바일 통신 서비스
Web / WAS
통계
메인 서비스
Galera Cluster
L4 L4

46. MariaDB 고객 사례
Xpand
Read/Write Split
auto failover
분석 아키텍처 (제안)
Web / WAS
OLTP
ColumnStore
OLAP
L4 L4

47. MariaDB - 네오클로바
진단/튜닝
마이그레이션
오픈소스 컨설팅
 오픈소스 기반의 OS, WEB, WAS,
DBMS 환경의 최고의 아키텍처
컨설팅 역량
 MariaDB 설정 / 정기 점검 /
기술지원 및 성능 진단에 따른
튜닝 역량
 Oracle/MSSSQL Server to
MariaDB : 체계적이고 전문적인
오픈소스 마이그레이션 수행
역량

48. 감사합니다