Azure App Service, Traffic Manager 및 Azure Database for MySQL을 사용하여 Linux 애플리케이션 리팩터링

이 문서에서는 가상의 회사인 Contoso가 GitHub 통합 및 Azure Database for MySQL을 사용하여 온-프레미스에서 Azure로 마이그레이션하는 2계층 LAMP 기반 애플리케이션을 리팩터링하는 방법을 보여 줍니다.

이 예에서 사용하는 서비스 데스크 애플리케이션인 osTicket은 오픈 소스 소프트웨어로 제공됩니다. 자체 테스트 목적으로 사용하려는 경우 GitHub의 osTicket 리포지토리에서 다운로드할 수 있습니다.

비즈니스 영향 요소

IT 리더십 팀은 비즈니스 파트너와의 긴밀한 협력을 통해 다음과 같이 기업이 달성하고자 하는 바를 잘 이해하고 있습니다.

  • 비즈니스 성장 해결. Contoso는 성장하면서 새로운 시장에 진입하고 있습니다. 고객 서비스 에이전트가 추가로 필요합니다.
  • 크기 조정. 비즈니스 확장으로 인해 Contoso가 고객 서비스 에이전트를 더 많이 추가할 수 있도록 솔루션을 구축해야 합니다.
  • 복원력 향상. 과거에는 시스템 문제가 내부 사용자에게만 영향을 미쳤습니다. 새 비즈니스 모델을 사용하면 외부 사용자가 영향을 받게 되며 Contoso는 항상 애플리케이션을 실행해야 합니다.

마이그레이션 목표

최상의 마이그레이션 방법을 결정하기 위해 Contoso 클라우드 팀은 이 마이그레이션에 대한 목표를 정했습니다.

  • 현재 온-프레미스 용량 및 성능을 능가하도록 애플리케이션을 확장해야 합니다. Contoso는 Azure의 주문형 크기 조정 기능을 활용하기 위해 애플리케이션을 옮기고 있습니다.
  • Contoso는 애플리케이션 코드 기반을 지속적인 업데이트 파이프라인으로 이동하려고 합니다. 애플리케이션 변경 내용이 GitHub에 푸시될 때 Contoso는 운영 담당자의 작업 없이 이러한 변경 내용을 배포하려고 합니다.
  • 애플리케이션은 확장 및 장애 조치(failover) 기능과 함께 복원력이 있어야 합니다. Contoso는 두 개의 서로 다른 Azure 지역에 애플리케이션을 배포하고 자동으로 확장되도록 설정하려고 합니다.
  • Contoso는 애플리케이션이 클라우드로 이동된 후 데이터베이스 관리 작업을 최소화하려고 합니다.

솔루션 디자인

해당 목표 및 요구 사항을 고정한 후 Contoso는 배포 솔루션을 디자인 및 검토하고, 마이그레이션에 사용할 Azure 서비스를 포함한 마이그레이션 프로세스를 식별합니다.

현재 아키텍처

  • 애플리케이션은 두 개의 VM(가상 머신)(OSTICKETWEBOSTICKETMYSQL)에 걸쳐 계층화됩니다.
  • VM은 VMware ESXi 호스트 contosohost1.contoso.com(버전 6.5)에 있습니다.
  • VMware 환경은 VM에서 실행되는 vCenter Server 6.5(vcenter.contoso.com)를 통해 관리됩니다.
  • Contoso에는 온-프레미스 데이터 센터(contoso-datacenter)와 온-프레미스 도메인 컨트롤러(contosodc1)가 있습니다.

현재 아키텍처의 다이어그램

제안된 아키텍처

