온프레미스 Oracle 데이터베이스를 AWS와 동기화하는 방법

게시 됨: 2023-01-11

20년 동안 첫 번째 줄에서 기업 소프트웨어 개발을 지켜보면 지난 몇 년간 부정할 수 없는 추세는 데이터베이스를 클라우드로 이동하는 것이 분명합니다.

저는 이미 기존 온프레미스 데이터베이스를 Amazon Web Services(AWS) 클라우드 데이터베이스로 가져오는 것이 목표인 몇 가지 마이그레이션 프로젝트에 참여했습니다. AWS 설명서 자료에서 이 작업이 얼마나 쉬운지 배우게 되지만 이러한 계획을 실행하는 것이 항상 쉬운 것은 아니며 실패할 수 있는 경우가 있음을 알려드립니다.

이 게시물에서는 다음과 같은 경우에 대한 실제 경험을 다룰 것입니다.

소스 : 이론적으로 소스가 무엇인지는 중요하지 않지만(대부분의 가장 인기 있는 DB에 대해 매우 유사한 접근 방식을 사용할 수 있음) Oracle은 수년 동안 대기업에서 선택한 데이터베이스 시스템이었습니다. 그것이 내 초점이 될 곳입니다.
The Target : 이 쪽을 구체적으로 말할 이유가 없습니다. AWS에서 대상 데이터베이스를 선택할 수 있으며 접근 방식은 여전히 적합합니다.
모드 : 전체 새로 고침 또는 증분 새로 고침을 사용할 수 있습니다. 배치 데이터 로드(소스 및 대상 상태가 지연됨) 또는 (거의) 실시간 데이터 로드. 둘 다 여기서 만질 것입니다.
빈도 : 일회성 마이그레이션 후 클라우드로 완전히 전환하거나 약간의 전환 기간이 필요하고 양쪽에서 동시에 데이터를 최신 상태로 유지해야 할 수 있습니다. 이는 온프레미스와 AWS 간의 매일 동기화를 개발하는 것을 의미합니다. 전자는 더 간단하고 훨씬 더 의미가 있지만 후자는 더 자주 요청되고 중단점이 훨씬 더 많습니다. 여기서 둘 다 다룰 것입니다.

문제 설명

요구 사항은 종종 간단합니다.

AWS 내에서 서비스 개발을 시작하고 싶으므로 모든 데이터를 "ABC" 데이터베이스에 복사하십시오. 빠르고 간단하게. 이제 AWS 내부의 데이터를 사용해야 합니다. 나중에 우리의 활동과 일치시키기 위해 DB 디자인의 어떤 부분을 변경해야 하는지 알아낼 것입니다.

더 진행하기 전에 고려해야 할 사항이 있습니다.

"우리가 가진 것을 복사하고 나중에 처리한다"는 생각에 너무 빨리 뛰어들지 마십시오. 제 말은, 예, 이것이 여러분이 할 수 있는 가장 쉬운 방법이고 신속하게 완료될 것이지만 이것은 대부분의 새로운 클라우드 플랫폼의 심각한 리팩토링 없이는 나중에 수정할 수 없는 근본적인 아키텍처 문제를 일으킬 가능성이 있습니다. . 클라우드 생태계가 온프레미스 생태계와 완전히 다르다고 상상해보세요. 시간이 지남에 따라 몇 가지 새로운 서비스가 도입될 예정입니다. 당연히 사람들은 동일한 것을 매우 다르게 사용하기 시작할 것입니다. 1:1 방식으로 클라우드에서 온프레미스 상태를 복제하는 것은 거의 좋은 생각이 아닙니다. 귀하의 특별한 경우일 수 있지만 이를 다시 확인하십시오.
다음과 같은 몇 가지 의미 있는 의심으로 요구 사항에 의문을 제기하십시오.
- 새로운 플랫폼을 사용하는 일반적인 사용자는 누구입니까? 온프레미스에서는 트랜잭션 비즈니스 사용자일 수 있습니다. 클라우드에서는 데이터 과학자나 데이터 웨어하우스 분석가가 될 수도 있고 데이터의 주요 사용자가 서비스(예: Databricks, Glue, 기계 학습 모델 등)일 수도 있습니다.
- 클라우드로 전환한 후에도 정규적인 일상 업무가 유지될 것으로 예상됩니까? 그렇지 않다면 어떻게 변할 것으로 예상됩니까?
- 시간 경과에 따라 데이터가 크게 증가할 계획입니까? 클라우드로 마이그레이션하는 가장 중요한 단일 이유인 경우가 많기 때문에 대답은 '예'일 가능성이 높습니다. 새로운 데이터 모델이 준비되어야 합니다.
최종 사용자는 새 데이터베이스가 사용자로부터 받게 될 몇 가지 일반적이고 예상되는 쿼리에 대해 생각할 것으로 예상합니다. 이것은 성능 관련성을 유지하기 위해 기존 데이터 모델이 얼마나 변경되어야 하는지를 정의합니다.

