애플리케이션 마이그레이션

  • 6분

온-프레미스에서 Azure로 데이터베이스를 마이그레이션한 후에는 새 위치에서 MySQL에 액세스할 수 있도록 기존 애플리케이션을 업데이트해야 합니다.

원래 온-프레미스 서버 및 데이터베이스에는 사용자와 연결된 권한, 수행할 수 있는 작업 및 이러한 작업을 수행하는 개체를 정의하는 역할이 포함됩니다. Azure Database for MySQL은 온-프레미스에서 실행되는 PostgreSQL과 동일한 인증 및 권한 부여 메커니즘을 사용합니다.

이 단원에서는 새로 마이그레이션된 Azure Database for MySQL에 연결하기 위해 애플리케이션에 대해 수행해야 하는 업데이트를 살펴봅니다.

수동으로 사용자 만들기

원래 온-프레미스 서버 및 데이터베이스에는 사용자, 사용자가 수행하는 작업 및 이러한 작업을 수행하는 개체가 포함됩니다. Azure Database for MySQL은 온-프레미스에서 실행되는 MySQL과 동일한 인증 및 권한 부여 메커니즘을 사용합니다.

Azure Database Migration Service를 사용하여 MySQL 데이터베이스를 Azure Database for MySQL로 전송하는 경우 사용자는 복사되지 않습니다. 대상 데이터베이스에 있는 테이블의 관리자 및 사용자에 필요한 사용자 계정을 수동으로 다시 만들어야 합니다. 이러한 작업을 수행하려면 SQL 언어 또는 MySQL Workbench와 같은 유틸리티를 사용합니다. CREATE USER 명령을 실행합니다. GRANT 명령을 사용하여 사용자에게 필요한 권한을 할당합니다. 다음은 그 예입니다.

CREATE USER 'myuseraccount'@'%' IDENTIFIED BY 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE [Database Name].* TO myuseraccount;
FLUSH PRIVILEGES;

온-프레미스 데이터베이스에서 기존 부여를 보려면 다음 SQL 문을 실행합니다.

USE [Database Name];

SHOW GRANTS FOR 'myuseraccount'@'%';;

애플리케이션 다시 구성

Azure Database for MySQL에 연결하도록 애플리케이션을 다시 구성하는 것은 간단한 프로세스입니다. 그러나 애플리케이션 마이그레이션 전략을 개발하는 것이 중요합니다.

MySQL 애플리케이션을 다시 구성할 때 고려 사항

회사 환경에서는 동일한 MySQL 데이터베이스에 대해 실행되는 많은 애플리케이션이 있을 수 있습니다. 이러한 애플리케이션을 실행하는 사용자가 많을 수 있습니다. 기존 시스템에서 Azure Database for MySQL로 전환하면 시스템이 계속 작동하며 사용자가 작업을 계속할 수 있으며 중요 비즈니스용 작업이 계속 작동합니다. 모듈 1, 2단원, 마이그레이션대한 고려 사항은 일반적인 측면에서 많은 문제에 대해 설명했습니다.

MySQL 데이터베이스를 Azure로 마이그레이션할 때 고려해야 할 몇 가지 세부 사항이 있습니다.

  • 오프라인 마이그레이션을 수행하는 경우 이전 데이터베이스를 계속 사용하는 경우 원래 MySQL 데이터베이스의 데이터와 Azure에서 실행되는 새 데이터베이스가 빠르게 다각화될 수 있습니다. 오프라인 마이그레이션은 잠시 동안 시스템을 완전히 작동이 중단한 다음 다시 시작하기 전에 모든 애플리케이션을 새 시스템으로 전환할 때 적합합니다. 이 방법은 중요 비즈니스용 시스템에서는 불가능할 수 있습니다. Azure 가상 머신에서 실행되는 MySQL로 마이그레이션하는 경우 온-프레미스 시스템과 Azure에서 실행되는 시스템 간에 MySQL 복제를 구성할 수 있습니다. 네이티브 MySQL 복제는 한 방향으로만 작동하지만 MySQL 서버 간의 양방향 복제를 지원하는 타사 솔루션을 사용할 수 있습니다. 이러한 솔루션은 Azure Database for MySQL에서 작동하지 않습니다.
  • 온라인 마이그레이션을 수행하는 경우 Azure Database for MySQL 서비스는 온-프레미스 데이터베이스에서 Azure에서 실행되는 데이터베이스로 복제를 설정합니다. 초기 데이터 전송 후 복제를 통해 온-프레미스 데이터베이스의 모든 변경 내용이 Azure의 데이터베이스에 복사되지만 다른 방법으로는 복사되지 않습니다.