다음은 제안된 아키텍처입니다.

  • OSTICKETWEB의 웹 계층 애플리케이션은 두 Azure 지역에서 Azure App Service 웹앱을 빌드하여 마이그레이션됩니다. Contoso 팀은 PHP 7.0 Docker 컨테이너를 사용하여 Linux용 Azure App Service를 구현합니다.
  • 애플리케이션 코드가 GitHub로 이동되고 Azure App Service 웹앱이 GitHub를 통해 지속적으로 업데이트되도록 구성됩니다.
  • Azure App Service는 주 지역(East US 2)과 보조 지역(Central US) 모두에 배포됩니다.
  • Azure Traffic Manager는 두 지역의 두 웹앱 앞에 설정됩니다.
  • Traffic Manager는 East US 2를 통해 트래픽을 강제 실행하도록 우선 순위 모드로 구성됩니다.
  • East US 2의 Azure 앱 서버가 오프라인이 되면 사용자는 Central US의 장애 조치(failover)된 애플리케이션에 액세스할 수 있습니다.
  • 애플리케이션 데이터베이스는 Azure Database Migration Service를 사용하여 Azure Database for MySQL 서비스로 마이그레이션됩니다. 온-프레미스 데이터베이스가 로컬에 백업되고 Azure Database for MySQL에 직접 복원됩니다.
  • 데이터베이스는 프로덕션 네트워크(VNET-PROD-EUS2)의 데이터베이스 서브넷(PROD-DB-EUS2)에 있는 주 지역(East US 2)에 있습니다.
  • 프로덕션 워크로드를 마이그레이션하기 때문에 애플리케이션의 Azure 리소스는 프로덕션 리소스 그룹 ContosoRG에 있습니다.
  • Traffic Manager 리소스는 Contoso의 인프라 리소스 그룹 ContosoInfraRG에 배포됩니다.
  • 마이그레이션이 완료되면 Contoso 데이터 센터의 온-프레미스 VM은 서비스 해제됩니다.

시나리오 아키텍처의 다이어그램

마이그레이션 프로세스

Contoso는 다음과 같이 마이그레이션 프로세스를 완료합니다.

  1. 첫 번째 단계로 Contoso 관리자는 Azure App Service 프로비저닝, Traffic Manager 설정 및 Azure Database for MySQL 인스턴스 프로비저닝을 포함하여 Azure 인프라를 설정합니다.
  2. Azure 인프라를 준비한 후 Azure Database Migration Service를 사용하여 데이터베이스를 마이그레이션합니다.
  3. Azure에서 데이터베이스를 실행한 후 지속적인 업데이트를 통해 Azure App Service용 GitHub 프라이빗 리포지토리를 업로드하고 osTicket 애플리케이션과 함께 로드합니다.
  4. Azure Portal에서 Azure App Service를 실행하여 GitHub에서 Docker 컨테이너로 애플리케이션을 로드합니다.
  5. DNS 설정을 조정하고 애플리케이션에 대한 자동 크기 조정을 구성합니다.

Contoso 마이그레이션 프로세스의 다이어그램

Azure 서비스

서비스 Description 비용
Azure App Service 이 서비스는 웹 사이트용 Azure PaaS(서비스 제공 플랫폼)를 사용하여 애플리케이션을 실행하고 확장합니다. 인스턴스의 크기와 필요한 기능에 따라 가격이 책정됩니다. 자세히 알아보기.
Azure Traffic Manager DNS(Domain Name System)를 사용하여 사용자를 Azure 또는 외부 웹 사이트 및 서비스로 안내하는 부하 분산 장치입니다. 가격은 수신된 DNS 쿼리 수와 모니터링되는 엔드포인트 수를 기반으로 합니다. 자세히 알아보기.
Azure Database Migration Service Azure Database Migration Service를 사용하면 가동 중지 시간을 최소화하면서 여러 데이터베이스 원본에서 Azure 데이터 플랫폼으로 원활하게 마이그레이션할 수 있습니다. 지원되는 지역Database Migration Service 가격에 대해 자세히 알아보세요.
Azure Database for MySQL 데이터베이스는 오픈 소스 MySQL 데이터베이스 엔진을 기반으로 합니다. 애플리케이션 개발 및 배포를 위해 완전 관리형 엔터프라이즈급 커뮤니티 MySQL 데이터베이스를 제공합니다. 가격은 컴퓨팅, 스토리지 및 백업 요구 사항을 기반으로 합니다. 자세한 정보를 알아보세요.

사전 요구 사항

이 시나리오를 실행하려면 Contoso가 다음 필수 구성 요소를 충족해야 합니다.

