마이그레이션할 Azure 지역 선택
기존 환경을 Azure로 마이그레이션하는 경우 마이그레이션된 구성 요소를 호스트할 Azure 지역 또는 지역 집합을 선택해야 합니다. 지역 선택에는 다음과 같은 개략적인 단계가 포함됩니다.
- 핵심 Azure 지역 선택 지침을 검토하여 요구 사항을 충족하는 Azure 지역을 선택하는 방법을 이해합니다.
- 환경의 현재 상태를 인벤토리화하고 문서화합니다.
- 단일 지역에서 실행하거나, 여러 가용성 영역을 사용하거나, 여러 지역을 사용할지 여부를 포함하여 마이그레이션에 대한 일반적인 접근 방식을 구현합니다.
- 필요할 수 있는 프로세스 변경 내용을 평가합니다.
- 마이그레이션 프로세스를 계획합니다.
- 프로세스 변경 내용을 최적화하고 승격합니다.
이 문서에서는 마이그레이션 요구 사항을 충족하는 Azure 지역을 선택하는 방법에 대한 지침을 제공합니다. 아직 없는 경우 다중 지역 접근 방식을 지원하도록 랜딩 존 지역을 확장해야 할 수 있습니다.
참고 항목
이 문서에서는 워크로드 마이그레이션과 관련된 고려 사항을 다룹니다. 또한 모든 조직 또는 워크로드에 대한 Azure 지역을 선택하는 일반적인 원칙을 이해해야 합니다. 자세한 내용은 Azure 지역 선택을 참조 하세요.
시나리오 복잡성 문서화
시나리오에 설명서 및 프로세스 맞춤이 필요한지 여부를 확인합니다. 다음 방법을 사용하여 잠재적인 과제를 평가하고 일반적인 작업 과정을 수립할 수 있습니다.
- 보다 강력한 준비 및 거버넌스 구현을 고려합니다.
- 영향을 받는 지리를 인벤토리로 작성합니다. 영향을 받는 국가 또는 지역 목록을 컴파일합니다.
- 사용자 기반을 문서화합니다. 클라우드 마이그레이션이 식별된 국가 또는 지역의 직원, 파트너 또는 고객에게 영향을 주나요?
- 데이터 센터 및 자산을 문서화합니다. 마이그레이션 노력에 식별된 국가 또는 지역의 자산이 포함됩니까?
- 지역 제품 버전 가용성 및 장애 조치(failover) 요구 사항을 문서화합니다.
- 복원력 요구 사항을 문서화하여 가용성 영역이 필요한지 여부를 확인합니다. 일반적으로 개별 지역이 아닌 전체 시나리오에 대한 복원력 요구 사항을 고려합니다.
- 주권 요구 사항 및 데이터 상주 요구 사항을 문서화합니다. 특정 주권 또는 데이터 상주 요구 사항이 있는 워크로드는 선택한 Azure 지역에 영향을 줄 수 있습니다.
마이그레이션 프로세스 전체에서 다양한 시나리오 및 인벤토리에서 변경 내용을 조정하는 방법을 고려합니다. 다음 표에서는 다양한 시나리오를 문서화하는 방법의 예를 보여 줍니다.
| 지역 | 국가/지역 | 로컬 직원 | 로컬 외부 사용자 | 로컬 데이터 센터 또는 자산 | 데이터 주권 요구 사항 |
|---|---|---|---|---|---|
| 북아메리카 | 미국 | 예 | 파트너 및 고객 | 예 | 아니요 |
| 북아메리카 | 캐나다 | 아니요 | 고객 | 예 | 예 |
| 유럽 | 독일 | 예 | 파트너 및 고객 | 아니요 - 네트워크 전용 | 예 |
| 아시아 태평양 | 대한민국 | 예 | 파트너 | 예 | 아니요 |
사용자의 위치가 관련이 있는 이유는 무엇인가요?
여러 국가 또는 지역의 사용자를 지원하는 조직은 사용자 트래픽을 해결하는 기술 솔루션을 개발합니다. 어떤 경우에는 자산의 지역화가 진행됩니다. 또 어떤 경우에는 조직이 네트워크 중심 솔루션을 통해 서로 다른 사용자 기반을 해결하기 위해 글로벌 WAN(광역 네트워크) 솔루션을 구현하기로 선택할 수 있습니다. 두 경우 모두 서로 다른 사용자의 사용 프로필이 마이그레이션 전략에 영향을 줄 수 있습니다.
예를 들어 조직에서 독일의 직원, 파트너 및 고객을 지원하지만 현재 독일에 데이터 센터가 없는 경우 조직은 임대 라인 솔루션을 구현할 수 있습니다. 이 유형의 솔루션은 트래픽을 다른 국가 또는 지역의 데이터 센터로 라우팅합니다. 이러한 기존 라우팅은 마이그레이션된 애플리케이션의 인식된 성능에 상당한 위험을 초래합니다. 설정 및 튜닝된 글로벌 WAN에서 더 많은 홉을 삽입하면 마이그레이션 후에 성능이 저하된 애플리케이션을 인식할 수 있게 됩니다. 이러한 문제를 찾아서 해결하면 프로젝트에 상당한 지연이 발생할 수 있습니다.
다음 각 섹션에는 평가, 마이그레이션 및 최적화의 필수 구성 요소 및 프로세스에서 이러한 복잡성을 해결하기 위한 지침이 포함되어 있습니다. 각 국가 또는 지역의 사용자 프로필을 이해하는 것은 이러한 복잡성을 적절히 관리하는 데 중요합니다.
데이터 센터의 위치가 관련되는 이유는 무엇인가요?
기존 데이터 센터의 위치는 마이그레이션 전략에 영향을 줄 수 있습니다. 다음 사항을 고려합니다.
아키텍처 결정: 마이그레이션 전략 설계의 첫 번째 단계 중 하나는 대상 지역을 결정하는 것입니다. 기존 자산의 위치는 종종 이러한 결정에 영향을 줍니다. 또한 클라우드 서비스의 가용성과 해당 서비스의 단가는 지역마다 다를 수 있습니다. 주권 요구 사항을 포함한 데이터 보존 요구 사항은 아키텍처 결정에 영향을 줄 수도 있습니다. 현재 및 미래의 자산이 어디에 있는지 이해하면 아키텍처 결정과 예산 예측에 영향을 줄 수 있습니다.
데이터 센터 종속성: 시나리오 복잡성 문서 섹션의 표에서 예제 시나리오에서는 다양한 글로벌 데이터 센터 간의 종속성을 계획해야 할 수 있음을 보여 줍니다. 이 규모로 작동하는 조직은 이러한 종속성을 문서화하거나 명확하게 이해하지 못할 수 있습니다. 사용자 프로필을 평가하는 조직의 접근 방식은 이러한 조직의 종속성을 파악하는 데 도움이 됩니다. 또한 팀은 종속성에서 발생하는 위험 및 복잡성을 완화하는 데 도움이 되는 더 많은 평가 단계를 탐색해야 합니다.
일반적인 접근 방식 구현
다음 접근 방식은 전역 마이그레이션 복잡성을 해결하기 위해 데이터 기반 모델을 사용합니다. 마이그레이션 범위에 여러 지역이 포함된 경우 클라우드 채택 팀은 다음 준비 고려 사항을 평가해야 합니다.
비즈니스 요구 사항을 충족할 수 있는지 확인: 여러 가용성 영역을 사용하여 고가용성, 복원력, 성능 및 비용에 대한 요구 사항을 결정합니다. 이러한 요구 사항이 충족되지 않는 경우 다중 지역 접근 방식이 필요한지 여부를 고려합니다.
데이터 주권 평가: 데이터 주권에는 일부 자산의 지역화가 필요할 수 있지만 많은 자산은 이러한 규정 준수 제약 조건에 의해 제어되지 않습니다. 로깅, 보고, 네트워크 라우팅, ID 및 기타 중앙 IT 서비스와 같은 서비스는 여러 구독 또는 지역에서 공유 서비스로 호스트될 수 있습니다. 해당 서비스에 대해 공유 서비스 모델을 사용하여 데이터 주권을 평가합니다. 이 방법의 개요는 공유 서비스를 사용하는 허브-스포크 토폴로지의 참조 아키텍처를 참조 하세요.
환경 크기 조정 확인: 유사한 환경의 여러 인스턴스를 배포하는 경우 환경 마이그레이션을 위한 전담 팀을 구성하여 일관성을 만들고, 거버넌스를 개선하고, 배포를 가속화할 수 있습니다. 복잡한 기업에 대한 거버넌스 가이드는 여러 지역에 걸쳐 확장되는 환경을 만드는 접근 방식을 설정합니다.
데이터 기반 필수 구성 요소
팀이 기준 접근 방식에 익숙해지고 준비 상태가 조정되면 다음과 같은 데이터 기반 필수 구성 요소를 고려합니다.
일반 검색 완료: 복잡성 문서화의 테이블을 완료하여 클라우드 채택 전략의 복잡성을 평가합니다.
영향을 받는 각 국가 또는 지역에 대한 사용자 프로필 분석: 마이그레이션 프로세스 초기에 일반 사용자 라우팅을 이해하는 것이 중요합니다. 글로벌 임대 라인을 변경하고 Azure ExpressRoute와 같은 연결을 클라우드 데이터 센터에 추가하면 몇 달 동안 네트워킹이 지연될 수 있습니다. 가급적이면 프로세스 초기에 사용자 라우팅을 해결하세요.
초기 디지털 자산 합리화 완료: 마이그레이션 전략에 복잡성을 도입하는 경우 초기 디지털 자산 합리화를 완료합니다. 자세한 내용은 디지털 자산이란?을 참조하세요.
디지털 자산 요구 사항에 태그 사용: 데이터 주권 요구 사항의 영향을 받는 워크로드를 식별하는 태그 정책을 수립합니다. 필요한 태그가 디지털 자산 합리화에서 시작하여 마이그레이션된 자산으로 전달되는지 확인합니다.
허브-스포크 모델 평가: 분산 시스템은 종종 공통 종속성을 공유합니다. 허브-스포크 모델을 구현하여 공유 종속성을 해결할 수 있는 경우가 많습니다. 허브-스포크 모델은 마이그레이션 프로세스 범위를 벗어나지만, 향후 준비 프로세스를 반복할 때 고려해 볼 수 있도록 플래그를 지정하세요.
마이그레이션 백로그 우선 순위 지정: 여러 지역을 지원하는 워크로드의 프로덕션 배포를 지원하기 위해 네트워크 변경이 필요한 경우 클라우드 전략 팀은 네트워크 변경으로 인한 에스컬레이션을 추적하고 관리해야 합니다. 이 더 높은 수준의 임원 지원은 전략 팀이 백로그의 우선 순위를 다시 지정하고 네트워크 변경이 글로벌 워크로드를 차단하지 않도록 하여 변경을 가속화하는 데 도움이 됩니다. 네트워크 변경이 완료된 경우에만 전역 워크로드의 우선 순위를 지정하세요.
이러한 필수 구성 요소는 마이그레이션 전략을 실행하는 동안 복잡성을 해결할 수 있는 프로세스를 설정하는 데 도움이 됩니다.
프로세스 변경 평가
마이그레이션 시나리오에 글로벌 자산 및 사용자 기반 복잡성이 포함된 경우 주요 활동을 추가하여 마이그레이션 후보를 평가합니다. 이러한 활동은 글로벌 사용자 및 자산에 대한 장애물과 결과를 명확히 하는 데 도움이 되는 데이터를 생성합니다.
평가 프로세스 중에 제안된 작업
데이터 센터 간 종속성 평가: Azure Migrate의 종속성 분석 도구는 종속성을 정확히 파악하는 데 도움이 될 수 있습니다. 마이그레이션을 시작하기 전에 이러한 도구를 사용합니다. 시나리오에 전역 복잡성이 포함된 경우 종속성 평가는 평가 프로세스에서 필요한 단계입니다. 종속성 그룹화를 사용하여 종속성을 시각화하고 워크로드를 지원하는 데 필요한 자산의 IP 주소 및 포트를 식별할 수 있습니다.
Important
- 보조 데이터 센터에 있는 자산을 식별하기 위해 자산 배치 및 IP 주소 스키마를 이해하는 SME(주제 전문가)가 필요합니다.
- 시각화에서 다운스트림 종속성 및 클라이언트를 평가하여 양방향 종속성을 이해합니다.
글로벌 사용자 영향 식별: 필수 구성 요소 사용자 프로필 분석의 출력은 전역 사용자 프로필의 영향을 받는 모든 워크로드를 식별해야 합니다. 마이그레이션 후보가 영향을 받는 워크로드 목록에 있는 경우 마이그레이션 설계자는 네트워킹 및 운영 중소기업을 참조해야 합니다. 이러한 전문가는 네트워크 라우팅 및 성능 기대치의 유효성을 검사하는 데 도움이 됩니다. 최소한 아키텍처에는 가장 가까운 네트워크 운영 센터와 Azure 간의 ExpressRoute 연결이 포함되어야 합니다. ExpressRoute 연결에 대한 참조 아키텍처는 필요한 연결을 구성하는 데 도움이 될 수 있습니다.
규정 준수를 위한 디자인: 필수 구성 요소 사용자 프로필 분석의 출력은 데이터 주권 요구 사항의 영향을 받는 모든 워크로드도 식별해야 합니다. 평가 프로세스의 아키텍처 작업 중에 할당된 설계자는 규정 준수 중소기업에 문의해야 합니다. 이러한 전문가는 설계자가 여러 지역에 걸친 마이그레이션 및 배포 요구 사항을 이해하는 데 도움을 줄 수 있습니다. 이러한 요구 사항은 디자인 전략에 크게 영향을 줍니다. 다음 참조 아키텍처는 디자인에 도움이 될 수 있습니다.
Warning
ExpressRoute에 대한 참조 아키텍처 또는 애플리케이션에 대한 참조 아키텍처를 사용하는 경우 데이터 주권 요구 사항을 충족하기 위해 특정 데이터 요소를 복제본(replica)tion 프로세스에서 제외해야 할 수 있습니다. 특정 데이터 요소를 제외하는 작업은 승격 프로세스에 단계를 추가합니다.
마이그레이션 프로세스 변경
여러 지역에 배포해야 하는 애플리케이션을 마이그레이션하는 경우 클라우드 채택 팀은 몇 가지 추가 고려 사항을 고려해야 합니다. Azure Site Recovery 자격 증명 모음 및 구성 및 프로세스 서버의 디자인은 이러한 두 가지 고려 사항입니다. 다른 두 가지 고려 사항은 네트워크 대역폭 디자인 및 데이터 동기화입니다.
마이그레이션 프로세스 중에 제안된 작업
Site Recovery 자격 증명 모음 디자인: Site Recovery는 디지털 자산을 Azure로 클라우드 네이티브 복제본(replica) 및 동기화하기 위한 권장 도구입니다. Site Recovery는 각 자산에 대한 데이터를 Site Recovery 자격 증명 모음에 복제본(replica). 이 자격 증명 모음은 특정 지역 및 Azure 데이터 센터의 특정 구독에 바인딩됩니다. 두 번째 지역에 자산을 복제본(replica) 경우 두 번째 Site Recovery 자격 증명 모음도 필요할 수 있습니다.
구성 및 프로세스 서버 디자인: Site Recovery는 단일 Site Recovery 자격 증명 모음에 바인딩된 구성 및 프로세스 서버의 로컬 인스턴스에서 작동합니다. 이 구성을 사용하는 경우 원본 데이터 센터에 이러한 서버의 두 번째 인스턴스를 설치해야 복제본(replica).
네트워크 대역폭 디자인: 복제본(replica) 및 지속적인 동기화 중에 네트워크를 통해 원본 데이터 센터에서 대상 Azure 데이터 센터의 Site Recovery 자격 증명 모음으로 이진 데이터를 이동합니다. 복제본(replica) 및 동기화 프로세스는 대역폭을 사용합니다. 워크로드를 두 번째 지역으로 복제하면 사용된 대역폭의 양이 두 배가 됩니다.
일부 시나리오에서는 대역폭이 제한됩니다. 다른 작업에서는 상당한 구성 또는 데이터 드리프트가 포함됩니다. 이러한 경우 데이터를 두 번째 지역에 복제본(replica) 마이그레이션을 완료하는 데 걸리는 시간을 방해할 수 있습니다. 더 중요한 것은 이러한 제약 조건이 원본 데이터 센터에서 사용 가능한 대역폭에 따라 달라지는 사용자 또는 애플리케이션의 환경에 영향을 줄 수 있다는 점입니다.
데이터 동기화: 가장 큰 대역폭 드레이닝은 데이터 플랫폼 동기화에서 발생하는 경우가 많습니다. 여러 가용성 영역에 배포하는 경우 여러 가용성 영역에서 데이터를 자동으로 동기화하는 영역 중복 데이터 서비스를 사용할 수 있습니다. 여러 지역에 배포하려면 애플리케이션을 정렬된 상태로 유지하기 위해 데이터 동기화가 필요한 경우가 많습니다. 이 방법은 다중 지역 웹 애플리케이션 및 다중 지역 n 계층 애플리케이션에 대한 참조 아키텍처에서 정의됩니다.
애플리케이션을 동기화된 상태로 유지하는 것이 애플리케이션에 원하는 운영 상태인 경우 원본 데이터 플랫폼을 각 클라우드 플랫폼과 동기화할 수 있습니다. 애플리케이션 및 중간 계층 자산을 마이그레이션하기 전에 이 동기화를 수행합니다.
Azure 간 재해 복구: 대체 옵션은 복잡성을 더욱 줄일 수 있습니다. 2단계 배포를 사용하여 타임라인 및 데이터 동기화 요구 사항을 충족하는 경우 Azure 간 재해 복구가 허용 가능한 솔루션일 수 있습니다. 이 시나리오에서는 단일 Site Recovery 자격 증명 모음 및 구성 및 프로세스 서버 디자인을 사용하여 워크로드를 첫 번째 Azure 데이터 센터로 마이그레이션합니다. 워크로드를 테스트한 후에는 마이그레이션된 자산의 두 번째 Azure 데이터 센터에 워크로드를 복구할 수 있습니다.
이 방법은 원본 데이터 센터의 리소스에 미치는 영향을 줄입니다. 또한 Azure 간 재해 복구는 Azure 데이터 센터 간의 빠른 전송 속도와 높은 대역폭 제한을 활용합니다.
참고 항목
Azure-Azure 재해 복구 접근 방식은 더 높은 송신 대역폭 요금을 통해 단기 마이그레이션 비용을 증가시킬 수 있습니다.
릴리스 프로세스 변경 내용
최적화 및 승격 중에 글로벌 복잡성을 해결할 때 배포하는 각 지역에서 동일한 노력이 필요할 수 있습니다. 단일 지역을 사용하는 경우에도 비즈니스 테스트 및 비즈니스 변경 계획을 복제본(replica) 해야 할 수 있습니다.
릴리스 프로세스 중에 제안된 작업
사전 테스트 최적화: 초기 자동화 테스트는 마이그레이션 작업과 마찬가지로 잠재적인 최적화 기회를 식별할 수 있습니다. 전역 워크로드의 경우 각 지역의 워크로드를 독립적으로 테스트합니다. 네트워크 또는 선택한 Azure 데이터 센터의 사소한 구성 변경은 성능에 영향을 줄 수 있습니다.
비즈니스 변경 계획: 복잡한 마이그레이션 시나리오에 대한 비즈니스 변경 계획을 만듭니다. 비즈니스 변경 계획은 비즈니스 프로세스 및 사용자 환경의 변경 내용에 대한 명확한 통신을 보장하는 데 도움이 됩니다. 또한 이 계획은 변경 내용을 통합하는 데 필요한 노력의 시기에 대한 명확한 의사 소통을 보장하는 데 도움이 됩니다. 전역 마이그레이션 작업의 경우 영향을 받는 각 지리적 영역의 사용자에 대한 고려 사항을 계획에 포함해야 합니다.
비즈니스 테스트: 각 지역에는 비즈니스 테스트가 필요할 수도 있습니다. 비즈니스 테스트는 수정된 네트워크 라우팅 패턴에 대한 적절한 성능 및 준수를 보장하는 데 도움이 됩니다.
프로모션 플라이트: 프로모션은 종종 단일 활동으로 발생하며 프로덕션 트래픽은 마이그레이션된 워크로드로 즉시 다시 라우팅됩니다. 글로벌 릴리스 작업에서는 플라이트라고 하는 미리 정의된 사용자 컬렉션에서 프로모션을 제공해야 합니다. 프로모션 플라이트를 통해 클라우드 전략 팀과 클라우드 채택 팀은 각 지역의 사용자에 대한 성능을 관찰하고 지원을 개선할 수 있습니다. 네트워킹 수준에서 프로모션 플라이트 제어할 수 있습니다. 특히 특정 IP 범위의 라우팅을 원본 워크로드 자산에서 새로 마이그레이션된 자산으로 변경할 수 있습니다. 지정된 사용자 컬렉션을 마이그레이션한 후 다음 그룹의 경로를 다시 지정할 수 있습니다.
비행 최적화: 프로모션 플라이트의 한 가지 이점은 더 심층적인 관찰과 배포된 자산을 최적화할 수 있는 기회를 제공한다는 것입니다. 첫 번째 플라이트에서 짧은 시간 동안 프로덕션을 성공적으로 사용한 후, IT 운영 절차의 지원이 있는 경우 마이그레이션된 자산을 구체화할 수 있습니다.