다음을 통해 공유


재배치를 위한 클라우드 워크로드 평가

평가는 재배치 이동 단계의 첫 번째 단계입니다. 평가의 목표는 성공적으로 이동할 수 있도록 재배치하려는 워크로드를 이해하는 것입니다. 재배치하는 모든 워크로드는 평가 단계부터 시작하여 이동 단계의 4단계를 거쳐야 합니다.

이동 단계에서 재배치 프로세스 및 강조 표시를 보여 주는 다이어그램 재배치 프로세스에는 2단계와 5단계가 있습니다. 첫 번째 단계는 시작 단계이며 시작이라는 한 단계가 있습니다. 두 번째 단계는 이동 단계이며 각 워크로드에 대해 반복하는 4단계가 있습니다. 단계는 평가, 선택, 마이그레이션 및 단독형입니다.

워크로드 선택

우선 순위가 지정된 워크로드 목록이 있어야 하며, 목록에서 워크로드를 재배치하려는 순서를 식별해야 합니다. 평가 단계를 방문할 때마다 목록 맨 위에 있는 워크로드를 선택합니다. 소규모 팀의 경우 한 번에 하나의 워크로드를 재배치해야 합니다. 각 워크로드 재배치를 통해 학습하고 개선할 수 있는 기회입니다. 대규모 팀은 여러 워크로드를 재배치하는 것을 고려해야 합니다. 대량 이전은 규모의 경제를 달성하는 데 도움이 될 수 있습니다.

검색 수행

워크로드 검색은 재배치의 기초입니다. 검색의 목표는 원활한 재배치를 보장하기에 충분한 워크로드를 이해하는 것입니다. 검색은 워크로드의 조직 및 기술 차원을 포괄적으로 파악해야 합니다.

조직 검색 수행

워크로드 조직 검색에는 워크로드를 담당하는 사람을 찾고, 워크로드를 이동하는 위험을 이해하고, 이동에 대해 통신하는 방법을 계획하는 작업이 포함됩니다. 이 단계를 통해 참여해야 하는 사용자를 식별하고, 위험을 관리하고, 모든 사람에게 적절한 정보를 받을 수 있습니다. 이러한 신중한 계획을 통해 비즈니스와 고객에게 전환을 원활하고 덜 방해할 수 있습니다.

  • 워크로드 소유권: 워크로드를 담당하는 사용자를 결정합니다.

  • 관련자 식별: 워크로드에 관심이 있는 모든 당사자를 식별합니다.

  • 위험 평가: 워크로드 이동과 관련된 잠재적 비즈니스 위험을 평가합니다.

  • 변경 관리: 워크로드의 변경 내용을 관리하기 위한 프로세스를 명확하게 이해합니다.

  • 중단 기간: 시스템이 재배치를 위해 오프라인으로 전환될 수 있는 허용 가능한 시간을 확인합니다.

  • 영향 분석: 재배치가 영향을 줄 수 있는 내부 사용자 또는 외부 고객을 인식합니다.

  • 통신 요구 사항: 가동 중지 시간 또는 변경 내용을 전달하기 위한 현재 및 필요한 통신 계획을 이해합니다.

  • 정책 준수: 이전이 조직 정책 및 업계 규정을 준수하는지 확인합니다.

기술 검색 수행

기술 워크로드 검색에는 종속성, 리소스, 네트워크 구성 및 기타 기술 요구 사항 또는 제약 조건을 포함하여 워크로드의 기술적 측면을 포괄적으로 이해해야 합니다. 기술 검색을 통해 재배치와 관련된 위험을 예측하고 완화할 수 있습니다. 기술 검색을 수행하기 위한 전략은 다음과 같습니다.

종속성 평가