요구 사항 세부 정보
Azure 구독 Contoso는 이 문서 시리즈의 앞에서 구독을 만들었습니다. Azure 구독이 아직 없는 경우 체험 계정을 만듭니다.

체험 계정을 만들면 구독 관리자로서 모든 작업을 수행할 수 있습니다.

기존 구독을 사용하고 관리자가 아닌 경우 관리자와 협력하여 소유자 또는 기여자 권한을 할당받아야 합니다.
Azure 인프라 Contoso는 마이그레이션을 위한 Azure 인프라에 설명된 대로 Azure 인프라를 설정합니다.

시나리오 단계

마이그레이션을 완료하기 위한 Contoso 계획은 다음과 같습니다.

  • 1단계: Azure App Service 프로비저닝. Contoso 관리자는 주 지역 및 보조 지역에 웹앱을 프로비전합니다.
  • 2단계: Traffic Manager 설정 라우팅 및 부하 분산 트래픽을 위해 웹앱 앞에 Traffic Manager를 설정합니다.
  • 3단계: Azure Database for MySQL 프로비저닝 Azure에서 Azure Database for MySQL 인스턴스를 프로비저닝합니다.
  • 4단계: 데이터베이스 마이그레이션 Azure Database Migration Service를 사용하여 데이터베이스를 마이그레이션합니다.
  • 5단계: GitHub 설정 애플리케이션 웹 사이트와 코드를 위한 로컬 GitHub 리포지토리를 설정합니다.
  • 6단계: 웹앱 구성 osTicket 웹 사이트로 웹앱을 구성합니다.

1단계: Azure App Service 프로비저닝

Contoso 관리자는 Azure App Service를 사용하여 두 개의 웹앱(각 지역에 하나씩)을 프로비저닝합니다.

  1. Azure Marketplace를 통해 주 지역(East US 2)에 웹앱 리소스(osticket-eus2)를 만듭니다.

  2. 리소스를 프로덕션 리소스 그룹 ContosoRG에 넣습니다.

    Linux에서 웹앱을 만들기 위한 웹앱 창의 스크린샷

  3. 주 지역에서 App Service 요금제 APP-SVP-EUS2를 만들고 표준 크기를 사용합니다.

    App Service 요금제를 만들기 위한 새 App Service 요금제 창의 스크린샷

  4. Docker 컨테이너인 PHP 7.0 런타임 스택을 사용하여 Linux OS를 선택합니다.

    Linux OS, 미국 동부 2 위치 및 PHP 7.0이 선택된 웹앱 창의 스크린샷

  5. 두 번째 웹앱인 osticket-cus미국 중부에 대한 Azure App Service 요금제를 만듭니다.

    Linux OS, 미국 중부 위치 및 PHP 7.0이 선택된 웹앱 창의 스크린샷

도움이 더 필요하세요?

2단계: Traffic Manager 설정

Contoso 관리자는 인바운드 웹 요청을 osTicket 웹 계층에서 실행 중인 웹앱으로 보내도록 Traffic Manager를 설정합니다.

  1. Azure Marketplace에서 Traffic Manager 리소스 osticket.trafficmanager.net을 만듭니다. 미국 동부 2가 주 사이트가 되도록 우선 순위 라우팅을 사용합니다. 기존 인프라 리소스 그룹 ContosoInfraRG에 리소스를 배치합니다. Traffic Manager는 전역을 대상으로 하며 특정 위치에 바인딩되지 않습니다.

    Traffic Manager 프로필 만들기 창의 스크린샷

  2. 엔드포인트로 Traffic Manager를 구성합니다. 미국 동부 2의 웹앱을 주 사이트인 osticket-eus2로 추가하고 미국 중부의 웹앱을 보조 사이트인 osticket-cus로 추가합니다.

    Traffic Manager에서 엔드포인트 추가 창의 스크린샷

  3. 엔드포인트를 추가한 후 관리자는 엔드포인트를 모니터링할 수 있습니다.

    Traffic Manager에서 엔드포인트를 모니터링하기 위한 엔드포인트 창의 스크린샷

도움이 더 필요하세요?

3단계: Azure Database for MySQL 프로비전

