윈도우 환경 디스커버리

애플리케이션 마이그레이션 서비스와 같은 현재 사용 가능한 기술을 사용하면 Windows Server, Linux 및 기타 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) 를 사용하여 보유한 서버를 표준화해야 합니다.

좋은 데이터

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

자동화

자동화는 대규모 마이그레이션에 필수적입니다. 자동화의 예로는 에이전트 설치, 자동화에 필요한 유틸리티의 소프트웨어 버전 업데이트 (예: .NET 또는PowerShell, AWS 시스템 관리자 에이전트 (SSM 에이전트), Amazon과 같은 AWS용 소프트웨어 로드 또는 업데이트CloudWatchAWS에서 실행하는 데 필요한 에이전트 또는 기타 백업 또는 관리 소프트웨어

세부 계획

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

• 용도웨이브 플래닝종속성과 우선 순위에 따라 서버를 웨이브로 구성할 수 있습니다.

• 용도주간 계획(컷오버까지 이어짐) 애플리케이션 팀과 통신하고 네트워크, DNS, 방화벽 및 컷오버 중에 해결해야 하는 기타 세부 정보를 식별합니다.

• 상세 사용, hour-to-hour계획(실제 컷오버 주변) 컷오버 유지 관리 기간을 설명합니다.

• 용도진행/불참 기준어떤 상황에서 애플리케이션이 AWS로 넘어간 것으로 간주되거나 소스 위치로 페일백되어야 하는지 설명합니다.

• 용도청소 활동반드시 완료해야 하는 후속 활동으로 이러한 활동은 컷오버 유지 관리 기간 외에 또는 완료 후에 발생할 수 있습니다.하이퍼케어. 정리 작업에는 백업 및 다양한 에이전트 확인, 서버에서 Application Migration Service 에이전트 제거 또는 소스 서버 및 관련 리소스 제거 등이 포함됩니다.

동원

모바일 단계에서는 조직의 복잡성과 변이를 최대한 많이 발견하여 마이그레이션 계획 중에 고려할 수 있도록 하는 것이 중요합니다. 이상적으로는 컷오버 유지 관리 기간 동안 이러한 복잡성과 변형을 다루지 않고 장애 복구를 방지할 수 있습니다.

대규모 마이그레이션의 어려움

마이그레이션 실패는 애플리케이션 또는 애플리케이션이 새 환경으로 전환되어 마이그레이션 유지 관리 기간 내에 성능 또는 기능 요구 사항을 충족할 수 없을 때 발생합니다. 이로 인해 애플리케이션 또는 애플리케이션이 원래 위치로 페일백됩니다. 또한 해당 애플리케이션 또는 애플리케이션에 종속된 다른 모든 애플리케이션도 페일백해야 합니다. 애플리케이션 일정을 조정해야 하기 때문에 마이그레이션 실패는 현재의 파도뿐만 아니라 미래의 웨이브에도 영향을 미치는 경향이 있습니다.

지연 시간에 민감한 종속성

마이그레이션 실패의 주요 원인은 지연 시간에 민감한 종속성입니다. 지연 시간에 민감한 종속성을 식별하지 못하면 성능 문제가 발생하여 응답 시간이나 트랜잭션 시간이 지나치게 길어질 수 있습니다. 예를 들어, 일반적으로 애플리케이션은 데이터베이스와 애플리케이션 서버를 동시에 클라우드로 이동합니다. 서로 자주 통신하고 동일한 데이터 센터에 있을 때 1밀리초 미만의 응답 시간이 필요하기 때문입니다. 데이터베이스만 클라우드로 이동하면 이러한 트랜잭션에 몇 초의 지연 시간이 발생하여 애플리케이션 성능에 상당한 영향을 미칠 수 있습니다. 이는 서로 의존도가 높고 제대로 작동하려면 동일한 데이터 센터에 있어야 하는 애플리케이션에도 적용됩니다.

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

IT 공유 서비스

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

구성 업데이트

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

• 방화벽 규칙

• 허용 목록

• DNS 레코드

• 연결 문자열

구성을 제대로 업데이트하지 않으면 워크로드, 해당 사용자 및 종속 시스템이 서로 통신하지 못할 수 있습니다. 운영 중단 기간 내에 이러한 문제를 해결하는 것은 가능하지만, 현재 변경에는 시간이 많이 걸리거나 시간 내에 충족되지 않는 변경 기록이 필요할 수 있습니다.

애플리케이션 기능 테스트

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

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

애플리케이션 간 종속성을 결정하는 것은 성공적인 마이그레이션을 위해 매우 중요하며, 지연 시간에 민감한 종속성과 연결 구성 항목을 감지하는 데 모두 중요합니다. 시장에는 다음과 같이 종속성을 검색하는 데 사용할 수 있는 몇 가지 도구가 있습니다.애플리케이션 검색 서비스(에이전트 및 에이전트리스 툴) 및클라우드마이즈(에이전트 기반 도구)

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

• 소요 시간— 알려진 피크, 월말 및 기타 이벤트와 같은 애플리케이션별 이벤트를 캡처할 수 있을 만큼 오랫동안 검색 도구를 실행하는 것이 좋습니다. 권장 최소 기간은 30일입니다.

• 액티브 (에이전트 기반)— 액티브 종속성 검색 툴은 운영 체제의 커널에 내장되어 모든 트랜잭션을 캡처하는 경우가 많습니다. 그러나 이 방법은 일반적으로 가장 비용이 많이 들고 시간이 많이 걸리는 방법입니다.

• 패시브 (에이전트 없음)— 패시브 종속성 검색 툴은 훨씬 저렴하고 빠르게 구현할 수 있지만 덜 사용되는 연결을 놓칠 위험이 있습니다.

• 제도적 지식— 애플리케이션 검색 툴은 보다 상세하고 정확한 정보를 제공하지만 대부분의 조직에서는 애플리케이션 팀과 해당 기관의 지식을 활용하여 애플리케이션 상관 관계를 파악합니다. 애플리케이션 팀은 대기 시간에 민감한 종속성에 대해 잘 알고 있는 경우가 많지만 연결 구성 설정, 방화벽 규칙 또는 파트너의 허용 목록 요구 사항과 같은 일부 세부 정보를 놓치는 경우가 드물지 않습니다. 기관 지식을 활용하여 애플리케이션 종속성 검색을 개선할 수 있지만 관련된 위험도 고려하고 완화하는 것이 좋습니다. 예를 들어 애플리케이션 팀의 지식에만 의존한다면 연결 구성 항목이나 지연 시간에 민감한 종속성을 놓칠 위험이 있습니다. 이로 인해 중단이 발생하거나 마이그레이션이 실패할 수 있습니다. 이러한 위험을 줄이려면 상세한 애플리케이션 기능 테스트를 수행하는 것이 좋습니다.