Oracle to AWS Aurora PG 2탄 !! (DB 이사가요~)

Cloud&Security

Oracle to AWS Aurora PG 2탄 !! (DB 이사가요~)

이미등록됨 2024. 3. 9. 00:21

안녕하세요. 클라우드2팀 이준성입니다.

지난 글에 ( Oracle to AWS Aurora PG 1탄 (Shareplex AWS 전환 여정)) 이어

이번에는 IDC 에서 운영 중인 Oracle DBMS를 클라우드 (이하 AWS)로 이사 간 것에 대해 이야기하겠습니다.

지금부터 1년 전...

당사에서 이용 중인 데이터센터 서비스 종료로 방을 빼줘야 하는 상황이라

조금씩 준비를 하고 있었습니다.

그 중 Oracle DBMS로 운영 중인 WEBDB (지난 글에 설명)도 대상이며 이 시스템을 동일하게 갈지

오픈소스로 전환할지 고민도 하게 되었고 간단한 성능 테스트 Tool인 HammerDB (HammerDB)로

MySQL, PostgreSQL 에 대해 벤치마킹을 진행했습니다.

대략 아래와 같은 성능 비교 결과를 확인 했습니다.

(Oracle이 괜히 비싸고 좋은게 아니...)

※ NOPM : New Order per Minute , TPM : Transaction per Minute

다년간 잘 사용해 왔고 성능이 검증된 시스템에 대해 쉽게 결정을 하지는 못하겠지만

생각 외로 빠르게 결정이 되었고

진행하게 되었습니다.

........

제가요??

IDC 서비스 종료까지는 시간이 많이 남았으나 기존에 사용한 경험이 없는 DBMS이다 보니

충분한 테스트와 검증을 위해 빠르게 환경 구성이 필요 했습니다.

AWS는 이미 아시다시피 쉽고 간편하게 구성이 가능했으나 문제는 데이터!!

수 TB 에 달하는 데이터 이관을 다운타임을 최소화하면서 이관을 해야 하는 것이었습니다.

(이것도 제가요..???)

"GS Way 03. 최고지향 목표 설정" 마음 가짐으로

다양한 Tool 들을 사용 및 경험해보면 최종적으로 AWS SCT 및 AWS DMS로

개발/운영 데이터를 이관하였습니다.

※ 간단 소개 , GS Way ?? ※

GS Way 는 GS리테일의 비전 달성을 위한 우리의 일하는 방식 입니다~

대략적인 순서는

1. AWS SCT로 테이블 및 인덱스 등 오브젝트 변환 및 타겟 데이터베이스에 적용

2. AWS DMS로 데이터 이관

어때요? 참 쉽죠?

AWS Schema Conversion Tool

(AWS Schema Conversion Tool이란 무엇인가요? - AWS Schema Conversion Tool (amazon.com))

" AWS Schema Conversion Tool (AWS SCT)를 사용하여 기존 데이터베이스 스키마를 한 데이터베이스 엔진에서 다른 데이터베이스 엔진으로 변환할 수 있습니다."

제품 설명에 나와 있듯이 기존 데이터베이스(Oracle)의 오브젝트를

이관 대상 데이터베이스 (Aurora PG)로 자동 변환 및 생성해 주는 아주 좋은 Tool입니다.

게다가 전환 시 DBMS 별로 어떤 어려움이 있을지 검사 및 사용자 후속 액션이 어떤 것들이 예상되는지 알 수 있습니다.

물론 모든 Tool 이 완벽하지 않으니 전 오브젝트 DDL 구문을 추출하여 확인하는 과정을 거쳐

Aurora PG에 반영하였고 최종 이관 완료 전까지 테이블 변경 사항을 병렬로 같이 반영했습니다.

AWS Database Migration Service

(AWS Database Migration Service란 무엇인가요? - AWS Database Migration Service (amazon.com))

