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