Oracle 데이터베이스를 AWS 기반 PostgreSQL로 마이그레이션 하기

KENNETH

6년 ago

이 블로그 게시물에서는 Oracle 데이터베이스를 AWS 기반의 PostgreSQL로 마이그레이션하는 방법을 소개합니다. 데이터베이스 마이그레이션에서 가장 중요한 두 가지 요소는 스키마 변환과 데이터 복제입니다. AWS Schema Conversion Tool(AWS SCT) 및 AWS Database Migration Service(AWS DMS)를 사용하여 이러한 두 가지 요소를 처리하는 방법에 대해 살펴보겠습니다.

SCT 와 DMS를 사용하기 전, 마이그레이션을 위한 예비 조치를 취해야 합니다. 마이그레이션을 더 쉽게 수행하기 위한 예비 조치 중 하나는 마이그레이션 전에 현대화 단계를 진행하는 것입니다. 이 단계에서는 Oracle 데이터베이스에서 객체 인벤토리를 가지고 온 후, 몇 가지 사항을 결정합니다.

첫째, 더 이상 필요하지 않은 객체는 사용하지 않습니다. 아무도 신경 쓰지 않는 객체를 마이그레이션하는 데 시간을 낭비할 필요 없습니다. 또한, 더 이상 필요하지 않은 기록 데이터는 제거합니다. 예를 들어 기존 유지 관리에서 사용한 테이블의 백업 복사본, 임시 테이블 등 필요하지 않은 데이터를 복제하는 데 시간을 들이지 않아도 됩니다. 둘째, LOB, CLOB, LONG 등에 저장된 긴 문자열 및 플랫 파일을 Amazon S3 또는 Amazon Dynamo DB로 옮깁니다. 이 프로세스에서는 클라이언트 소프트웨어를 변경해야 하지만, 데이터베이스의 복잡성과 크기가 줄어들기 때문에 전체 시스템의 효율성은 높아집니다. PL/SQL 패키지, 프로시저 등의 객체는 SCT가 해당 객체를 변환할 수 없다면 수동으로 마이그레이션 하거나 클라이언트 소프트웨어로 다시 이동하는 것을 고려해야 합니다.

이 블로그에서는 아래에 제안된 단계를 사용하여 Oracle에서 PostgreSQL로 데이터베이스를 마이그레이션하는 방법을 중점적으로 살펴봅니다. 다른 플랫폼으로 이동하지 않더라도 데이터베이스를 마이그레이션하는 데 아래 제안된 방법 외, 더 적절한 네이티브 도구나 다른 기술이 존재할 수 있습니다.

대상 데이터베이스에 스키마를 생성합니다.
대상 데이터베이스에서 외래 키 및 보조 인덱스를 삭제하고, 트리거를 비활성화합니다.
전체 로드 및 CDC(변경 데이터 캡처)와 같은 DMS 작업을 설정하여 데이터를 복제합니다.
전체 로드 단계가 완료되면 작업을 중지하고, 외래 키 및 보조 인덱스를 다시 생성합니다.
DMS 작업을 활성화합니다.
도구 및 소프트웨어를 마이그레이션하고, 트리거를 활성화합니다.

1. 대상 데이터베이스에 스키마 생성

먼저, 마이그레이션하려는 스키마를 분석 합니다. 여기에서는 AWS Schema Conversion Tool(AWS SCT)을 사용하여 분석을 수행합니다. 애플리케이션을 시작할 때, 소스가 Oracle이고 대상이 PostgreSQL인 새 프로젝트를 만들어야 합니다. 연결되면 왼쪽에서 마이그레이션하려는 스키마의 이름을 선택합니다. 스키마 이름을 마우스 오른쪽 버튼으로 클릭하고 Convert Schema를 선택합니다. 그런 다음, View/Assessment Report View를 선택합니다.

AWS SCT 평가 보고서는 Oracle 데이터베이스를 PostgreSQL로 변환하는 데 필요한 활동을 개괄적으로 보여줍니다. 다음은 평가 보고서의 예시입니다.

이 보고서는 각 객체 유형 별, 객체 변환에 필요한 수작업을 보여줍니다. 일반적으로 패키지, 프로시저 및 함수에는 해결해야 할 몇 가지 문제가 있습니다. AWS SCT는 이러한 객체를 수정해야 하는 이유를 알려주며 이를 수행하는 방법에 대한 힌트도 제공합니다.