" AWS Database Migration Service (AWS DMS)는 관계형 데이터베이스, 데이터 웨어하우스, NoSQL 데이터베이스 및 기타 유형의 데이터스토어를 마이그레이션 할 수 있는 클라우드 서비스입니다.

AWS DMS를 사용하여 데이터를 AWS 클라우드로 마이그레이션 하거나, 클라우드와 온프레미스 설정 조합 간에 마이그레이션 할 수 있습니다."

AWS SCT로 데이터를 저장할 테이블을 만들었다면 이제 진짜 데이터를 넘겨줄 서비스는 AWS DMS로 진행이 됩니다.

내부적으로는 복잡하고 다양한 설정이 있으나 간단하게 소스 데이터베이스에서 데이터를 읽어서 타겟 데이터베이스에 넣어주는 간단하면서도 복잡한(?) 기능을 구현하는 서비스입니다.

(이 외 스키마 컨버전 등 다른 기능도 있으나 데이터 마이그레이션용으로만 사용했습니다.)

AWS DMS를 제대로 사용하기 전에는 DBeaver Tool로 Oracle에서 데이터 추출, PG로 데이터 COPY 하는 방법으로 상당히 오랜 시간 동안 작업을 하곤 했습니다.

(창립 기념일에도 회사 출근해서 한건 안 비밀..)

위 구조에서도 알 수 있듯이 인프라 측면의 데이터 마이그레이션 성능은 크게

소스 데이터베이스 , 네트워크 , 복제 인스턴스, 타겟 데이터베이스 이 4가지가 있습니다.

복제 인스턴스, 타겟 데이터베이스는 AWS 리소스라 언제든 탄력적으로 조정이 가능하였으나

IDC 리소스를 사용하는 소스 데이터베이스와 서버의 네트워크는 쉽게 변경할 수 없는 상황이었습니다.

다행히 팀 내 "GS Way 6. 적극적인 소통과 협업"으로 문제의 해결방안을 찾았고

또 다행히 최종 이관 전 PM 작업이라는 작업 시간이 있어 해당 부분에 대해서도 개선이 진행되었습니다.

데이터 이관 전용으로 10Gbps 추가 및 Direct Connect 설정하여 데이터 이관 중 인프라 리소스 문제가

발생하지 않게 구성 완료 하게 되었습니다.

본격적으로 데이터 이관 진행을 위해 복제 인스턴스를 생성합니다.

이 복제 인스턴스가 소스 데이터베이스에 연결해서 데이터 읽고,

복제 인스턴스 내부에서 타겟 데이터베이스에 로드할 수 있게 작업을 거친 다음

타겟 데이터베이스에 로드 하게 됩니다.

AWS DMS 서비스 자체는 무료이지만 구조 자체가 위와 같이 이루어져

효과적인 마이그레이션 성능을 위해서는 적절한 인스턴스 타입 선정도 중요 합니다.

다음으로 소스 데이터베이스와 타겟 데이터베이스에 대한 엔드포인트 설정을 진행합니다.

소스/타겟 데이터베이스 IP, Port, ID, PW 기본 접속 정보 뿐만 아니라 연결 시 사용할 각종 옵션 설정

특히 소스 데이터베이스 변경 발생 시 타겟 데이터베이스에 자동으로 반영되는 CDC 설정도 엔드포인트 옵션 설정에서 해야 합니다.

마지막으로 작업 설정입니다.

위에서 설정한 내용을 바탕으로 소스 데이터베이스에서 타겟 데이터베이스로

어떻게 마이그레이션을 할 것인지 작업을 생성 후 해당 작업을 실행하면

실제 데이터 마이그레이션이 진행됩니다.

작업 설정 부분에서 어떤 테이블을 이관할지 LOB 데이터는 어떻게 처리할 것인지 등

모든 결정이 이 작업 설정에서 이루어집니다.

하나의 작업에서 선택할 수 있는 작업 유형은 아래 3가지가 있으며

데이터 사이즈, 타입 등에 따라 선택하여 사용하였습니다.