두 경우 모두 실수로 덮어쓰기를 통해 라이브 데이터가 손실되지 않도록 해야 합니다. 예를 들어 온라인 시나리오에서 Azure Database for MySQL에서 실행되는 데이터베이스에 연결된 애플리케이션은 온-프레미스 데이터베이스를 사용하는 애플리케이션에서 변경 내용을 맹목적으로 덮어쓸 수 있습니다. 따라서 다음 방법을 고려해야 합니다.

  • 워크로드 유형에 따라 애플리케이션을 마이그레이션합니다. 읽기 전용 데이터에 액세스하는 애플리케이션은 Azure Database for MySQL에서 실행되는 데이터베이스로 안전하게 이동할 수 있으며 온-프레미스 데이터베이스를 사용하는 애플리케이션에서 변경한 모든 내용을 볼 수 있습니다. 읽기 전용 애플리케이션에 완전히 up-to데이터 데이터가 필요하지 않은 경우 반대 전략을 채택할 수도 있습니다.
  • 워크로드 유형에 따라 사용자를 마이그레이션합니다. 이 전략은 다른 사용자가 데이터를 수정하는 동안 보고서만 생성하는 사용자가 있을 수 있다는 점을 제외하고 이전 전략과 비슷합니다. 사용자의 요구 사항에 따라 적절한 데이터베이스에 연결하도록 동일한 애플리케이션을 구성할 수 있습니다.
  • 사용하는 데이터 세트를 기반으로 애플리케이션을 마이그레이션합니다. 다른 애플리케이션에서 서로 다른 데이터 하위 집합을 사용하는 경우 이러한 애플리케이션을 서로 독립적으로 마이그레이션할 수 있습니다.

애플리케이션 다시 구성

애플리케이션을 다시 구성하려면 새 데이터베이스를 가리킵니다. 대부분의 잘 작성된 애플리케이션은 연결 논리를 격리해야 합니다. 이는 변경이 필요한 코드의 유일한 부분이어야 합니다. 대부분의 경우 연결 정보가 구성 정보로 저장될 수 있으므로 해당 정보를 업데이트하기만 하면 됩니다.

Azure Portal의 Azure Database for MySQL 서비스에 대한 연결 정보는 Azure Database for MySQL 서비스의 연결 문자열 페이지에서 찾을 수 있습니다. Azure는 많은 일반적인 프로그래밍 언어 및 프레임워크에 대한 정보를 제공합니다.

Azure Portal Azure Database for MySQL 항목에 대한 연결 문자열 페이지를 보여 주는 이미지

네트워크 포트 열기

이 모듈의 1단원에서 설명한 것처럼 Azure Database for MySQL은 방화벽 뒤에서 실행되는 보호된 서비스입니다. 서비스에서 IP 주소를 인식하지 않는 한 클라이언트는 연결할 수 없습니다. 데이터베이스에 연결해야 하는 애플리케이션을 실행하는 클라이언트의 경우 IP 주소 또는 주소 블록 범위를 추가해야 합니다.

애플리케이션 테스트 및 확인

애플리케이션 및 사용자를 새 데이터베이스로 전환하기 전에 모든 항목을 올바르게 구성했는지 확인해야 합니다.

"드라이 러닝" 애플리케이션으로 시작하고 각 역할로 연결하여 올바른 기능을 사용할 수 있는지 확인합니다.

다음으로, "테스트 흡수"를 수행하여 일정 기간 동안 일반적인 워크로드를 동시에 실행하는 사용자 수를 모방합니다. 시스템을 모니터링하고 Azure Database for MySQL 서비스에 충분한 리소스를 할당했는지 확인합니다.

이제 사용자에게 시스템을 롤아웃할 수 있습니다. 일부 형태의 "카나리아 테스트"를 구현하는 것이 도움이 될 수 있습니다. 여기서 사용자의 작은 하위 집합은 인식하지 못하고 시스템으로 전송됩니다. 이렇게 하면 사용자가 새 데이터베이스와 동일하거나, 더 좋거나, 더 나쁜 환경을 가지고 있는지 여부에 대한 편견 없는 의견을 얻을 수 있습니다.