종속성은 워크로드를 실행해야 하는 리소스 또는 서비스입니다. 성공적인 워크로드 재배치를 위해서는 모든 종속성을 식별해야 합니다. 종속성은 워크로드 작업에 필수적인 다양한 리소스 및 서비스를 포함합니다. 다음 목록에서는 종속성의 몇 가지 예를 제공합니다.

  • Azure 서비스: 워크로드가 사용하는 모든 Azure 서비스입니다. 전역 리소스는 특정 지역에 배포되지 않으므로 재배치에서 이동할 필요가 없습니다. 그러나 다른 지역에서 작동하도록 다시 구성할 수도 있습니다. 예를 들어 재배치된 워크로드의 새 IP 주소를 가리키도록 Azure Front Door 프로필의 IP 주소를 업데이트해야 할 수 있습니다.

  • 타사 애플리케이션: 워크로드에 통합되거나 필요한 다른 공급업체의 애플리케이션입니다. 워크로드와 관련된 제품의 기능 및 제한 사항을 이해합니다.

  • 라이선스: 모든 필수 소프트웨어 라이선스가 고려되고 새 위치에서 유효한지 확인합니다.

  • 네트워킹: 재배치 후 원활한 연결을 보장하기 위해 방화벽을 포함한 네트워크 설정을 밑도는 중입니다.

  • 테스트: 새 환경에서 워크로드가 올바르게 작동하는지 확인하는 데 필요한 테스트 절차를 결정합니다.

  • 태그 지정: 효과적인 관리 및 추적을 위해 리소스에 적절하게 태그를 지정하고 식별합니다.

  • 자동화: 조직에서 스크립트와 인프라를 코드로 사용할 수 있습니다. 스크립트 또는 코드 내에서 Azure 지역, 서비스 이름 또는 서비스 URL에 대한 참조를 업데이트해야 합니다. 참조는 이동하는 새 Azure 지역에 해당해야 합니다.

    워크로드 수명 주기 동안 변경될 수 있는 코드의 값을 하드코딩하지 않아야 합니다. 대신 이러한 값을 동적으로 검색하거나 코드 내에서 구성 가능한 매개 변수를 사용합니다. 이 방법은 변경을 덜 부담하게 만들고 보다 원활한 재배치 프로세스를 보장합니다.

  • DNS: Azure는 지역에 따라 엔드포인트에 공용 IP 주소를 할당합니다. 엔드포인트를 다른 Azure 지역으로 이동하면 다른 IP 주소를 가져옵니다. 이러한 새 IP 주소로 DNS 레코드를 업데이트해야 합니다. 또한 '허용' 목록에 이전 IP 주소가 있는 모든 시스템에 새 IP 주소를 제공해야 합니다.

    이전 리소스를 해제하기 전에 새 Azure 지역에 새 리소스를 배포해야 할 수 있습니다. 이 경우 두 리소스에 동일한 DNS 이름을 한 번에 가질 수 없는 문제가 발생할 수 있습니다. 이 문제를 방지하기 위해 각 서비스에 고유한 이름을 사용하는 것이 좋습니다. 경우에 따라 CNAME 레코드를 사용하여 추상화 계층을 제공할 수 있습니다. 이렇게 하면 리소스 이름을 보다 쉽게 관리할 수 있습니다.

  • Load Balancer 새 백 엔드 IP 주소 또는 호스트를 가리키도록 부하 분산 장치를 업데이트합니다. DNS 기반 부하 분산 장치의 경우 DNS 캐시 및 TTL(Time to Live) 레코드 만료에 따라 변경 내용이 전파되는 데 다소 시간이 걸릴 수 있습니다. 자세한 내용은 Azure 부하 분산 서비스를 참조 하세요. DNS 레코드에 대한 TTL(Time to Live) 설정을 일시적으로 줄이는 것이 좋습니다. DNS 레코드가 새 IP 주소로 더 빠르게 전환하는 데 도움이 됩니다. 또한 짧은 기간 동안 백 엔드 시스템의 상태를 더 자주 확인하도록 부하 분산 장치를 설정하는 것이 좋습니다. 나중에 추가 비용과 성능 저하를 방지하려면 마이그레이션 후 이러한 설정을 다시 정상으로 변경해야 합니다.

  • Azure Backup 등록. 가상 머신을 새 Azure 지역으로 이동하는 경우 현재 지역의 Azure Backup 서비스에서 등록을 취소하고 새 지역의 Azure Backup 서비스에 등록해야 합니다. 기존 백업 복구 지점은 새 백업 자격 증명 모음으로 전송할 수 없으므로 액세스할 수 없습니다. 새 지역에서 새 복구 지점 만들기를 시작해야 합니다.

