기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Windows 환경 검색

Windows Server, Linux AWS Application Migration Service및 기타 x86 기반 운영 체제와 워크로드를 로 이전하는 것과 같은 오늘날의 사용 가능한 기술을 사용하면 AWS 매우 간단합니다. 그러나 이러한 워크로드가 제대로 작동하도록 하고 대규모로 수행하면 다른 문제가 발생합니다. 이 섹션은 Microsoft 워크로드를 빠르고 안전하며 원활하게 마이그레이션할 수 있는 마이그레이션 고려 사항을 식별하기 위한 것입니다.

평가

계획 및 자동화를 최소화하면서 소규모 마이그레이션(예: 서버 100개가 포함된 마이그레이션)을 '차단력'으로 수행할 수 있지만이 방법을 사용하면 500개 이상의 서버를 이동할 수 없습니다. 다음 고려 사항은 성공적인 대규모 마이그레이션의 주요 기여자이며 마이그레이션 준비 상태 평가(MRA)를 사용하여 집중하려는 고려 영역을 식별할 수 있습니다.

엔터프라이즈 아키텍처

환경에 기술 부채가 많을수록 마이그레이션하기가 더 어렵습니다. 정상적인 엔터프라이즈 아키텍처 프로그램을 보유한 조직은 환경을 최신 버전의 소프트웨어 및 시스템(주로 주요 릴리스의 N 및 N -1 버전이라고 함)으로 제한하기 위해 노력합니다. 이렇게 하면 고려해야 할 시나리오 수가 줄어들 뿐만 아니라 최신 릴리스의 발전도 활용할 수 있습니다. 예를 들어 Windows Server 2012, Windows Server 2008 및 이전 버전의 Windows Server는 Windows Server 환경에서 최신 버전보다 자동화하기가 점점 더 어렵습니다. 이전 버전과 지원되지 않는 버전에서도 라이선싱이 더 어렵습니다.

표준화 및 구성 관리

환경 표준화는 고려해야 할 또 다른 요소입니다. 수동으로 빌드되고 유지 관리되는 환경이 있는 조직은 반려동물과 유사한 것으로 간주됩니다. 각 시스템은 고유하며 표준화된 이미지, 코드형 인프라(IaC) 또는 지속적 통합 및 지속적 전송(CI/CD) 파이프라인을 사용하여 구축된 경우보다 구성 조합이 훨씬 더 많습니다.

예를 들어 개별 서버를 수동으로 마이그레이션하는 대신 마이그레이션할 때 IaC 또는 CI/CD를 사용하여 일반적인 웹 서버를 다시 빌드하는 것이 좋습니다. 또한 데이터베이스, 파일 공유 또는 리포지토리와 같은 데이터 스토어에 모든 영구 데이터를 저장하는 것이 모범 사례입니다. IaC 또는 CI/CD를 사용하여 시스템을 재구축하지 않는 경우 최소한 구성 관리 도구(예: Puppet, Chef 또는 Ansible)를 사용하여 보유한 서버를 표준화해야 합니다.

좋은 데이터

좋은 데이터도 성공적인 마이그레이션의 핵심 요소입니다. 자동화 및 계획을 위해서는 현재 서버 및 메타데이터에 대한 정확한 데이터가 필수적입니다. 좋은 데이터가 부족하면 마이그레이션을 계획할 때 어려움이 커집니다. 좋은 데이터의 예로는 서버의 정확한 인벤토리, 서버의 애플리케이션, 버전이 있는 서버의 소프트웨어, CPUs 수, 메모리 양, 디스크 수가 있습니다. 웨이브 플래너가 계획에 필요한 모든 데이터 또는 마이그레이션 프로세스 자동화의 일부로 사용하려는 모든 데이터를 캡처하는 것이 좋습니다.

자동화

대규모 마이그레이션에는 자동화가 필수적입니다. 자동화의 예로는 에이전트 설치, .NET 또는 PowerShell과 같은 자동화에 필요한 유틸리티의 소프트웨어 버전 업데이트, AWS Systems Manager 에이전트(SSM 에이전트), Amazon CloudWatch 에이전트 또는 실행에 필요한 기타 백업 또는 관리 소프트웨어 AWS 와 같은에 대한 소프트웨어 로드 또는 업데이트 등이 있습니다 AWS.

세부 계획

대규모 마이그레이션에는 세부 계획을 개발하고 관리하는 것도 필수적입니다. 몇 주 동안 매주 50개의 서버를 마이그레이션하려면 잘 정의된 계획이 있어야 합니다. 효과적인 계획에는 다음이 포함됩니다.

동원