마이그레이션 설정

대상 데이터베이스가 선택되고 데이터 모델이 만족스럽게 논의되면 다음 단계는 AWS Schema Conversion Tool에 익숙해지는 것입니다. 이 도구가 제공할 수 있는 여러 영역이 있습니다.

소스 데이터 모델을 분석하고 추출합니다. SCT는 현재 온프레미스 데이터베이스에 있는 내용을 읽고 시작할 원본 데이터 모델을 생성합니다.
대상 데이터베이스를 기반으로 대상 데이터 모델 구조를 제안합니다.
대상 데이터 모델을 설치하기 위한 대상 데이터베이스 배포 스크립트를 생성합니다(도구가 원본 데이터베이스에서 발견한 내용을 기반으로 함). 이렇게 하면 배포 스크립트가 생성되고 실행 후 클라우드의 데이터베이스는 온프레미스 데이터베이스에서 데이터를 로드할 준비가 됩니다.

이제 Schema Conversion Tool을 사용하기 위한 몇 가지 팁이 있습니다.

첫째, 출력을 직접 사용하는 경우는 거의 없어야 합니다. 데이터의 이해와 목적, 클라우드에서 데이터가 사용되는 방식에 따라 조정을 수행해야 하는 참조 결과와 비슷하다고 생각합니다.

둘째, 이전에는 일부 구체적인 데이터 도메인 엔터티에 대한 빠른 짧은 결과를 기대하는 사용자가 테이블을 선택했을 것입니다. 그러나 이제 분석 목적으로 데이터를 선택할 수 있습니다. 예를 들어, 이전에 온프레미스 데이터베이스에서 작동했던 데이터베이스 인덱스는 이제 쓸모가 없으며 이 새로운 사용과 관련된 DB 시스템의 성능을 확실히 향상시키지 않습니다. 마찬가지로 소스 시스템에서와 마찬가지로 타겟 시스템에서 데이터를 다르게 분할하고자 할 수 있습니다.

또한 마이그레이션 프로세스 중에 일부 데이터 변환을 수행하는 것을 고려하는 것이 좋을 수 있습니다. 이는 기본적으로 일부 테이블의 대상 데이터 모델을 변경하는 것을 의미합니다(더 이상 1:1 복사본이 아님). 나중에 변환 규칙을 마이그레이션 도구에 구현해야 합니다.

마이그레이션 도구 구성

원본 및 대상 데이터베이스가 동일한 유형인 경우(예: Oracle 온프레미스 대 AWS의 Oracle, PostgreSQL 대 Aurora Postgresql 등) 구체적인 데이터베이스가 기본적으로 지원하는 전용 마이그레이션 도구를 사용하는 것이 가장 좋습니다( 예: 데이터 펌프 내보내기 및 가져오기, Oracle Goldengate 등).

그러나 대부분의 경우 원본 데이터베이스와 대상 데이터베이스가 호환되지 않으므로 확실한 도구는 AWS Database Migration Service입니다.

AWS DMS는 기본적으로 다음을 정의하는 테이블 수준에서 작업 목록 구성을 허용합니다.

연결할 정확한 소스 DB와 테이블은 무엇입니까?
대상 테이블의 데이터를 가져오는 데 사용할 명령문 사양입니다.
소스 데이터가 대상 테이블 데이터에 매핑되는 방법을 정의하는 변환 도구(있는 경우)(1:1이 아닌 경우).
데이터를 로드할 정확한 대상 데이터베이스 및 테이블은 무엇입니까?

DMS 작업 구성은 JSON과 같은 사용자에게 친숙한 형식으로 수행됩니다.