Contoso 관리자는 미국 동부 2의 주 지역에서 MySQL 데이터베이스 인스턴스를 프로비저닝합니다.

  1. Azure Portal에서 Azure Database for MySQL 리소스를 만듭니다.

    Azure Portal에서 Azure Database for MySQL 링크의 스크린샷

  2. Azure 데이터베이스의 이름 contosoosticket을 추가합니다. 프로덕션 리소스 그룹 ContosoRG에 데이터베이스를 추가한 다음 이에 대한 자격 증명을 지정합니다.

  3. 온-프레미스 MySQL 데이터베이스가 버전 5.7이므로 호환성을 위해 이 버전을 선택합니다. 데이터베이스 요구 사항과 일치하는 기본 크기를 사용합니다.

    버전 5.7이 선택된 MySQL Server 창의 스크린샷

  4. 백업 중복 옵션에 대해 지역 중복을 선택합니다. 이 옵션을 사용하면 중단이 발생할 경우 보조 지역(미국 중부)에서 데이터베이스를 복원할 수 있습니다. 데이터베이스를 프로비저닝할 때만 이 옵션을 구성할 수 있습니다.

    지역 중복 옵션이 선택된 백업 중복 옵션 창의 스크린샷

  5. 연결 보안을 설정합니다. 데이터베이스에서 연결 보안을 선택한 다음 데이터베이스가 Azure 서비스에 액세스할 수 있도록 방화벽 규칙을 설정합니다.

  6. 시작 및 끝 IP 주소에 로컬 워크스테이션 클라이언트 IP 주소를 추가합니다. 이렇게 하면 웹앱이 마이그레이션을 수행하는 데이터베이스 클라이언트와 함께 MySQL 데이터베이스에 액세스할 수 있습니다.

    설정된 Azure 서비스에 대한 액세스와 선택된 클라이언트 IP 주소를 보여 주는 연결 보안 창의 스크린샷

4단계: 데이터베이스 마이그레이션

MySQL 데이터베이스를 이동하는 방법에는 여러 가지가 있습니다. 각 옵션을 사용하려면 Contoso 관리자가 대상에 대한 Azure Database for MySQL 인스턴스를 만들어야 합니다. 인스턴스를 만든 후 다음 두 경로 중 하나를 사용하여 데이터베이스를 마이그레이션할 수 있습니다.

  • 4a단계: Azure Database Migration Service
  • 4b단계: MySQL Workbench 백업 및 복원

4a단계: Azure Database Migration Service를 통해 데이터베이스 마이그레이션

Contoso 관리자는 단계별 마이그레이션 자습서에 따라 Azure Database Migration Service를 통해 데이터베이스를 마이그레이션합니다. MySQL 5.6 또는 5.7을 사용하여 온라인, 오프라인 및 하이브리드(미리 보기) 마이그레이션을 수행할 수 있습니다.

참고

MySQL 8.0은 Azure Database for MySQL에서 지원되지만 Database Migration Service 도구는 아직 이 버전을 지원하지 않습니다.

