애플리케이션 마이그레이션
온-프레미스에서 Azure로 데이터베이스를 마이그레이션한 후에는 새 위치에서 PostgreSQL에 액세스할 수 있도록 기존 애플리케이션을 업데이트해야 합니다.
원본 온-프레미스 서버와 데이터베이스에는 사용자와 연결된 권한, 수행할 수 있는 작업 및 이러한 작업을 수행하는 개체를 정의하는 역할이 포함됩니다. Azure Database for PostgreSQL은 온-프레미스에서 실행되는 PostgreSQL과 동일한 인증 및 권한 부여 메커니즘을 사용합니다.
이 단원에서는 새로 마이그레이션한 Azure Database for PostgreSQL에 연결하기 위해 애플리케이션에서 수행해야 하는 업데이트를 살펴보겠습니다.
수동으로 사용자 역할 생성
Azure Database Migration Service를 사용하여 Azure Database for PostgreSQL에 PostgreSQL 데이터베이스를 전송할 때 역할 및 역할 할당은 복사되지 않습니다. 대상 데이터베이스에 있는 테이블의 관리자 및 사용자에 필요한 역할 및 사용자 계정을 수동으로 다시 만들어야 합니다. 이 작업을 수행하려면 psql 또는 pgAdmin 유틸리티를 사용합니다. CREATE ROLE 명령을 실행합니다. GRANT 명령을 사용하여 필요한 권한을 역할에 할당합니다. 예를 들면 다음과 같습니다.
CREATE ROLE myuseraccount WITH LOGIN NOSUPERUSER CREATEDB PASSWORD 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuseraccount;
참고
bash 프롬프트에서 createuser 명령을 사용하여 PostgreSQL 역할도 생성합니다.
온-프레미스 데이터베이스의 기존 역할을 보려면 다음 SQL 문을 실행합니다.
SELECT rolname
FROM pg_roles;
psql 유틸리티의 \du 명령을 사용하여 역할에 할당된 권한을 표시할 수 있습니다.
List of roles
Role name | Attributes | Member of
---------------+------------------------------------------------------------+-----------
azureuser | Superuser, Create DB | {}
myuseraccount | Create DB | {}
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
참고
Azure Database for PostgreSQL은 자체 역할을 추가합니다. 이 역할에는 서비스를 만들 때 지정한 azure_pg_admin, azure_superuser 및 관리자가 포함됩니다. 관리 계정을 사용하여 로그인하지만 다른 두 역할은 Azure에서 사용하도록 예약되어 있으므로 사용하지 않아야 합니다.
애플리케이션 다시 구성
Azure Database for PostgreSQL에 연결하기 위해 애플리케이션을 다시 구성하는 프로세스가 간단하기는 하지만 그러나 마이그레이션 애플리케이션의 전략을 결정하는 것이 더 중요합니다.
PostgreSQL 애플리케이션을 다시 구성할 때 고려할 사항
회사 환경에서는 동일한 PostgreSQL 데이터베이스에 대해 실행 중인 애플리케이션이 많을 수 있습니다. 이러한 애플리케이션을 실행하는 사용자도 매우 많을 수 있습니다. 기존 시스템에서 Azure Database for PostgreSQL로 전환하는 경우 시스템이 계속 작동하고, 사용자가 작업을 계속 수행할 수 있으며, 중요 비즈니스용 작업이 계속 진행되도록 보장하려고 합니다. 모듈 1, 단원 2, 마이그레이션 고려 사항에는 일반적인 용어로 이러한 문제의 많은 부분이 설명되어 있습니다. PostgreSQL 데이터베이스를 Azure로 마이그레이션하는 경우 다음과 같은 몇 가지 사항에 주의해야 합니다.
- 오프라인 마이그레이션을 수행하는 경우 원래 PostgreSQL 데이터베이스와 Azure에서 실행되는 새 데이터베이스의 데이터는 이전 데이터베이스를 계속 사용하고 있어도 빠르게 분기할 수 있습니다. 오프라인 마이그레이션은 잠시 동안 시스템을 완전히 작동하지 않도록 하는 경우에 적합합니다. 시스템을 다시 시작하기 전에 모든 애플리케이션을 새 시스템으로 전환하세요. 이 방법은 중요 비즈니스용 시스템에는 사용이 불가능할 수 있습니다. Azure 가상 머신에서 실행되는 PostgreSQL로 마이그레이션하는 경우 온-프레미스 시스템과 Azure에서 실행되는 시스템 간에 PostgreSQL 복제를 구성합니다. 기본 PostgreSQL 복제는 한 방향으로만 작동하지만 PostgreSQL 서버 간의 양방향 복제를 지원하는 타사 솔루션을 사용할 수 있습니다. 이 솔루션은 Azure Database for PostgreSQL에서 작동하지 않습니다.
- 온라인 마이그레이션을 수행하는 경우 Azure Database for PostgreSQL 서비스에서는 온-프레미스 데이터베이스로부터 Azure에서 실행되는 데이터베이스로 복제가 수행되도록 설정합니다. 초기 데이터 전송 후 복제를 사용하면 온-프레미스 데이터베이스의 변경 내용이 Azure의 데이터베이스로 복사되도록 하지만 그 반대 방향으로는 변경 내용이 복사되지 않도록 합니다.
두 경우 다 실수로 덮어써서 라이브 데이터를 손실하는 일이 없도록 해야 합니다. 예를 들어 이 온라인 시나리오의 경우 Azure Database for PostgreSQL에서 실행되는 데이터베이스에 연결된 애플리케이션은 온-프레미스 데이터베이스를 계속 사용하는 애플리케이션에 의해 변경 내용이 무조건 덮어쓰일 수 있습니다. 이 점을 염두에 두고 다음 방법을 고려해야 합니다.
- 워크로드 유형을 기반으로 애플리케이션을 마이그레이션합니다. 읽기 전용 데이터에 액세스하는 애플리케이션은 Azure Database for PostgreSQL에서 실행되는 데이터베이스로 안전하게 이동할 수 있으며 온-프레미스 데이터베이스를 계속 사용하는 애플리케이션에 의해 변경된 내용을 모두 볼 수 있습니다. 읽기 전용 애플리케이션에 완전히 최신의 데이터가 필요하지 않은 경우 반대 전략을 채택할 수도 있습니다.
- 워크로드 유형을 기반으로 사용자를 마이그레이션합니다. 이 전략은 보고서만 생성하는 사용자와 데이터를 수정하는 사용자가 있을 수 있다는 점을 제외하고는 이전 방법과 유사합니다. 사용자의 요구 사항에 따라 적절한 데이터베이스에 연결하도록 동일한 애플리케이션을 구성할 수 있습니다.
- 사용하는 데이터 세트를 기반으로 애플리케이션을 마이그레이션합니다. 다양한 애플리케이션에서 다양한 하위 세트의 데이터를 활용하는 경우 서로 독립적으로 이러한 애플리케이션을 마이그레이션할 수 있습니다.
애플리케이션 다시 구성
애플리케이션을 다시 구성하려면 새 데이터베이스에서 해당 애플리케이션을 가리킵니다. 잘 작성된 애플리케이션은 대부분 연결 논리를 격리해야 합니다. 이것이 코드에서 변경이 필요한 유일한 부분입니다. 많은 경우 연결 정보를 구성 정보로 저장할 수 있기 때문에 해당 정보를 업데이트하기만 하면 됩니다.
Azure Portal에서 Azure Database for PostgreSQL 서비스에 대한 연결 정보는 서비스의 연결 문자열 페이지에 있습니다. Azure에서는 여러 일반적인 프로그래밍 언어 및 프레임워크에 대한 정보를 제공합니다.
네트워크 포트 열기
이 모듈의 1단원에 설명된 것처럼 Azure Database for PostgreSQL은 보호되는 서비스로, 방화벽 뒤에서 실행됩니다. 클라이언트는 해당 IP 주소가 이 서비스에서 인식되지 않는 한 연결할 수 없습니다. 데이터베이스에 연결해야 하는 애플리케이션을 실행하는 클라이언트의 IP 주소 또는 주소 블록 범위를 추가해야 합니다.
애플리케이션 테스트 및 확인
애플리케이션 및 사용자를 새 데이터베이스로 전환하기 전에 모든 항목을 올바르게 구성했는지 확인하는 것이 중요합니다.
애플리케이션을 “시험 실행”하여 시작하고 각 역할로 연결하여 제대로 기능을 사용할 수 있는지 확인합니다.
그런 다음 “내구성 테스트”를 수행하여 일정 기간 동안 동시에 대표 워크로드를 실행하는 일반적인 사용자 수를 모방합니다. 시스템을 모니터링하고 Azure Database for PostgreSQL 서비스에 충분한 리소스를 할당했는지 확인합니다.
이제 사용자에게 시스템을 롤아웃할 수 있습니다. 소수의 사용자 하위 집합을 불시에 시스템으로 전송하는 일종의 “카나리아 테스트”를 구현하면 유용할 수 있습니다. 새 데이터베이스에 대한 사용자의 경험이 동일한지, 더 좋은지, 더 나쁜지에 대한 편견 없는 의견을 얻을 수 있습니다.