이제 가장 간단한 시나리오에서는 대상 데이터베이스에서 배포 스크립트를 실행하고 DMS 작업을 시작하기만 하면 됩니다. 그러나 그것에 훨씬 더 많은 것이 있습니다.

일회성 전체 데이터 마이그레이션

실행하기 가장 쉬운 경우는 요청이 전체 데이터베이스를 대상 클라우드 데이터베이스로 한 번 이동하는 것일 때입니다. 그런 다음 기본적으로 필요한 모든 작업은 다음과 같습니다.

각 원본 테이블에 대한 DMS 작업을 정의합니다.
DMS 작업의 구성을 올바르게 지정해야 합니다. 이는 합리적인 병렬 처리, 캐싱 변수, DMS 서버 구성, DMS 클러스터 크기 조정 등을 설정하는 것을 의미합니다. 이것은 최적의 구성 상태에 대한 광범위한 테스트와 미세 조정이 필요하기 때문에 일반적으로 가장 시간이 많이 걸리는 단계입니다.
각 대상 테이블이 예상 테이블 구조의 대상 데이터베이스에 생성(비어 있음)되었는지 확인하십시오.
데이터 마이그레이션을 수행할 기간을 예약합니다. 그 전에 성능 테스트를 수행하여 마이그레이션을 완료하는 데 시간이 충분한지 확인하십시오. 마이그레이션 자체 동안 소스 데이터베이스는 성능 관점에서 제한될 수 있습니다. 또한 마이그레이션이 실행되는 동안 원본 데이터베이스가 변경되지 않을 것으로 예상됩니다. 그렇지 않으면 마이그레이션이 완료된 후 마이그레이션된 데이터가 원본 데이터베이스에 저장된 데이터와 다를 수 있습니다.

DMS 구성이 제대로 완료되면 이 시나리오에서 나쁜 일이 발생하지 않습니다. 모든 단일 소스 테이블이 선택되어 AWS 대상 데이터베이스로 복사됩니다. 유일한 관심사는 활동의 성능과 저장 공간 부족으로 인해 실패하지 않도록 모든 단계에서 크기 조정이 올바른지 확인하는 것입니다.

증분 일일 동기화

이것은 일이 복잡해지기 시작하는 곳입니다. 내 말은, 세상이 이상적이라면 아마도 항상 잘 작동할 것입니다. 그러나 세상은 결코 이상적이지 않습니다.

DMS는 두 가지 모드로 작동하도록 구성할 수 있습니다.

전체 로드 – 위에서 설명하고 사용한 기본 모드입니다. DMS 작업은 사용자가 시작할 때 또는 시작하도록 예약될 때 시작됩니다. 완료되면 DMS 작업이 완료됩니다.
CDC(변경 데이터 캡처) – 이 모드에서는 DMS 작업이 계속 실행됩니다. DMS는 소스 데이터베이스에서 테이블 수준의 변경 사항을 검색합니다. 변경이 발생하면 변경된 테이블과 관련된 DMS 작업 내부의 구성을 기반으로 대상 데이터베이스의 변경 사항을 즉시 복제하려고 시도합니다.

CDC를 사용할 때는 또 다른 선택, 즉 CDC가 원본 DB에서 델타 변경 사항을 추출하는 방법을 선택해야 합니다.

#1. Oracle Redo 로그 판독기

한 가지 옵션은 CDC가 변경된 데이터를 가져오고 최신 변경 사항을 기반으로 동일한 변경 사항을 대상 데이터베이스에 복제하는 데 활용할 수 있는 Oracle의 기본 데이터베이스 다시 실행 로그 판독기를 선택하는 것입니다.

Oracle을 소스로 사용하는 경우 이것이 확실한 선택처럼 보일 수 있지만 문제가 있습니다. Oracle redo 로그 리더는 소스 Oracle 클러스터를 활용하므로 데이터베이스에서 실행 중인 다른 모든 작업에 직접 영향을 미칩니다(실제로 활성 세션을 직접 생성합니다. 데이터베이스).

구성한 DMS 작업이 많을수록(또는 병렬로 연결된 DMS 클러스터가 많을수록) Oracle 클러스터를 더 많이 업사이징해야 합니다. 기본적으로 기본 Oracle 데이터베이스 클러스터의 수직 확장을 조정해야 합니다. 이것은 확실히 솔루션의 총 비용에 영향을 미치며 일일 동기화가 장기간 프로젝트와 함께 유지되는 경우 더욱 그렇습니다.

