AWS Application Migration Service를 사용한 마이그레이션 - AWS 권장 가이드
장점단점최적의 시나리오

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

AWS Application Migration Service를 사용한 마이그레이션

를 AWS 사용하기 위한 대부분의 대규모 lift-and-shift 마이그레이션AWS Application Migration Service. 이 서비스는 직접 연결된 블록 스토리지 디바이스(예: 하드 드라이브 또는 SAN 드라이브)에 저장된 데이터를 AWS의 해당 Amazon Elastic Block Store(Amazon EBS) 스토리지 디바이스로 이동하여 물리적 수준에서 작동합니다. 기본적으로 기존 백업/복원 절차(하드 드라이브를 복제하여)를 구현하지만, 스테이징 영역의 소스 시스템과 대상 스토리지 디바이스 간에 지속적 데이터 보호(CDP) 동기화 모드를 달성하여 복구 시점 목표(RPO)를 거의 초로, 복구 시간 목표(RTO)를 분으로 제공합니다.

이 블록 수준 복제 방법은 네트워크 연결 스토리지(NAS), NFS(Network File System) 공유와 같은 공유 드라이브 또는 CIFS(Common Internet File System)/SMB(Server Message Block) 공유를 지원하지 않습니다. 마이그레이션 시 마이그레이션된 시스템에 직접 연결된 블록 수준 스토리지만 지원합니다. (자세한 내용은 SAN/NAS 지원에 대한 Application Migration Service FAQ를 참조하세요.) 이는 대부분의 클러스터가 다양한 구현의 공유 스토리지에 의존하기 때문에 대부분의 클러스터링된 시스템에 대해 Application Migration Service를 통한 복제 적용 가능성을 제한합니다. 자세한 내용은이 페이지의 장점 및 단점 섹션을 참조하세요.

블록 수준 복제 방법을 사용하려면 운영 체제(OS) 수준에서 AWS 복제 에이전트를 설치해야 하며, 해당 에이전트는 Windows 또는 Linux 운영 체제를 기반으로 하는 x86 플랫폼만 지원합니다(Application Migration Service에서 지원하는 운영 체제 참조). Non-x86 플랫폼은이 마이그레이션 방법의 범위를 벗어납니다. 여기에는 ARM, RISC/CISC 시스템, PowerPC 변형, pSeries, iSeries, zSeries와 같은 IBM 시스템 및 AIX, HP-UX, Solaris, PowerPC용 Linux, 메인프레임의 zLinux 및 기타 비x86 아키텍처와 같은 해당 운영 체제가 포함됩니다.

AWS Replication Agent는 OS 스택의 가상 파일 시스템 디바이스 드라이버* 수준에서 작동하여 다음 질문 아래의 Application Migration Service FAQ 페이지에 설명된 대로 기본 블록 수준 디바이스(드라이브, 하드 드라이브 및 직접 연결된 SAN 디바이스 포함)에 쓸 데이터 블록을 캡처합니다.

* Wikipedia의 파일 시스템, 가상 파일 시스템 및 디바이스 드라이버 정의를 참조하세요.

장점

모든 규모의 lift-and-shift 마이그레이션의 경우 Application Migration Service에는 다음과 같은 많은 이점이 있습니다.

  • 복제는 설정하기 쉽습니다(가파른 학습 곡선이 필요하지 않음).

  • 소스 머신에서 에이전트를 롤아웃하여 빠르게 확장할 수 있습니다.

  • Cloud Migration Factory를 사용하면 대부분의 수동 작업을 자동화하고, 여러 시스템을 관리하고, 마이그레이션 웨이브를 오케스트레이션할 수 있습니다.

  • 광범위한 x86 운영 체제 아키텍처를 지원합니다.

  • 모든 유형의 소스 환경(온프레미스 데이터 센터, 기타 클라우드 또는 기타)을 지원합니다 AWS 리전.

  • 애플리케이션에 구애받지 않으므로 소스 서버에서 실행되는 모든 애플리케이션을 지원합니다.

  • 라이선스나 구매는 필요하지 않습니다. AWS 는 pay-as-you-go 요금을 제공하므로 장기 계약이나 복잡한 라이선스 없이 서비스를 사용하는 동안에만 서비스에 대한 요금을 지불합니다. Application Migration Service는 서버당 90일의 무료 기간을 제공하며, 이는 대부분의 마이그레이션에 충분합니다. 자세한 내용은 AWS 웹 사이트의 AWS Application Migration Service 요금을 참조하세요.

단점

