애플리케이션 마이그레이션
온-프레미스에서 Azure로 데이터베이스를 마이그레이션한 후에는 새 위치에서 MySQL에 액세스할 수 있도록 기존 애플리케이션을 업데이트해야 합니다.
원본 온-프레미스 서버와 데이터베이스에는 사용자와 연결된 권한, 수행할 수 있는 작업 및 이러한 작업을 수행하는 개체를 정의하는 역할이 포함됩니다. Azure Database for MySQL은 온-프레미스에서 실행되는 PostgreSQL과 동일한 인증 및 권한 부여 메커니즘을 사용합니다.
이 단원에서는 새로 마이그레이션한 Azure Database for MySQL에 연결하기 위해 애플리케이션에서 수행해야 하는 업데이트를 살펴보겠습니다.
수동으로 사용자 생성
원본 온-프레미스 서버와 데이터베이스에는 사용자, 수행하는 작업 및 이러한 작업을 수행하는 대상 개체가 포함됩니다. Azure Database for MySQL은 온-프레미스에서 실행되는 MySQL과 동일한 인증 및 권한 부여 메커니즘을 사용합니다.
Azure Database Migration Service를 사용하여 Azure Database for MySQL에 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에서 실행되는 데이터베이스로 안전하게 이동할 수 있으며 온-프레미스 데이터베이스를 계속 사용하는 애플리케이션에 의해 변경된 내용을 모두 볼 수 있습니다. 읽기 전용 애플리케이션에 완전히 최신의 데이터가 필요하지 않은 경우 반대 전략을 채택할 수도 있습니다.
- 워크로드 유형을 기반으로 사용자를 마이그레이션합니다. 이 전략은 보고서만 생성하는 사용자와 데이터를 수정하는 사용자가 있을 수 있다는 점을 제외하고는 이전 방법과 유사합니다. 사용자의 요구 사항에 따라 적절한 데이터베이스에 연결하도록 동일한 애플리케이션을 구성할 수 있습니다.
- 사용하는 데이터 세트를 기반으로 애플리케이션을 마이그레이션합니다. 다양한 애플리케이션에서 다양한 하위 집합의 데이터를 사용하는 경우 서로 독립적으로 이러한 애플리케이션을 마이그레이션할 수 있습니다.
애플리케이션 다시 구성
애플리케이션을 다시 구성하려면 새 데이터베이스에서 해당 애플리케이션을 가리킵니다. 잘 작성된 애플리케이션은 대부분 연결 논리를 격리해야 합니다. 이것이 코드에서 변경이 필요한 유일한 부분입니다. 많은 경우 연결 정보를 구성 정보로 저장할 수 있기 때문에 해당 정보를 업데이트하기만 하면 됩니다.
Azure Portal에서 Azure Database for MySQL 서비스에 대한 연결 정보는 Azure Database for MySQL 서비스의 연결 문자열 페이지에 있습니다. Azure에서는 여러 일반적인 프로그래밍 언어 및 프레임워크에 대한 정보를 제공합니다.
네트워크 포트 열기
이 모듈의 1단원에 설명된 것처럼 Azure Database for MySQL은 보호되는 서비스로, 방화벽 뒤에서 실행됩니다. 클라이언트는 해당 IP 주소가 이 서비스에서 인식되지 않는 한 연결할 수 없습니다. 데이터베이스에 연결해야 하는 애플리케이션을 실행하는 클라이언트의 IP 주소 또는 주소 블록 범위를 추가해야 합니다.
애플리케이션 테스트 및 확인
애플리케이션 및 사용자를 새 데이터베이스로 전환하기 전에 모든 항목을 올바르게 구성했는지 확인하는 것이 중요합니다.
애플리케이션을 “시험 실행”하여 시작하고 각 역할로 연결하여 제대로 기능을 사용할 수 있는지 확인합니다.
그런 다음, “내구성 테스트”를 수행하여 일정 기간 동안 동시에 일반적인 워크로드를 실행하는 사용자 수를 모방합니다. 시스템을 모니터링하고 Azure Database for MySQL 서비스에 충분한 리소스를 할당했는지 확인합니다.
이제 사용자에게 시스템을 배포할 수 있습니다. 소수의 사용자 하위 집합을 불시에 시스템으로 전송하는 일종의 “카나리아 테스트”를 구현하면 유용할 수 있습니다. 새 데이터베이스에 대한 사용자의 경험이 동일한지, 더 좋은지, 더 나쁜지에 대한 편견 없는 의견을 얻을 수 있습니다.