사례로 알아보는 MariaDB 마이그레이션
현대적인 IT 환경과 애플리케이션을 만들기 위해 우리는 오늘도 고민을 거듭합니다. 최근 들어 오픈소스 DB가 많은 업무에 적용되고 검증이 되면서, 점차 무거운 상용 데이터베이스를 가벼운 오픈소스 DB로 전환하는 움직임이 대기업의 미션 크리티컬 업무까지로 확산하고 있습니다. 이는 클라우드 환경 및 마이크로 서비스 개념 확산과도 일치하는 움직임입니다.
상용 DB를 MariaDB로 이관한 사례를 통해 마이그레이션의 과정과 효과를 살펴 볼 수 있습니다.
MariaDB로 이관하는 것은 어렵다는 생각을 막연히 가지고 계셨다면 본 자료를 통해 이기종 데이터베이스를 MariaDB로 마이그레이션 하는 작업이 어렵지 않게 수행될 수 있다는 점을 실제 사례를 통해 확인하시길 바랍니다.
웨비나 동영상
https://www.youtube.com/watch?v=xRsETZ5cKz8&t=52s
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법Ji-Woong Choi
MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
MariaDB 10.5 binary install (바이너리 설치)
- 네오클로바 DB지원사업부
1. About MariaDB
1.1 MariaDB 개요
1.2 MariaDB as a R-DBMS
1.3 Open Source Database System
2. 설치
2.1 설치 기본 정보
2.2 설치 준비
2.3 MariaDB 설치
2.4 MariaDB 시작 / 접속 / 종료
2.5 추가 설정
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
데이터 분석가를 위한 신규 분석 서비스 - 김기영, AWS 분석 솔루션즈 아키텍트 / 변규현, 당근마켓 소프트웨어 엔지니어 :: AWS r...Amazon Web Services Korea
AWS re:Invent에서는 다양한 고객들의 요구에 맞추어 새로운 분석 및 서버리스 서비스가 대거 출시되었습니다. 본 강연에서는 새롭게 출시된 핵심 분석 기능들과 함께, 누구나 손쉽게 사용할 수 있는 AWS의 분석 서버리스와 On-demand 기능들에 대한 심층적인 정보를 확인하실 수 있습니다.
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...Amazon Web Services Korea
SK Telecom의 망관리 프로젝트인 TANGO에서는 오라클을 기반으로 시스템을 구축하여 운영해 왔습니다. 하지만 늘어나는 사용자와 데이터로 인해 유연하고 비용 효율적인 인프라가 필요하게 되었고, 이에 클라우드 도입을 검토 및 실행에 옮기게 되었습니다. TANGO 프로젝트의 클라우드 도입을 위한 검토부터 준비, 실행 및 이를 통해 얻게 된 교훈과 향후 계획에 대해 소개합니다.
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
24시간 365일 서비스를 위한 MySQL DB 이중화.
MySQL 이중화 방안들에 대해 알아보고 운영하면서 겪은 고민들을 이야기해 봅니다.
목차
1. DB 이중화 필요성
2. 이중화 방안
- HW 이중화
- MySQL Replication 이중화
3. 이중화 운영 장애
4. DNS와 VIP
5. MySQL 이중화 솔루션 비교
대상
- MySQL을 서비스하고 있는 인프라 담당자
- MySQL 이중화에 관심 있는 개발자
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법Ji-Woong Choi
MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
MariaDB 10.5 binary install (바이너리 설치)
- 네오클로바 DB지원사업부
1. About MariaDB
1.1 MariaDB 개요
1.2 MariaDB as a R-DBMS
1.3 Open Source Database System
2. 설치
2.1 설치 기본 정보
2.2 설치 준비
2.3 MariaDB 설치
2.4 MariaDB 시작 / 접속 / 종료
2.5 추가 설정
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안SANG WON PARK
Apache Kafak의 빅데이터 아키텍처에서 역할이 점차 커지고, 중요한 비중을 차지하게 되면서, 성능에 대한 고민도 늘어나고 있다.
다양한 프로젝트를 진행하면서 Apache Kafka를 모니터링 하기 위해 필요한 Metrics들을 이해하고, 이를 최적화 하기 위한 Configruation 설정을 정리해 보았다.
[Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안]
Apache Kafka 성능 모니터링에 필요한 metrics에 대해 이해하고, 4가지 관점(처리량, 지연, Durability, 가용성)에서 성능을 최적화 하는 방안을 정리함. Kafka를 구성하는 3개 모듈(Producer, Broker, Consumer)별로 성능 최적화를 위한 …
[Apache Kafka 모니터링을 위한 Metrics 이해]
Apache Kafka의 상태를 모니터링 하기 위해서는 4개(System(OS), Producer, Broker, Consumer)에서 발생하는 metrics들을 살펴봐야 한다.
이번 글에서는 JVM에서 제공하는 JMX metrics를 중심으로 producer/broker/consumer의 지표를 정리하였다.
모든 지표를 정리하진 않았고, 내 관점에서 유의미한 지표들을 중심으로 이해한 내용임
[Apache Kafka 성능 Configuration 최적화]
성능목표를 4개로 구분(Throughtput, Latency, Durability, Avalibility)하고, 각 목표에 따라 어떤 Kafka configuration의 조정을 어떻게 해야하는지 정리하였다.
튜닝한 파라미터를 적용한 후, 성능테스트를 수행하면서 추출된 Metrics를 모니터링하여 현재 업무에 최적화 되도록 최적화를 수행하는 것이 필요하다.
데이터 분석가를 위한 신규 분석 서비스 - 김기영, AWS 분석 솔루션즈 아키텍트 / 변규현, 당근마켓 소프트웨어 엔지니어 :: AWS r...Amazon Web Services Korea
AWS re:Invent에서는 다양한 고객들의 요구에 맞추어 새로운 분석 및 서버리스 서비스가 대거 출시되었습니다. 본 강연에서는 새롭게 출시된 핵심 분석 기능들과 함께, 누구나 손쉽게 사용할 수 있는 AWS의 분석 서버리스와 On-demand 기능들에 대한 심층적인 정보를 확인하실 수 있습니다.
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...Amazon Web Services Korea
SK Telecom의 망관리 프로젝트인 TANGO에서는 오라클을 기반으로 시스템을 구축하여 운영해 왔습니다. 하지만 늘어나는 사용자와 데이터로 인해 유연하고 비용 효율적인 인프라가 필요하게 되었고, 이에 클라우드 도입을 검토 및 실행에 옮기게 되었습니다. TANGO 프로젝트의 클라우드 도입을 위한 검토부터 준비, 실행 및 이를 통해 얻게 된 교훈과 향후 계획에 대해 소개합니다.
엔터프라이즈 클라우드 마이그레이션 준비와 실행. 그리고, 클라우드 운영 모범 사례 공유-최지웅, 오픈소스컨설팅 CTO / 장진환, 스마일샤...Amazon Web Services Korea
클라우드 마이레이션은 단순한 업무의 환경 이전 차원을 넘어 미래를 준비하는 긴 여정의 출발점이기도 합니다. 또한, 클라우드 마이그레이션의 전략,기술 준비사항은 기존의 IT 운영 환경에 비례하여 매우 다양하며 복잡 합니다. 이번 세션에서는 AWS MSP 파트너사인 오픈소스 컨설팅, 스마일 샤크의 다양한 클라우드 마이그레이션 사례 및 운영 환경 최적화 사례를 기반으로 여러분들의 클라우드 여정에 도움을 드리고자 합니다.
대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...Amazon Web Services Korea
고객사 A는 하루 30억 트랜잭션과 연 750TB의 데이터베이스를 온프레미스 환경에서 상용 데이터베이스를 이용하여 운영 중입니다. 또한 매일 대용량의 배치가 발생하고 실시간으로 대량의 조회가 발생하는 미션 크리티컬 시스템입니다. 고객사 A와 함께 클라우드 환경에서 동일한 워크로드의 수행이 가능한지 여부를 검증하는 Feasiblity Pilot 프로젝트를 진행하였고 여기서의 레슨런을 공유합니다. 마이그레이션 도중 고객 IT팀은 On-premise 운영 모델에서 클라우드 운영 모델로 전환되어야 합니다. 전환 도중에 ITIL을 클라우드, 애자일, DevOps 기반 역량과 프로세스에 매핑해야 합니다. 해당 세션에서는 클라우드 운영 모델로 원활한 전환을 도와주는 CEE (Cloud Enablement Engine)의 작동 원리 및 적용 방식을 살펴보고자 합니다.
성공적인 디지털 트랜스포메이션을 위해서는 클라우드 전환이 필수적인데요, 많은 기업에서 막상 클라우드를 도입할 때 여러가지 장벽에 맞닥뜨리게 됩니다.
클라우드 마이그레이션에 관한 여러분의 고민을 시원하게 해결해주기 위해 Global Public Cloud의 독보적인 선두 AWS(Amazone Web Services)와 클라우드 마이그레이션 전문기업 오픈소스컨설팅이 만났습니다!
많은 기업들이 마이그레이션 수행할 때 가장 많이 하는 질문 Top 10에 대한 기술 전문가의 노하우가 담긴 답변을 공유합니다.
네이버클라우드플랫폼에서 제공하는 클라우드 데이터베이스 서비스를 소개하고, 네이버클라우드 플랫폼의 클라우드 데이터베이스 관리 노하우에 대해 소개합니다 | Introduce cloud database services provided by Naver Cloud Platform and know-how of managing cloud databases on Naver Cloud Platform
[AWS Summit Seoul 2017] 현재 많은 기업들이 기업 내에서 보유한 많은 인프라를 아마존 기반의 클라우드 환경으로 이관하고, 데이터센터와 클라우드를 연결한 후 시스템을 이관하는 것으로 요구하고 있습니다. 이 때 기존 시스템을 분석, 데이터 이관, 애플리케이션 이관 등의 복잡한 절차를 통해 시스템을 전환하게 됩니다.
본 발표에서는 그러한 복잡한 형태의 클라우드 이관 시 이를 분석, 전환할 수 있는 방법과 그에 대한 도구(AWS ISV 파트너 도구 및 신규 U2C 솔루션)를 소개하고 최적의 전환 방법을 설명합니다. 또한 르노삼성자동차 등의 실제 전환 고객 사례를 통해 DB 마이그레이션, 서버 마이그레이션에 대한 노하우를 들으실 수 있습니다.
AWS에서는 애플리케이션의 목적과 특징에 맞는 다양한 클라우드 기반 데이터베이스 선택 옵션을 제공합니다. 본 세션에서는 클라우드 DB 서비스를 간단히 알아보고, 그 중에서도 DB 서버 및 클러스터 관리 및 운영에 대한 걱정이 전혀 없는 서버리스(Serverless) DB 서비스인 Amazon Aurora Serverless와 DynamoDB에 대해 자세히 알아봅니다. DB 관리 및 운영 등의 번거러운 작업은 AWS에 맡기고, 비지니스 로직에 필요한 데이터 모델 구성 및 쿼리 최적화 등에 집중하여 시장에 요구에 따른 비지니스에 민첩한 서비스를 만드는 방법을 알아 봅니다.
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...Amazon Web Services Korea
Database Migration Service(DMS)는 RDBMS 이외에도 다양한 데이터베이스 이관을 지원합니다. 실제 고객사 사례를 통해 DMS가 데이터베이스 이관, 통합, 분리를 수행하는 데 어떻게 활용되는지 알아보고, 동시에 데이터 분석을 위한 데이터 수집(Data Ingest)에도 어떤 역할을 하는지 살펴보겠습니다.
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
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 최적화
마이그레이션 조직 구성
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
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의 경우 전환 난이도가 낮아짐
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
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 데이터의 발견 시 처리 방안과 명확한 요건 정리가 필요
37. 오픈소스 MariaDB
MariaDB 는 개방성과 커뮤니티 보존을
위해 개발되었다 . 그 결과 우리는 더욱
빠른 속도로 미래의 애플리케이션을
준비할 수 있게되었다 .
Michael “Monty” Widenius
설립자 & CTO of MariaDB
MySQL 의 창시자
오픈소스의
철학
“
”
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만 달러를 절약할 수 있음
47. MariaDB - 네오클로바
진단/튜닝
마이그레이션
오픈소스 컨설팅
오픈소스 기반의 OS, WEB, WAS,
DBMS 환경의 최고의 아키텍처
컨설팅 역량
MariaDB 설정 / 정기 점검 /
기술지원 및 성능 진단에 따른
튜닝 역량
Oracle/MSSSQL Server to
MariaDB : 체계적이고 전문적인
오픈소스 마이그레이션 수행
역량