엔드포인트 평가

엔드포인트 검색은 워크로드와 연결된 모든 엔드포인트 또는 IP 주소를 식별하는 프로세스를 나타냅니다. 모든 워크로드 엔드포인트를 검색하면 모든 네트워크 연결 및 액세스 지점을 고려하고 새 환경에서 올바르게 구성할 준비를 할 수 있습니다. 공용 IP 주소 및 프라이빗 엔드포인트를 처리하기 위한 권장 사항은 다음과 같습니다.

  • 공용 IP 주소: 공용 IP 주소는 지역별로 다릅니다. 지역 간에 이동할 수 없습니다. 공용 IP의 구성을 내보내고 새 대상 지역에 배포해야 합니다. 자세한 내용은 Azure 공용 IP 구성을 다른 Azure 지역으로 이동을 참조하세요.
  • 프라이빗 엔드포인트: 프라이빗 엔드포인트를 다시 배포하면 연결하는 서브넷에서 새 IP 주소를 얻을 수 있습니다. 프라이빗 엔드포인트를 통해 리소스에 연결하는 경우 이러한 엔드포인트는 가상 네트워크 내에서 리소스의 네트워크 주소를 확인하는 프라이빗 DNS 영역에 연결됩니다. 재배치에서는 연결을 유지하기 위해 프라이빗 DNS 영역 내의 DNS 레코드를 업데이트해야 합니다.

자동화된 도구 사용

가능한 경우 자동화된 도구를 사용하여 워크로드를 구성하는 애플리케이션 및 Azure 서비스에 대한 정보를 수집합니다. 이러한 도구를 사용하여 특정 워크로드의 재배치에 대해 낮은 수준의 검색 및 아키텍처 디자인 검색을 수행할 수 있습니다. 다음 Azure 도구 및 서비스를 사용해야 합니다.

Azure Resource Mover를 사용해 보세요. 먼저 Azure Resource Mover를 시도해야 합니다. 현재 사용할 수 있는 가장 쉬운 검색 도구이며 서비스와 데이터를 서비스로 재배치할 수도 있습니다. 그러나 Azure Resource Mover는 제한된 수의 서비스만 지원하므로 계속하기 전에 서비스가 지원되는지 확인합니다. 자세한 내용은 Azure Resource Mover에 대해 지원되는 리소스를 참조 하세요.

시각화 도구를 사용합니다. Azure Resource Mover가 모든 요구 사항을 충족하지 않는 경우 시각화 도구를 사용하여 검색을 수행할 수 있습니다. Azure에는 종속성을 매핑하는 데 사용할 수 있는 여러 시각화 도구가 있습니다. 요구 사항을 가장 잘 지원하는 도구를 선택합니다.

  • 리소스 그룹 시각화 도우미: 리소스 그룹의 리소스 간 연결을 시각화할 수 있습니다. Azure Portal에서 리소스 그룹으로 이동하고 왼쪽 탐색에서 리소스 시각화 도우미를 선택합니다.

  • Azure Monitor 토폴로지: Azure Monitor에서 토폴로지 기능을 사용하여 네트워크 종속성을 볼 수 있습니다. 자세한 내용은 네트워크 인사이트 토폴로지 참조하세요.

  • Application Insights: Application Insights에는 분산 애플리케이션의 논리적 구조를 볼 수 있는 애플리케이션 매핑 기능이 있습니다. 자세한 내용은 Azure 애플리케이션 Insights의 애플리케이션 맵을 참조하세요.

  • Azure 리소스 탐색기: Azure Resource Explorer는 Microsoft Entra 테넌트에 있는 모든 리소스를 나열합니다. 가시성을 제공하지만 종속성을 나타내지는 않습니다. 워크로드 구성 요소 및 종속성을 수동으로 매핑해야 합니다. 자세한 내용은 Azure Resource Explorer를 참조하세요.

  • Azure Resource Graph: Azure Resource Graph를 사용하면 Microsoft Entra 테넌트의 리소스에 대해 쿼리를 실행할 수 있습니다. Resource Graph는 포털 및 명령줄에서 액세스할 수 있습니다. 워크로드 구성 요소 및 종속성을 수동으로 매핑해야 합니다. 자세한 내용은 Azure Resource Graph 설명서를 참조 하세요.

  • 인벤토리 대시보드: Azure Portal에서 기본 제공 인벤토리 템플릿을 사용하여 기존 리소스를 추적하는 대시보드를 만들 수 있습니다. 리소스와 인스턴스 수를 빠르게 확인할 수 있습니다.