Application Migration Service와 같은 블록 수준 복제 도구를 사용하는 경우 다음과 같은 모서리 사례와 고려해야 할 요소가 발생할 수 있습니다.

  • Application Migration Service는 탑재된 공유 파일 시스템 또는 CIFS/SMB 및 NFS 파일 시스템을 포함한 NAS와 같은 공유 스토리지 디바이스를 지원하지 않습니다. NAS 또는 공유 파일 시스템의 복제 방법에 대한 자세한 내용은 NFS 공유를 마이그레이션하기 위한 MGN 복제 에이전트(AWS re:Post 문서) 및 AWS 대규모 마이그레이션에서 공유 파일 시스템 마이그레이션(AWS 권장 가이드 패턴)을 참조하세요.

  • Application Migration Service는 공유 스토리지가 있는 대부분의 클러스터링된 파일 서버 또는 데이터베이스 클러스터 구성을 지원하지 않습니다. 공유 스토리지가 디바이스 드라이버 계층을 통해 OS 수준으로 표시되는 방식에 제한이 있기 때문입니다. 예를 들어 Storage Space Direct(S2D) 옵션이 있는 Microsoft SQL Server 클러스터는 지원되지 않습니다. 그러나 Application Migration Service를 사용하여 공유 블록 스토리지가 있는 다른 유형의 클러스터링된 시스템을 복제할 수 있습니다. 예: Windows Server 장애 조치 클러스터(WSFC)의 장애 조치 클러스터 인스턴스(FCI) 구성의 공유 스토리지, 블로그 게시물 CloudEndure Migration을 AWS 사용하여 Microsoft Windows 클러스터를 로 마이그레이션에 설명된 대로 외부 SAN 배열에서 노출된 스토리지(iSCSI 연결), 및 특정 모서리의 일부 Microsoft SQL Server Always On 가용성 그룹(AAG) 클러스터. 일반적으로 Application Migration Service는 마이그레이션 중에 스토리지 디바이스가 서버에 완전히 있는 서버에서 블록 수준 디바이스의 복제를 지원합니다. ( AWS 복제 에이전트가 서버에 설치되어 있어야 하며 복제를 위해 디바이스가 에이전트에 표시되어야 합니다.) 그러나 이러한 모든 시나리오에는 매우 구체적인 절차가 필요하므로 전환 기간이 길어집니다. 

  • OLTP 데이터베이스와 같이 데이터 변경률이 높은 시스템은 성능이나 네트워크 요구 사항이 더 높아 마이그레이션 작업이 복잡해질 수 있습니다.

  • 네트워크 대역폭은 계획된 마이그레이션 및 전환 기간 내에 전송할 데이터 양에 충분해야 합니다. Application Migration Service는와 달리 오프라인 배송 옵션을 제공하지 않기 때문입니다AWS Snowball. 

  • 마이그레이션에는 몇 분이라는 RTO 내에서 약간의 가동 중지 기간이 필요합니다. Application Migration Service는 마이그레이션 프로세스의 일부로 EBS 스냅샷을 사용하며, 이러한 스냅샷에서 생성된 새 EBS 디스크는 처음에 성능이 저하됩니다. 일부 데이터베이스 읽기 패턴의 경우 마이그레이션된 데이터베이스가 최대 성능을 발휘할 때까지 유효 전환 기간이 늘어날 수 있습니다. 

최적의 시나리오

Application Migration Service는 이전 두 섹션에서 설명한 것처럼 거의 단점 없이 거의 모든 lift-and-shift 마이그레이션을 완전히 다룹니다. 이 도구는 이러한 시스템에 필요한 긴 전환 기간이 마이그레이션 요구 사항을 충족하는 한 데이터베이스 클러스터와 같은 대부분의 특수 사례를 처리할 수 있습니다. 

다음 섹션에서는 두 가지 시나리오를 좀 더 자세히 다룹니다.

  • 여러 마이그레이션 웨이브를 사용하는 대규모 마이그레이션

  • 가동 중지 시간을 최소화해야 하는 단일 애플리케이션 마이그레이션 

여러 마이그레이션 웨이브를 사용하는 대규모 마이그레이션

대규모 마이그레이션의 예로는 크기 및 속도 요구 사항을 특징으로 하는 데이터 센터 출구가 있습니다. 또한 일반적으로 데이터 센터의 임대 계약 종료와 같은 특정 시간 제약이 수반됩니다. 이 경우에는 규모에 따라 접근 방식이 결정됩니다. 마이그레이션 웨이브는 데이터베이스를 포함한 애플리케이션별로 결정되고 그룹화되며, 각 웨이브에는 구체적인 가동 중지 시간 요구 사항과 함께 계획된 준비, 마이그레이션 및 최종 전환 단계가 있습니다. 

