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

  • 8분

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

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

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

수동으로 사용자 역할 만들기

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

애플리케이션 다시 구성

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

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

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

네트워크 포트 열기

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

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

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

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

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

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