간단히 말해서 Contoso는 다음을 수행합니다.

  • 모든 마이그레이션 필수 조건이 충족되었는지 확인합니다.

    • MySQL 데이터베이스 서버 원본은 Azure Database for MySQL이 지원하는 버전과 일치해야 합니다. Azure Database for MySQL은 MySQL Community Edition, InnoDB 스토리지 엔진, 동일한 버전의 원본 및 대상 간 마이그레이션을 지원합니다.

    • my.ini(Windows) 또는 my.cnf(Unix)에서 이진 파일 로깅을 사용하도록 설정합니다. 이렇게 하지 않으면 마이그레이션 마법사에서 다음 오류가 발생합니다.

      Error in binary logging. Variable binlog_row_image has value 'minimal'. Please change it to 'full'.

      자세한 내용은 MySQL 설명서에서 이진 파일 로깅 옵션 및 변수를 참조하세요.

    • 사용자에게 ReplicationAdmin 역할이 있어야 합니다.

    • 외래 키 및 트리거 없이 데이터베이스 스키마를 마이그레이션합니다.

  • ExpressRoute 또는 VPN을 통해 온-프레미스 네트워크에 연결하는 VPN(가상 사설망)을 만듭니다.

  • 가상 네트워크에 연결된 프리미엄 SKU를 사용하여 Azure Database Migration Service 인스턴스를 만듭니다.

  • Azure Database Migration Service가 가상 네트워크를 통해 MySQL 데이터베이스에 액세스할 수 있도록 합니다. 여기에는 가상 네트워크 수준, 네트워크 VPN 및 MySQL을 호스팅하는 컴퓨터에서 Azure에서 MySQL로 들어오는 모든 포트가 허용되는지 확인해야 합니다.

  • Database Migration Service 도구를 실행한 후 다음을 수행합니다.

    1. 프리미엄 SKU를 기반으로 하는 마이그레이션 프로젝트를 만듭니다.

      마이그레이션 서비스가 성공적으로 생성되었다는 메시지가 있는 MySQL 개요 창의 스크린샷

      MySQL 새 마이그레이션 프로젝트 창의 스크린샷

    2. 원본(온-프레미스 데이터베이스)을 추가합니다.

      마이그레이션 마법사 원본 세부 정보 추가 창의 스크린샷

    3. 대상을 선택합니다.

      마이그레이션 마법사 대상 세부 정보 창의 스크린샷

    4. 마이그레이션할 데이터베이스를 선택합니다.

      마이그레이션 마법사 대상 데이터베이스에 매핑 창의 스크린샷

    5. 고급 설정을 구성합니다.

      마이그레이션 마법사 마이그레이션 설정 창의 스크린샷

    6. 복제를 시작하고 오류를 해결합니다.

      서버 세부 정보 창의 스크린샷

    7. 최종 컷오버를 수행합니다.

      osTicket 세부 정보 창의 스크린샷

      컷오버 완료 창의 스크린샷

      마이그레이션 작업 상태 테이블의 스크린샷

    8. 외래 키 및 트리거를 복원합니다.

    9. 새 데이터베이스를 사용하도록 애플리케이션을 수정합니다.

      마이그레이션 작업 테이블의 스크린샷

4b단계: 데이터베이스 마이그레이션(MySQL Workbench)

  1. Contoso 관리자는 필수 조건 및 MySQL Workbench 다운로드를 확인합니다.

  2. 설치 지침에 따라 Windows용 MySQL Workbench를 설치합니다. MySQL Workbench를 설치하는 컴퓨터는 인터넷을 통해 osticketmysql VM 및 Azure에 액세스할 수 있어야 합니다.

  3. MySQL Workbench에서는 osticketmysql에 대한 MySQL 연결을 만듭니다.

    MySQL Workbench 연결 세부 정보 창의 스크린샷

  4. 데이터베이스를 로컬 자체 포함 파일에 osticket으로 내보냅니다.

    MySQL Workbench 데이터 내보내기 창의 스크린샷

  5. 데이터베이스를 로컬로 백업한 후 관리자는 Azure Database for MySQL 인스턴스에 대한 연결을 만듭니다.

    MySQL Workbench 새 연결 설정 창의 스크린샷

  6. 이제 자체 포함 파일에서 Azure Database for MySQL 인스턴스의 데이터베이스를 가져올(복원할) 수 있습니다. 인스턴스에 대해 새 스키마 osticket이 만들어집니다.

    MySQL Workbench 데이터 가져오기 창의 스크린샷

  7. 데이터를 복원한 후 관리자는 MySQL Workbench를 사용하여 데이터를 쿼리할 수 있습니다. 데이터는 Azure Portal에 표시됩니다.

    복원된 데이터를 표시하는 Azure Portal의 스크린샷

    osTicket 데이터베이스를 가리키는 화살표가 있는 MySQL 데이터베이스 블레이드의 스크린샷

  8. 관리자는 웹앱에서 데이터베이스 정보를 업데이트합니다. MySQL 인스턴스에서 연결 문자열을 엽니다.

    MySQL 인스턴스에서 연결 문자열 링크의 스크린샷

  9. 연결 문자열 목록에서 웹앱 설정을 선택한 다음 복사하려면 클릭을 선택하여 복사합니다.

    MySQL 인스턴스에서 웹앱 설정의 스크린샷

  10. 메모장에서 새 파일을 열고, 문자열을 붙여넣고, osTicket 데이터베이스, MySQL 인스턴스 및 자격 증명 설정과 일치하도록 문자열을 업데이트합니다.

    메모장 파일에 붙여 넣은 연결 문자열의 스크린샷

  11. Azure Portal에서 MySQL 인스턴스에 대한 개요 창을 통해 서버 이름을 확인하고 로그인할 수 있습니다.

    서버 이름 및 서버 관리자 계정 이름을 표시하는 리소스 그룹 창의 스크린샷

