기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 검색 가속화 및 초기 계획
포트폴리오 평가의이 첫 단계는 포트폴리오 수준에서 데이터를 얻고 분석하는 초기 단계에 중점을 둡니다. 주요 목표는 비즈니스 동인을 식별하고 애플리케이션 및 인프라에서 일반 데이터를 수집하여 포트폴리오의 초기 보기를 얻는 것입니다. 이 데이터에는 [데이터 요구 사항](understanding-initial-assessment-data-requirements.md) 섹션에 설명된 대로 애플리케이션 이름, 환경, 제품 버전, 중요도, 성능 값 등과 같은 상위 수준의 기술 및 비즈니스 속성이 포함됩니다. 이 단계를 완료하는 것은 프로젝트의 범위를 이해하고, 초기 마이그레이션 후보를 식별하고, 비즈니스 사례를 알리는 데 중요합니다.
## 이 단계의 기본 결과
+ 문서화된 비즈니스 동인, 성과, 목표 및 기술 지침 원칙.
+ 애플리케이션 및 인프라의 초기 인벤토리 및 식별된 데이터 격차. 이는 추가 단계에서 반복되고 개선될 포트폴리오의 초기 보기입니다.
+ 방향성 비즈니스 사례 및 마이그레이션 예상 비용.
+ 초기 마이그레이션 후보 목록(예: 3-5개 애플리케이션).
+ 다음 단계를 정의했습니다.
# 초기 평가 데이터 요구 사항 이해
데이터 수집에는 상당한 시간이 소요될 수 있으며 필요한 데이터와 필요한 시간에 대한 명확한 설명이 없는 경우 쉽게 차단할 수 있습니다. 핵심은이 단계의 결과에 비해 너무 적은 데이터와 너무 많은 데이터의 균형을 이해하는 것입니다. 포트폴리오 평가의이 초기 단계에 필요한 데이터와 충실도 수준에 초점을 맞추려면 데이터 수집에 대한 반복적인 접근 방식을 채택합니다.
## 데이터 소스 및 데이터 요구 사항
첫 번째 단계는 데이터 소스를 식별하는 것입니다. 먼저 데이터 요구 사항을 충족할 수 있는 조직 내 주요 이해관계자를 식별합니다. 이들은 일반적으로 서비스 관리, 운영, 용량 계획, 모니터링 및 지원 팀, 애플리케이션 소유자의 구성원입니다. 이러한 그룹의 구성원과 작업 세션을 설정합니다. 데이터 요구 사항을 전달하고 데이터를 제공할 수 있는 도구 및 기존 설명서 목록을 가져옵니다.
이러한 대화를 안내하려면 다음 질문 세트를 사용합니다.
+ 현재 인프라 및 애플리케이션 인벤토리는 얼마나 정확하고 최신 상태입니까? 예를 들어 회사 구성 관리 데이터베이스(CMDB)의 경우 격차가 있는 위치를 이미 알고 있습니까?
+ CMDB(또는 이에 상응하는)를 최신 상태로 유지하는 활성 도구 및 프로세스가 있습니까? 그렇다면 얼마나 자주 업데이트되나요? 최신 새로 고침 날짜는 언제입니까?
+ CMDB와 같은 현재 인벤토리에 application-to-infrastructure 매핑이 포함되어 있습니까? 각 인프라 자산이 애플리케이션에 연결되어 있습니까? 각 애플리케이션이 인프라에 매핑되나요?
+ 인벤토리에 각 제품의 라이선스 및 라이선스 계약 카탈로그가 포함되어 있습니까?
+ 인벤토리에 종속성 데이터가 포함되어 있습니까? 서버 대 서버, 애플리케이션 대 애플리케이션, 애플리케이션 또는 서버 대 데이터베이스와 같은 통신 데이터가 있는지 확인합니다.
+ 환경에서 애플리케이션 및 인프라 정보를 제공할 수 있는 다른 도구는 무엇입니까? 데이터 소스로 사용할 수 있는 성능, 모니터링 및 관리 도구가 있는지 확인합니다.
+ 애플리케이션 및 인프라를 호스팅하는 데이터 센터와 같은 다양한 위치는 무엇입니까?
이러한 질문에 답변한 후 식별된 데이터 소스를 나열합니다. 그런 다음 각각에 충실도 수준 또는 신뢰 수준을 할당합니다. 도구와 같은 활성 프로그래밍 방식 소스에서 최근에(30일 이내) 검증된 데이터는 충실도가 가장 높습니다. 정적 데이터는 충실도가 낮고 신뢰도가 낮은 것으로 간주됩니다. 정적 데이터의 예로는 문서, 통합 문서, 수동으로 업데이트된 CMDBs 또는 프로그래밍 방식으로 유지 관리되지 않는 기타 데이터 세트 또는 마지막 새로 고침 날짜가 60일 이상인 데이터 세트가 있습니다.
다음 표의 데이터 충실도 수준은 예제로 제공됩니다. 조직의 요구 사항을 가정에 대한 최대 허용 범위 및 관련 위험 측면에서 평가하여 적절한 수준의 충실도를 결정하는 것이 좋습니다. 표에서 제도적 지식은 문서화되지 않은 애플리케이션 및 인프라에 대한 모든 정보를 나타냅니다.
| **데이터 소스** | **충실도 수준** | **포트폴리오 적용 범위** | **설명** |
| --- |--- |--- |--- |
| 실험 지식 | 낮음 - 정확한 데이터의 최대 25%, 가정된 값 또는 데이터의 75%가 150일을 초과합니다. | 낮음 | 중요한 애플리케이션에 초점을 맞춘 Scarce |
| 지식 기반 | 중간 낮음 - 정확한 데이터의 35\$140%, 가정된 값 또는 데이터의 65\$160%는 120\$1150일입니다. | 중간 | 수동으로 유지 관리되고 일관성 없는 세부 정보 수준 |
| CMDB | 중간 - 정확한 데이터의 \$150%, \$150% 가정된 값 또는 데이터는 90\$1120일입니다. | 중간 | 혼합 소스의 데이터, 여러 데이터 격차 포함 |
| VMware vCenter 내보내기 | 중간-높음 - 정확한 데이터의 75\$180%, 가정된 값 또는 데이터의 25\$120%는 60\$190일입니다. | 높음 | 가상화 자산의 90%를 차지합니다. |
| 애플리케이션 성능 모니터링 | 높음 - 대부분 정확한 데이터, \$15% 가정된 값 또는 데이터는 0\$160일 경과되었습니다. | 낮음 | 중요한 프로덕션 시스템으로 제한됨(애플리케이션 포트폴리오의 15% 포함) |
다음 표에는 각 자산 클래스(애플리케이션, 인프라, 네트워크 및 마이그레이션)의 필수 및 선택적 데이터 속성, 특정 활동(인벤토리 또는 비즈니스 사례),이 평가 단계에 권장되는 데이터 충실도가 나와 있습니다. 테이블은 다음 약어를 사용합니다.
+ R, 필수
+ (D), 방향성 비즈니스 사례의 경우 총 소유 비용(TCO) 비교 및 방향성 비즈니스 사례에 필요
+ (F) 전체 방향성 비즈니스 사례의 경우 TCO 비교에 필요하고 마이그레이션 및 현대화 비용을 포함하는 방향성 비즈니스 사례
+ O, 선택 사항의 경우
+ 해당 없음, 해당 없음
**애플리케이션**
| **속성 이름** | **설명** | **인벤토리 및 우선순위 지정** | **비즈니스 사례** | **권장 충실도 수준(최소)** |
| --- |--- |--- |--- |--- |
| 고유한 식별자 | 애플리케이션 ID를 예로 들 수 있습니다. 일반적으로 기존 CMDBs 또는 기타 내부 인벤토리 및 제어 시스템에서 사용할 수 있습니다. 조직에 고유 ID가 정의되지 않은 경우 고유 IDs를 생성하는 것이 좋습니다. | R | R(D) | 높음 |
| 애플리케이션 이름 | 이 애플리케이션이 조직에 알려진 이름입니다. 해당하는 경우 상용 off-the-shelf(COTS) 공급업체 및 제품 이름을 포함합니다. | R | R(D) | 중간-높음 |
| COTS입니까? | 예 또는 아니요. 상용 애플리케이션인지 아니면 내부 개발인지 여부 | R | R(D) | 중간-높음 |
| COTS 제품 및 버전 | 상용 소프트웨어 제품 이름 및 버전 | R | R(D) | 중간 |
| 설명 | 기본 애플리케이션 함수 및 컨텍스트 | R | O | 중간 |
| 중요도 | 예: 전략적 또는 수익 창출 애플리케이션 또는 중요한 함수 지원 | R | O | 중간-높음 |
| Type | 예: 데이터베이스, 고객 관계 관리(CRM), 웹 애플리케이션, 멀티미디어, IT 공유 서비스 | R | O | 중간 |
| 환경 | 예: 프로덕션, 사전 프로덕션, 개발, 테스트, 샌드박스 | R | R(D) | 중간-높음 |
| 규정 준수 및 규제 | 워크로드에 적용되는 프레임워크(예: HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) 및 규제 요구 사항 | R | R(D) | 중간-높음 |
| 종속성 | 내부 및 외부 애플리케이션 또는 서비스에 대한 업스트림 및 다운스트림 종속성. 운영 요소와 같은 비기술적 종속성(예: 유지 관리 주기) | O | O | 중간-낮음 |
| 인프라 매핑 | 애플리케이션을 구성하는 물리적 및/또는 가상 자산에 매핑 | O | O | 중간 |
| 라이선스 | 상품 소프트웨어 라이선스 유형(예: Microsoft SQL Server Enterprise) | O | R | 중간-높음 |
| 비용 | 소프트웨어 라이선스, 소프트웨어 운영 및 유지 관리 비용 | 해당 사항 없음 | O | 중간 |
**인프라**
| | | | | |
| --- |--- |--- |--- |--- |
| **속성 이름** | **설명** | **인벤토리 및 우선순위 지정** | **비즈니스 사례** | **권장 충실도 수준(최소)** |
| 고유한 식별자 | 서버 ID를 예로 들 수 있습니다. 일반적으로 기존 CMDBs 또는 기타 내부 인벤토리 및 제어 시스템에서 사용할 수 있습니다. 조직에 고유 ID가 정의되지 않은 경우 고유 IDs를 생성하는 것이 좋습니다. | R | R | 높음 |
| 네트워크 이름 | 네트워크의 자산 이름(예: 호스트 이름) | R | O | 중간-높음 |
| DNS 이름(정규화된 도메인 이름 또는 FQDN) | DNS 이름 | O | O | 중간 |
| IP 주소 및 넷마스크 | 내부 및/또는 퍼블릭 IP 주소 | R | O | 중간-높음 |
| 애셋 유형 | 물리적 또는 가상 서버, 하이퍼바이저, 컨테이너, 디바이스, 데이터베이스 인스턴스 등 | R | R | 중간-높음 |
| 제품 이름 | 상용 공급업체 및 제품 이름(예: VMware ESXi, IBM Power Systems, Exadata) | R | R | 중간 |
| 운영 체제 | 예: REHL 8, Windows Server 2019, AIX 6.1 | R | R | 중간-높음 |
| 구성 | 할당된 CPU, 코어 수, 코어당 스레드 수, 총 메모리, 스토리지, 네트워크 카드 | R | R | 중간-높음 |
| 사용률 | CPU, 메모리, 스토리지 피크 및 평균. 데이터베이스 인스턴스 처리량. | R | O | 중간-높음 |
| 라이선스 | 상품 라이선스 유형(예: RHEL Standard) | R | R | 중간 |
| 공유 인프라입니까? | 인증 공급자, 모니터링 시스템, 백업 서비스 및 유사한 서비스와 같은 공유 서비스를 제공하는 인프라 서비스를 나타내는 예 또는 아니요 | R | R(D) | 중간 |
| 애플리케이션 매핑 | 이 인프라에서 실행되는 애플리케이션 또는 애플리케이션 구성 요소 | O | O | 중간 |
| 비용 | 하드웨어, 유지 관리, 운영, 스토리지(SAN, NAS, 객체), 운영 체제 라이선스, 랙스페이스 공유, 데이터 센터 오버헤드 등 베어 메탈 서버의 전체 로드 비용 | 해당 사항 없음 | O | 중간-높음 |
**네트워크**
| | | | | |
| --- |--- |--- |--- |--- |
| **속성 이름** | **설명** | **인벤토리 및 우선순위 지정** | **비즈니스 사례** | **권장 충실도 수준(최소)** |
| 파이프 크기(Mb/s), 중복(Y/N) | 현재 WAN 링크 사양(예: 1000Mb/s 중복) | O | R | 중간 |
| 링크 사용률 | 최대 및 평균 사용률, 아웃바운드 데이터 전송(GB/월) | O | R | 중간 |
| 지연 시간(ms) | 연결된 위치 간의 현재 지연 시간입니다. | O | O | 중간 |
| 비용 | 현재 월별 비용 | 해당 사항 없음 | O | 중간 |
**마이그레이션**
| | | | | |
| --- |--- |--- |--- |--- |
| **속성 이름** | **설명** | **인벤토리 및 우선순위 지정** | **비즈니스 사례** | **권장 충실도 수준(최소)** |
| 리호스팅 | 각 워크로드(인일), 일일 고객 및 파트너 비용 비율, 도구 비용, 워크로드 수에 대한 고객 및 파트너 작업 | 해당 사항 없음 | R(F) | 중간-높음 |
| 리플랫포밍 | 각 워크로드(인일), 일일 고객 및 파트너 비용 비율, 워크로드 수에 대한 고객 및 파트너 노력 | 해당 사항 없음 | R(F) | 중간-높음 |
| 리팩터링 | 각 워크로드(인일), 일일 고객 및 파트너 비용 비율, 워크로드 수에 대한 고객 및 파트너 노력 | 해당 사항 없음 | O | 중간-높음 |
| 만료 | 서버 수, 평균 폐기 비용 | 해당 사항 없음 | O | 중간-높음 |
| 랜딩 존 | 기존 재사용(Y/N), 필요한 AWS 리전 목록, 비용 | 해당 사항 없음 | R(F) | 중간-높음 |
| 사람 및 변화 | 클라우드 운영 및 개발에서 훈련할 직원 수, 1명당 훈련 비용, 1명당 훈련 시간 비용 | 해당 사항 없음 | R(F) | 중간-높음 |
| 지속 시간 | 범위 내 워크로드 마이그레이션 기간(개월) | O | R(F) | 중간-높음 |
| 병렬 비용 | 마이그레이션 중에 있는 그대로 비용을 제거할 수 있는 기간 및 비율 | 해당 사항 없음 | O | 중간-높음 |
| 마이그레이션 중에 AWS 제품 및 서비스와 기타 인프라 비용이 도입되는 기간 및 속도 | 해당 사항 없음 | O | 중간-높음 |
## 검색 도구의 필요성 평가
조직에 검색 도구가 필요합니까? 포트폴리오 평가에는 애플리케이션 및 인프라에 대한 높은 신뢰도의 up-to-date 데이터가 필요합니다. 포트폴리오 평가의 초기 단계에서는 가정을 사용하여 데이터 격차를 해소할 수 있습니다.
그러나 진행 상황이 진행됨에 따라 충실도가 높은 데이터를 통해 성공적인 마이그레이션 계획을 수립하고 대상 인프라를 올바르게 추정하여 비용을 절감하고 이점을 극대화할 수 있습니다. 또한 종속성을 고려하고 마이그레이션 위험을 방지하는 구현을 활성화하여 위험을 줄입니다. 클라우드 마이그레이션 프로그램에서 검색 도구의 주요 사용 사례는 다음을 통해 위험을 줄이고 데이터의 신뢰도 수준을 높이는 것입니다.
+ 자동 또는 프로그래밍 방식 데이터 수집으로 검증되고 신뢰도가 높은 데이터 생성
+ 데이터 획득 속도 가속화, 프로젝트 속도 향상 및 비용 절감
+ CMDBs에서 일반적으로 사용할 수 없는 통신 데이터 및 종속성을 포함하여 데이터 완전성 수준 향상
+ 자동화된 애플리케이션 식별, TCO 분석, 예상 실행률 및 최적화 권장 사항과 같은 인사이트 확보
+ 신뢰도가 높은 마이그레이션 웨이브 계획
시스템이 특정 위치에 있는지 확실하지 않은 경우 대부분의 검색 도구는 네트워크 서브넷을 스캔하고 ping 또는 Simple Network Management Protocol(SNMP) 요청에 응답하는 시스템을 검색할 수 있습니다. 모든 네트워크 또는 시스템 구성이 ping 또는 SNMP 트래픽을 허용하는 것은 아닙니다. 네트워크 및 기술 팀과 이러한 옵션에 대해 논의합니다.
애플리케이션 포트폴리오 평가 및 마이그레이션의 추가 단계는 정확한 종속성 매핑 정보에 크게 의존합니다. 종속성 매핑은에 AWS 필요한 인프라 및 구성(예: 보안 그룹, 인스턴스 유형, 계정 배치 및 네트워크 라우팅)에 대한 이해를 제공합니다. 또한 동시에 이동해야 하는 애플리케이션(예: 짧은 지연 시간 네트워크를 통해 통신해야 하는 애플리케이션)을 그룹화하는 데 도움이 됩니다. 또한 종속성 매핑은 비즈니스 사례를 발전시키기 위한 정보를 제공합니다.
검색 도구를 결정할 때는 평가 프로세스의 모든 단계를 고려하고 데이터 요구 사항을 예측하는 것이 중요합니다. 데이터 격차는 차단 요소가 될 가능성이 있으므로 향후 데이터 요구 사항과 데이터 소스를 분석하여 이를 예측하는 것이 중요합니다. 필드에서의 경험에 따르면 대부분의 중단된 마이그레이션 프로젝트에는 범위 내 애플리케이션, 관련 인프라 및 종속성이 명확하게 식별되지 않는 제한된 데이터 세트가 있습니다. 이러한 식별 부족으로 인해 잘못된 지표, 결정 및 지연이 발생할 수 있습니다. up-to-date 데이터를 얻는 것이 성공적인 마이그레이션 프로젝트의 첫 번째 단계입니다.
*검색 도구를 선택하려면 어떻게 해야 하나요?*
시장 내 여러 검색 도구는 다양한 기능을 제공합니다. 요구 사항을 고려하세요. 그리고 조직에 가장 적합한 옵션을 결정합니다. 마이그레이션을 위한 검색 도구를 결정할 때 가장 일반적인 요소는 다음과 같습니다.
*보안*
+ 도구 데이터 리포지토리 또는 분석 엔진에 액세스하는 인증 방법은 무엇입니까?
+ 누가 데이터에 액세스할 수 있으며 도구에 액세스하기 위한 보안 제어는 무엇입니까?
+ 도구는 어떻게 데이터를 수집하나요? 전용 자격 증명이 필요합니까?
+ 도구를 사용하여 시스템에 액세스하고 데이터를 얻으려면 어떤 자격 증명과 액세스 수준이 필요합니까?
+ 도구 구성 요소 간에 데이터가 어떻게 전송되나요?
+ 도구가 저장 데이터 암호화 및 전송 중 데이터 암호화를 지원하나요?
+ 내 환경 내부 또는 외부의 단일 구성 요소에 데이터가 중앙 집중화되어 있습니까?
+ 네트워크 및 방화벽 요구 사항은 무엇입니까?
보안 팀이 검색 도구에 대한 초기 대화에 참여하고 있는지 확인합니다.
*데이터 주권*
+ 데이터는 어디에 저장되고 처리되나요?
+ 도구에서 서비스형 소프트웨어(SaaS) 모델을 사용하나요?
+ 내 환경의 경계 내에 모든 데이터를 유지할 수 있나요?
+ 내 조직의 경계를 벗어나기 전에 데이터를 검사할 수 있나요?
데이터 레지던시 요구 사항 측면에서 조직의 요구 사항을 고려합니다.
*아키텍처*
+ 필요한 인프라와 다양한 구성 요소는 무엇입니까?
+ 둘 이상의 아키텍처를 사용할 수 있나요?
+ 도구가 공기 잠금 보안 영역에 구성 요소 설치를 지원하나요?
*성능*
+ 데이터 수집이 시스템에 미치는 영향은 무엇인가요?
*호환성 및 범위*
+ 도구가 내 제품 및 버전의 전체 또는 대부분을 지원하나요? 도구 설명서를 검토하여 범위에 대한 현재 정보를 기준으로 지원되는 플랫폼을 확인합니다.
+ 대부분의 운영 체제가 데이터 수집을 지원하나요? 운영 체제 버전을 모르는 경우 검색 도구 목록을 지원되는 시스템의 범위가 더 넓은 것으로 좁히십시오.
*수집 방법*
+ 도구에서 각 대상 시스템에 에이전트를 설치해야 합니까?
+ 에이전트 없는 배포를 지원하나요?
+ 에이전트와 에이전트가 없는 도 동일한 기능을 제공하나요?
+ 수집 프로세스란 무엇입니까?
*Features*
+ 사용 가능한 기능은 무엇입니까?
+ 총 소유 비용(TCO)과 예상 AWS 클라우드 실행률을 계산할 수 있나요?
+ 마이그레이션 계획을 지원하나요?
+ 성능을 측정하나요?
+ 대상 AWS 인프라를 추천할 수 있나요?
+ 종속성 매핑을 수행하나요?
+ 어떤 수준의 종속성 매핑을 제공하나요?
+ API 액세스를 제공하는가?(예: 데이터를 얻기 위해 프로그래밍 방식으로 액세스할 수 있는가?)
강력한 애플리케이션 및 인프라 종속성 매핑 함수가 있는 도구와 통신 패턴에서 애플리케이션을 유추할 수 있는 도구를 고려합니다.
*비용*
+ 라이선스 모델이란 무엇입니까?
+ 라이선스 비용은 얼마인가요?
+ 각 서버의 요금인가요? 계층형 요금인가요?
+ 온디맨드 방식으로 라이선스를 부여할 수 있는 기능이 제한된 옵션이 있나요?
검색 도구는 일반적으로 마이그레이션 프로젝트의 전체 수명 주기 동안 사용됩니다. 예산이 제한된 경우 최소 6개월을 고려하세요. 그러나 검색 도구가 없으면 일반적으로 수동 작업과 내부 비용이 증가합니다.
*지원 모델*
+ 기본적으로 제공되는 지원 수준은 무엇입니까?
+ 지원 플랜을 사용할 수 있나요?
+ 인시던트 대응 시간은 어떻게 됩니까?
*전문 서비스*
+ 공급업체는 검색 결과를 분석하기 위한 전문 서비스를 제공합니까?
+ 이 가이드의 요소를 다룰 수 있나요?
+ 도구 \$1 서비스에 대한 할인 또는 번들이 있나요?
**작은 정보**
검색 도구를 찾고 평가하려면 [검색, 계획 및 권장 사항](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/) 사이트를 사용합니다.
*검색 도구에 권장되는 기능*
시간이 지남에 따라 여러 도구에서 데이터를 프로비저닝하고 결합하는 것을 방지하려면 검색 도구에서 다음과 같은 최소 기능을 포함해야 합니다.
+ **소프트웨어** - 검색 도구는 실행 중인 프로세스와 설치된 소프트웨어를 식별할 수 있어야 합니다.
+ **종속성 매핑** - 네트워크 연결 정보를 수집하고 서버 및 실행 중인 애플리케이션의 인바운드 및 아웃바운드 종속성 맵을 구축할 수 있어야 합니다. 또한 검색 도구는 통신 패턴을 기반으로 인프라 그룹에서 애플리케이션을 추론할 수 있어야 합니다.
+ **프로파일 및 구성 검색** - CPU 패밀리(예: x86, PowerPC), CPU 코어 수, 메모리 크기, 디스크 수 및 크기, 네트워크 인터페이스와 같은 인프라 프로파일을 보고할 수 있어야 합니다.
+ **네트워크 스토리지 검색** - 네트워크 연결 스토리지(NAS)에서 네트워크 공유를 감지하고 프로파일링할 수 있어야 합니다.
+ **성능** - CPU, 메모리, 디스크 및 네트워크의 최대 및 평균 사용률을 보고할 수 있어야 합니다.
+ **격차 분석** - 데이터 수량 및 충실도에 대한 인사이트를 제공할 수 있어야 합니다.
+ **네트워크 스캔** - 네트워크 서브넷을 스캔하고 알 수 없는 인프라 자산을 검색할 수 있어야 합니다.
+ **보고** - 수집 및 분석 상태를 제공할 수 있어야 합니다.
+ **API 액세스** - 수집된 데이터에 액세스할 수 있는 프로그래밍 방식을 제공할 수 있어야 합니다.
*고려해야 할 추가 기능*
+ 현재 온프레미스 비용과 예상 비용 간의 AWS 비용 비교를 제공하는 **TCO 분석**.
+ 리호스팅 및 리플랫포밍 시나리오에서 Microsoft SQL Server 및 Oracle 시스템에 대한 **라이선스 분석 및 최적화 권장 사항**입니다.
+ **마이그레이션 전략 권장 사항**(검색 도구가 현재 기술을 기반으로 기본 마이그레이션 R 유형 권장 사항을 만들 수 있습니까?)
+ **인벤토리 내보내기**(CSV 또는 유사한 형식으로)
+ **적절한 크기 권장 사항**(예: 권장 대상 AWS 인프라를 매핑할 수 있습니까?)
+ **종속성 시각화**(예: 종속성 매핑을 그래픽 모드로 시각화할 수 있습니까?)
+ **아키텍처 보기**(예: 아키텍처 다이어그램을 자동으로 생성할 수 있습니까?)
+ **애플리케이션 우선 순위 지정**( 마이그레이션을 위한 우선 순위 지정 기준을 생성하기 위해 애플리케이션 및 인프라 속성에 가중치 또는 관련성을 할당할 수 있습니까?)
+ **웨이브 계획**(예: 권장 애플리케이션 그룹 및 마이그레이션 웨이브 계획 생성 기능)
+ **마이그레이션 비용 추정(마이그레이션** 작업 추정)
*배포 고려 사항*
검색 도구를 선택하고 조달한 후에는 다음 질문을 고려하여 조직에 도구 배포를 담당하는 팀과 대화를 나누세요.
+ 서버 또는 애플리케이션을 타사에서 운영하나요? 이로 인해 팀이 참여하고 따라야 할 프로세스가 필요할 수 있습니다.
+ 검색 도구 배포 승인을 얻기 위한 상위 수준 프로세스는 무엇입니까?
+ 서버, 컨테이너, 스토리지 및 데이터베이스와 같은 시스템에 액세스하기 위한 주요 인증 프로세스는 무엇입니까? 서버 자격 증명은 로컬입니까, 아니면 중앙 집중식입니까? 자격 증명을 얻는 프로세스는 무엇입니까? 시스템(예: 컨테이너, 가상 또는 물리적 서버, 하이퍼바이저 및 데이터베이스)에서 데이터를 수집하려면 자격 증명이 필요합니다. 각 자산에 연결하기 위해 검색 도구의 자격 증명을 얻는 것은 어려울 수 있습니다. 특히 이러한 자산이 중앙 집중화되지 않은 경우 더욱 그렇습니다.
+ 네트워크 보안 영역 개요란 무엇입니까? 네트워크 다이어그램을 사용할 수 있나요?
+ 데이터 센터에서 방화벽 규칙을 요청하는 프로세스는 무엇입니까?
+ 데이터 센터 운영(검색 도구 설치, 방화벽 요청)과 관련된 현재 지원 서비스 수준 계약(SLAs)은 무엇입니까?
# 비즈니스 동인 및 기술 지침 원칙
## 비즈니스 동인
조직이 이미 클라우드로 전환하기로 결정했는지 또는 해당 결정에 근접했는지 여부에 관계없이 클라우드 마이그레이션을 위한 비즈니스 동인을 정의하고 문서화하면 마이그레이션 이유를 명확히 할 수 있습니다. 이유가 문서화된 후 마이그레이션할 대상과 마이그레이션 방법을 정의할 수 있습니다. 이 활동은 중요합니다. 다음 단계를 알리고 안내하려면 프로세스 초기에 수행하는 것이 좋습니다.
토론에 참여해야 하는 이해관계자를 식별하여 동인을 문서화합니다. 일반적으로 CxOs, 고위 관리자, 조직 내 주요 기술 리더 및 자체 고객. 고객이이 토론에 참여할 가능성은 낮지만 조직의 한 명 이상의 사람이 지정되어 고객의 관점과 목표를 나타내는 것이 좋습니다.
비즈니스 동인은 마이그레이션 여정 전체에서 측정할 수 있는 지표에 연결되어 결과가 달성되었는지 확인해야 합니다. 회사의 전략적 목표와 연간 보고서는 출발점 역할을 할 수 있습니다.
클라우드로 전환한 결과로 기존 지표와 예상 지표를 기반으로 회사가 원하는 위치에 대한 대화에 집중합니다. 목표와 비즈니스 성과를 고려합니다. 또한 클라우드 채택이 증가함에 따라 성공이 어떤 모습인지 생각해 보세요.
그런 다음 각 드라이버의 중요도 수준을 설정합니다. 우선 순위는 무엇입니까? 예상되는 이점은 무엇입니까? 이점이 비즈니스 목표와 성과를 어떻게 지원하나요? 애플리케이션 포트폴리오 평가의 맥락에서 답변은 마이그레이션을 위한 워크로드의 우선순위를 지정하고 기술 가이드 원칙을 설정하는 데 도움이 됩니다. 그러나 비즈니스 동인은 마이그레이션 프로그램 전체를 정의하고 영향을 미칩니다.
## 기술 지침 원칙
기술 지침 원칙은 포트폴리오 평가의 후반부 단계에서 마이그레이션 전략 선택을 안내합니다. 현재 단계에서는 이를 식별하는 데 중점을 둡니다.
기본 원칙은 비즈니스 목표 및 성과에서 파생된 일반적인 기술 관련 및 접근 방식 관련 결정으로 설정할 수 있습니다.
예를 들어 회사는 비용을 절감하는 주요 목표를 가지고 있으며, 원하는 성과는 6\$112개월 내에 지정된 날짜까지 온프레미스 데이터 센터를 닫는 것입니다. 그에 따른 기본 원칙은 가능하면 리호스팅 또는 재배치 마이그레이션 전략을 사용하여 모든 애플리케이션을 클라우드로 리프트 앤드 시프트하는 것입니다. 이 경우 lift-and-shift 접근 방식은 단기 마이그레이션 결과를 가속화합니다. 애플리케이션이 온프레미스 데이터 센터 밖으로 이동한 후 회사는 마이그레이션된 워크로드를 최적화하거나 현대화하기 위해 주요 비즈니스 동인에 집중할 수 있습니다.
기술 지침 원칙을 설정하려면 먼저 비즈니스 동인을 분석합니다. 비즈니스 목표 및 성과를 달성할 수 있는 기술 및 기법 목록을 식별합니다. 그런 다음 목록을 구체화하고 적합성 또는 선호도에 따라 관련성 순서를 할당하여 원하는 결과를 달성합니다.
마이그레이션을 계획하고 수행하는 데 관련된 사람들과 지침 원칙을 문서화하고 전달합니다. 원칙과 실제 구현 간의 우려 사항 및 잠재적 충돌을 강조합니다.
다음 표에는 비즈니스 동인과 기술 지침 원칙의 예가 나와 있습니다.
| **비즈니스 드라이버** | **결과** | **Metrics** | **기술 지침 원칙** |
| --- |--- |--- |--- |
| 혁신을 가속화합니다. | 경쟁력 향상, 비즈니스 민첩성 향상 | 일별 또는 월별 배포 수, 분기당 릴리스된 새로운 기능, 고객 만족도 점수, 실험 수 | 마이크로서비스와 DevOps 운영 모델을 사용하여 차별화된 애플리케이션을 리팩터링하여 새로운 기능의 민첩성과 출시 속도를 높입니다. |
| 운영 및 인프라 비용을 절감합니다. | 공급 및 수요 일치, 탄력적 비용 기반(사용한 만큼 지불) | 시간 경과에 따른 지출 변동 | 1. 인프라 적정 크기로 애플리케이션을 리호스팅합니다.2. 사용률이 낮거나 없는 애플리케이션은 사용 중지합니다. |
| 운영 복원력을 높입니다. | 가동 시간 개선, 평균 복구 시간 단축 | SLAs, 인시던트 수 | 1. 애플리케이션을 가장 잘 지원되는 최신 운영 체제 버전으로 리플랫포밍합니다.2. 중요한 애플리케이션을 위한 고가용성 아키텍처를 구현합니다. |
| 데이터 센터를 종료합니다. | 6\$112개월 이내 날짜별 데이터 센터 폐쇄 | 서버 마이그레이션 속도 | Cloud Migration Factory 솔루션을 사용하여 애플리케이션을 리호스팅합니다. |
| 온프레미스에서는 유지하되 민첩성과 복원력을 높입니다. | 온프레미스에 남아 있는 동안 경쟁 및 가동 시간 개선 | 일별 또는 월별 배포 수, 분기당 새로운 기능 릴리스, SLAs, 인시던트 수 | 1. 기능을 클라우드로 확장하여 시스템을 현대화합니다.2. 리호스팅 또는 리플랫포밍을 평가합니다 AWS Outposts. |
# 데이터 수집 시작
데이터 수집은 애플리케이션 및 인프라에서 메타데이터를 수집하는 프로세스입니다. 프로세스는 평가의 모든 단계에서 반복적입니다. 각 단계에서 데이터 수량과 충실도가 증가합니다. 이 단계에서는 초기 인벤토리를 설정하는 데 도움이 될 수 있는 일반 데이터를 수집하는 데 중점을 둡니다. 인벤토리는 방향성 비즈니스 사례를 생성하고 초기 마이그레이션 후보를 식별하는 데 사용됩니다.
현재 데이터 소스를 식별한 후에는 가능한 한 많은 시스템에서 정보를 수집하는 것이 좋습니다. 자세한 내용은이 단계의 [데이터 요구 사항을](understanding-initial-assessment-data-requirements.md) 참조하세요.
이 접근 방식은 현재 포트폴리오 보기와 애플리케이션 및 서비스에 대한 조직의 지식을 업데이트하는 데 도움이 되는 이점이 있습니다. 또한 이동할 대상을 결정하는 데도 도움이 됩니다. 권장 접근 방식은 구성 관리 데이터베이스(CMDB) 출력 및 정보 기술 서비스 관리(ITSM) 시스템과 같은 기존 데이터를 검토하는 것입니다. 그런 다음 데이터 수집을 대상으로 하는 자산 목록을 구성합니다. 조직에서 마이그레이션 범위 내에 있고 범위를 벗어난 항목을 완전히 명확히 파악한 경우 데이터 수집을 범위 내에 있는 시스템으로 제한할 수 있습니다.
포트폴리오를 구축할 때 애플리케이션과 해당 환경 또는 소프트웨어 릴리스 수명 주기를 고려하세요. 예를 들어 고객 관계 관리(CRM) 애플리케이션을 식별하고 테스트, 개발 및 생산 환경이 있음을 지정하는 대신 세 가지 애플리케이션(예: CRM-Test, CRM-Dev, CRM-Prod)을 나열합니다. 또는 CRM 이름을 사용하지만 각 환경에 고유한 ID를 할당하고 데이터 리포지토리에 별도의 레코드로 제공합니다. 이렇게 하면 이러한 환경의 마이그레이션을 개별적으로 계획하고 추적하는 데 도움이 됩니다. 예를 들어 비프로덕션 환경을 먼저 마이그레이션할 수 있습니다. 환경에 따라 애플리케이션 인스턴스를 나열하면 전환을 명확하게 관리하고 관리할 수 있습니다.
데이터 수집 중에 특정 데이터 센터 또는 소스 위치에 있는 애플리케이션 또는 서버에 대한 불확실성이 있을 수 있습니다. 이러한 경우 기존 관리 도구에서 베어 메탈 및 하이퍼바이저 목록을 가져오는 것이 좋습니다. 예를 들어 하이퍼바이저에 연결하여 데이터 수집 대상 가상 머신 목록을 가져올 수 있습니다.
기존 데이터 소스를 결합할 때 초기 출력이 불완전할 수 있습니다. 핵심은이 단계의 [데이터 요구 사항](understanding-initial-assessment-data-requirements.md)과 기존 소스에서 얻을 수 있는 내용 측면에서 격차 분석을 수행하는 것입니다. 완전성의 백분율을 데이터 충실도 수준과 대조하는 것이 중요합니다. 충실도가 낮은 소스의 완전성 수준이 높을수록 분석 결함으로 이어질 수 있는 몇 가지 가정이 포함됩니다. 이 평가 단계에서는 최대 데이터 충실도가 필요하지 않지만 데이터 소스는 최소한 중간에서 중간까지 충실도가 높은 것이 좋습니다. 이러한 수치와 데이터 격차를 줄이기 위한 가정 사용을 포함하여 조직의 위험 허용 오차를 비교합니다.
격차 분석은 작업 중인 데이터의 양과 품질을 이해하는 데 도움이 됩니다. 또한 분석을 통해 방향성 비즈니스 사례를 생성하고 마이그레이션을 위한 애플리케이션의 우선순위를 정하기 위해 수행해야 하는 가정 수준을 설정할 수 있습니다. 검색 도구는 격차를 해소하고 충실도가 높은 데이터를 수집하는 데 도움이 될 수 있습니다. 데이터의 신뢰도 수준을 높이고 마이그레이션 결과를 가속화하려면 최대한 빨리 검색 도구를 배포하는 것이 좋습니다. 새 도구의 내부 조달, 보안 및 구현 프로세스를 완료하는 데 몇 주 또는 몇 달이 걸릴 수 있으므로 초기 조치도 중요합니다.
이 단계에서는 커뮤니케이션 계획 또는 주기와 범위 변경 제어 메커니즘을 설정하는 것이 좋습니다. 이를 통해 이해관계자가 미리 계획을 세우고 위험을 완화할 수 있도록 이해관계자에게 최신 정보를 제공할 수 있습니다. 명확한 커뮤니케이션의 핵심 요소는 애플리케이션 포트폴리오 및 관련 인프라에 대한 단일 정보 소스를 정의하는 것입니다. 여러 개의 레코드 시스템, 애플리케이션 및 인프라 목록을 보관하지 마세요. 버전 관리 및 온라인 공동 작업을 지원하는 데이터(예: 데이터베이스, 도구 또는 스프레드시트)를 한 곳에 보관하고 소유자를 할당합니다.
# 우선순위 지정 및 마이그레이션 전략
마이그레이션 계획의 핵심 요소는 우선순위 기준을 설정하는 것입니다. 이 연습의 요점은 애플리케이션을 마이그레이션할 순서를 이해하는 것입니다. 전략은 우선순위 지정 모델을 발전시키기 위해 반복적이고 점진적인 접근 방식을 취하는 것입니다.
## 애플리케이션 우선 순위 지정
이 평가 단계는 저위험 및 저복잡성 워크로드의 우선 순위를 정하기 위한 초기 기준을 설정하는 데 중점을 둡니다. 이러한 워크로드는 파일럿 애플리케이션에 적합합니다. 초기 마이그레이션에서 위험이 낮고 복잡성이 낮은 워크로드를 사용하면 위험이 줄어들고 팀이 경험을 얻을 수 있는 기회가 제공됩니다. 이러한 기준은 마이그레이션 웨이브 플랜을 생성할 때 비즈니스 동인에 우선순위를 맞추기 위해 추가 평가 단계에서 발전할 것입니다.
초기 기준은 클라우드 지원 인프라와 비프로덕션 환경에서 실행되는 소수의 종속성이 있는 애플리케이션의 우선 순위를 지정해야 합니다. 예를 들어 개발 또는 테스트 환경에서 있는 그대로 리호스팅할 준비가 된 종속성이 0\$13개인 애플리케이션이 있습니다. 이러한 기준은 클라우드 채택 성숙도 및 신뢰도 수준에 따라 파일럿 애플리케이션과 잠재적으로 첫 번째 및 두 번째 마이그레이션 웨이브를 정의하는 데 유효합니다.
*사용할 초기 기준 결정*
첫 번째 워크로드의 우선 순위를 지정하는 데 사용할 데이터 포인트를 2\$110개 선택합니다. 이러한 데이터 포인트는 초기 애플리케이션 및 인프라 인벤토리에서 가져옵니다([데이터 수집](initiating-data-collection.md) 섹션 참조).
그런 다음 각 데이터 포인트의 가능한 각 값에 대한 점수 또는 가중치를 정의합니다. 예를 들어 환경 속성을 선택하고 가능한 값이 프로덕션, 개발 및 테스트인 경우 각 값에 점수가 할당되며, 숫자가 클수록 우선 순위가 높습니다. 선택 사항이지만 중요도 또는 관련성을 각 데이터 포인트에 곱하는 요소를 할당하는 것이 좋습니다. 이 선택적 단계는 더 중요한 것이 무엇인지 강조하는 상위 수준의 차별화 요소를 제공하므로 값에 점수를 반복적으로 할당할 때 기준을 일치시키는 데 도움이 됩니다.
다음 표에는 처음 몇 번의 마이그레이션 웨이브에 대해 위험도가 낮고 간단한 애플리케이션의 우선 순위를 지정하는 전략에 따라 속성 선택 예제와 해당 값 할당이 나와 있습니다.
| **속성(데이터 포인트)** | **가능한 값** | **점수(0\$199)** | **중요도 또는 관련성 곱하기 계수** |
| --- |--- |--- |--- |
| 환경 | 테스트 | 60 | 높음(1x) |
| 개발 | 40 |
| 프로덕션 | 20 |
| 비즈니스 중요도 | 낮음 | 60 | 높음(1x) |
| 중간 | 40 |
| 높음 | 20 |
| 규제 또는 규정 준수 프레임워크 | 없음 | 60 | 높음(1x) |
| FedRAMP | 10 |
| 운영 체제 지원 | 클라우드 지원 | 60 | 중간-높음(0.8x) |
| 클라우드에서 지원되지 않음 | 10 |
| 컴퓨팅 인스턴스 수 | 1-3 | 60 | 중간-높음(0.8x) |
| 4-10 | 40 |
| 11개 이상 | 20 |
| 마이그레이션 전략 | 리호스팅 | 70 | 중간(0.6x) |
| 리플랫포밍 | 30 |
| 리팩터링 또는 리아키텍트 | 10 |
애플리케이션 간의 주요 차별화 요소 역할을 할 수 있는 속성을 선택해야 합니다. 그렇지 않으면 기준이 동일한 우선 순위를 공유하는 워크로드가 많습니다. 모델을 적용한 후에는 결과 순위의 상단과 하단을 보고 동의하는지 확인하는 것이 좋습니다. 일반적으로 동의하지 않는 경우 워크로드 점수를 매기는 데 사용한 기준을 다시 살펴볼 수 있습니다.
순위를 얻은 후 전체 포트폴리오의 점수 분포를 살펴봅니다. 점수 자체는 중요하지 않습니다. 중요한 것은 점수 간의 차이입니다. 예를 들어 최고 총 점수는 8,000이고 최저 점수는 800입니다. 분포가 좋은지 확인할 수 있도록 결과 점수를 히스토그램으로 도표화하는 것이 좋습니다. 이상적인 분포는 몇 개의 매우 높은 우선 순위 워크로드와 몇 개의 매우 낮은 우선 순위 워크로드가 있는 표준 종형 곡선과 같습니다. 대부분의 애플리케이션은 중간에 있습니다.
초기 우선순위 지정의 또 다른 주요 측면은 클라우드를 조기에 채택하는 데 관심을 보이는 내부 팀 또는 사업부를 포함하는 것입니다. 이는 특히 초기에 특정 애플리케이션을 마이그레이션하기 위한 비즈니스 지원을 받는 데 상당한 도움이 될 수 있습니다. 조직의 경우 위 표에 사업부 속성을 포함시킵니다. 애플리케이션을 제공할 의향이 있는 사업부에 높은 점수를 할당합니다. 사업부 속성을 사용하면 해당 애플리케이션을 목록 맨 위로 가져오는 데 도움이 됩니다.
결과 순위에 동의한 후 상위 5\$110개 애플리케이션을 선택합니다. 이들은 초기 애플리케이션 마이그레이션 후보가 됩니다. 3\$15개의 애플리케이션을 확인하도록 목록을 구체화합니다. 이를 통해 상세한 애플리케이션 평가를 수행할 때 대상 접근 방식을 취할 수 있습니다. 자세한 내용은 [우선 순위가 지정된 애플리케이션 평가를](prioritized-applications-assessment.md) 참조하세요.
## 마이그레이션을 위한 R 유형 결정
각 애플리케이션 및 관련 인프라에 대한 마이그레이션 전략을 결정하면 마이그레이션 속도, 비용 및 이점 수준에 영향을 미칩니다. 비즈니스 동인, 기술 지침 원칙, 우선순위 기준, 비즈니스 전략 등 요소의 균형 잡힌 조합을 기반으로 전략을 결정하는 것이 중요합니다.
이러한 요인으로 인해 보기가 충돌하는 경우가 있습니다. 예를 들어 마이그레이션의 주요 동인은 혁신과 민첩성일 수 있습니다. 동시에 비용을 빠르게 줄여야 할 수도 있습니다. 범위 내에서 모든 애플리케이션을 현대화하면 장기적으로 비용을 절감할 수 있지만 더 많은 투자를 선결제해야 합니다. 이 경우 한 가지 접근 방식은 리호스팅 또는 리플랫포밍과 같이 적은 노력이 필요한 전략을 사용하여 애플리케이션을 마이그레이션하는 것입니다. 이는 단기적으로 빠른 효율성과 비용 절감을 제공할 수 있습니다. 그런 다음 나중에 애플리케이션을 현대화하는 데 비용 절감을 다시 투자하고 추가 비용을 절감합니다.
그러나 모든 애플리케이션의 완전한 리호스팅부터 시작하면 현대화의 더 큰 이점이 지연됩니다. 핵심은 마이그레이션 전략 간의 균형을 찾아 비즈니스 전략 애플리케이션이 현대화를 우선시하는 반면 다른 애플리케이션은 먼저 리호스팅하거나 리플랫포밍한 다음 현대화할 수 있도록 하는 것입니다.
*애플리케이션의 마이그레이션 전략을 어떻게 결정하나요?*
이 평가 단계에서는 마이그레이션 전략 선택을 안내하기 위한 초기 모델을 통합하는 데 중점을 둡니다. 초기 애플리케이션의 마이그레이션 전략을 검증하려면 비즈니스 동인 및 우선순위 기준과 함께 모델을 사용합니다. 결정 트리의 기본 로직은 범위에 대한 초기 처리를 결정하는 데 도움이 됩니다. 트리에서는 리팩터링 또는 리아키텍트와 같은 가장 복잡한 접근 방식이 전략적 워크로드용으로 예약되어 있습니다.
![\[이 가이드에서 설명하는 6R 결정 프로세스입니다.\]](http://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/application-portfolio-assessment-guide/images/6Rs-DecisionTree-baseModel.png)
이 다이어그램의 사용자 지정 가능한 [draw.io](https://github.com/jgraph/drawio-desktop/releases) 버전은 *[첨부](#attachments)* 파일 섹션에서 확인할 수 있습니다.
초기 모델의 첫 번째 단계는 트리 상단의 비즈니스 동인을 조직에서 정의한 동인으로 업데이트하는 것입니다. 다음으로 애플리케이션 전체가 아닌 애플리케이션 구성 요소에 트리를 적용합니다. 예를 들어 세 가지 구성 요소(프런트 엔드, 애플리케이션 계층 및 데이터베이스)가 있는 3계층 애플리케이션의 경우 각 구성 요소는 트리를 독립적으로 전송하고 특정 전략 및 패턴을 할당받아야 합니다. 이는 경우에 따라 특정 티어를 리호스팅하거나 리플랫포밍하고 다른 티어를 리팩터링(리아키텍트)할 수 있기 때문입니다.
독립 구성 요소 할당을 통해 연결된 인프라에 대한 마이그레이션 전략을 정의할 수 있습니다. 인프라 전략은 지원하는 애플리케이션 구성 요소와 동일한 전략이거나 다를 수 있습니다. 예를 들어 최신 운영 체제를 사용하는 새 가상 머신으로 리플랫포밍되는 애플리케이션 구성 요소는 리플랫포밍 전략을 따르는 반면 해당 구성 요소를 호스팅하는 현재 가상 머신은 사용 중지됩니다. 인프라에 대한 마이그레이션 전략은 애플리케이션 구성 요소에 대해 선택한 전략을 기반으로 계산됩니다.
의사 결정 트리를 사용하여 마이그레이션 전략을 설정하기 전에 몇 가지 애플리케이션으로 로직을 테스트하고 일반적으로 결과에 동의하는지 확인합니다. 6Rs 의사 결정 트리는 정확성을 결정하는 데 필요한 분석을 대체하지 않는 가이드입니다. 트리 로직은 특정 사례에 적용되지 않을 수 있습니다. 이러한 사례를 예외로 처리하고 트리 로직을 변경하는 대신 재정의의의 근거를 문서화하여 트리가 주도하는 결정을 재정의합니다. 이렇게 하면 관리가 어려울 수 있는 여러 의사 결정 트리 버전을 방지할 수 있습니다. 일반적인 지침은 트리가 워크로드의 70\$180% 이상에서 유효해야 한다는 것입니다. 나머지는 예외가 있습니다. 이 평가 단계에서 트리 로직을 조정하려면 초기 모델을 설정하는 데 집중해야 합니다. [포트폴리오 분석 및 마이그레이션 계획과 같은 추가 반복 및](portfolio-analysis-migration-planning.md) 개선은 이후 단계에서 이루어집니다.
## 첨부 파일
[attachment.zip](samples/attachment.zip)
# 방향성 비즈니스 사례 생성
비즈니스 전반의 이해관계자는 각 단계에서 혁신을 위해 비즈니스 사례를 이해하고 구매해야 합니다.
초기 단계에서는 프로그램을 계획하고 설정하는 데 필요한 리소스를 보호할 수 있도록 마이그레이션 프로그램의 잠재적 가치를 충분히 빠르게 보여주는 것이 중요합니다. 방향성 비즈니스 사례는 조기에 수집할 수 있는 제한된 데이터로 매력적인 비즈니스 가치를 달성하는 데 합리적인 확신을 제공하도록 설계되었습니다.
프로그램이 설정되면 비즈니스 사례가 추가로 개발됩니다. 자세한 사례는 정확도 향상, 프로그램 가치에 대한 보다 완전한 그림, 계획 우선 순위에 대한 인사이트를 제공합니다. 조직이 구매하는 계획된 비즈니스 성과를 정의하고 정량화하며, 프로그램 거버넌스 사무소가 프로그램을 주도하고 성과를 측정할 수 있는 기준을 설정합니다.
## 방향성 비즈니스 사례의 범위 수정
방향성 비즈니스 사례는 일반적으로 2\$14주 이내에 빠르게 수집됩니다. 리소스를 보호하여 핵심 팀을 설정하고, 필요한 경우 AWS 파트너를 참여시키고, 최소한 [우선 순위가 지정된 애플리케이션 평가](prioritized-applications-assessment.md), [포트폴리오 분석 및 마이그레이션 계획](portfolio-analysis-migration-planning.md) 단계를 완료할 수 있도록 충분한 신뢰도를 생성해야 합니다.
일반적으로 포트폴리오 마이그레이션을 지원하는 방향성 비즈니스 사례는 다음 중 하나로 생성됩니다.
+ 있는 그대로 인프라 환경과 마이그레이션 후 AWS 서비스 아키텍처 간의 간단한 *총 소유 비용(TCO)*** **비교입니다. 비교는 지정된 워크로드 볼륨에 대한 예상 실행 속도의 차이를 보여줍니다.
+ 마이그레이션 비용과 그대로 유지를 AWS 포함하여 마이그레이션하기 위한 순 현재 가치(NPV), 투자 수익률(ROI), 회수 기간, 수정된 내부 수익률(MIRR) 및 3\$15년 현금 흐름 분석을** **보여주는 비즈니스 사례입니다.
방향성 비즈니스 사례 범위는 일반적으로 다음 중 하나로 제한됩니다.
+ 인프라 기술 비용 비교
+ 인프라 기술 및 운영 비용 비교
일반적으로 포트폴리오가 클수록 개발해야 하는 사례가 줄어듭니다. 이는 결과에 큰 영향을 주지 않고 더 광범위한 가정을 할 수 있기 때문입니다. 더 작은 포트폴리오의 경우 변경 사항이 더 큰 영향을 미치므로 더 자세한 정보가 필요합니다.
먼저 기본 인프라 비용 비교를 구축합니다. 그런 다음 계속하기 전에 비교가 충분히 매력적인지 확인합니다. 일반적으로 400개 이상의 서버 포트폴리오는 운영 후 3년 이내에 인프라 비용 절감만으로 AWS또는 5년 이내에 250개의 서버로 구성된 긍정적인 비즈니스 사례를 보여주지만 이는 다를 수 있습니다. 더 작은 포트폴리오의 경우 더 자세한 정보가 필요할 수 있습니다.
반대로 총 마이그레이션 범위가 약 5개의 워크로드 또는 50개의 서버 미만이 아닌 한 복원력 향상 또는 비즈니스 민첩성에서 파생된 값과 같은 다른 비즈니스 가치 구성 요소를이 단계에서 검사하는 것은 거의 유용하지 않습니다.
## 포커스 값 동인
인프라 기술 TCO 비교는 있는 그대로 인프라 비용의 모델을 동등한 성능과 가용성으로 워크로드를 실행하는 데 필요한 재료 AWS 서비스 표의 기본 모델과 비교합니다. 많은 최적화를 수행할 수 있습니다. 그러나이 단계에서는 평가가 더 쉽고 일반적으로 약 30%의 TCO 절감을 달성하므로 다음 목록에 중점을 둡니다.
+ **컴퓨팅 탄력성** - 8x5(24% 사용량), 10x5(30%) 또는 10x6(36%)을 실행하는 개발 또는 UAT 서버, 2%로 실행되는 재해 복구(DR) 서버와 같이 사용량이 100%가 아닌 서버를 사용 시에만 요금이 청구되는 온디맨드 서비스에 매핑합니다.
+ **절감형 플랜으로 조달** - 비용을 최대 75% 절감할 수 있는 적절한 절감형 플랜으로 사용량이 많은(36% 초과) 프로덕션 서버 및 기타 서버를 조달할 계획입니다. 옵션에는 1년 약정과 3년 약정이 포함되며, 더 큰 할인을 보장하기 위해 선결제 금액이 다릅니다.
+ **좀비 제거 **- CPU 사용률이 2% 미만인 서버를 식별하여 더 이상 필요하지 않음을 확인하고 비용 분석에서 제거합니다.
+ **올바른 컴퓨팅 크기 조정 -** CPU 및 메모리 사용률 시계열 데이터를 사용하여 각 서버에 필요한 컴퓨팅 성능과 메모리를 평가합니다. 그런 다음 적합한 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 선택합니다.
+ **관계형 데이터베이스 관리 시스템(RDBMS) 라이선스 적정 크기 조정 -** 데이터베이스 서버의 컴퓨팅 적정 크기 조정 후 RDBMS 라이선스 요구 사항을 재평가하고, 기존 보유 라이선스 사용(BYOL)과에서 라이선스 조달을 비교하고 AWS, Amazon Relational Database Service(RDS)가 비용 절감 효과를 높일 수 있는 가능성을 살펴봅니다.
+ **스토리지** - 필요한 총 스토리지 볼륨의 크기를 조정하고 포트폴리오 전반의 초당 입/출력 작업(IOPS) 요구 사항을 식별합니다. SLAs와 비용이 서로 다른 객체 스토리지로 이동할 수 있는 양을 결정합니다.
## 데이터 요구 사항
[초기 평가 데이터 요구 사항 이해](understanding-initial-assessment-data-requirements.md)의 표에는 방향성 비즈니스 사례의 각 부분을 구축하는 데 필요한 데이터와 필수인지 아니면 선택 사항인지가 나와 있습니다.
사례를 구축하려면 초기 계획 데이터의 인프라 하위 집합과 비용 데이터가 필요합니다. 포함할 인프라를 식별하는 방법은 비즈니스 목표에 따라 결정됩니다.
+ 프로그램의 목표가 특정 애플리케이션을 마이그레이션하고 현대화하는 경우 공유된 인프라를 고려하여 애플리케이션에 필요한 것을 기반으로 인프라 포트폴리오를 구축합니다.
+ 임대가 만료될 예정인 데이터 센터에서 마이그레이션하는 등 프로그램의 목표가 인프라 중심인 경우 인프라 TCO 비교에 애플리케이션 매핑이 필요하지 않습니다.
선택 사항으로 표시된 데이터(예: 서버의 CPU 및 메모리 피크 사용률)는 일반적으로 표준 벤치마크 값으로 대체할 수 있습니다. AWS 파트너 또는 AWS 전문 서비스와 이에 대해 논의할 수 있습니다. 또는 포트폴리오의 일부(예: 하이퍼바이저에서 수집한 데이터)에서 사용할 수 있는 데이터 포인트의 값을 추정할 수 있습니다. 포트폴리오가 클수록 더 정확합니다.
## 인프라 TCO 비교 구축
도구는 인프라 TCO 비교를 구성하는 데 매우 중요합니다. [AWS 전문 서비스](https://aws.amazon.com/professional-services/) 또는 [AWS 파트너는](https://aws.amazon.com/migration/partner-solutions/) 특히 광범위한 마이그레이션 프로세스를 지원하기 위해 참여하려는 경우 모든 유형의 방향성 사례에 도움을 제공할 수 있습니다.
다음을 수행하는 데 사용할 수 있는 도구가 있습니다.
+ 인벤토리 데이터를 수집합니다.
+ 사용률 데이터를 수집합니다.
+ 정확한 그대로 인프라 비용 벤치마킹 데이터를 제공합니다.
+ 좀비 식별 및 제거.
+ 적절한 규모의 평가를 수행합니다.
+ 구매 옵션을 권장합니다.
+ 소프트웨어 라이선스 옵션을 비교합니다.
+ 간단한 그래픽 현금 흐름 분석을 생성합니다.
의 [마이그레이션 평가자](https://aws.amazon.com/migration-evaluator/)는 한 가지 옵션 AWS 입니다. 이 모든 기능을 **무료 관리형 서비스로 제공합니다. AWS 계정 관리자 또는 마이그레이션 역량 파트너를 통해 또는 온라인으로 요청을 제출하여 AWS 마이그레이션 평가자를 요청할** 수 있습니다. [https://pages.awscloud.com/Migration-Evaluator-request.html](https://pages.awscloud.com/Migration-Evaluator-request.html) 마이그레이션 평가자는 인프라 기술 TCO 비교를 신속하게 생성하기 위한 포인트 솔루션으로 특별히 설계되었습니다.
주요 이점:
+ 무료
+ 도구 기반 검색이 제한된 인벤토리 데이터의 에이전트 없는 검색 또는 수동 구성
+ 배포, 구성, 데이터 수집 및 기본 사례 또는 방향성 비즈니스 사례 구축을 지원하는 전용 지원
+ SaaS 작업의 편리성, 하지만 분석 엔진에 로드하기 전에 스크러빙을 지원하기 위해 고객 네트워크 내에서 데이터 수집을 완전히 실행할 수 있음
+ Microsoft 라이선스 적정 크기 조정에 대한 강력한 지원
+ 전체 데이터 내보내기 기능
주요 제한 사항:
+ x86 아키텍처 서버(Windows 및 Linux)만 평가
+ 벤치마크를 있는 그대로 비용 데이터를 구성하거나 보정하는 제한된 옵션
+ 운영 비용 최적화 모델링을 지원하지 않음
+ 마이그레이션 비용 모델링을 지원하지 않음
+ TCO 비교를 넘어 비즈니스 사례 구축을 직접 지원하지 않음
애플리케이션 스택 및 상호 종속성 검색과 같은 포트폴리오 검색 및 분석 기능에 상용 검색 도구를 사용하기로 결정한 경우 일반적으로 인프라 TCO 비교도 제공합니다. 포트폴리오 검색 및 평가를 위한 도구 사용에 [대한 지침은 검색 도구의 필요성 평가를 참조하세요](understanding-initial-assessment-data-requirements.md#discovery-tooling). 시장 최고의 도구의 주요 기능을 검토하고 비교하려면 [Discovery, Planning 및 Recommendation 마이그레이션 도구를](https://aws.amazon.com/prescriptive-guidance/migration-tools/migration-discovery-tools/) 참조하세요.
## 운영 비용 최적화 구축
IT 운영 생산성 개선은 마이그레이션의 중요한 가치 기여자인 경우가 많습니다. [Amazon Web Services를 통한 비즈니스 가치 창출을 위한 비즈니스 및 조직 혁신 촉진](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770) 백서에 따르면 마이그레이션 후 평균 AWS적으로 IT 운영 직원 생산성은 마이그레이션을 통해 62% 증가합니다. 그러나 크기 조정과 방향성 사례에 이러한 이점 포함에는 두 가지 문제가 있습니다.
첫째, 생산성 향상의 전체 범위를 평가하려면 광범위한 데이터 수집이 필요하며 [자세한 비즈니스 사례에](detailed-business-case.md) 더 적합합니다. 이 문제는 간단한 벤치마크 데이터로 보다 쉽게 평가되고 크기가 조정되지만 여전히 상당한 이점을 보이는 몇 가지 요소에 집중하여 해결할 수 있습니다.
둘째, 비용 절감의 원인으로 생산성에 집중하면 주요 고객 이해관계자와 프로그램 구성원 간에 우려와 부정성이 발생할 수 있습니다. 혜택이 실현되는 방식과 영향을 받는 사람에게 어떤 의미가 있는지 명확하게 설명해야 합니다. 이러한 문제는 팀의 역할만 개선한다는 점을 명확히 하여 피할 수 있습니다.
+ 마이그레이션 프로그램에는 내부 운영 직원을 개발하고 코드 자동화로 인프라를 구축하는 DevSecOps 팀에 합류하고 팀의 성장을 주도할 자동화를 테스트하는 등 새로운 역할로 이동하는 트랙이 포함되어 있습니다.
+ 내부 직원이 고부가가치 활동에 집중할 수 있도록 운영 아웃소싱 계약의 크기를 조정하고 크기를 조정하여 이점을 실현할 수 있습니다.
고려하려는 운영 혁신을 기반으로이 비즈니스 사례 요소를 구성하는 접근 방식:
+ 기존 사내 운영 팀이 있는 경우 팀원의 역량을 높이고 예상되는 생산성 개선을 보여줍니다.
+ 또는 현재 운영 솔루션에서 AWS Managed Services (AMS) 또는 AWS 파트너의 대체 관리형 서비스로 마이그레이션합니다.
첫 번째 변환의 경우 사례에 포함될 수 있는 생산성 향상에 대한 보수적인 재무 추정치를 얻으려면 다음을 수행하는 것이 좋습니다.
1. 특히 서버 관리 운영 생산성에 중점을 둡니다. 운영 작업의 상당 부분이고, 더 쉽게 평가할 수 있으며, 나중에 더 쉽게 확인되는 경향이 있습니다.
1. 각 정규직(FTE) 직원이 관리할 수 있는 서버 수에 대한 벤치마크를 기반으로 필요한 인력 배치를 계산합니다. 온프레미스에서이 수는 약 150개의 서버입니다. 약 400 AWS개의 서버가 있습니다.
1. 이러한 지표를 EC2 인스턴스 수와 비교하여 온프레미스 서버 수에 적용합니다.
1. 전체 운영 팀에 대한 혼합 비용 요율로 절약된 시간을 곱합니다.
그런 다음 결과가 다음 표(IDC 백서 [비즈니스 촉진 및 Amazon Web Services를 통한 비즈니스 가치 창출을 위한 조직 변환](https://pages.awscloud.com/rs/112-TZM-766/images/AWS-BV%20IDC%202018.pdf?aliId=1614258770)에서 가져온 데이터)에 제공된 역할별 평균 생산성 향상을 크게 초과하지 않는지 확인하여 두 방법 중 하나로 결과를 확인할 수 있습니다.
| **역할** | **효율성 향상** |
| --- |--- |
| IT 인프라 관리 | 62% |
| IT 지원 | 59% |
| 애플리케이션 관리 | 43% |
| 데이터베이스 관리 | 19% |
| 애플리케이션 개발 | 25% |
두 번째 변환의 경우 범위 내 포트폴리오의 현재 총 운영 및 지원 비용을 고려 중인 관리형 서비스의 비용과 직접 비교하여 운영 비용 절감을 추가할 수 있습니다.
관리형 서비스의 비용을 얻으려면 AWS 계정 관리자 또는 [AWS Managed Services 파트너에게](https://aws.amazon.com/managed-services/partners/) 제안된 자재 AWS 명세서, 서비스 수준 선택(Plus 또는 Premium) 및 AMS 패키지(AMS Accelerate 또는 AMS Advanced)를 제공하세요. 이렇게 하면 변환된 솔루션의 구성 요소인AWS 서비스 에 대한 관리형 서비스의 총 비용이 제공됩니다. 마찬가지로 자체 파라미터를 기반으로 자체 관리형 서비스 패키지를 제공하는 AWS 파트너로부터 요금을 받을 수 있습니다.
## 전체 방향성 비즈니스 사례로 확장
일반적으로 전체 방향성 비즈니스 사례를 수집하려면 IT 생산성 요소를 사용하거나 사용하지 않고 TCO 비교를 구축하고 모든 마이그레이션 및 현대화 비용을 추정합니다. 그런 다음 migrate-and-modernize 시나리오 쌍을 다루고 t-migrate-and-modernize하지 않는 현금 흐름을 생성합니다.
가장 기본적인 사례는 단일 시나리오 쌍을 준비하는 것입니다. 여기서 t-migrate-and-modernize 않는 시나리오는 현재 상황이고 migrate-and-modernize 시나리오는 다음과 같은 특성을 갖습니다.
+ 트랜잭션 볼륨, 컴퓨팅 또는 네트워킹 용량의 증가 또는 감소 없음
+ 스토리지 요구 사항의 안정적인 소량 증가
+ 기존 시스템의 기능과 일치하는 Quality-of-service 기능(예: 가용성, 내구성, 처리량 및 성능)
매우 작은 포트폴리오를 제외한 모든 포트폴리오의 경우 방향성 사례 모음을 구축하는 목표에 적합합니다. 앞으로 나아갈 수 있는 권한을 얻기에 충분한 가치를 빠르게 보여줍니다.
소규모 포트폴리오의 경우 다음과 같이 클라우드 migrate-and-modernize와 마이그레이션 t-migrate-and-modernize 금지 시나리오 쌍을 추가하는 것이 유용할 수 있습니다.
+ 이러한 성장이 예상되는 워크로드 전반의 중간 및 대용량 성장 요구 사항 혼합
+ 고가용성, DR 및 내결함성과 같은 향상된 복원력 포함
+ 엣지 컴퓨팅, 콘텐츠 전송 네트워크(CDN), 다중 리전 데이터베이스 복제를 통해 글로벌 성능을 개선했습니다.
+ 프로그램의 비즈니스 우선 순위를 설정한 기타 특정 개선 서비스 품질
이러한 시나리오의 경우 현재 비클라우드 인프라 아키텍처를 새 사양과 일치하도록 업그레이드할 때 발생하는 비용 및 현금 흐름 영향을 정확하게 추정해야 합니다. 이 추정치를 얻는 가장 직접적인 방법은 시스템 통합자에게 인용을 요청하는 것일 수 있습니다. 특히 마이그레이션 및 migrate-and-modernize 시나리오와 마이그레이션 t-migrate-and-modernize 시나리오를 모두 지원할 수 있는 마이그레이션 역량을 갖춘 AWS 컨설팅 파트너인 경우 더욱 그렇습니다.
각 시나리오 쌍에 대해 다음으로 구성된 사례를 수집합니다.
+ 마이그레이션 t-migrate-and-modernize 않는 시나리오의 비용입니다. 가장 기본적인 경우에는 다음이 포함됩니다.
+ 현재 인프라 구성의 비즈니스 사례 기간 동안 총 소유 비용
+ 컴퓨팅, 스토리지 및 네트워크 트래픽 소비의 주기적 증가
+ 다음을 포함한 migrate-and-modernize 시나리오의 비용:
+ 세부 검색, 마이그레이션 계획, 세부 비즈니스 사례 개발, 핵심 팀 설정 및 기술 향상, 아직 없는 경우 랜딩 존 설정, 마이그레이션된 워크로드에 대한 보안 관리 및 운영 통합 설정 등 프로그램 설정
+ 워크로드 마이그레이션 및 현대화 비용
+ 네트워크 연결, [AWS Snowball Edge](https://aws.amazon.com/snowball/) 및와 같은 데이터 마이그레이션 서비스를 포함한 마이그레이션 인프라 비용[AWS DataSync](https://aws.amazon.com/datasync/), 마이그레이션 프로세스 자체에 필요한 아키텍처의 AWS 유틸리티 비용(예: 테스트용)
+ 웨이브가 가동됨에 따라 마이그레이션 과정에서 AWS 유틸리티 비용의 증가 및 AWS 기반 서비스로 대체되고 폐기될 때 기존 인프라 비용의 감소
+ 모든 부실 자산에 대한 폐기 비용 및 상각
## 마이그레이션 및 현대화 프로그램 설정 추정
성공을 위한 프로그램을 설정하려면 일련의 기본 활동을 실행하여 기준 기능을 구축하고 이전에 수행하지 않은 경우 세부 계획을 수립해야 할 수 있습니다. 이러한 기본 활동에는 다음이 포함됩니다.
1. 포트폴리오 [분석 및 마이그레이션 계획 섹션에 설명된 대로 세부 포트폴리오 검색, 마이그레이션 계획 및](portfolio-analysis-migration-planning.md) 세부 비즈니스 사례 개발을 수행하고 사용된 검색 도구의 비용을 문서화합니다.
1. 교육 및 채용을 통해 클라우드 비즈니스 및 기술 핵심 팀을 구축하고 사내 기술을 개발합니다. 교육이 필요한 IT 조직의 구성원을 식별하고 각 사람에게 교육 예산을 할당합니다.
1. 필요한 비용, 운영 및 보안 거버넌스 기능을 지원하도록 [랜딩 존](https://aws.amazon.com/solutions/implementations/aws-landing-zone/)을 설정하고 구성합니다.
AWS 컨설팅 파트너는 항목 1 및 3에 대한 견적을 제공하는 데 도움을 줄 수 있습니다.
*마이그레이션 및 현대화 비용 추정*
방향성 비즈니스 사례의 목표를 충족하고 다음 단계로 진행하기에 *충분한* 상업적 잠재력을 입증하려면 마이그레이션 및 현대화 비용 추정을 가능한 한 기본으로 유지합니다.
이를 위해 다음 마이그레이션 전략에 속하는 애플리케이션에 집중하여 방향성 비즈니스 사례를 준비하는 것이 좋습니다.
+ 만료
+ 보관
+ 재배치하다
+ 리호스팅
+ 리플랫포밍
+ 재구매
일반적으로 워크로드의 약 70%는 리호스팅, 재배치 또는 리플랫포밍할 수 있으며, 또 다른 5%는 사용 중지할 수 있습니다. 마이그레이션 전략을 통해 애플리케이션을 평가하면 일반적으로 비용 절감 사례의 핵심이 해결됩니다.
리팩터링 또는 리아키텍팅 비용을 추정하는 것은 복잡할**** 수 있습니다. 방향성 비즈니스 사례를 준비하는 데 주어진 기간 내에 이를 시도하는 것은 실용적이지 않습니다. 앞서 [마이그레이션을 위한 R 유형 결정](prioritization-and-migration-strategy.md#migration-r-type)에서 설명한 대로 마이그레이션 및 현대화의 첫 번째 단계에서 리호스팅, 재배치 또는 리플랫포밍 전략을 사용하는 것이 좋습니다. 이러한 R 전략은 초기 페이백을 가속화하고, 구현 위험을 줄이고, 단기적으로 비즈니스 사례를 개선할 가능성이 높습니다. 또한 애플리케이션 팀이 AWS 환경 내에서 실행 중인 애플리케이션을 그렇지 않은 애플리케이션보다 현대화하는 것이 훨씬 쉽습니다. [세부 비즈니스 사례가](detailed-business-case.md) 준비되면 특정 애플리케이션을 리팩터링(리아키텍처링)하기 위한 추정치를 추가하는 것이 가장 좋습니다.
*전략별 마이그레이션 작업 추정*
마이그레이션마다 다릅니다. 예산 또는 계획을 약정하기 전에 프로젝트를 책임질 팀의 마이그레이션 활동에 대한 워크로드 추정치를 시드하세요. 이는 사내 애플리케이션 팀, AWS 전문 서비스 또는 AWS 파트너 조직입니다.
방향성 사례를 구축하는 데 도움이 되도록 다음 표에는 다양한 처리에 대한 표시 작업 범위가 나와 있습니다. 이러한 범위는 medium-to-large 포트폴리오가 마이그레이션되고 있으며 마이그레이션 팀이 훈련되고 경험이 있다고 가정합니다. 소규모 포트폴리오의 경우 방향성 사례에도 마이그레이션을 담당하는 팀이 견적을 준비하도록 하는 것이 가장 좋습니다.
| 마이그레이션 전략 | 추정 프로세스 | 요소 | 사람 시간 | 사람 시간 |
| --- |--- |--- |--- |--- |
| Retain | Do nothing, with no cost, no benefits, and no reduction in technology debt. | – | – | – |
| Retire | Estimate decommissioning the hardware equipment used, if any. | – | – | – |
| Relocate | Estimate copying the workload within VMware using VMware tools. This includes copying the data, smoke testing to verify, and any hardware decommissioning. The effort to relocate VMs is typically less than for low-complexity rehost patterns. | – | – | – |
| Rehost | Estimate copying the workload and data with an image copy, smoke testing, high availability (HA) and disaster recovery (DR) testing where appropriate for production servers, and any hardware decommissioning. The best practice is to use tools such as [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/). Divide workloads into low, medium, and high complexity, based on factors such as whether a database or other infrastructure software is running, database complexity, whether clustered, integration complexity, and data volumes. | Effort per app per server | Migration | HA/DR test |
| Low | 10–14 | 3–5 |
| Medium | 16–24 | 4–6 |
| High | 26–38 | 8–12 |
| Replatform | For replatform migrations that include upgrades to operating system or RDBMS version, take the estimate for a rehost, and add time to run a rebuild and smoke test on the new platform.If the replatform includes changing the technology of the platform, estimate additional time for the use of the conversion tools, such as [AWS Schema Conversion Tool](https://aws.amazon.com/dms/schema-conversion-tool/) and [AWS Database Migration Service](https://aws.amazon.com/dms/), and a more complete application test. An example of changing the technology is migrating away from a proprietary commercial database to an open source replacement. | Effort per app per server | Version up | Technology change |
| Low | Add 1–3 | Add 10–15 |
| Medium | Add 2–5 | Add 20–30 |
| High | Add 4–8 | Add 40–60 |
| Repurchase | Estimate data extraction, transformation, and uploading into the newly purchased SaaS service replacement, and any hardware decommissioning. | – | – | – |
*마이그레이션 인프라 비용 추정*
마이그레이션 과정에서 사용할 인프라에 대한 추정치를 포함합니다. 일반적으로 이러한 추정치는 다음과 같습니다.
+ 현재 환경에서 로 워크로드 및 데이터 마이그레이션을 위한 연결 및 데이터 교환 서비스 예산 AWS
+ 마이그레이션, 테스트 및 전환 프로세스 중에 마이그레이션된 워크로드를 호스팅하는 데 필요한 AWS 서비스 (특히 컴퓨팅 및 스토리지) 예산
+ 각 마이그레이션 웨이브가 완료될 때 AWS 유틸리티 비용 증가
+ 마이그레이션된 워크로드를 더 이상 실행하지 않을 기존 인프라의 폐기 비용
데이터 교환의 경우 총 데이터 볼륨을 검사하고 네트워킹 사용 가능성을 평가합니다. 마이그레이션 후 운영 용도로 WAN의 특정 지점[Site-to-Site VPN](https://aws.amazon.com/vpn/) AWS 으로 또는 [AWS Direct Connect](https://aws.amazon.com/directconnect/) 링크를 미리 프로비저닝한 경우 해당 리소스를 서비스 할당량까지 사용할 수 있습니다.
네트워크 용량이 충분하지 않은 경우 가상 프라이빗 네트워크(VPN)를 사용하여 인터넷 대역폭을 단기적으로 늘리는 것이 비용 효율성이 높은 솔루션인 경우가 많습니다. 그렇지 않은 경우 [AWS Snowball Edge](https://aws.amazon.com/snowball/) 및와 같은 AWS 미디어 교환 디바이스는 대부분 솔루션을 [AWS Snowball Edge](https://aws.amazon.com/snowcone/) 제공합니다 AWS 리전. 또한 대용량 데이터 마이그레이션의 경우에 대한 예산을 포함[AWS DataSync](https://aws.amazon.com/datasync/)시켜 안정성을 개선하고 사용된 미디어에 관계없이 전송을 가속화할 수 있습니다.
비즈니스 사례의 현금 흐름 분석 요소에는 AWS 서비스 증가 및 기존 인프라 감소 모델링이 중요합니다. 이 단계에서는 비용이 발생하는 시기를 정확히 결정할 웨이브 플랜이 없을 것입니다. 다음과 같이 하는 것이 좋습니다:
+ 마이그레이션 기간 동안 AWS 의 비용을 일정한 속도로 늘립니다.
+ 동일한 기간 동안 일정한 속도로 폐기하려는 기존 인프라의 비용을 줄입니다.
기존 인프라가 축소되기 1\$12개월 전에 AWS 비용이 증가합니다. 이렇게 하면 각 웨이브에 대해 마이그레이션을 수행할 수 있는 1개월의 AWS 유틸리티 사용량이 제공됩니다. 여기에는 테스트 시간과 교체된 인프라에서 비용 발생을 중지하는 데 필요한 폐기 작업을 완료하는 추가 시간이 포함됩니다.
*폐기 비용 추정*
재배포할 수 없는 장비를 폐기하고 합법적이고 환경 친화적인 방식으로 폐기하면 약간의 비용이 발생할 수 있습니다. 그러나 방향성 비즈니스 사례의 경우 일반적으로 교체된 자산의 나머지 책 가치를 상각하는 비용이 유일한 금액입니다.
방향성 비즈니스 사례의 경우 다음을 수행하는 것이 좋습니다.
+ 자산 목록을 검토합니다.
+ 폐기될 항목을 식별합니다.
+ 상각을 줄이려면 디바이스를 전환할 기회를 검토하여 목록에 있는 최신 디바이스를 사용하여 더 오래되고 사용 중단된 자산을 교체할 수 있도록 합니다.
+ 해당 시점에 폐기될 자산의 향후 책 가치를 평가합니다.
+ 이를 폐기의 마이그레이션 비용으로 포함합니다.
*전체 방향성 비즈니스 사례 수집 및 조정*
각 시나리오 쌍에 대한 전체 비용 세트를 준비한 후 각 시나리오에 대해 할인된 현금 흐름 명세서를 작성하고 그래프로 표시합니다. 하드웨어 새로 고침 주기와 동일한 기간 동안 방향성 비즈니스 사례를 구축하는 것이 좋습니다. 서버, 스토리지 및 네트워크 디바이스의 경우 일반적으로 5년입니다. 하드웨어 새로 고침 주기와 동일한 기간을 사용하는 경우 정확히 한 번의 새로 고침 비용이 각 시나리오의 있는 그대로 비용에 포함됩니다.
그런 다음 프로그램의 다음 단계로 진행하기 위한 승인을 받는 데 필요한 주요 재무 지표를 계산합니다. 일반적으로 다음을 포함합니다.
+ 평가된 비용 절감 및 생산성 향상의 절대값을 측정하기 위한 순 현재 가치(NPV)
+ 반환이 충분히 빠른지 확인하기 위한 월별 페이백 기간
+ 프로세스가 기간 동안 충분한 비용을 소비하고 있는지 확인하기 위한 최종 실행률 비교
+ 투자 수익률(ROI) 및 수정된 투자 수익률(MIRR)로, 조직이 우선시할 수 있는 다른 자본 수요에 비해 프로그램의 상대적 재무 성과를 평가합니다.
사례의 첫 번째 반복을 사용하여 다음 예제와 같이 예상 재무 성과가 개선이 이루어져야 함을 의미하는지 확인합니다.
+ 회수 속도가 너무 느리면 다음과 같이 마이그레이션 비용을 가속화하고 줄일 수 있는 옵션을 고려하세요.
+ AWS 파트너 또는 AWS 전문 서비스를 사용하여 사용 가능한 리소스를 확장하고 더 기본적인 패턴으로 워크로드 마이그레이션을 추가로 병렬화할 수 있습니다.
+ VMware에서 실행되는 워크로드의 경우 최소한 초기 단계에서 재배치 전략을 리호스팅 또는 리플랫포밍 전략과 비교합니다. 재배치 전략을 사용하면 마이그레이션 비용을 줄이고 마이그레이션 속도를 높일 수 있습니다.
+ 기술적으로 가능한 경우 더 복잡한 리플랫포밍 또는 리팩터링(리아키텍트) 전략이 필요한 워크로드를 초기 비즈니스 사례 범위를 벗어나 미래 단계로 푸시합니다.
+ ROI와 MIRR이 너무 낮으면 다음을 고려하세요.
+ 고려 중인 시나리오가 너무 보수적입니까? 가장 가능성이 높은 용량 증가 및 탄력성 요구 사항을 반영하는 시나리오가 있습니까? 목표 내에서 서비스 품질 증가를 포함한 비용을 비교하는 시나리오가 있습니까?
+ 첫 번째 단계에서 마이그레이션할 애플리케이션 포트폴리오의 범위를 구체화하여 현재 사용률이 낮거나 비용이 많이 드는 재해 복구(DR) 요구 사항이 있는 워크로드와 같이 더 강력한 수익을 창출할 워크로드에 집중할 수 있습니까?
+ 애플리케이션 포트폴리오의 범위를 구체화하여 처음에 덜 상업적으로 달성되는 특정 워크로드를 제외할 수 있습니까? 예를 들어 퍼블릭 클라우드 인프라에 배포하는 조건이 다르기 때문에 타사 소프트웨어 라이선스가 더 비싼 워크로드를 연기할 수 있나요?
+ 최종 실행률 비교가 예상 목표를 충족하지 않는 경우 다음을 살펴봅니다.
+ 먼저 다른 지표가 기대치를 충족하는지 확인합니다. 방향성 비즈니스 사례는 주로 마이그레이션 준비의 다음 단계를 시작하는 것을 정당화할 수 있는 충분한 재정적 기회가 있음을 보여주는 것입니다.
+ 마이그레이션의 초기 단계 AWS 이후에에서 비용 성능을 계속 개선할 수 있는 기회 목록을 식별합니다.
세부 비즈니스 사례를 준비할 때 기회 목록에 대한 평가를 포함합니다. 또한 사례의 지속적인 유지 관리와 마이그레이션 완료 후 month-to-month 비용 최적화 프로세스에 기회 평가를 포함합니다.