도구 선택 및 마이그레이션 모델에 대한 결정 기준 분석
이제 마이그레이션 방법론 및 도구 옵션에 대한 옵션을 살펴보니 Azure Database for PostgreSQL 유연한 서버로 마이그레이션을 실행하는 데 필요한 결정 기준을 살펴볼 수 있습니다. 선택할 수 있는 세 가지 주요 기준은 가동 중지 시간, 원본 데이터베이스 위치 및 사용자 지정 가능성입니다.
가동 중지 시간
가동 중지 시간은 마이그레이션 활동의 주요 측면이며 이해 관계자가 허용할 수 있는 기간은 오프라인 또는 온라인 마이그레이션 작업을 수행해야 하는지 여부를 결정하는 데 도움이 됩니다.
일반적으로 마이그레이션 작업은 작업에 대한 적절한 변경 제어 및 관련 거버넌스가 완료되도록 사전에 계획됩니다. 이 계획을 통해 주요 이해 관계자와의 대화 상자에서 시스템이 오프라인 상태가 될 수 있는 기간을 이해할 수 있습니다. 이 경우 예상 최소 및 최대 가동 중지 시간을 설정할 수 있는 다양한 옵션에 걸리는 시간을 아는 것이 좋습니다.
애플리케이션 컷오버를 수행하는 데 필요한 최소 가동 중지 시간을 설정하는 것이 중요합니다. 궁극적으로 이 시간은 온라인(또는 최소 가동 중지 시간) 마이그레이션 작업에서도 시스템을 오프라인으로 전환해야 하는 양입니다. 애플리케이션의 복잡성에 따라 이 시간 표시줄이 결정됩니다. 비교적 간단한 애플리케이션의 경우 이 프로세스는 서비스를 중지하고 구성 파일을 업데이트한 다음 다시 켜는 경우일 수 있습니다. 더 복잡한 환경에서는 서버와 애플리케이션 계층이 여러 개 있는 경우 이 프로세스가 훨씬 더 오래 걸릴 수 있습니다.
온라인 또는 오프라인 마이그레이션 작업에 필요한 기간을 이해하는 것은 가동 중지 시간과 관련된 다음 중요한 요소입니다. 오프라인 마이그레이션인 경우 원본에서 대상으로 데이터를 추출, 전송 및 로드한 다음 유효성 검사 및 확인에 걸리는 시간은 가동 중지 시간입니다. 그러면 이 가동 중지 시간은 앱/워크로드를 끄는 데 걸리는 시간과 앱/워크로드를 다시 켜는 데 걸린 시간 사이에 끼어 있습니다.
온라인(최소 가동 중지 시간) 마이그레이션인 경우 가동 중지 시간은 애플리케이션이 꺼진 후 원본에서 대상으로 최종 변경 내용을 동기화하는 데 필요한 기간입니다. 애플리케이션/워크로드를 다시 구성하고 사용하도록 설정하기 전에 해당 가동 중지 시간, 유효성 검사 및 확인 활동에 추가합니다.
이 정보가 있으면 마이그레이션의 기술 요소를 살펴보고 실행 가능한 옵션을 설정하는 데 도움이 될 수 있습니다.
원본 데이터베이스 위치
마이그레이션할 데이터베이스의 원본 위치는 지정된 구성에 적용될 가능성이 있는 제약 조건으로 인해 한 몫을 합니다.
온-프레미스 또는 비 Azure 원본
온-프레미스 또는 비 Azure에 위치한 데이터베이스의 경우 키 제약 조건은 일반적으로 원본과 대상 간의 네트워크 연결입니다. 여기서 고려해야 할 세 가지 사항은 대역폭, 대기 시간 및 데이터 볼륨입니다. 이러한 점을 이해하면 실행 가능한 마이그레이션 유형에 대한 정보에 입각한 결정을 내릴 수 있습니다.
마이그레이션할 많은 양의 데이터와 비례적으로 적은 양의 대역폭이 있는 경우 간단한 덤프 및 복원은 실행 가능하지 않을 것입니다. 데이터 양이 많고 대역폭이 많은 경우에는 문제가 되지 않습니다.
마찬가지로 데이터 동기화가 수행되는 온라인 마이그레이션인 경우 대기 시간이 주요 요소 중 하나입니다. 대기 시간이 높은 경우 동기화 프로세스를 완료하는 데 너무 오래 걸리기 때문에 시스템 성능에 부정적인 영향을 줄 수 있습니다.
다른 클라우드 공급자에서 마이그레이션할 때 고려해야 할 중요한 요소 중 하나는 데이터 송신에 대한 요금을 부과하는지 여부입니다. 그렇다면 전송되는 데이터의 물리적 공간을 최소화할 수 있는 것이 고려될 수 있습니다. 이와 같은 상황에서 압축 기술은 동기화에 사용되는 덤프 또는 데이터 스트림에 중요할 수 있습니다.
기타 Azure 기반 서비스
다른 Azure 기반 서비스에서 Azure Database for PostgreSQL 유연한 서버로 마이그레이션하려는 상황이 발생할 수 있습니다. 이러한 원본 데이터베이스는 Azure VM, 컨테이너 또는 Azure Database for PostgreSQL 단일 서버에 있을 수 있습니다. 그렇다면 탐색해야 할 다른 고려 사항이 있지만 동시에 이러한 시나리오에 대한 Azure 서비스 내의 최적화를 활용할 수 있는 몇 가지 기회가 있습니다.
사용자 지정 가능
마지막 고려 사항은 사용자 지정이 얼마나 필요한지입니다. 이 고려 사항은 데이터 복제를 지원하기 위해 원본 데이터베이스 구조를 수정해야 하는 형태를 취할 수 있습니다. 또는 스크립팅을 통해 자동화하는 것이 얼마나 쉬운지를 의미할 수 있습니다.
좋은 예는 덤프 파일의 압축 및 압축 해제를 포함하여 동시에 pg_dump 및 pg_restore를 통해 데이터베이스의 오프라인 마이그레이션을 자동화하는 것입니다.
의사 결정
이제 이 모든 정보를 수집하는 프로세스를 거쳤으므로 관련자와 협력하여 지정된 시나리오에 가장 적합한 옵션을 결정할 수 있습니다. 사용할 방법론 및 기술을 결정할 때 비즈니스 이해 관계자뿐만 아니라 기술 이해 관계자와 협력하는 것이 중요합니다. 이 협업은 비즈니스가 최소한의 가동 중지 시간 마이그레이션을 추진하는 상황을 방지하는 데 도움이 되며, 기술 팀은 인력, 리소스 또는 기술 제약 조건으로 인해 제공할 수 있는 위치에 있지 않습니다.
여기서 중요한 것은 기대치를 관리하고 개방적이고 정직한 대화 상자를 갖는 것입니다. 또한 데이터베이스 마이그레이션을 제공하는 기술 팀의 송금 외부에 있는 유효성 검사 작업의 소유권을 비즈니스에서 가져오는 것이 중요합니다. 이 유효성 검사에는 데이터 일관성 및 유효성 검사 및 사용자 환경 테스트가 포함될 수 있습니다.