이 문서에서는 실패 시나리오를 포함하여 데이터베이스 마이그레이션 프로세스를 설정하고 실행하는 방법을 설명합니다. 이 문서는 2부로 구성된 시리즈 중 2부입니다. 1부에서는 데이터베이스를 온프레미스 또는 기타 클라우드 환경에서 Google Cloud로 마이그레이션해야 하는 클라우드 설계자를 위한 다운타임이 거의 0에 가까운 데이터베이스 마이그레이션의 개념, 원칙, 용어를 소개합니다.
데이터베이스 마이그레이션 설정
이 섹션에서는 데이터베이스 마이그레이션의 여러 단계를 설명합니다. 먼저 마이그레이션을 설정합니다. 그런 다음 마이그레이션을 완료하고 클라이언트를 대상 데이터베이스로 전환한 후에는 소스 데이터베이스를 삭제하거나 필요한 경우 전환 후 발생하는 마이그레이션 문제의 대체 계획을 실행합니다. 대체는 비즈니스 연속성을 확보하는 데 도움이 됩니다.
마이그레이션하는 동안 발생할 수 있는 스키마 또는 데이터 변경사항에 특히 주의해야 합니다. 이러한 변경사항이 미칠 수 있는 영향에 대한 자세한 내용은 이 문서의 뒷부분에 있는 마이그레이션 시 동적 변경사항을 참조하세요.
대상 스키마 사양
각 대상 데이터베이스 시스템에 대해 스키마를 정의하고 생성해야 합니다. 동종 데이터베이스 마이그레이션의 경우 소스 데이터베이스 스키마를 대상 데이터베이스로 내보내 대상 데이터베이스 스키마를 만들어 이 사양을 더 빠르게 생성할 수 있습니다.
스키마 이름 지정 방법이 중요합니다. 한 가지 옵션은 소스와 대상 스키마 이름을 일치시키는 것입니다. 이렇게 하면 클라이언트 전환이 간단해지지만 도구가 소스와 대상 데이터베이스 스키마에 동시에 연결되면(예: 데이터 비교) 사용자에게 혼란을 줄 수 있습니다. 구성 파일을 사용하여 스키마 이름을 추출하는 경우 대상 데이터베이스 스키마에 소스와 다른 이름을 지정하면 스키마를 쉽게 구분할 수 있습니다.
이기종 데이터베이스 마이그레이션의 경우 각 대상 데이터베이스 스키마를 생성해야 합니다. 이 엔지니어링 프로세스에는 여러 번의 반복 작업이 필요할 수 있습니다. 마이그레이션을 구현하기 전에 마이그레이션 프로세스 및 데이터 수정을 수용하기 위해 스키마를 추가로 변경해야 할 수 있습니다.
마이그레이션을 테스트하고 실행할 때 대상 데이터베이스를 여러 번 만들 가능성이 높으므로 스키마를 만드는 프로세스는 반복이 가능해야 합니다(설치 스크립트를 통해 수행하는 것이 좋음). 코드 관리 시스템을 사용하여 스크립트 버전을 제어하고, 일관성을 유지하고, 스크립트의 변경 내역에 액세스할 수 있습니다.
쿼리 마이그레이션 및 실행 시맨틱스
궁극적으로 소스 데이터베이스 시스템 액세스에서 대상 데이터베이스 시스템 액세스로 클라이언트를 전환해야 합니다. 동종 데이터베이스 통합에서는 스키마가 수정되지 않은 경우 쿼리가 변경되지 않을 수 있습니다. 클라이언트는 대상 데이터베이스 시스템에서 테스트되어야 하지만 쿼리 때문에 클라이언트를 수정할 필요는 없습니다.
일반적으로 이기종 데이터베이스 마이그레이션의 경우 소스 데이터베이스와 대상 데이터베이스 간의 스키마가 다르므로 쿼리를 수정해야 합니다. 소스 데이터베이스와 대상 데이터베이스의 데이터 유형이 일치하지 않을 수 있습니다. 또한 소스 데이터베이스 시스템에서 사용할 수 있는 쿼리 언어의 모든 기능을 대상 데이터베이스 시스템에서 사용할 수 있는 것은 아닙니다. 반대의 경우도 마찬가지입니다. 극단적인 경우 소스 데이터베이스 시스템의 쿼리를 대상 시스템의 여러 쿼리로 변환해야 할 수 있습니다. 반대 시나리오, 즉 소스에서보다 대상 데이터베이스에서 사용할 수 있는 쿼리 언어 기능이 더 많은 경우에는 소스 데이터베이스의 여러 쿼리를 해당 대상 데이터베이스의 단일 쿼리로 결합해야 할 수 있습니다.
쿼리의 시맨틱스도 다를 수 있습니다. 예를 들어 일부 데이터베이스 시스템은 해당 트랜잭션 내에서 트랜잭션 내의 업데이트를 즉시 구체화하므로 동일한 데이터 항목을 읽을 때 업데이트된 값이 검색됩니다. 다른 시스템은 업데이트를 즉시 구체화하지 않고 트랜잭션이 커밋될 때까지 기다립니다. 소스 데이터베이스 시스템의 로직이 구체화되는 쓰기에 의존하는 경우 대상 데이터베이스의 동일한 로직으로 인해 잘못된 데이터 또는 장애가 발생할 수 있습니다.
쿼리를 마이그레이션해야 하는 경우 모든 기능을 테스트하여 마이그레이션 전후의 클라이언트 동작이 동일하도록 해야 합니다. 데이터 수준에서도 테스트할 수 있지만 이러한 테스트는 클라이언트 수준의 테스트를 대신할 수 없습니다. 클라이언트는 비즈니스 로직 관점에서 쿼리를 실행하기 때문에 비즈니스 로직 수준에서만 테스트할 수 있습니다.
마이그레이션 프로세스
이기종 데이터베이스 마이그레이션의 경우, 마이그레이션 프로세스는 소스 데이터베이스 시스템에서 추출된 데이터가 수정되어 대상 데이터베이스에 삽입되는 방식을 지정합니다. 이 문서의 데이터 변경사항에 설명된 것과 같은 데이터 수정사항은 데이터 항목이 소스 데이터베이스에서 추출되어 대상 데이터베이스로 전송되는 동안 정의 및 실행됩니다.
동종 데이터베이스 마이그레이션의 경우 소스 및 대상 데이터베이스의 스키마가 동일하면 데이터를 수정할 필요가 없습니다. 소스 데이터베이스에서 추출된 데이터는 대상 데이터베이스에 삽입됩니다.
데이터베이스 마이그레이션 시스템에 따라 몇 가지 구성이 필요할 수 있습니다. 예를 들어 수정 및 전송되는 데이터를 데이터베이스 마이그레이션 시스템에 간헐적으로 저장해야 하는지 여부를 지정해야 합니다. 데이터를 저장하면 전체 마이그레이션 프로세스가 느려질 수 있지만 오류 발생 시 복구 속도가 크게 향상될 수 있습니다. 인증 유형을 지정해야 할 수 있습니다. 예를 들어 일부 데이터베이스 마이그레이션 시스템은 소스 및 대상 시스템을 쿼리하여 쿼리 지점으로 마이그레이션된 데이터세트의 등가를 설정합니다. 오류를 처리하려면 장애 복구 동작을 지정해야 합니다. 이 요구사항은 사용 중인 데이터베이스 마이그레이션 시스템에 따라 다릅니다.
데이터 마이그레이션을 철저하게 반복적으로 테스트해야 합니다. 이상적으로는 마이그레이션은 모든 알려진 데이터 항목이 마이그레이션되고, 데이터 수정 오류가 발생하지 않고, 성능 및 처리량이 충분하며, 마이그레이션 시간을 달성하도록 테스트되어야 합니다.
대체 프로세스
데이터베이스 마이그레이션 중에는 소스 데이터베이스가 계속 작동합니다(마이그레이션에 다운타임이 계획되어 있지 않은 경우). 데이터베이스 마이그레이션에 실패할 경우(최악의 경우) 마이그레이션을 취소하고 대상 데이터베이스를 초기 상태로 초기화할 수 있습니다. 장애를 해결한 후 데이터베이스 마이그레이션을 다시 시작할 수 있습니다. 장애 및 해결은 운영 소스 데이터베이스 시스템에 영향을 미치지 않습니다.
데이터베이스 마이그레이션이 완료되고 클라이언트가 대상 데이터베이스로 전환된 후 장애가 발생하면 장애와 해결 프로세스로 인해 클라이언트가 제대로 작동하지 않을 수 있습니다. 최선의 경우에는 장애가 빠르게 해결되고 클라이언트의 다운타임이 짧지만, 최악의 경우에는 장애가 해결되지 않거나 해결에 시간이 오래 걸리며 클라이언트를 다시 소스 데이터베이스로 전환해야 합니다.
클라이언트를 소스 데이터베이스로 다시 전환하려면 대상 데이터베이스의 모든 데이터 수정사항을 소스 데이터베이스로 다시 마이그레이션해야 합니다. 이 프로세스는 별도의 완전한 데이터베이스 마이그레이션으로 설정하고 실행할 수 있습니다. 그러나 이 시점에서 클라이언트는 대상 데이터베이스에서 작동하지 않으므로 상당한 다운타임이 발생합니다.
이 시나리오에서 클라이언트 다운타임을 방지하려면 원래 데이터베이스 마이그레이션이 완료된 직후 마이그레이션 프로세스를 시작해야 합니다. 대상 데이터베이스 시스템에 적용된 모든 변경사항은 소스 데이터베이스 시스템에 즉시 적용됩니다. 이 방법을 따르면 대상 및 소스 데이터베이스 시스템이 항상 동기화 상태로 유지됩니다.
대상 데이터베이스에서 소스 데이터베이스로 대체를 준비하려면 상당한 노력이 필요합니다. 대체 프로세스를 구현 및 테스트할 것인지 결정하고 그렇지 않을 경우의 결과, 즉 상당한 다운타임을 파악하는 것이 중요합니다.
데이터베이스 마이그레이션 실행
데이터베이스 마이그레이션을 실행하려면 이 섹션에서 설명하는 5가지 단계를 수행해야 합니다. 6단계는 대체이지만, 대체는 극단적인 경우이며 일반적인 데이터베이스 이전 실행의 예외로 간주됩니다.
이 섹션에서 설명하는 프로세스는 다운타임이 거의 0에 가까운 이기종 데이터베이스 마이그레이션입니다. 상당한 다운타임이 발생할 수 있는 경우 백업/복원 또는 내보내기/가져오기 방식을 사용하여 처음 세 단계(초기 로드, 마이그레이션 진행, 드레이닝)를 하나의 단계로 결합할 수 있습니다.
동종 데이터베이스 마이그레이션은 특별한 경우입니다. 이 유형의 마이그레이션의 경우 소스 데이터베이스 시스템이 작동하는 동안 데이터를 마이그레이션하는 데이터베이스 관리 시스템 복제 기능(지원 시스템용)을 사용할 수 있습니다.
여기에서 설명하는 단계에서는 데이터베이스 마이그레이션 프로세스의 요구사항에 따라 수정해야 할 수 있는 방식을 소개합니다.
1단계: 초기 로드
먼저 모든 소스 데이터베이스에서 마이그레이션되도록 지정된 모든 데이터를 마이그레이션해야 합니다. 데이터 마이그레이션이 시작될 때 소스 데이터베이스는 특정 상태에 있으며 이 상태는 마이그레이션 중에 변경됩니다.
변경이 진행됨과 동시에 마이그레이션을 시작하기 위한 팁은 첫 번째 데이터 항목이 추출되기 직전에 데이터베이스 시스템 시간을 기록하는 것입니다. 이 타임스탬프를 사용하면 해당 시점부터 트랜잭션 로그에서 모든 데이터베이스 변경사항을 가져올 수 있습니다. 또한 초기 로드는 모든 데이터에서 일관적인 데이터베이스 상태를 읽어야 합니다. 일관적이지 않은 데이터세트를 읽는 것을 방지하기 위해 데이터베이스에 짧은 기간 잠금이 필요할 수 있습니다.
이 단계는 다음과 같이 구성됩니다.
- 데이터베이스 마이그레이션이 시작되기 직전에 데이터베이스 시스템 시간을 확인합니다.
- 마이그레이션되고 데이터세트를 마이그레이션해야 하는 소스 데이터베이스에서 데이터세트(전체 또는 일부)를 쿼리하는 초기 로드 마이그레이션 프로세스를 실행합니다. 관계형 데이터베이스 모델에서 초기 로드 마이그레이션 프로세스는
SELECT *와 같은 쿼리 또는 선택이나 프로젝션이 있는(또는 둘 다 있는) 쿼리를 실행합니다. 마이그레이션 프로세스는 프로세스에 지정된 대로 데이터를 수정합니다.
초기 로드 마이그레이션 프로세스가 실행되는 동안 클라이언트는 일반적으로 소스 데이터베이스를 변경합니다. 시작 시 데이터베이스 시스템 시간을 기록하므로 나중에 트랜잭션 로그에서 이러한 변경사항을 가져올 수 있습니다.
초기 로드 단계의 결과는 소스 데이터베이스 시스템에서 대상 데이터베이스 시스템으로 초기 데이터세트를 완전히 마이그레이션하는 것입니다. 그러나 마이그레이션하는 동안 클라이언트가 소스 데이터베이스를 수정했을 가능성이 높기 때문에 소스 및 대상 데이터베이스는 아직 동기화되지 않습니다. 2단계에서는 이러한 변경사항을 캡처하고 마이그레이션합니다.
2단계: 마이그레이션 진행
마이그레이션 진행에는 두 가지 목적이 있습니다. 첫째, 초기 로드가 시작된 후 소스 데이터베이스에서 발생한 변경사항을 읽습니다. 둘째, 이러한 변경사항을 캡처하여 대상 데이터베이스로 전송합니다.
이 단계는 다음과 같이 구성됩니다.
- 1단계에서 기록된 데이터베이스 시스템 시간부터 마이그레이션 프로세스를 시작합니다. 마이그레이션은 이 시점부터 트랜잭션 로그를 읽고 모든 변경사항을 대상 데이터베이스 시스템에 적용합니다.
- 데이터 수정을 실행합니다. 마이그레이션 프로세스는 지정한 대로 이 단계를 수행합니다.
데이터베이스 시스템 시간 이후에 기록되는 변경사항은 초기 로드 중에 전송되기도 합니다. 따라서 마이그레이션을 진행하는 동안 이러한 변경사항을 다시 적용할 수 있습니다. 변경사항이 두 번 적용되지 않도록 마이그레이션 프로세스를 정의해야 합니다(예: 식별자 사용). 변경된 데이터 항목이 초기 로드 중에 전송되고 해당 삽입이 트랜잭션 로그에 기록되었다고 가정해 보겠습니다. 데이터 항목에 식별자를 적용하면 마이그레이션 시스템은 데이터 항목이 이미 있기 때문에 다른 삽입이 필요하지 않다고 트랜잭션 로그를 통해 판단할 수 있습니다.
마이그레이션 단계가 진행되면 대상 데이터베이스가 소스 데이터베이스와 완전히 또는 거의 완전하게 동기화됩니다. 소스 데이터베이스 시스템의 변경사항이 마이그레이션되지 않으면 데이터베이스가 거의 동기화됩니다.
데이터베이스 마이그레이션 시스템을 구성하는 방법에 따라 불일치가 적거나 크게 발생할 수 있습니다. 예를 들어 효율성을 높이기 위해 모든 변경사항이 즉시 마이그레이션되어야 하는 것는 아닙니다. 그렇지 않으면 소스에 대한 변경사항이 급증할 경우 소스에 과도한 부하가 발생할 수 있습니다. 일반적으로 변경사항은 일괄 작업으로 일괄 수집 및 마이그레이션됩니다. 배치가 작으면 소스와 대상 간 불일치가 더 적게 발생하지만, 자주 변경되면 소스에서 더 많은 부하가 발생할 수 있습니다.
배치 크기가 동적으로 구성되면 처음에 계속되는 마이그레이션 진행 단계에서 먼저 대규모 배치를 동기화한 다음 데이터베이스를 거의 따라잡았을 때 점점 크기가 작은 배치를 동기화하는 것이 가장 좋습니다. 이러한 접근 방식을 사용하면 따라잡는 프로세스의 효율성이 높아지고 나중에 소스 데이터베이스와 대상 데이터베이스 간의 불일치가 감소합니다.
3단계: 드레이닝
소스에서 대상 데이터베이스로 클라이언트를 전환할 준비를 하려면 소스 데이터베이스와 대상 데이터베이스가 완전히 동기화되었는지 확인해야 합니다. 드레이닝은 소스 데이터베이스에서 대상 데이터베이스로 나머지 변경사항을 마이그레이션하는 프로세스입니다.
이 단계는 다음과 같이 구성됩니다.
- 소스 데이터베이스 시스템을 종료합니다. 즉, 소스 데이터베이스에서 데이터를 수정할 수 없으며 트랜잭션 로그에 추가 수정 항목이 수신되지 않습니다.
- 모든 변경사항이 대상 데이터베이스로 마이그레이션될 때까지 기다립니다. 이 프로세스는 변경사항의 실제 드레이닝입니다.
- 드레이닝이 완료되면 이후 증분 백업에 정의된 시작점을 확보하도록 대상 데이터베이스를 백업합니다.
드레이닝 단계를 완료하면 소스 데이터베이스 시스템과 대상 데이터베이스 시스템이 동기화되고 데이터가 수정되지 않습니다.
드레이닝이 완료되었는지 확인하려면 '마지막 삽입' 데이터 항목을 소스 데이터베이스에 기록합니다. '마지막 삽입' 데이터 항목이 해당 대상 데이터베이스에 표시되면 드레이닝 단계가 완료된 것입니다.
4단계: 전환
드레이닝 단계가 완료되면 클라이언트를 소스에서 대상 데이터베이스로 전환할 수 있습니다. 다음 권장사항을 따르는 것이 좋습니다.
- 프로덕션 데이터베이스에 대한 액세스를 사용 설정하기 전에 기본 기능을 테스트하여 클라이언트가 작동하고 의도한 대로 동작하는지 확인합니다. 테스트 횟수에 따라 프로덕션 데이터베이스의 실제 다운타임이 결정됩니다.
- 클라이언트 액세스를 사용 설정하기 전에 대상 데이터베이스를 백업합니다. 이렇게 하면 대상 데이터베이스의 초기 상태를 복구할 수 있습니다.
전환이 끝나면 클라이언트가 완전히 작동하고 프로덕션 데이터베이스(이 문서에서는 대상 데이터베이스라고 함)에 액세스하기 시작합니다.
5단계: 소스 데이터베이스 삭제
프로덕션 데이터베이스로의 전환을 완료하면 소스 데이터베이스를 삭제할 수 있습니다. 액세스할 수 있는 정의된 종료 상태가 되도록 각 소스 데이터베이스의 최종 백업을 수행하는 것이 좋습니다. 규정 준수를 위해 데이터 규정에 따라 최종 백업이 필요할 수도 있습니다.
6단계: 대체
특히 중요도가 높은 데이터베이스 클라이언트의 경우 대체를 실행하면 마이그레이션 문제를 효과적으로 방지할 수 있습니다. 대체는 마이그레이션과 비슷하지만 역으로 가는 작업입니다. 즉, 대체를 통해 대상 데이터베이스에서 다시 소스 데이터베이스로 마이그레이션을 설정합니다. 이기종 데이터베이스 마이그레이션의 경우 대체가 더 복잡합니다. 따라서 데이터베이스 마이그레이션 프로세스 및 대상 데이터베이스에 연결된 애플리케이션이 서비스수준계약(SLA)을 충족하는지 철저히 테스트한 후에만 전환을 수행하는 것이 좋습니다.
소스 데이터베이스를 드레이닝하고 모든 데이터베이스를 백업한 후에는 전환 이전에 대상 데이터베이스의 변경사항을 식별하고 소스 데이터베이스로 이전하는 마이그레이션 프로세스를 사용 설정할 수 있습니다.
이러한 마이그레이션 프로세스를 구축하면 클라이언트가 대상 데이터베이스를 변경한 후 소스 데이터베이스가 동기화되고 데이터 상태가 최신 상태로 유지됩니다. 전환 후 며칠 또는 몇 주 후에 대체가 필요할 수 있습니다. 예를 들어 클라이언트는 처음으로 기능에 액세스할 수 있으며, 빠르게 수정할 수 없는 손상된 기능이 있는 경우 차단될 수 있습니다. 이 경우 클라이언트를 소스 데이터베이스 액세스로 다시 전환할 수 있습니다. 클라이언트를 다시 전환하기 전에 대상 데이터베이스의 모든 변경사항을 소스 데이터베이스로 드레이닝해야 합니다.
이러한 접근 방식에서는 특별한 주의가 필요한 경우가 있습니다.
- 대상 데이터베이스에서 소스 데이터베이스로 역 마이그레이션이 가능하도록 대상 스키마를 설계해야 합니다. 예를 들어 소스에서 대상으로의 초기 마이그레이션 프로세스에 조인 또는 집계가있는 경우 역 마이그레이션은 간단하지 않거나 불가능합니다. 이러한 경우 개별 데이터를 대상 데이터베이스에서도 사용할 수 있어야 합니다.
- 소스 데이터베이스에 트랜잭션 로그가 있지만 대상 데이터베이스가 이러한 기능을 제공하지 않는 문제가 발생할 수 있습니다. 이 경우 대상에서 소스로의 역 마이그레이션은 차등 쿼리를 활용해야 합니다. 이 설정은 대상 데이터베이스 스키마에서 설계하고 준비해야 합니다.
- 원래 소스 데이터베이스에서 작업한 클라이언트는 대체에서 사용 설정될 수 있도록 사용 가능하고 작동해야 합니다. 대상 데이터베이스에 액세스하는 클라이언트에 대한 모든 기능 변경사항은 소스 데이터베이스에 액세스하는 클라이언트에도 동일한 기능을 제공해야 합니다.
대체는 최후의 수단이지만 대체를 실행하는 것은 중요하며 테스트를 포함한 전체 데이터베이스 마이그레이션으로 처리되어야 합니다.
마이그레이션 중 동적 변경사항
스키마와 데이터 값은 변경할 수 있으므로 데이터베이스는 보통 동적 시스템입니다. 데이터베이스 스키마는 비즈니스 요구사항과 같은 요소에 따라 변경될 수 있으며 데이터 값은 스키마 변경사항과 함께 또는 독립적으로 변경될 수 있습니다. 데이터 값 변경사항은 애플리케이션 구현의 해당 변경사항과 함께 언제든지 동적으로 발생할 수 있습니다. 다음 섹션에서는 가능한 몇 가지 변경사항과 데이터베이스 마이그레이션에 미치는 영향을 설명합니다.
스키마 변경사항
데이터베이스는 사전 정의된 스키마가 필요하거나 스키마가 없는 시스템으로 분류할 수 있습니다. 일반적으로 사전 정의된 스키마가 필요한 시스템은 스키마 변경 작업(예: 관계형 시스템에 속성 또는 열 추가)을 지원합니다.
이러한 시스템에서는 변경 관리 프로세스를 통해 변경사항을 제어합니다. 변경 관리 프로세스는 제어되는 방식으로 변경할 수 있도록 합니다. 쿼리 또는 데이터 마이그레이션 프로세스와 같이 스키마에 의존하는 모든 작업은 전체적으로 일관된 변경을 보장하기 위해 동시에 변경됩니다.
사전 정의된 스키마가 필요하지 않은 데이터베이스 시스템은 언제든지 변경될 수 있습니다. 스키마 변경은 승인된 사용자만 수행할 수 있는 것이 아니며 프로그래매틱 방식으로도 가능합니다. 이 경우 언제든지 스키마가 변경될 수 있습니다. 스키마에 의존하는 작업(예: 쿼리 또는 데이터 마이그레이션 프로세스)은 실패할 수 있습니다. 이러한 데이터베이스 시스템에서 제어되지 않는 스키마 변경을 방지하려면 시스템 시행이 아닌 관례 및 수락된 규칙으로 변경 관리 프로세스를 구현해야 합니다.
데이터 변경사항
일반적으로 스키마는 다양한 데이터 속성에 대해 가능한 데이터 값을 제어합니다. 스키마가 없는 시스템에는 데이터 값에 대한 제약이 없습니다.
두 경우 모두 이전에 저장되지 않은 데이터 값이 표시될 수 있습니다. 예를 들어 열거형 유형은 데이터베이스 시스템에서 문자열 집합으로 구현되는 경우가 많습니다. 프로그래밍 언어 수준에서는 이러한 작업이 클라이언트에서 실제 열거형으로 구현될 수 있지만, 반드시 그렇지는 않습니다. 클라이언트는 다른 클라이언트가 유효하다고 간주하지 않는 유효한 열거 값으로 간주하는 데이터를 저장할 수 있습니다. 또한 데이터 마이그레이션 프로세스는 열거 값에서 기능을 입력할 수 있습니다. 새로운 값이 표시되면 데이터 마이그레이션 프로세스가 실패할 수 있습니다.
JSON 구조의 스토리지에서 또 다른 예시를 확인할 수 있습니다. 대부분의 경우 JSON 구조는 데이터 유형 문자열에 저장되지만 액세스 시 JSON 값으로 해석됩니다. JSON 구조가 변경되면 데이터베이스 시스템에서 이를 감지하지 못합니다. 문자열을 JSON 값으로 해석하는 데이터 마이그레이션 프로세스가 실패할 수 있습니다.
마이그레이션 프로세스 변경사항
데이터베이스 마이그레이션이 진행되는 동안 변경 관리는 어렵고 복잡하며 데이터 마이그레이션 실패 또는 데이터 불일치로 이어질 수 있습니다. 소스와 대상 데이터베이스 시스템이 동기화되는 시점인 드레이닝 단계가 끝날 때까지 필요한 변경사항이 지연되는 것이 바람직합다. 이때 변경사항은 대체가 실행되지 않는 한 대상 데이터베이스 및 해당 클라이언트로 제한됩니다.
데이터 마이그레이션 중에 마이그레이션 프로세스를 변경해야 하는 경우 변경사항을 최소한으로 유지하고 한 개의 복잡한 변경사항 대신 여러 개의 작은 변경사항을 만드는 것이 좋습니다. 또한 소스 및 대상 데이터베이스의 테스트 인스턴스를 사용하여 이러한 변경사항을 먼저 테스트할 수도 있습니다. 프로덕션 데이터로 테스트 소스를 로드한 다음 테스트 대상으로 마이그레이션하는 것이 가장 좋습니다. 이 방식을 사용하면 진행 중인 프로덕션 마이그레이션에 영향을 주지 않고 제안된 변경사항을 확인할 수 있습니다. 변경사항을 테스트하고 확인한 후 프로덕션 시스템에 변경사항을 적용할 수 있습니다.
데이터 마이그레이션이 진행되는 동안 변경사항을 적용하려면 데이터 마이그레이션 시스템을 중지하고 데이터 마이그레이션 프로세스를 수정하여 다시 시작할 수 있어야 합니다. 이 경우 초기 데이터 로드 단계부터 시작할 필요가 없습니다. 데이터 마이그레이션 시스템에서 테스트 마이그레이션 실행 기능을 지원하는 경우에는 이러한 기능 또한 사용할 수 있습니다.
데이터 마이그레이션 중에는 스키마, 데이터 값 또는 데이터 마이그레이션 프로세스를 변경하지 않는 것이 좋습니다. 변경해야 하는 경우 시작 상태가 정의되어 있는지 확인하기 위해 데이터 마이그레이션을 처음부터 다시 시작하는 것을 고려할수 있습니다. 어떤 경우든 프로덕션 데이터를 사용하여 테스트하고 변경사항을 적용하기 전에 데이터베이스를 백업하여 필요한 경우 전체 시스템을 일관된 상태로 초기화할 수 있어야 합니다.
마이그레이션 실패 완화
데이터베이스 마이그레이션 중에 예기치 않은 문제가 발생할 수 있습니다. 다음은 사전 계획이 필요한 몇 가지 영역입니다.
- 처리량 부족. 마이그레이션 시스템에는 부하 테스트를 해도 처리량이 부족할 수 있습니다. 이 문제에는 소스 데이터베이스 변경사항의 전례없는 증가나 네트워크 제한 등 여러 가지 원인이 있을 수 있습니다. 관련된 모든 구성 요소를 동적으로 수직 확장 또는 수평 확장하기 위한 추가 리소스를 확보하면 이러한 문제에 대비할 수 있습니다.
- 데이터베이스 불안정. 소스 데이터베이스 또는 대상 데이터베이스가 불안정하여 데이터 마이그레이션 프로세스의 속도가 느려지거나 간헐적으로 액세스가 차단될 수 있습니다. 데이터 마이그레이션 프로세스는 자주 복구해야 할 수 있습니다. 이 경우 의도적인 HA 또는 DR 전환을 통해 문제를 해결할 수 있습니다. 전환하면 작동하지 않는 환경(머신 및 스토리지)이 변경되며 문제를 완화하는 데 도움이 될 수 있습니다. 이 경우 전환이 대상 데이터베이스의 데이터 불일치를 유발하지 않도록 전환 및 데이터베이스 이전 복구 프로세스를 테스트해야 합니다.
- 트랜잭션 로그 파일 크기 소진. 트랜잭션 로그가 상한선이 있는 파일에 저장되는 경우가 있습니다. 이 상한선에 도달하면 데이터베이스 마이그레이션이 실패할 수 있습니다. 리소스 제한 문제가 발생하면 이를 해결하기 위해 데이터베이스 시스템에서 동적으로 재구성할 수 있는 부분을 이해하는 것이 중요합니다. 특정 측면을 동적으로 구성할 수 없는 경우 초기 크기를 신중하게 결정해야 합니다.
현실적이고 완성도 높은 테스트를 많이 할수록 해결해야 할 잠재적인 문제를 사전에 발견할 가능성이 높습니다.
다음 단계
- 데이터베이스 마이그레이션에 대한 다음 리소스를 확인하기
- 데이터베이스 마이그레이션 가이드에 대한 자세한 내용은 데이터베이스 마이그레이션 참조
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기 Cloud 아키텍처 센터를 살펴보세요.