각 마이그레이션 웨이브 내에서 데이터베이스 서버는 별도의 마이그레이션 접근 방식이 필요할 수 있는 다음과 같은 특수한 경우에 대한 몇 가지 예외를 제외하고 Application Migration Service 블록 수준 복제를 사용하여 대규모로 이동하는 것이 가장 좋습니다.

  • 대부분의 클러스터형 데이터베이스 시스템

  • 변경률이 사용 가능한 네트워크 처리량을 초과하는 데이터베이스 시스템(복제 지연이 발생할 수 있음) 

각각의 특수한 경우에 대해 가동 중지 시간 요구 사항과 다른 마이그레이션 도구를 사용하는 데 필요한 노력 수준 간의 균형을 고려하세요. 경우에 따라 별도의 도구를 사용하고 특정 시스템에 대해 다른 프로세스를 생성하는 대신 모든 시스템에 동일한 마이그레이션 접근 방식을 사용하는 것이 훨씬 더 쉽습니다. Application Migration Service가 특정 시스템의 가동 중지 시간 요구 사항을 지원하지 않는 경우 기본 데이터베이스 도구를 사용한 마이그레이션 섹션에 설명된 방법 중 하나를 대신 사용하는 것이 좋습니다.

단일 애플리케이션 마이그레이션

단일 애플리케이션 시나리오는 마이그레이션 중 가동 중지 시간이 최소화되거나 거의 0에 가까워야 하는 단일 비즈니스 크리티컬 애플리케이션 또는 이러한 몇몇 애플리케이션을 마이그레이션하는 세부적인 접근 방식을 나타냅니다. 마이그레이션 범위는 이전(대규모 마이그레이션) 시나리오의 속도 및 규모 요구 사항과 달리 비즈니스 중요도 및 가동 중지 시간 요구 사항에 따라 다를 수 있습니다. 애플리케이션이 Application Migration Service의 RTO 내에서 가동 중지를 허용하는 경우 앞서 설명한 대규모 마이그레이션과 동일한 방식으로 처리해야 합니다. 

그러나 전환 시간이 가능한 한 최소에 가까워야 하는 경우, 예를 들어 마이그레이션된 데이터베이스에 최대 성능으로 작동하는 데 오랜 시간이 필요한 읽기 패턴이 있고 전환 기간이 작게 유지되어야 하는 경우, 보다 세부적이고 세분화된 접근 방식을 고려해야 합니다. 일반적으로 이러한 접근 방식에는 추가 단계와 요구 사항이 포함되므로 더 많은 노력과 시간이 필요합니다. 이 단계 중 하나는 애플리케이션 서버 마이그레이션에서 데이터베이스 마이그레이션을 분리하고 다음 섹션에서 설명한 데이터베이스 마이그레이션 도구를 사용하여 소스 데이터베이스와 대상 데이터베이스를 동기화된 상태로 유지하는 것입니다. 다양한 방법을 사용하여 동기화할 수 있습니다. 각 메서드에는 장단점이 있으며 가동 중지 시간과 동기화 복잡성 간의 장단점이 서로 다릅니다. 하지만 소스 환경과 대상 환경 간에 데이터베이스를 동기화된 상태로 유지하면 애플리케이션 계층에서 데이터베이스 계층의 연결을 해제할 수 있습니다. 애플리케이션 서버가 영구 데이터를 로컬에 저장하지 않고 모든 데이터를 데이터베이스 계층에 전달한다고 가정하면 동기화는 애플리케이션 계층에서 가동 중지 제한도 제거합니다. 

데이터베이스와 애플리케이션 계층을 분리하면 이전 시나리오와 같이 Application Migration Service를 사용하여 애플리케이션 서버를 마이그레이션할 수 있습니다. 소스 시스템이 계속 작동하고 데이터를 처리하고 데이터베이스 계층에 저장하는 동안 대상 환경에서 대상 애플리케이션 서버를 시작할 수 있습니다. 데이터베이스 계층이 이미 대상과 동기화되어 있으므로 전환 시간은 최소화됩니다. 여기에는 네트워크를 전환하고 이전 소스 시스템에서 대상 환경으로 고객 요청을 리디렉션하는 것만 포함됩니다. 블루/그린 배포에 대한 지침에 따라 일반적으로 DNS 엔드포인트 전환, 가중치 기반 DNS 영역 사용, TTL(Time to Live) DNS 전파 지연을 줄이기 위한 AWS Global Accelerator 사용 및 이와 유사한 방법 등 다양한 방법을 사용하여 이 작업을 수행할 수 있습니다.