5단계: GitHub 설정

Contoso 관리자는 새 프라이빗 GitHub 리포지토리를 만들고 Azure Database for MySQL에서 osTicket 데이터베이스에 대한 연결을 설정합니다. 그런 다음 Azure App Service에 웹앱을 로드합니다.

  1. osTicket 소프트웨어 공용 GitHub 리포지토리로 이동하여 Contoso GitHub 계정에 포크합니다.

    포크 단추를 강조 표시하는 GitHub 리포지토리 페이지의 스크린샷

  2. 리포지토리를 분기한 후 include 폴더를 찾아 ost-config.php 파일을 선택합니다.

    GitHub에서 PHP 파일의 스크린샷

  3. 브라우저에서 파일이 열리면 파일을 편집합니다.

    GitHub에서 파일 편집(연필) 아이콘의 스크린샷

  4. 편집기에서 관리자는 특히 DBHOSTDBUSER에 대한 데이터베이스 세부 정보를 업데이트합니다.

    GitHub에서 파일 편집 창의 스크린샷

  5. 변경 내용을 커밋합니다.

    편집 창에서 변경 내용 커밋 단추를 강조 표시하는 스크린샷

  6. 각 웹앱(osticket-eus2osticket-cus)에 대해 Azure Portal에서 왼쪽 창에서 애플리케이션 설정을 선택한 다음 설정을 수정합니다.

    Azure Portal에서 애플리케이션 설정 링크를 강조 표시하는 스크린샷

  7. 이름이 osticket인 연결 문자열을 입력하고 메모장에서 값 영역으로 문자열을 복사합니다. 문자열 옆의 드롭다운 목록에서 MySQL을 선택하고 설정을 저장합니다.

    osTicket 연결 문자열을 강조 표시하는 연결 문자열 창의 스크린샷

6단계: 웹앱 구성

마이그레이션 프로세스의 마지막 단계로 Contoso 관리자는 osTicket 웹 사이트를 사용하여 웹앱을 구성합니다.

  1. 기본 웹앱인 osticket-eus2에서 배포 옵션을 연 다음 원본을 GitHub로 설정합니다.

    원본으로 GitHub가 선택된 배포 옵션 창의 스크린샷

  2. 배포 옵션을 선택합니다.

    배포 옵션 창에 있는 옵션 세부 정보의 스크린샷

  3. 옵션을 설정하면 구성이 Azure Portal에 보류 중으로 표시됩니다.

    보류 중인 사이트 상태를 표시하는 배포 옵션 창의 스크린샷

  4. 구성이 업데이트되고 osTicket 웹앱이 GitHub에서 Azure App Service를 실행하는 Docker 컨테이너로 로드되면 사이트가 활성으로 표시됩니다.

    배포 옵션 창의 스크린샷

  5. 보조 웹앱 osticket-cus에 대해 이전 단계를 반복합니다.

  6. 사이트가 구성된 후에는 Traffic Manager 프로필을 통해 사이트에 액세스할 수 있습니다. DNS 이름은 osTicket 애플리케이션의 새 위치입니다. 자세한 정보.

    DNS 이름을 표시하는 Traffic Manager 프로필 창의 스크린샷

  7. Contoso는 기억하기 쉬운 DNS 이름을 사용하려고 합니다. 새 리소스 레코드 창에서 별칭, CNAME 및 정규화된 도메인 이름 osticket.contoso.com을 만듭니다. 이 이름은 도메인 컨트롤러의 DNS에 있는 Traffic Manager 이름을 가리킵니다.

    별칭 이름 및 Traffic Manager에 대한 포인터를 표시하는 새 리소스 레코드 창의 스크린샷

  8. 사용자 지정 호스트 이름을 허용하도록 osticket-eus2osticket-cus 웹앱을 모두 구성합니다.

    유효성 검사 단추를 강조 표시하는 Ad 호스트 이름 창의 스크린샷

