[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 AWS Migration Whitepaper(2018년, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
본 문서는 총 4부로 구성되어 있으며 이 글은 2부입니다.
1부 : AWS 마이그레이션 백서 1/4
3부 : AWS 마이그레이션 백서 3/4
4부 : AWS 마이그레이션 백서 4/4
마이그레이션 전략
여기에서 마이그레이션 전략을 개발하기 시작합니다. 클라우드 여행이 조직의 더 큰 비즈니스 전략에서 어디에 적합한지 고려하고 비전을 조정할 기회를 찾으십시오. 비즈니스 사례를 지원하고 신중한 마이그레이션 계획을 갖춘 잘 조정 된 마이그레이션 전략은 클라우드 채택 성공을 위한 적절한 토대를 설정합니다.
마이그레이션 전략을 개발하는데 있어 중요한 한 가지 측면은 애플리케이션 포트폴리오 데이터를 수집하여 6 R (Re-Host, Re-platform, Re-factor / Re-architect, Re-purchase, Retire 및 6 R)로 합리화하는 것입니다. 유지하십시오. 이는 환경의 내용, 상호 의존성, 마이그레이션의 기술적 복잡성 및 각 응용 프로그램 또는 응용 프로그램 집합을 마이그레이션하는 방법을 분류하는 방법입니다. 아래에 설명 된“6 R”프레임 워크를 사용하여 응용 프로그램을 리 호스트, 리 플랫폼, 리팩토링 / 다시 아키텍처, 재구매, 폐기 및 유지로 그룹화하십시오. 이 지식을 사용하여 포트폴리오의 각 응용 프로그램에 대한 마이그레이션 계획을 간략하게 설명합니다. 이 계획은 마이그레이션을 진행하고 신뢰를 구축하며 새로운 기능을 배우고 기존 부동산을 더 잘 이해함에 따라 반복적이고 성숙됩니다.
기존 응용 프로그램 마이그레이션의 복잡성은 아키텍처, 기존 라이센스 계약 및 비즈니스 요구 사항과 같은 고려 사항에 따라 다릅니다. 예를 들어 가상화 된 서비스 지향 아키텍처를 마이그레이션하는 것은 스펙트럼의 복잡성이 낮은 수준에 있습니다. 모 놀리 식 메인 프레임은 스펙트럼의 복잡도 끝에 있습니다.
일반적으로, 팀의 자신감을 높이고 학습 경험을 제공하기 위해 빠른 승리를 위해 스펙트럼의 복잡도가 낮은 애플리케이션을 시작하려고 합니다. 또한 비즈니스에 영향을 주는 응용 프로그램을 선택하려고 합니다. 이러한 전략은 추진력 구축에 도움이 됩니다.
“6 R”: 6 응용 프로그램 마이그레이션 전략
가장 일반적인 6 가지 응용 프로그램 마이그레이션 전략은 다음과 같습니다.
1. Re-host (“리프트 앤 시프트”라고 함)
변경없이 응용 프로그램을 이동하십시오. 대규모 레거시 마이그레이션에서 조직은 비즈니스 목표를 달성하기 위해 빠르게 이동하려고 합니다. 이러한 응용 프로그램의 대부분은 다시 호스팅 됩니다. GE Oil & Gas는 클라우드 최적화를 구현하지 않아도 리 호스팅을 통해 약 30 %의 비용을 절감 할 수 있음을 발견했습니다.
대부분의 재 호스팅은 도구 (예 : AWS VM Import / Export)를 사용하여 자동화 할 수 있습니다. 일부 고객은 레거시 시스템을 새로운 클라우드 플랫폼에 적용하는 방법을 배울 때 수동으로 수행하는 것을 선호합니다.
클라우드에서 이미 실행중인 애플리케이션은 더 쉽게 최적화 / 아키텍처 할 수 있습니다. 조직이 이를 수행 할 수 있는 기술을 개발했기 때문에 부분적으로, 응용 프로그램, 데이터 및 트래픽 마이그레이션과 같은 어려운 부분이 이미 완료 되었기 때문입니다.
2. Re-platform (“리프트, 시프트”라고함)
실질적인 이점을 달성하기 위해 몇 가지 클라우드 최적화를 수행하십시오. 애플리케이션의 핵심 아키텍처는 변경하지 않습니다. 예를 들어 Amazon Relational Database Service (Amazon RDS)와 같은 데이터베이스 서비스 플랫폼으로 마이그레이션하거나 애플리케이션을 AWS Elastic Beanstalk와 같은 완전히 관리되는 플랫폼으로 마이그레이션하여 데이터베이스 인스턴스 관리에 소요되는 시간을 줄이십시오.
한 대형 미디어 회사는 온 프레미스에서 실행 한 수백 개의 웹 서버를 AWS로 마이그레이션했습니다. 이 과정에서 WebLogic (고가 라이센스가 필요한 Java 애플리케이션 컨테이너)에서 오픈 소스에 해당하는 Apache Tomcat으로 이동했습니다. 이 미디어 회사는 AWS로 마이그레이션함으로써 수백만 달러의 라이센스 비용을 절감하고 절감 및 민첩성을 높였습니다.
3. Re-factor / Re-architect
클라우드 네이티브 기능을 사용하여 애플리케이션을 설계하고 개발하는 방법을 다시 상상하십시오. 이는 애플리케이션의 기존 환경에서 달성하기 어려운 기능, 확장 성 또는 성능을 추가해야하는 강력한 비즈니스 요구로 인해 발생합니다.
민첩성을 높이거나 비즈니스 연속성을 향상시키기 위해 단일 아키텍처에서 서비스 지향 (또는 서버리스) 아키텍처로 마이그레이션 하려고 하십니까?
이 전략은 비용이 가장 많이 드는 경향이 있지만 제품 시장에 잘 맞는다면 가장 유리할 수 있습니다.
4. Re-purchase
영구 라이센스에서 서비스 형 소프트웨어 모델로 이동하십시오. 예를 들어 CRM (고객 관계 관리)에서 Salesforce.com으로, HR 시스템을 Workday로, CMS (콘텐츠 관리 시스템)를 Drupal로 이동하십시오.
5. Retire
더 이상 필요 없는 응용 프로그램을 제거하십시오. 환경에 대한 검색을 완료하면 각 응용 프로그램을 소유 한 사람에게 문의하십시오. 엔터프라이즈 IT 포트폴리오의 10 % ~ 20 %는 더 이상 유용하지 않으며 끌 수 있습니다. 이러한 비용 절감은 비즈니스 사례를 강화하고 사람들이 사용하는 애플리케이션에 팀의 관심을 유도하며 보안해야 하는 애플리케이션 수를 줄일 수 있습니다.
6. Retain
비즈니스에 중요하지만 마이그레이션하기 전에 주요 리팩토링이 필요한 애플리케이션을 유지하십시오. 나중에 이 범주에 속하는 모든 응용 프로그램을 다시 방문 할 수 있습니다.
나에게 적합한 마이그레이션 전략은 무엇입니까?
올바른 마이그레이션 전략을 선택하는 것은 클라우드 도입을 위한 비즈니스 동인과 시간 고려 사항, 비즈니스 및 재정적 제약, 리소스 요구 사항에 따라 다릅니다. 비용 방지를 위해 마이그레이션하고 하드웨어를 새로 고칠 필요가 없는 경우 플랫폼을 다시 설치하십시오. 그림 3은 이 전략이 리호스트 전략보다는 노력이 많지만 리팩터 전략보다는 적은 노력이 필요하다는 것을 보여줍니다. 데이터 센터 계약이 12 개월 안에 끝나고 갱신하지 않으려는 경우 플랫폼의 대부분을 다시 호스팅하고 나중에 리팩터링 하십시오.
한 번에 모든 작업을 수행하는 것이 아니라 첫 번째 단계에서 비즈니스 기능의 우선 순위를 정하여 응용 프로그램 마이그레이션에 대한 단계별 접근 방식을 고려하십시오. 다음 단계에서는 AWS 플랫폼이 비용, 성능, 생산성 또는 규정 준수 측면에서 현저한 차이를 만들 수 있는 애플리케이션을 최적화하십시오. 예를 들어, Oracle 데이터베이스를 활용하는 응용 프로그램을 마이그레이션하고 있고 전략에 Oracle을 Aurora PostgreSQL로 교체하는 것이 포함되어있는 경우 가장 좋은 마이그레이션 방법은 응용 프로그램을 마이그레이션하고 마이그레이션 단계에서 안정화하는 것입니다. 그런 다음 후속 단계에서 데이터베이스 변경 작업을 실행하십시오. 이 접근 방식은 마이그레이션 단계에서 위험을 제어하고 마이그레이션 비즈니스 사례 및 가치 제안에 중점을 둡니다.
모든 마이그레이션에 포함되어야 하는 포트폴리오 전체에서 애플리케이션 성능, 탄력성 및 컴플라이언스를 향상시키는 일반적인 목표가 있습니다. 일관성 있는 실행을 위해 마이그레이션 프로세스에 패키지되어야 합니다.
마이그레이션 전략은 팀이 빠르고 독립적으로 이동하도록 안내해야 합니다. 명확한 예산, 일정 및 비즈니스 성과를 포함하는 프로젝트 관리 모범 사례를 적용하면 이 목표를 지원합니다. 귀하의 전략은 다음과 같은 질문을 해결해야합니다.
· 비즈니스 사례 또는 비즈니스 동인 (예 : 데이터 센터 종료 또는 계약 만료)에 시간 민감성이 있습니까?
· 누가 AWS 환경과 애플리케이션을 운영합니까? 오늘 아웃소싱 공급자를 사용하십니까? 장기적으로 어떤 운영 모델을 원하십니까?
· 마이그레이션하는 모든 응용 프로그램에 어떤 표준을 적용해야 합니까?
· 클라우드 운영, 유연성 및 속도의 출발점으로 애플리케이션에 어떤 자동화 요구 사항을 적용 하시겠습니까? 이러한 요구 사항이 모든 응용 프로그램 또는 정의 된 하위 집합에 적용됩니까? 이러한 표준을 어떻게 적용 하시겠습니까?
다음은 예입니다.
· 마이그레이션 타임 라인을 통해 특정 시설을 폐기하고 절감액을 사용하여 클라우드 컴퓨팅으로의 전환에 자금을 지원합니다. 시간은 매우 중요하지만, 즉시 비용을 절감하면서 빠르고 안전하게 수행 할 수 있는 모든 변경 사항을 고려할 것입니다.
· 역사적으로 아웃소싱 된 핵심 엔지니어링 기능을 제공합니다. 운영 장벽을 제거하고 이 기능을 확장 할 수 있는 기술 플랫폼을 살펴 보겠습니다.
· 비즈니스 연속성은 마이그레이션의 중요한 원동력입니다. 마그레이션하는 동안 우리의 입장을 개선하기 위해 시간이 걸릴 것입니다. 애플리케이션 위험과 비용이 높은 경우 단계적 접근 방식을 고려합니다. 먼저 마이그레이션하고 후속 단계에서 최적화합니다. 이 경우 마이그레이션 계획에 두 번째 단계가 포함되어야 합니다.
· 모든 사용자 지정 개발을 위해 DevOps 모델로 이동합니다. 이 패턴과 일치하는 각 응용 프로그램 마이그레이션 계획에서 개발 및 릴리스 프로세스를 구축하고 개발 팀을 교육하는 데 시간이 걸립니다.
애플리케이션 포트폴리오를 이해하는 것은 마이그레이션 전략 및 후속 마이그레이션 계획 및 비즈니스 사례를 결정하는 중요한 단계입니다. 이 전략은 정교 할 필요는 없지만 위의 질문을 해결하면 조직을 조정하고 운영 규범을 테스트하는 데 도움이됩니다.
마이그레이션을 위한 비즈니스 사례 구축
IT 리더는 비용 절감, 운영 탄력성, 생산성 및 제공 속도 등 AWS가 조직에 제공하는 가치를 이해합니다. 명확하고 강력한 마이그레이션 비즈니스 사례를 구축하면 이니셔티브를 지원하기 위한 데이터 중심의 근거를 조직의 리더십에 제공 할 수 있습니다.
마이그레이션 비즈니스 사례에는 1) 실행 비용 분석, 2) 변경 비용, 3) 노동 생산성 및 4) 비즈니스 가치의 네 가지 범주가 있습니다. 마이그레이션에 대한 비즈니스 사례는 다음 질문을 해결합니다.
· AWS의 향후 예상 IT 비용과 기존 (기본) 비용은 얼마입니까?
· 예상 마이그레이션 투자 비용은 얼마입니까?
· 예상 ROI는 무엇이며 프로젝트는 언제 현금 흐름에 긍정적입니까?
· 비용 절감 이상의 비즈니스 이점은 무엇입니까?
· AWS를 사용하면 비즈니스 변화에 대응하는 능력이 어떻게 향상됩니까?
다음 표에는 각 비용 또는 값 범주가 요약되어 있습니다.
엔터프라이즈 석유 및 가스 고객의 경우 비용 절감이 주요 마이그레이션 동인이었습니다. 이 고객은 300 개 이상의 애플리케이션을 AWS로 마이그레이션하는 과정을 통해 추가적인 재무 및 전반적인 비즈니스 이점을 실현했습니다. 예를 들어이 고객은 비즈니스 민첩성, 운영 탄력성을 높이고 인력 생산성을 향상 시키며 운영 비용을 절감 할 수있었습니다. 다음 표에 표시된 각 값 범주의 데이터는 강력한 마이그레이션 사례를 제공합니다.
비즈니스 사례 작성
비즈니스 사례는 방향성, 정교함, 세부적인 여러 단계로 진행됩니다. 지향성 비즈니스 사례에서는 서버 수와 서버 사용률에 대한 대략적인 크기 (ROM) 가정을 추정합니다. 목표는 조기 바이 인을 통해 예산을 할당하고 자원을 적용하는 것입니다. 마이그레이션 및 워크로드 범위에 대한 추가 데이터가 있는 경우 정제 된 비즈니스 사례를 개발할 수 있습니다. 초기 발견 프로세스는 마이그레이션 및 비즈니스 사례의 범위를 개선합니다. 자세한 비즈니스 사례에는 온-프레미스 환경 및 서버 사용률에 대한 심층적인 검색이 필요합니다. 심층 검색에는 자동 검색 도구를 사용하는 것이 좋습니다. 이 내용은 나중에 Application Discovery 섹션에서 설명합니다.
고려해야 할 사항
비즈니스 사례를 구축 할 때 다음 사항을 고려하십시오.
· 올바른 크기 매핑은 AWS에서 기존 애플리케이션 및 프로세스를 실행하는 데 필요한 AWS 서비스 (컴퓨팅, 스토리지 등)의 추정치를 제공합니다. 용량 보기 (프로비저닝) 및 사용률 보기 (실제 사용 기준)가 포함됩니다. 이는 특히 과도하게 프로비저닝 된 가상화 된 데이터 센터에서 가치 제안의 중요한 부분입니다.
· 적절한 크기의 매핑을 확장하여 풀 타임으로 필요하지 않은 리소스를 고려합니다 (예 : 사용하지 않을 때 개발 및 테스트 서버 끄기 및 실행 비용 절감).
· 마이그레이션 프로세스를 설정하고 마이그레이션 준비 및 계획 단계에서 경험을 개발하기 위해 마이그레이션을위한 초기 후보를 식별합니다.
응용 프로그램 검색 데이터를 조기에 분석하면 실행 속도 비용, 마이그레이션 비용, 리소스 요구 사항 및 마이그레이션 일정을 결정하는 데 도움이됩니다.
AWS에는 마이그레이션을위한 비즈니스 사례를 개발하는 데 도움이되는 일련의 도구와 프로세스가 있습니다. AWS Simple Monthly Calculator는 방향성 비즈니스 사례 입력을 제공 할 수 있는 반면, AWS 총 운영 비용 (TCO) 계산기는 보다 세련된 비즈니스 사례를 제공 할 수 있습니다. 또한 AWS에는 마이그레이션 비용을 추정 할 수 있는 도구가 있습니다.
