클라우드 워크로드를 다른 지역으로 마이그레이션
마이그레이션 단계는 워크로드를 새 지역으로 이동하는 위치입니다. 워크로드에 따라 준비해야 할 몇 가지 기술적 요구 사항이 있을 수 있지만 워크로드에 대한 재배치 전략은 명확해야 합니다. 재배치를 실행할 준비가 되어 있어야 합니다.
준비
워크로드 재배치를 시작하기 전에 대상 지역을 준비해야 합니다. 필요에 따라 다음 단계에 따라 재배치하기 전에 워크로드 환경을 준비합니다. 이렇게 하면 지역 허브와 같은 핵심 지역 네트워킹과 필요한 경우 프레미스 간 연결이 보장됩니다.
랜딩 존을 설정합니다. 이동을 계획할 때 Azure 랜딩 존의 범위를 확장하는지 평가합니다. 확장이 필요한 경우 기본 단계로 Azure 랜딩 존 지침을 참조하세요. 이 단계에서는 접근 방식이 설정된 모범 사례와 일치하도록 합니다. 자세한 내용은 기존 Azure 랜딩 존에 새 지역 추가를 참조 하세요. 새 랜딩 존을 설정하기 위한 중요한 고려 사항은 다음과 같습니다.
- 네트워킹: 새 지역의 랜딩 존에 대한 네트워크 구조, 라우팅 경로 및 연결 요구 사항을 평가합니다.
- 통합: 새 랜딩 존을 원본 지역의 랜딩 존과 통합해야 하는지 확인합니다.
- 선택적 리소스 재배치: 모든 리소스가 새 지역으로 이동할지 여부를 결정합니다. 일부 리소스가 원래 위치에 기본 경우 지속 가능한 지역 간 네트워크 토폴로지를 계획하여 분산된 리소스를 효과적으로 관리합니다.
필요한 경우에만 새 구독을 만듭니다. 관련된 서비스 및 리소스를 재구성해야 하는 경우에만 새 구독을 만듭니다. 가능하면 새 구독을 만들면 복잡성이 추가되므로 워크로드를 기존 구독에 유지합니다. 구독은 예산, 정책 및 RBAC(역할 기반 액세스 제어)의 경계 역할을 합니다. 새 구독의 경우 예산, 정책 및 RBAC의 유효성을 검사해야 합니다. 구독의 모든 리소스를 이동하지 않는 경우 더 작은 리소스 그룹화와 일치하도록 ID 및 보안 정책의 범위를 다시 지정해야 합니다. 새 구독을 만들려면 대상 구독에서 필요한 Azure 정책 및 RBAC 역할을 만들고, 범위를 지정하고, 구현해야 합니다. 목표는 기본 거버넌스 및 보안 태세를 파악하는 것입니다.
필요한 경우 새 do기본 이름을 구성합니다. 사용자 지정 작업기본 변경이 있는 경우 새 do기본 이름을 구성해야 합니다. 새 호스트 이름을 만들고, 애플리케이션 또는 서비스에 할당한 다음, 이름 확인의 유효성을 검사합니다. TTL(Time to Live)을 낮추고 구성하고 자동 만료를 위해 단독형 단계에서 설정할 수도 있습니다. 자세한 내용은 App Service 계획에 사용자 지정 do기본 및 Map DNS 이름 추가를 참조하세요.
필요한 경우 새 SSL/TLS 인증서를 만듭니다. 새 do기본 이름에 대해 새 SSL/TLS 인증서(X.509)를 만들어야 합니다. 이러한 인증서를 사용하면 퍼블릭-프라이빗 키 암호화 및 HTTPS(보안 네트워크 통신)를 사용할 수 있습니다. Azure Key Vault를 사용하여 X.509 인증서를 만들거나 가져옵니다. 자세한 내용은 Azure Key Vault 인증서 및인증서 만들기 방법을 참조하세요.
Azure Key Vault를 재배치합니다. 워크로드를 이동하기 전에 Azure Key Vault를 재배치해야 합니다. 애플리케이션 환경당 하나의 키 자격 증명 모음이 있어야 하며, 키 자격 증명 모음은 기밀성을 보장하기 위해 지역 간에 비밀을 공유해서는 안 됩니다. 이 지침에 맞게 새 대상 지역에 새 키 자격 증명 모음을 만들어야 할 수 있습니다.
새 Log Analytics 작업 영역을 만듭니다. 각 지역에 대해 별도의 Log Analytics 작업 영역이 있어야 합니다. 대상 지역에 새 작업 영역을 만듭니다. Log Analytics 작업 영역을 다른 지역으로 이동할 수 없으므로 대상 지역에 새 Log Analytics 작업 영역을 만들어야 합니다. 원래 작업 영역에서 데이터를 유지하는 두 가지 옵션이 있습니다. 데이터가 필요하지 않을 때까지 현재 작업 영역을 유지하여 데이터를 읽기 전용으로 처리할 수 있습니다. 작업 영역 데이터를 새 대상 Azure 지역의 스토리지 계정으로 내보낼 수도 있습니다.
서비스 마이그레이션
워크로드에서 서비스 마이그레이션을 시작할 수 있습니다. 실행을 위해 선택한 재배치 자동화에 대한 사용 가능한 지침을 따르세요. Azure Resource Mover 및 Azure Site Recovery에는 서비스 재배치에 따라야 하는 단계별 자습서가 있습니다. 자세한 내용은 다음을 참조하세요.
이동할 수 없는 리소스에 대한 코드 기반 인프라 템플릿 또는 스크립트를 만들 수 있습니다. Azure Portal에서 수동으로 배포를 실행할 수도 있습니다. 수행하는 특정 단계는 사용하는 Azure 서비스 및 해당 구성에 따라 달라집니다. 자세한 내용은 코드로 인프라 개요를 참조하세요.
데이터 마이그레이션
이 단계는 워크로드에 데이터 마이그레이션이 필요한 경우에만 관련이 있습니다. 선택한 자동화를 사용하여 데이터 마이그레이션을 수행합니다. 대상 지역의 워크로드를 중단하기 전에 관련 데이터가 원본 지역과 동기화되어 있는지 확인해야 합니다. 데이터 일관성은 주의가 필요한 중요한 측면입니다. 워크로드 데이터를 마이그레이션하기 위한 지침은 다음과 같습니다.
원본 지역 데이터를 마이그레이션합니다. 원본 지역 데이터를 마이그레이션하는 방법은 워크로드 서비스에 대한 재배치 방법을 따라야 합니다. 핫, 콜드 및 웜 메서드에는 원본 지역의 데이터를 관리하기 위한 여러 프로세스가 있습니다.
데이터를 동기화합니다. 동기화 기술은 워크로드의 아키텍처와 애플리케이션의 수요에 따라 달라집니다. 예를 들어 주문형 동기화에서 데이터가 처음으로 액세스되면 변경 내용이 끌어오게 됩니다. 변경 내용 끌어와 병합은 마지막 애플리케이션 액세스와 현재 애플리케이션 액세스 간에 차이가 있는 경우에만 발생합니다.
동기화 충돌을 해결합니다. 원본 및 대상 위치의 데이터가 동기화되어 있는지 확인하고 데이터 충돌을 해결합니다. 사용자가 사용 가능한 데이터에만 액세스하려고 합니다. 예를 들어 Azure Cosmos DB는 데이터 일관성을 보장하기 위해 동시 쓰기를 직렬화할 수 있습니다.
연결 문자열 업데이트
연결 문자열 구성은 애플리케이션이 연결하는 서비스에 따라 달라집니다. 설명서 페이지에서 "연결 문자열"을 검색하여 서비스 관련 지침을 찾고 해당 지침을 사용하여 연결 문자열 업데이트할 수 있습니다. 자세한 내용은 기술 설명서를 참조 하세요.
관리 ID
시스템 할당 관리 ID에는 Azure 리소스에 바인딩된 수명 주기가 있습니다. 따라서 Azure 리소스의 재배치 전략은 시스템 할당 관리 ID를 처리하는 방법을 결정합니다. 대상에 리소스의 새 인스턴스가 만들어지면 새 시스템 할당 관리 ID에 원본 지역의 시스템 할당 관리 ID와 동일한 권한을 부여해야 합니다.
반면에 사용자 할당 관리 ID에는 독립적인 수명 주기가 있으며 사용자 할당 관리 ID를 대상 지역의 새 리소스에 매핑할 수 있습니다. 자세한 내용은 관리 ID 개요를 참조하세요.
다음 단계
워크로드 서비스 및 데이터를 마이그레이션했습니다. 이제 단독형으로 재배치를 완료해야 합니다.