자동 크기 조정 설정

마지막으로 Contoso 관리자는 애플리케이션에 대한 자동 크기 조정을 설정합니다. 자동 크기 조정은 에이전트가 애플리케이션을 사용할 때 비즈니스 요구에 따라 애플리케이션 인스턴스가 증가하거나 감소하도록 합니다.

  1. App Service APP-SVP-EUS2에서 배율 단위를 엽니다.

  2. 현재 인스턴스의 CPU 사용량이 10분 동안 70%를 초과하면 인스턴스 수를 하나씩 늘리는 단일 규칙으로 새로운 자동 크기 조정 설정을 구성합니다.

    첫 번째 지역에 대한 자동 크기 조정 설정 페이지의 스크린샷

  3. 애플리케이션이 보조 지역으로 장애 조치(failover)되는 경우 동일한 동작이 적용되도록 APP-SVP-CUS에서 동일한 설정을 구성합니다. 유일한 차이점은 장애 조치(failover) 전용이기 때문에 기본 인스턴스를 1로 설정한다는 것입니다.

    두 번째 지역에 대한 자동 크기 조정 설정 페이지의 스크린샷

마이그레이션 후 정리

마이그레이션이 완료되면 프라이빗 GitHub 리포지토리를 사용하여 지속적으로 업데이트되는 Azure App Service 웹앱에서 실행되도록 osTicket 애플리케이션이 리팩터링됩니다. 애플리케이션은 복원력을 높이기 위해 두 지역에서 실행됩니다. osTicket 데이터베이스는 PaaS 플랫폼으로 마이그레이션한 후 Azure Database for MySQL에서 실행됩니다.

마이그레이션 후 정리하기 위해 Contoso는 다음을 수행합니다.

  • vCenter 인벤토리에서 VMware VM을 제거합니다.
  • 로컬 백업 작업에서 온-프레미스 VM을 제거합니다.
  • 새 위치와 IP 주소를 표시하도록 내부 설명서를 업데이트합니다.
  • 온-프레미스 VM과 상호 작용하는 모든 리소스를 검토하고 관련 설정 또는 설명서를 업데이트하여 새 구성을 반영합니다.
  • 애플리케이션이 실행 중인지 추적하기 위해 osticket.trafficmanager.net URL을 가리키도록 모니터링을 재구성합니다.

배포 검토

이제 애플리케이션이 실행되고 있으므로 Contoso는 새 인프라를 완전히 운영하고 보호해야 합니다.

보안

Contoso 보안 팀은 애플리케이션을 검토하여 보안 문제를 확인합니다. osTicket 애플리케이션과 MySQL 데이터베이스 인스턴스 간의 통신이 SSL에 대해 구성되지 않았음을 식별합니다. 데이터베이스 트래픽이 해킹되지 않도록 하기 위해 이 모든 작업을 수행합니다. 자세히 알아보기.

Backup

  • osTicket 웹앱에는 상태 데이터가 포함되어 있지 않으므로 백업이 필요하지 않습니다.
  • Contoso 팀은 데이터베이스에 대한 백업을 구성할 필요가 없습니다. Azure Database for MySQL에서 자동으로 서버 백업을 만들고 저장합니다. 팀은 데이터베이스에 대해 지리적 중복을 사용하도록 선택했으므로 복원력이 높고 프로덕션 준비가 완료되었습니다. 백업을 사용하여 서버를 특정 시점으로 복원할 수 있습니다. 자세히 알아보기.

라이선스 및 비용 최적화

  • PaaS 배포에 대한 라이선스 문제는 없습니다.
  • Contoso는 Azure Cost Management + Billing을 사용하여 IT 리더가 설정한 예산 내에서 유지되도록 합니다.