수동으로 설명서 만들기

자동화된 검색 방법만으로는 충분하지 않은 경우 워크로드에 대한 수동 평가를 수행할 수 있습니다. 대부분의 수동 평가는 기술 전문가와의 인터뷰 및 기술 설명서에 의존하여 필요한 정보를 얻습니다. 제품 또는 응용 프로그램 소유자를 식별하고 인터뷰합니다. 이러한 인터뷰는 선택 사항이지만 팀이 도구에서 제공하는 정보의 격차를 해소해야 하는 경우 필요합니다. 또한 앱 소유자는 태그를 끌어와 종속성을 수동으로 식별할 수 있습니다.

지역 지원 가능성 찾기

Azure의 모든 지역이 동일한 서비스를 제공하는 것은 아니므로 워크로드를 실행하는 데 필요한 서비스를 대상 지역에서 사용할 수 있는지 확인해야 합니다. 이 결정을 내리는 프로세스의 후반부로 보일 수 있지만 지원 가능성을 보장하기 위해 검색 세부 정보가 필요합니다. 워크로드에 대한 지역 지원 가능성을 확인하려면 각 Azure 지역에서 사용할 수 있는 제품 및 서비스를 참조하세요.

대상 지역이 쌍을 이루는 지역인지 여부와 가용성 영역을 지원하는지 여부를 확인합니다. 지역 페어링 및 가용성 영역은 재배치 노력에 영향을 주지 않지만 대상 지역의 BCDR(비즈니스 연속성 및 재해 복구) 전략에 영향을 줍니다. 자세한 내용은 Azure 지역가용성 영역을 참조하세요.

워크로드 서비스 분류

재배치는 서비스 및 구성 요소 수준에서 발생합니다. 대부분의 워크로드는 여러 서비스를 사용합니다. 상태 저장 및 상태 비정상 서비스의 두 가지 기본 유형이 있습니다. 각 서비스를 상태 저장 또는 상태 비주류로 분류해야 합니다. 이 지식은 종속성을 결정하고, 서비스 통합을 이해하고, 재배치 자동화 옵션을 좁히는 데 도움이 됩니다.

  • 상태 비지정 서비스: 상태 비지정 서비스에는 구성 정보만 있습니다. 이러한 서비스는 이동하는 데이터의 연속 복제가 필요하지 않습니다. 예를 들어 가상 네트워크, 네트워크 어댑터, 부하 분산 장치 및 네트워크 보안 그룹이 있습니다.

  • 상태 저장 서비스: 상태 저장 서비스에는 이동해야 하는 구성 정보 및 데이터가 있습니다. 가상 머신 및 SQL 데이터베이스를 예로 들어 있습니다.

다음 단계

워크로드를 평가하면 재배치 방법 및 선택한 메서드를 실행할 도구를 선택할 수 있는 충분한 정보가 제공됩니다. 선택 단계에서는 재배치 방법 및 재배치 방법에 대한 올바른 도구를 선택하는 결정을 안내합니다.