스키마가 자동으로 변환되지 않는 경우, 아래에서 문제 해결에 유용한 몇 가지 힌트를 참고하시기 바랍니다.

AWS SCT가 객체를 대상 PostgreSQL로 변환할 수 있도록 소스 Oracle 데이터베이스에서 해당 객체를 수정합니다.
스키마를 있는 그대로 변환하고 AWS SCT가 생성한 스크립트를 수동으로 수정한 다음, 대상 PostgreSQL 데이터베이스에 적용합니다.
변환할 수 없는 객체는 무시하고, 다른 AWS 서비스 또는 해당 객체와 동등한 서비스로 기능을 대체합니다.

스키마의 변환 기능을 개선하면 반복 프로세스를 통해 보고서 및 스키마를 다시 생성할 수 있습니다. Action Items 탭에서 변환 프로세스를 수행할 때 발생하는 문제 목록과 각 문제 별 내용을확인할 수 있습합니다. 변환된 스키마 결과가 만족스러운 경우, 그 결과를 대상 PostgreSQL 데이터베이스에 적용할 수 있습니다.

대상 데이터베이스의 스키마를 살펴보고 열 데이터 형식, 객체 이름 등을 확인하는 것을 권고합니다. 데이터 형식에 대한 자세한 내용은 소스 및 대상 데이터 형식에 대한 AWS Database Migration Service 참조에서 확인할 수 있습니다. 또한 Oracle에서 PostgreSQL로 변환할 때, 객체 이름이 Oracle에서는 대문자, PostgreSQL에서는 소문자라는 점을 유념하시기 바랍니다.

2. 외래 키 제약 조건 및 보조 인덱스 삭제, 트리거 비활성화

마이그레이션 대상 스키마를 결정하면, 소스에서 실제 데이터를 마이그레이션하기 위한 스키마를 준비해야 합니다. 이 블로그 포스트에서는 AWS Database Migration Service(AWS DMS)를 사용한 방법을 소개합니다. DMS에는 1) 전체 로드 및 2) CDC(변경 데이터 캡처)의 두 단계가 있습니다. 전체 로드 단계 중에는, 테이블이 순서 없이 로드됩니다. 따라서 대상에서 제약 조건을 활성화하면, 일부 외래 키 제약 조건 위반이 발생합니다. 또한, 전체 로드 중에 보조 인덱스가 테이블 복제 속도를 저하할 수 있으므로 보조 인덱스를 비활성화해야 합니다. 레코드를 로드할 때 인덱스를 유지해야 하므로 복제 속도가 저하됩니다.

대상 PostgreSQL 데이터베이스에서 쿼리를 실행하여 데이터베이스 테이블의 외래 키 제약 조건에 대한 DDL을 생성하고 출력을 저장합니다. 온라인에서 많은 샘플 쿼리를 찾을 수 있으나, 다음과 비슷한 것을 사용해야 합니다. 이렇게 하면 나중에 외래 키 제약 조건을 다시 생성하는 DDL이 제공됩니다.

ALTER TABLE <table_name> ADD CONSTRAINT <constraint_name> FOREIGN KEY (key column) REFERENCES <parent table_name> (key column) MATCH FULL;

그런 다음, DDL 생성 쿼리를 실행하여 대상 데이터베이스의 모든 외래 키 제약 조건을 삭제합니다.

ALTER TABLE <table_name> DROP CONSTRAINT <constraint_name>;

이제 보조 인덱스에 대해서도 같은 방법을 적용 합니다 – create 명령과 결과를 생성한 후, 보조 인덱스를 삭제합니다.

그런 다음, 트리거를 비활성화합니다.

ALTER TABLE <table_name> DISABLE TRIGGER ALL;

ID 열에 시퀀스를 사용하는 경우, 대상 데이터베이스의 시퀀스는 소스 데이터베이스의 시퀀스보다 더 높은 값을 설정하는 것이 좋습니다. 시퀀스 값이 마이그레이션 이후에도 소스 데이터베이스보다 여전히 높을 수 있도록 하려면 충분히 차이를 두고 설정하십시오. 이렇게 하면 마이그레이션 이후 시퀀스 ID의 충돌을 방지할 수 있습니다.

3. DMS 작업을 설정하여 데이터 복제

