기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 모범 사례
애플리케이션을 사용 중지하기로 선택하는 것은 특히 AWS 클라우드로 마이그레이션하는 동안 복잡한 결정일 수 있습니다. 다음 섹션에서는 의사 결정 프로세스에 사용할 수 있는 모범 사례를 제공합니다.
**Topics**
+ [마이그레이션 팩토리 접근 방식 고려](best-practice-1.md)
+ [마이그레이션 초기에 애플리케이션을 식별하고 사용 중지](best-practice-2.md)
+ [데이터를 기반으로 하고 검색 도구를 사용하여 중단을 방지](best-practice-3.md)
+ [제어 중지 설정](best-practice-4.md)
+ [애플리케이션 마이그레이션 여부 재평가](best-practice-5.md)
+ [애플리케이션 사용 중지](best-practice-6.md)
# 마이그레이션 팩토리 접근 방식 고려
대규모 마이그레이션의 중요한 부분은 초기 파일럿 워크로드를 마이그레이션한 후 *마이그레이션 팩토리*를 구축하는 것입니다.
마이그레이션 팩토리는 이전 마이그레이션 웨이브에서 배운 교훈을 통합하여 체계적인 방식으로 마이그레이션을 간소화하기 위해 협력하는 팀, 도구 및 프로세스로 구성됩니다. 마이그레이션 팩토리는 패턴을 적용하여 워크로드 마이그레이션을 가속화하고 최종 결과를 개선합니다.
사용 중지해야 하는 IT 포트폴리오의 규모에 따라 마이그레이션 팩토리 접근 방식을 구현하는 것이 가치가 있는지 고려해 볼 가치가 있습니다. 또한 이 가이드에 요약된 방법론과 원칙은 이러한 접근 방식을 보완하며 메커니즘에 포함할 수 있습니다.
일반적으로 엔터프라이즈 애플리케이션 포트폴리오의 20\$150%는 마이그레이션 팩토리 접근 방식으로 최적화할 수 있는 반복되는 패턴으로 구성되어 있습니다. 패턴의 예는 마이그레이션 팀이 마이그레이션을 조정하고 자동화하기 위해 구현할 수 있는 [AWS Cloud Migration Factory 솔루션](https://aws.amazon.com//solutions/implementations/cloud-migration-factory-on-aws/)을 참조하세요.
팀은 비즈니스 중요도가 가장 낮은 애플리케이션부터 시작하여 점차 더 중요한 시스템으로 이동해야 합니다. 팀이 비즈니스 크리티컬 시스템을 마이그레이션하기 시작할 무렵에는 수천 개는 아니더라도 수백 개의 워크로드를 마이그레이션하고 많은 교훈을 얻었을 것입니다.
평가 단계가 시작되기 전에 사용 중지될 것으로 확인된 애플리케이션에 대해 한 달 분량의 종속성 데이터를 캡처하는 프로세스를 만들 수 있습니다. 데이터가 준비되면 팀에 통보되고 데이터에 대한 액세스 권한이 부여됩니다. 그런 다음 팀은 애플리케이션이 영향을 미칠 가능성에 따라 데이터에 점수를 매깁니다. 그러면 애플리케이션 소유자가 다음 단계를 시작하기 전에 연결에 대한 심층 분석을 수행할 수 있습니다.
마이그레이션 팩토리 방법론에 대한 자세한 내용은 [AWS 대규모 마이그레이션 가이드](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/)를 참조하세요.
# 마이그레이션 초기에 애플리케이션을 식별하고 사용 중지
마이그레이션 프로세스 초기에 애플리케이션을 식별한 다음 사용 중지하는 것이 중요하며 이는 워크로드를 마이그레이션하는 동안 수행해야 합니다.
마이그레이션 프로젝트에서는 워크로드 마이그레이션을 우선순위로 두는 경우가 많기 때문에 마이그레이션되지 않고 사용 중지된 것으로 식별된 시스템에는 프로젝트 종료 시점이 집중되는 경우가 많습니다. 그러나 프로젝트가 끝날 때까지 이러한 애플리케이션을 그대로 두면 나중에 애플리케이션이 중요하다고 판단될 경우 마이그레이션에 포함시킬 시간이 거의 남지 않을 위험이 있습니다.
마이그레이션 프로젝트 중에 워크로드를 조기에 사용 중지하면 워크로드를 유지 관리하는 팀의 작업량이 줄어듭니다. 예를 들어 마이그레이션 프로젝트 초기 단계에서 서버를 사용 중지하면 운영 체제 팀이 패치, 업그레이드, 유지 관리 또는 지원할 서버 수가 줄어듭니다. 그러면 해당 팀은 마이그레이션 프로젝트 자체에 집중할 수 있습니다.
마지막으로, 이 가이드의 모범 사례 중 일부는 오랜 기간 따를 때 가장 효과적입니다. 사용 중지 프로세스를 일찍 시작했지만 나중에 다른 서비스에 애플리케이션이 실제로 필요하다고 판단되면 마이그레이션 계획을 수정하여 향후 마이그레이션 웨이브에 포함시킬 수 있습니다.
# 데이터를 기반으로 하고 검색 도구를 사용하여 중단을 방지
애플리케이션을 사용 중지할 때는 데이터를 기반으로 하는 것이 매우 중요합니다. 아키텍처 다이어그램과 제도적 지식은 구식이거나 불완전하기 쉽습니다. 고장 수리 시나리오로 인해 공식적인 개입 없이 다른 애플리케이션이 시스템에 의존하게 되는 등 예상치 못한 문제가 발생할 수도 있습니다.
데이터 기반 접근 방식은 결정을 내리거나 접근 방식을 검증할 수 있는 기반을 제공합니다. 애플리케이션의 사용 중지 가능 여부를 평가할 때는 마이그레이션하는 워크로드가 해당 애플리케이션에 종속되지 않는지 확인해야 합니다. 이러한 워크로드를 마이그레이션한 다음 종속된 애플리케이션을 사용 중지하면 서비스 성능이 저하되거나 더 심하게는 서비스가 중단될 수 있습니다.
다행히도 사용 중지될 예정인 서버의 네트워크 인바운드 및 아웃바운드 연결을 데이터를 사용하여 모니터링함으로써 이러한 종속성을 이해하는 것은 매우 간단합니다. 애플리케이션에 연결하는 애플리케이션과 같은 네트워크 인바운드 연결과 NFS(네트워크 파일 시스템) 공유로의 파일 업로드와 같은 아웃바운드 연결은 잠재적인 업스트림 종속성을 나타냅니다. AWS 클라우드로 마이그레이션해야 하는 워크로드가 애플리케이션에 연결되는 경우 나중에 애플리케이션이 사용 중지되면 서비스 중단이 발생할 수 있으므로 이러한 종속성을 조사해야 합니다. 이 프로세스에서는 종속성 체인을 추적하기 위해 심층 조사가 필요할 수도 있습니다. 이전 예에 이어 애플리케이션이 NFS 공유에 파일을 업로드하는 경우 다음 단계는 해당 파일을 사용하는 시스템과 해당 애플리케이션의 상태를 확인하는 것입니다.
이러한 연결을 조사하고 영향 수준을 평가하기로 결정할 수도 있습니다. 이를 위해 검색 도구를 사용하여 사용 중지될 예정인 서버로 시작되는 연결을 표시할 수 있습니다. 대부분의 연결은 관리 서버로부터 연결되며 성능 지표나 시스템 관리자 프록시 인스턴스를 수집하는 도구이기 때문에 무시해도 된다는 것을 알 수 있습니다. 하지만 서버에 연결하는 애플리케이션 중에 마이그레이션이 예약되어 있는 경우 해당 애플리케이션에 마이그레이션이 미칠 수 있는 잠재적 영향을 더 자세히 확인해야 합니다.
[AWS Application Discovery Service](https://aws.amazon.com/application-discovery/)는 고객이 사용 중지하려는 온프레미스 데이터 센터에 대한 정보를 수집하여 마이그레이션 프로젝트를 계획할 수 있도록 지원합니다. 에이전트를 서버에 배포한 후 Application Discovery Service는 각 서버의 인바운드 및 아웃바운드 네트워크 활동을 기타 정보와 함께 기록합니다. [Amazon Athena](https://aws.amazon.com/athena/)를 사용하여이 데이터를 분석하면 다른 애플리케이션이 사용 중지 예정인 서버에 의존하고 있는지 식별할 수 있습니다. [AWS Migration Competency Partners](https://aws.amazon.com//migration/partner-solutions/)는 심층 검색 및 계획 도구를 제공할 수도 있습니다.
**참고**
Application Discovery Service는 더 이상 신규 고객에게 공개되지 않습니다. 또는 유사한 기능을 AWS Transform 제공하는를 사용합니다. 자세한 내용은 [AWS Application Discovery Service 가용성 변경](https://docs.aws.amazon.com/application-discovery/latest/userguide/application-discovery-service-availability-change.html)을 참조하세요.
예를 들어, 다음 화면의 그림은 포트 22에서 서버에 연결되는 4개의 소스 IP 주소를 보여줍니다(대상 = 172.31.1.117).
![\[연결 분석의 예.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/migration-retiring-applications/images/best-practices-4.png)
이는 시스템 관리자가 사용하는 Bastion Host이므로 무시해도 됩니다. 또한 이 이미지에는 계획된 마이그레이션 범위 내에 있는 포트 80을 통해 이 애플리케이션에 연결하는 두 대의 서버가 나와 있습니다. 이 단계에서는 연결 애플리케이션에 대해 더 깊이 파고들어 이해해야 합니다. 이렇게 심층적인 분석을 통해 사용 중지 후 업스트림 영향이 있을지 평가할 수 있습니다.
# 제어 중지 설정
마이그레이션 계획에서 마이그레이션 프로세스 중에 제어 중지 시간을 정해야 합니다. 제어 중지를 설정하면 마이그레이션 프로세스가 일시 중지되어 애플리케이션이 사용 중지될 경우 중단될 가능성을 파악할 수 있습니다. 이를 통해 애플리케이션의 사용 중지를 시뮬레이션하고 결과를 관찰할 수 있습니다. 제어 중지 기간이 완료되면 마이그레이션을 쉽게 재개할 수 있습니다.
제어 중지 접근 방식은 작업 중인 애플리케이션 유형 및 관련 프로세스에 따라 달라집니다. 일반적인 제어 중지 패턴은 다음과 같습니다.
+ 모든 트래픽을 차단하는 호스트 기반 방화벽을 구현하여 사용 중지를 시뮬레이션합니다.
+ 가상 머신 일시 중지
+ 호스트에서 서비스 중지
+ 외부 방화벽을 사용하여 모든 트래픽 차단
마이그레이션 프로젝트 및 애플리케이션 소유자는 애플리케이션 유형에 따라 제어 중지 기간을 정의해야 합니다. 예를 들어, 한 달에 한 번 또는 한 분기에 한 번만 실행되는 배치 기반 워크로드를 사용 중지하는 경우, 1주간의 제어 중지를 수행하는 것만으로는 다른 시스템에 미치는 영향을 판단하기에 충분하지 않을 수 있습니다.
이전 섹션의 예를 계속 살펴보면, 사용 중지될 예정인 서버에 다른 애플리케이션이 연결되고 있었습니다. 초기 평가에서는 업스트림 서버에 영향을 미치지 않아야 한다는 결론을 내렸습니다. 이제 제어 중지를 실시하여 영향을 파악할 수 있습니다.
이렇게 제어 중지는 호스트 기반 방화벽을 구현하여 모든 트래픽을 차단하고 서버 종료 효과를 시뮬레이션하여 수행됩니다. 이로 인해 AWS 클라우드로 마이그레이션하도록 예약된 애플리케이션에 대한 서비스 문제가 발생하는 경우 방화벽 규칙이 추가되고 모든 트래픽이 재개됩니다. 제어 중지 이후에는 이러한 서비스 저하 또는 중단으로 인해 서버의 사용 중지가 다시 고려됩니다.
# 애플리케이션 마이그레이션 여부 재평가
앞서 살펴본 두 가지 모범 사례는 사용 중지될 예정인 시스템에 대한 조치를 계속하는 것이 적절한지 판단하는 데 도움이 됩니다. 이러한 모범 사례에서 업스트림 비즈니스에 미칠 수 있는 영향이 부각되는 경우 애플리케이션의 마이그레이션 패턴을 재평가하는 것을 고려해야 합니다. 애플리케이션 사용 중지 프로세스를 일찍 시작함으로써 이제 애플리케이션을 사용 중지할 수 없는 문제나 종속성이 발생할 경우 후속 마이그레이션 웨이브에 애플리케이션을 포함시킬 충분한 시간을 확보할 수 있습니다.
이러한 모범 사례를 따른 후에도 애플리케이션 사용 중지에 대해 완전히 확신하지 못하는 경우 AWS 클라우드로 리호스팅해야 하는지 고려하세요. 이는 데이터 센터 임대 만료일과 같이 마이그레이션 종료 날짜가 정해져 있는 경우 특히 중요합니다.
[AWS 애플리케이션 마이그레이션 서비스](https://aws.amazon.com/application-migration-service/)와 같은 서비스는 재호스팅 마이그레이션 접근 방식을 단순화합니다. 애플리케이션을 로 마이그레이션할 때 Amazon Elastic Block Store(Amazon EBS) 볼륨의 일일 스냅샷을 생성하고 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 종료하여 비용을 절감하고 장기간에 걸쳐 애플리케이션의 사용 중지를 테스트 AWS할 수 있습니다. 영향이나 문제가 발생하는 경우 스냅샷을 기반으로 EBS 볼륨을 생성하여 EC2 인스턴스를 재개할 수 있다는 확신을 갖게 됩니다.
**중요**
EC2 인스턴스를 종료하기 전에 이 복구 프로세스를 테스트하세요.
# 애플리케이션 사용 중지
이 가이드의 이전 다섯 가지 모범 사례를 따랐다면 애플리케이션을 사용 중지해도 안전하다고 판단했을 수 있습니다. 마이그레이션 팩토리 접근 방식을 배포하고, 사용 중지 프로세스를 일찍 시작하고, 데이터 및 검색 도구를 사용하여 인바운드 연결을 모니터링하고, 제어 중지를 성공적으로 수행하고, 애플리케이션을 폐기해야 하는지 여부를 평가했습니다. 이제 마이그레이션 전략의 일환으로 애플리케이션을 사용 중지할 수 있습니다.
이때 애플리케이션에 나중에 유용할 수 있는 데이터가 포함되어 있는지 확인해야 합니다. 기계 학습(ML)과 분석은 데이터의 가치를 그 어느 때보다 높였습니다. 지금은 ML 알고리즘을 개발하고 있지 않을 수도 있지만, 과거 데이터가 미래에는 유용할 수 있습니다. 애플리케이션이 사용 중지되었더라도 지정된 기간 동안 데이터를 저장해야 하는 규제 또는 규정 준수 요구 사항이 있을 수도 있습니다.
AWS 는 장기 보존, 규정 준수 및 디지털 보존을 위한 포괄적인 클라우드 스토리지 서비스 세트를 제공합니다. 데이터 아카이빙 AWS 을 위한 스토리지 솔루션은 무제한 규모, 99.999999999%의 내구성, 데이터 신뢰성 및 데이터 보안을 제공하는 데 도움이 됩니다.
규정 준수 노력을 지원하기 위해는 수천 가지 글로벌 규정 준수 요구 사항에 대한 타사 검증을 AWS 정기적으로 달성합니다. 이를 지속적으로 모니터링하여 금융, 소매, 의료, 정부 등의 보안 및 규정 준수 표준을 충족할 수 있도록 지원합니다.
를 사용한 데이터 아카이빙에 대한 자세한 내용은 AWS 웹 사이트의 [데이터 아카이빙](https://aws.amazon.com//archive/)을 AWS참조하세요.