마이그레이션 단계 및 고려 사항
성공적인 마이그레이션은 여러 단계에 걸쳐 고려 사항의 균형을 맞춥니다.
마이그레이션 단계
마이그레이션은 여러 단계로 진행됩니다. 먼저, 마이그레이션 범위를 계획합니다. 즉, 데이터베이스 리소스 검색 및 평가, 가동 중지 시간과 같은 비즈니스 요구 사항, 마이그레이션 실패 시 대체 계획을 수립합니다. 그런 다음 적절한 리소스를 프로비전하고 원본 환경과 대상 환경 간의 연결을 설정하여 마이그레이션을 준비합니다. 마이그레이션 방식이 설정되고 리소스가 준비된 후에는 일반적으로 프로덕션 마이그레이션 전에 문제를 식별하기 위해 스테이징 환경에서 시험 실행을 수행하는 것이 좋습니다. 마지막으로 최종 마이그레이션을 수행하고 진행 중인 진행률과 성공적인 완료를 유효성 검사합니다.
이 모듈에서는 준비(2) 및 최종 마이그레이션(4, 5) 단계에 중점을 둡니다.
마이그레이션 고려 사항
애플리케이션 가동 중지 시간, 버전 호환성, 네트워킹 및 보안, 성능, 비용, 비즈니스 연속성에 대한 요구 사항을 평가해야 합니다.
애플리케이션 가동 중지 시간
가장 먼저 고려해야 할 사항 중 하나는 비즈니스 시나리오에서 수용할 수 있는 가동 중지 시간입니다. 답변은 사용 가능한 마이그레이션 옵션을 강력하게 제한합니다.
가장 좋은 가동 중지 시간은 사용자가 알아차리지 못하는 시간입니다. 실제로 마이그레이션은 복잡한 절차이며 이 모듈의 고려 사항에 대한 결정에 따라 필요한 가동 중지 시간이 결정됩니다. 단점에는 가용성과 마이그레이션 비용 및 위험이 포함됩니다. 가동 중지 시간을 몇 분 또는 몇 초로 줄이는 데 따른 복잡성으로 인해 가정을 테스트하고 허용 가능한 마이그레이션 가동 중지 시간을 결정해야 합니다.
오프라인 마이그레이션
오프라인 마이그레이션의 경우 데이터베이스를 이동하려면 애플리케이션을 종료해야 합니다. 이렇게 하면 마이그레이션 중에 데이터가 변경되지 않습니다. 그러나 이 방식을 사용하려면 데이터 내보내기를 마무리하기 위해 데이터베이스를 종료해야 합니다. 최소한 데이터를 전송하는 데 걸리는 시간만큼 가동 중지 시간이 발생합니다. 오프라인 마이그레이션에는 다음이 포함됩니다.
- 원본 데이터베이스에서 모든 앱의 연결을 끊습니다.
- 원본 데이터베이스의 콘텐츠를 내보내는 중입니다.
- 원본 데이터를 대상 데이터베이스로 가져옵니다.
- 가져오기가 완료된 후 대상 데이터베이스에 애플리케이션을 다시 연결합니다.
일부 애플리케이션에는 트래픽이 적은 기간 동안 유지 관리 기간이 예약되어 있습니다. 지금은 오프라인 마이그레이션을 수행하기에 좋은 시기입니다.
증분 오프라인 마이그레이션은 애플리케이션을 오프라인으로 전환하기 전에 대량의 데이터를 이동하여 가동 중지 시간을 줄입니다. 먼저 전체 데이터베이스 백업을 마이그레이션합니다. 그런 다음 이전 마이그레이션 이후 추가된 데이터베이스에 변경 내용을 마이그레이션합니다. 이러한 새로운 변경 내용을 마이그레이션하는 데 필요한 시간이 허용 가능한 가동 중지 시간 내에 맞으면 애플리케이션을 오프라인으로 전환하여 데이터를 동결하고 마이그레이션을 완료합니다. 단일 마이그레이션 증분만으로도 가동 중지 시간을 10배 이상 줄일 수 있으며, 특히 수년간의 기록이 있는 데이터베이스의 경우 더욱 그렇습니다. 크고 사용량이 많은 데이터베이스의 경우 허용 가능한 가동 중지 시간에 도달하려면 여러 증분을 마이그레이션해야 할 수도 있습니다.
온라인 마이그레이션
온라인 마이그레이션을 사용하면 마이그레이션 중에 원본 서버에서 대상 서버로 변경 사항을 복제한 다음 복제가 완전히 동기화되면 대상 서버로 전환하여 가동 중지 시간의 필요성을 크게 줄이거나 없앨 수 있습니다.
경우에 따라 가동 중지 시간은 바람직하지 않거나 용납할 수 없는 경우도 있습니다. 이 경우 애플리케이션을 꺼서 데이터베이스 상태를 "고정"하는 것은 불가능합니다. 대신, 원본 데이터베이스는 일반 작업 중에 대상 데이터베이스에 복제됩니다. 대상이 원본을 완전히 따라잡으면 애플리케이션은 대상 데이터베이스로 전환됩니다.
온라인 마이그레이션을 위해서는 다음이 필요합니다.
- 원본 데이터베이스를 대상 데이터베이스로 복제를 시작합니다.
- 대상 데이터베이스가 catch되면 애플리케이션을 일시 중지하거나 읽기 전용 모드를 사용하도록 설정하여 쓰기가 실패하도록 강제하여 원본 데이터베이스를 고정합니다.
- 대상 데이터베이스가 변경 내용을 100% 따라잡으면 대상에서 복제를 해제합니다.
- 모든 클라이언트를 대상 데이터베이스로 리디렉션하고 작업을 다시 시작합니다.
- 레거시 원본 데이터베이스를 종료합니다.
온라인 및 오프라인 마이그레이션 비교
오프라인 마이그레이션에는 가동 중지 시간이 필요하지만 앞서 설명한 증분 마이그레이션 기술은 가동 중지 시간을 크게 줄여줍니다. 여러 증분을 통해 최종 마이그레이션을 하루 분량의 데이터 이하로 줄일 수 있습니다. Azure DMS와 같은 자동화된 서비스는 일련의 소규모 마이그레이션을 수행하여 가동 중지 시간을 최소화합니다. 네트워크 설정으로 인해 자동화가 불가능한 경우 증분 오프라인 마이그레이션을 수동으로 수행할 수도 있습니다.
온라인 마이그레이션은 데이터베이스 및 애플리케이션 팀 전체의 섬세한 작업을 조정합니다. 마이그레이션 중 데이터 손실을 방지하려면 쓰기 실패에 적절하게 대응하도록 클라이언트 애플리케이션을 도구화해야 합니다. 클라이언트는 또한 사용자 환경을 중단하지 않고 새로운 데이터베이스 서버에 대한 연결을 지원해야 합니다. 이 애플리케이션 도구가 아직 존재하지 않는 경우 빌드하는 데 비용이 많이 들 수 있습니다.
버전 호환성
대부분의 애플리케이션 작업은 MySQL 업그레이드와 호환됩니다. 그러나 어떤 경우에는 애플리케이션 구성 요소나 데이터베이스 사용이 특정 MySQL 버전에서만 작동할 수도 있습니다.
모든 애플리케이션 구성 요소가 대상 데이터베이스 버전과 호환되는지 확인합니다. 데이터베이스를 재배치하거나 다시 구성하는 마이그레이션과 버전 업그레이드를 분리하는 것이 좋습니다. 예를 들어, 온-프레미스 MySQL 5.7에서 MySQL 8.0을 실행하는 Azure Database for MySQL 유연한 서버로 마이그레이션하는 경우 온-프레미스에서 MySQL 5.7을 실행하는 Azure Database for MySQL 유연한 서버로 마이그레이션한 다음 5.7에서 8.0으로 업그레이드하는 것이 좋습니다.
네트워킹 및 보안
데이터베이스 마이그레이션을 위해서는 원본 데이터베이스에서 대상 데이터베이스로 데이터를 전송해야 합니다. 이러한 일이 발생하는 방식과 속도는 주로 두 네트워크 간의 연결에 따라 달라집니다. 원본에서 대상으로 라이브 연결을 설정할 수 없는 경우 중간 워크스테이션이나 서버 등을 통해 실제 데이터 파일을 다른 방법으로 전송해야 합니다. 이 경우 각 시스템에 스냅샷을 저장할 수 있는 충분한 디스크 공간이 있는지 확인합니다.
마이그레이션 중에 보안 요구 사항을 고려하는 것도 중요합니다. 원본 및 대상 데이터베이스에 대한 적절한 인증 및 권한이 필요합니다. 마이그레이션 단계의 일부 또는 전체를 수행하기 위해 서비스 계정을 만든 다음 완료 시 해당 액세스 권한을 제거할 수도 있습니다.
원본 데이터베이스가 온-프레미스에 있든 다른 클라우드 공급자에 있든 관계없이 네트워크 설정은 일반적으로 외부 연결을 허용하지 않습니다. Azure와의 연결을 허용하도록 네트워크를 구성해야 합니다.
원본 데이터베이스가 온-프레미스이고 데이터 볼륨이 큰 경우 일반 인터넷 연결을 통해 테라바이트 단위의 데이터를 이동하는 속도가 비현실적으로 느려질 수 있습니다. 이 시나리오에서는 네트워크와 Azure 간에 Azure ExpressRoute 연결을 설정하는 것이 좋습니다.
ExpressRoute를 사용하더라도 연결이 다른 트래픽에도 제공될 수 있으며 두 트래픽이 서로 간섭할 수 있습니다. 경합에 따라 기존 애플리케이션과 마이그레이션 프로세스에 대한 성능 저하가 심각할 수 있습니다.
성능
데이터베이스 마이그레이션은 인프라 크기를 조정하여 용량을 늘릴 수 있는 좋은 기회입니다. CPU, RAM 또는 I/O 리소스를 늘리면 데이터베이스 사용량이 향상될 수 있습니다.
대상 서버를 프로비전하기 전에 현재 데이터베이스 사용량을 고려합니다. 예측 증가 및 SLA와 함께 CPU 사용량과 같은 성능 메트릭을 모니터링하여 더 큰 컴퓨팅 크기를 할당해야 하는지 결정합니다. 반대로, 용량이 과도하게 할당되어 축소하면 비용이 절약될 수 있습니다.
비용
Azure로 마이그레이션하면 투명한 가격 책정의 이점을 누릴 수 있습니다. Azure 가격 계산기를 사용하면 선택한 SKU와 중복성, 고가용성 등의 기타 매개 변수를 사용하여 계획 중에 마이그레이션 후 비용을 예상할 수 있습니다. 또한 계산기를 사용하여 가용성과 비용 등의 장단점을 알릴 수도 있습니다.
비즈니스 연속성
데이터베이스 마이그레이션은 비즈니스 연속성 메트릭과 목표를 검토하기에 좋은 시기입니다. 백업 보존 정책을 변경하거나 지역 중복 백업 또는 고가용성으로 전환하는 것이 적절할 수 있습니다. 과거 작동 시간과 SLA 및 중단 복구 시간을 고려합니다. 마이그레이션은 또한 재해 복구 계획을 알릴 수 있는 실제 데이터 파일에서 새 데이터베이스를 구축하는 실제 사례를 제공합니다.