대상 PostgreSQL 데이터베이스에 스키마를 준비해 두었으니 이제 데이터를 복제를 시작할 수 있습니다. 이 시점에 DMS가 등장합니다. DMS의 가장 큰 장점은 각 테이블의 데이터를 복제하는 것이 아니라 마이그레이션할 준비가 될 때까지 CDC 모드를 통해 해당 데이터를 최신 상태로 유지한다는 것입니다.

DMS를 통해 데이터를 복제하기 위해 소스 Oracle 데이터베이스에서 준비해야 하는 사항은 아래와 같습니다.

Oracle 로그인에 필요한 권한이 있는지 확인합니다.
DMS에서 Oracle 소스 데이터베이스의 변경 사항을 캡처하기 위해 필요로 하는 보충 로깅을 설정합니다.
추가 준비 정보는 소스 Oracle 데이터베이스에 대한 DMS 설명서를 참조하세요.

AWS 콘솔에서 DMS를 시작합니다. 먼저 복제 인스턴스를 만들어야 합니다. 복제 인스턴스에서 DMS 작업을 실행하게 됩니다. 이 인스턴스는 소스 Oracle 데이터베이스와 대상 PostgreSQL 데이터베이스 모두에 연결되어야 하는 중간 서버입니다. 특히 여러 작업을 생성하거나, 다수의 테이블을 마이그레이션하거나, 이를 둘 다 수행할 것으로 예상되는 경우, 적절한 크기의 서버를 선택합니다.

그런 다음, 소스 데이터베이스용 엔드포인트 및 대상 데이터베이스용 엔드포인트를 각각 생성해야 합니다. 이 때, Oracle 데이터베이스 및 PostgreSQL 데이터베이스에 대한 적절한 연결 정보를 모두 입력합니다. 각 엔드포인트 생성을 완료하기 전, 성공적인 연결 테스트 및 테스트 실행 이후 스키마 새로 고침 옵션을 선택했는지 확인합니다.

이제 작업을 생성할 준비가 되었습니다. 작업 이름을 입력하고, 생성한 복제 인스턴스와 소스 및 대상 엔드포인트를 선택합니다. 마이그레이션 유형은 기존 데이터 마이그레이션 및 지속적인 변경 사항 복제를 선택합니다. AWS SCT를 사용하여 스키마를 미리 생성하기 때문에 대상 테이블 준비 모드는 아무 작업 안 함 또는 자르기를 선택합니다.

전체 로드가 완료되고 캐시된 변경 사항이 적용된 후 작업이 일시적으로 중지되기를 원하기 때문에 전체 로드 완료 후 작업 중지 옵션에 대해 캐시된 변경 사항 적용 후 중지를 선택합니다. 캐시된 변경 사항은 전체 테이블 로드 프로세스가 실행되는 동안 발생하고 누적된 변경 사항입니다. 이 시점은 CDC가 적용되기 직전 단계입니다.

이 블로그에서는 소스 Oracle 데이터베이스를 현대화하고, LOB를 S3, DynamoDB 또는 다른 유사한 서비스로 전환했습니다. 그렇게 하지 않을 경우, LOB를 처리하기 위한 몇 가지 옵션이 있습니다. 복제에 LOB 열 포함 옵션을 선택한 경우, 모든 테이블의 전체 LOB를 복제하려면 전체 LOB 모드를 선택합니다. LOB를 특정 길이까지만 복제하려면 제한적 LOB 모드를 선택합니다. 최대 LOB 크기(kb) 텍스트 상자에 마이그레이션할 LOB 길이를 지정합니다.

마지막으로, 작업으로 인해 발생하는 오류 또는 경고를 확인하고 해당 문제를 해결할 수 있도록 로깅 활성화를 선택하는 것을 추천합니다. 작업 생성을 선택합니다.

다음으로, 테이블 매핑에서 마이그레이션하려는 스키마를 선택하고 Add selection rule을 선택합니다. JSON탭을 선택합니다. Enable JSON editing 확인란을 선택합니다. 그런 후, 다음 JSON 문자열을 입력합니다. 스키마 이름 DMS_SAMPLE은 원하는 스키마 이름으로 바꿉니다.