1. 기존 데이터 마이그레이션 : 전체 데이터 마이그레이션 후 작업 종료

2. 기존 데이터 마이그레이션 및 변경 사항 복제 : 전체 데이터 마이그레이션 후 변경 사항 복제

3. 데이터 변경 사항만 복제

대부분의 테이블들은 아주 잘 넘어가네요

LOB 데이터 형식과 수억 건이 넘는 테이블을 만나기 전까지는요....

데이터 이관에 어려운 데이터 형식과 대용량 테이블의 경우 다양한 오류를 발생시키면서

데이터 이관의 발목을 잡았습니다.

보통 이런 유형의 테이블들이 이관 시간도 오래 걸려 바로 문제를 알 수 없고

보통 작업 실행 다음 날 (또는 새벽 시간)에 "ORA-01555 snapshop to old" 오류를 발생시키며

작업이 중단되고 처음부터 다시 이관을 해야 하는 어려움이 있었습니다.

문제가 쉽게 풀릴 거 같지 않은 상황이었으며 많은 고민을 했습니다.

하지만, "GS Way 3. 최고 지향 목표 설정" 마음으로 다시 생각하면서 문제를 풀어 나갔습니다.

작업이 장시간 실행되며 오류가 발생하니 단시간에 완료될 수 있는 방법을 고민하여 찾았고

대용량 테이블은 여러 개의 작업으로 나누어 이관하는 방법을 찾았습니다.

(해당 방법은 AWS 자격시험에도 나오는 Best Prectice 케이스였습니다.)

찾은 방법으로 대용량 테이블을 이관해보니 목표 시간 안에 들어왔으며

반복 검증으로 소요시간 예측 및 하나의 태스크에 설정할 데이터 건수도 확인할 수 있었습니다.

(참고로 약 2천만 건 / 1시간 정도)

다만 해당 방법은 하나의 테이블을 여러 이관 작업으로 나누어야 했으며 기준이 되는 컬럼과 데이터 건수를 확인해야 하는 (많은) 확인 과정이 필요했습니다.

PK 컬럼의 데이터를 기준으로 약 2천만 건씩 작업을 생성했습니다.

대용량 테이블 하나당 작업은.... 10개면 되겠지?.... 20개.....????? ..30개? .... 40개?????...

50...ㄱ..ㅐ.!!?????

이렇게 이관 작업을 나누고 나누고 쪼개어 작업을 병렬로 동시 실행하면서 짧은(?) 시간에 데이터 이관을 완료할 수 있었고 수많은 작업을 생성하면서 하나의 복제 인스턴스에서 생성할 수 있는 작업 개수가 200개까지 인 것도 알게 되었습니다. (200개 제한으로 복제 인스턴스를 4개 만들어서 운영은 안정적(?)으로 잘 이관 마무리 하였습니다.)

이렇게 전체 데이터 마이그레이션은 진행은 되었고 다음이 서비스 다운타임 최소화를 위해 데이터 변경 사항에 대한 복제 (CDC)도 대용량 테이블 개별 작업으로 생성하여 진행을 하였습니다.

CDC 진행을 위해서는 어떤 방식으로 CDC를 진행할 것인지 방식 선정부터 필요합니다.

소스 데이터베이스 엔드포인트에 추가 설정을 해야 하는 부분이라

초반에 사전 환경을 고려하여 테스트 진행을 하였습니다.

두 방식에 대한 테스트 후 Binary Reader 방식이 LogMiner 대비 CPU 사용률 낮았고 동기화 시간도 짧았습니다.

다만, 리두 및 트랜잭션 로그를 CDC 작업 개수만큼 네트워크를 통해 전송하는 단점이 있었으나 이 부분은 다행히 위에 언급한 네트워크 카드 추가 및 Direct Connect 설정으로 해소된 상황이라 WEBDB 마이그레이션에는 Binary Reader 방식을 선택하였습니다.