동원 단계에서는 마이그레이션 계획 중에 고려될 수 있도록 조직의 복잡성과 변형을 최대한 많이 발견하는 것이 중요합니다. 전환 유지 관리 기간 동안 이러한 복잡성 및 변형을 처리하지 않고 장애 복구를 방지하는 것이 가장 좋습니다.

대규모 마이그레이션의 과제

마이그레이션 실패는 애플리케이션 또는 애플리케이션이 새 환경으로 전환되어 마이그레이션 유지 관리 기간 내에 성능 또는 기능 요구 사항을 충족할 수 없는 경우에 발생합니다. 이렇게 하면 애플리케이션 또는 애플리케이션이 원래 위치로 다시 실패합니다. 또한 해당 애플리케이션 또는 애플리케이션에 종속된 다른 모든 애플리케이션도 장애 복구해야 합니다. 실패한 마이그레이션은 애플리케이션을 다시 예약해야 하므로 현재 웨이브뿐만 아니라 향후 웨이브에도 영향을 미치는 경향이 있습니다.

지연 시간에 민감한 종속성

마이그레이션이 실패한 주요 이유는 지연 시간에 민감한 종속성입니다. 지연 시간에 민감한 종속성을 식별하지 못하면 성능 문제가 발생하여 응답 시간 또는 트랜잭션 시간이 허용되지 않을 수 있습니다.

예를 들어 일반적으로 애플리케이션은 데이터베이스와 애플리케이션 서버를 동시에 클라우드로 이동합니다. 서로 자주 통신하고 둘 다 동일한 데이터 센터에 있을 때 밀리초 미만의 응답 시간이 필요하기 때문입니다. 데이터베이스만 클라우드로 이동하면 이러한 트랜잭션에 몇 초의 지연 시간이 발생하여 애플리케이션에 상당한 성능 영향을 미칠 수 있습니다. 이는 또한 서로 크게 의존하고 적절하게 수행하려면 동일한 데이터 센터에 있어야 하는 애플리케이션에도 적용됩니다.

따라서 마이그레이션을 계획할 때 애플리케이션 종속성을 이해하고 해결하는 것이 가장 중요합니다. 서로 종속된 애플리케이션과 서비스를 식별해야 함께 마이그레이션할 수 있습니다.

IT 공유 서비스

워크로드가 클라우드에 있는 경우 제대로 작동하고 적절하게 안전하게 유지 관리하려면 다양한 서비스가 필요합니다. 여기에는 랜딩 존, 네트워크 및 보안 경계, 인증, 패치, 보안 스캐너, IT 서비스 관리 도구, 백업, 접속 호스트 및 기타 리소스가 포함됩니다. 이러한 서비스가 없으면 워크로드가 제대로 작동하지 않을 수 있으며 원래 위치로 다시 실패해야 합니다.

구성 업데이트

대부분의 경우 워크로드가 클라우드로 이동한 후 워크로드가 제대로 작동하려면 몇 가지 구성을 변경해야 합니다. 이러한 구성 변경은 워크로드의 다음 종속성과 종종 연관됩니다.

적절한 구성 업데이트를 수행하지 않으면 워크로드, 사용자 및 종속 시스템이 서로 통신하지 못할 수 있습니다. 중단 기간 내에 이러한 문제를 해결할 수 있지만, 현재 변경 사항은 시간이 많이 걸리거나 제시간에 해결할 수 없는 변경 레코드가 필요할 수 있습니다.

애플리케이션 기능 테스트

대규모 마이그레이션의 또 다른 과제는 애플리케이션 기능 테스트의 필요성입니다. 이는 많은 조직이 애플리케이션 팀에 의존하여 지연 시간에 민감한 종속성, IT 공유 서비스 또는 필요한 구성 업데이트를 식별하기 때문에 특히 중요합니다. 이상적으로는 애플리케이션 팀이 전환 유지 관리 기간 동안 실행할 수 있는 서면 또는 자동 테스트 계획을 제공하여 애플리케이션이 허용 가능한 성능으로 완벽하게 작동하는지 검증하는 것이 좋습니다. 전환 유지 관리 기간을 최소로 유지하려면 30분 이내에 테스트를 완료할 수 있어야 합니다.

애플리케이션 종속성 검색을 위한 도구

성공적인 마이그레이션을 위해서는 지연 시간에 민감한 종속성과 연결 구성 항목을 모두 감지하기 위해 애플리케이션 간 종속성을 결정하는 것이 중요합니다. (에이전트 및 에이전트 없는 도구) 및 CloudamizeAWS Application Discovery Service(에이전트 기반 도구)와 같은 종속성을 검색하기 위해 마켓플레이스에서 사용할 수 있는 몇 가지 도구가 있습니다.

애플리케이션 종속성 검색을 위한 도구를 선택할 때는 다음 사항을 고려하세요.