{
 "rules": [
  {
   "rule-type": "selection",
   "rule-id": "1",
   "rule-name": "1",
   "object-locator": {
    "schema-name": "DMS_SAMPLE",
    "table-name": "%"
   },
   "rule-action": "include"
  },
  {
   "rule-type": "transformation",
   "rule-id": "6",
   "rule-name": "6",
   "rule-action": "convert-lowercase",
   "rule-target": "schema",
   "object-locator": {
    "schema-name": "%"
   }
  },
  {
   "rule-type": "transformation",
   "rule-id": "7",
   "rule-name": "7",
   "rule-action": "convert-lowercase",
   "rule-target": "table",
   "object-locator": {
    "schema-name": "%",
    "table-name": "%"
   }
  },
  {
   "rule-type": "transformation",
   "rule-id": "8",
   "rule-name": "8",
   "rule-action": "convert-lowercase",
   "rule-target": "column",
   "object-locator": {
    "schema-name": "%",
    "table-name": "%",
    "column-name": "%"
   }
  }
 ]
}

PostgreSQL의 경우 이 JSON 문자열이 스키마 이름, 테이블 이름 및 열 이름을 소문자로 변환합니다.

작업이 생성되면 자동으로 시작됩니다. 작업을 선택하고 테이블 통계 탭을 클릭함으로써 DMS 콘솔을 사용하여 진행 상태를 모니터링할 수 있습니다. 전체 로드가 완료되고 캐시된 변경 사항이 적용되면 작업이 자체적으로 중지됩니다.

4. 전체 로드가 완료되면 작업을 중지하고, 외래 키 및 보조 인덱스를 다시 생성함

이제 테이블 로드가 완료되었습니다! 로그를 검토하여 작업에 오류가 없는지 확인하기 좋은 시기입니다.

작업의 다음 단계는 CDC로, 소스 데이터베이스에서 발생한 순서대로 변경 사항을 적용하는 단계입니다. 이 접근 방식은 상위 테이블이 대상 데이터베이스의 하위 테이블보다 이전에 업데이트되기 때문에 외래 키를 다시 생성할 수 있음을 의미합니다.

필요에 따라 생성된 스크립트를 조정하여 이전에 삭제된 외래 키 및 보조 인덱스를 다시 생성합니다. 보조 인덱스는 이 단계의 작업에서 중요합니다. 이 단계는 소스 데이터베이스에서 where 절을 사용하여 수행한 모든 업데이트가 대상 데이터베이스에서도 인덱스 조회이기 때문에 중요합니다. 업데이트에서 인덱스를 누락한 경우 이러한 업데이트는 전체 테이블 스캔으로 실행됩니다.

마이그레이션 전환이 일어날 때까지 트리거 활성화를 연기합니다. 이는 트리거가 소스에서 비롯된 데이터를 업데이트할 수 있기 때문입니다.

5.DMS 작업 활성화

외래 키 및 보조 인덱스가 다시 생성되었으므로 이제 DMS 작업을 활성화할 수 있습니다. DMS 콘솔로 이동하여 작업을 선택하면 됩니다. 목록에서 작업을 선택하고, 시작/재시작을 선택합니다. 시작 옵션을 선택하고, 작업 시작을 선택합니다.

6. 도구 및 소프트웨어를 마이그레이션하고 트리거 활성화

마침내 전환 시점이 다가왔습니다. 사용하던 도구 및 소프트웨어와 소스 데이터베이스의 연결을 중단하고 DMS가 소스 데이터베이스의 마지막 데이터 변경 사항을 대상 데이터베이스로 복제를 완료하면 DMS 콘솔에서 DMS 작업을 중지합니다. 그런 다음, 대상 데이터베이스에서 트리거를 활성화합니다.

ALTER TABLE <table_name> ENABLE TRIGGER ALL;

유용한 힌트

스키마 변환을 쉽게 수행하려면 AWS SCT를 사용하여 평가 보고서를 확인하고 작업 항목을 반복합니다. 대상 PostgreSQL 스키마의 최종 버전에 이를 때까지 대상 스키마를 여러 번 생성해야 합니다.
새 스키마에 대한 쿼리가 새 플랫폼에서 작동하는지 확인하려면 대상 시스템에서 애플리케이션을 테스트합니다. AWS SCT는 애플리케이션 쿼리도 PostgreSQL로 변환할 수 있습니다. 자세한 내용은 AWS SCT 설명서를 확인하세요. 또한, 대상 서버 크기 및 데이터베이스 설정이 올바른지 확인하기 위해 대상 시스템에서 로드 테스트를 수행할 수도 있습니다.
앞서 설명한 실제 마이그레이션 단계를 실습해보고 프로세스를 간소화합니다. 여기서 언급한 단계는 시작 지점에 불과하며, 각 데이터베이스는 고유합니다.

추가 참고 자료

다음 자료를 검토하는 것을 권장합니다.