#2. AWS DMS 로그 마이너

위의 옵션과 달리 이것은 동일한 문제에 대한 기본 AWS 솔루션입니다. 이 경우 DMS는 원본 Oracle DB에 영향을 주지 않습니다. 대신 Oracle redo 로그를 DMS 클러스터에 복사하고 그곳에서 모든 처리를 수행합니다. Oracle 리소스를 절약하지만 더 많은 작업이 관련되므로 더 느린 솔루션입니다. 또한 쉽게 추측할 수 있듯이 Oracle redo 로그에 대한 사용자 지정 판독기는 Oracle의 기본 판독기 작업에서 속도가 느릴 수 있습니다.

원본 데이터베이스의 크기와 일일 변경 횟수에 따라 최상의 시나리오에서는 온프레미스 Oracle 데이터베이스에서 AWS 클라우드 데이터베이스로 데이터를 거의 실시간으로 증분 동기화할 수 있습니다.

다른 시나리오에서는 여전히 거의 실시간 동기화되지 않지만 소스 및 대상 클러스터 성능 구성 및 병렬 처리를 조정하거나 DMS 작업의 양과 CDC 인스턴스 간의 배포.

그리고 가능한 모든 변경이 지원되는 것은 아니기 때문에 CDC에서 지원하는 소스 테이블 변경(예: 열 추가)을 알아보고 싶을 수도 있습니다. 경우에 따라 유일한 방법은 대상 테이블을 수동으로 변경하고 CDC 작업을 처음부터 다시 시작하는 것입니다(그 과정에서 대상 데이터베이스의 모든 기존 데이터 손실).

일이 잘못되면 무슨 일이 있어도

나는 이것을 어려운 방법으로 배웠지만 매일 복제의 약속을 달성하기 어려운 DMS와 관련된 특정 시나리오가 하나 있습니다.

DMS는 정의된 속도로만 리두 로그를 처리할 수 있습니다. 작업을 실행하는 DMS 인스턴스가 더 있는지는 중요하지 않습니다. 여전히 각 DMS 인스턴스는 정의된 단일 속도로만 리두 로그를 읽고 각 인스턴스는 전체를 읽어야 합니다. Oracle redo 로그 또는 AWS 로그 마이너를 사용하는 경우에도 문제가 되지 않습니다. 둘 다 이 제한이 있습니다.

Oracle redo 로그가 매일 엄청나게 커지는(예: 500GB 이상) 하루 동안 소스 데이터베이스에 많은 변경 사항이 포함된 경우 CDC는 작동하지 않을 것입니다. 하루가 끝나기 전에 복제가 완료되지 않습니다. 복제할 새로운 변경 세트가 이미 기다리고 있는 다음 날 처리되지 않은 일부 작업을 가져올 것입니다. 처리되지 않은 데이터의 양은 매일 증가합니다.

이 특별한 경우에 CDC는 옵션이 아니었습니다(수많은 성능 테스트와 실행한 시도 후). 현재 날짜의 모든 델타 변경 사항이 같은 날에 복제되도록 하는 유일한 방법은 다음과 같이 접근하는 것입니다.

자주 사용하지 않는 매우 큰 테이블을 분리하고 일주일에 한 번만 복제합니다(예: 주말).
크지는 않지만 여전히 큰 테이블의 복제를 여러 DMS 작업 간에 분할하도록 구성합니다. 하나의 테이블은 결국 10개 이상의 분리된 DMS 작업에 의해 병렬로 마이그레이션되어 DMS 작업 간의 데이터 분할이 구별되고(여기에는 사용자 지정 코딩이 포함됨) 매일 실행됩니다.
DMS 인스턴스를 더 추가하고(이 경우 최대 4개) DMS 작업을 이들 간에 균등하게 분할합니다. 이는 테이블 수뿐만 아니라 크기도 의미합니다.

기본적으로 DMS의 전체 로드 모드를 사용하여 일일 데이터를 복제했습니다. 이것이 최소한 당일 데이터 복제 완료를 달성하는 유일한 방법이었기 때문입니다.

완벽한 솔루션은 아니지만 여전히 존재하며 수년이 지난 후에도 여전히 동일한 방식으로 작동합니다. 결국 그렇게 나쁜 해결책은 아닐 수도 있습니다.