[ 고지 사항 (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부로 구성되어 있으며 이 글은 3부입니다.
1부 : AWS 마이그레이션 백서 1/4
2부 : AWS 마이그레이션 백서 2/4
4부 : AWS 마이그레이션 백서 4/4
사람과 조직
대규모 AWS 마이그레이션을 준비하고 있다면 프로덕션 AWS 경험이 있는 중요한 사람들을 개발하는 것이 중요합니다. 운영 프로세스를 설정하고 적절한 리소스를 동원하기 위한 CCoE (Cloud Center of Excellence)를 구성하십시오. CCoE는 마이그레이션 과정에서 조직 및 비즈니스 혁신을 통해 회사를 이끌 것입니다. CCoE는 모범 사례, 거버넌스 표준, 자동화 및 조직 전체의 변화를 주도합니다. CCoE가 잘 이루어지면 문화적으로 혁신으로 전환하고 변화는 정상적인 사고 방식에 영감을 줍니다.
회사의 클라우드 팀 구성
효과적인 CCoE 팀은 시간이 지남에 따라 규모, 구성, 기능 및 목적이 발전합니다. 주요 운영 모델 결정과 함께 장기 및 단기 목표는 팀을 조정해야합니다.
클라우드 도입의 초기 단계에서 팀 개발은 공유 관심사 (클라우드 구현 경험)로 연결된 소규모의 비공식 그룹으로 시작됩니다. 클라우드 이니셔티브가 커지고보다 공식화 된 구조에 대한 필요성이 증가함에 따라 클라우드의 가치를 전파하는 데 전념하는 CCoE를 구축하는 것이 유리합니다. CCoE가 진화하는 기술 운영에 대한 모범 사례, 방법 및 거버넌스를 확립하는 동안 추가 소규모 클라우드 팀이 형성됩니다. 이 소규모 팀은 일반적으로 마이그레이션 물결이라고하는 후보 애플리케이션 및 애플리케이션 그룹을 클라우드 환경으로 마이그레이션합니다. CCoE는 마이그레이션 팀의 운영 매개 변수를 지시하고 CCoE 및 마이그레이션 팀 모두 피드백을 제공합니다. 전체적으로 교훈을 배우고 문서화하여 실무 경험을 통해 효율성과 자신감을 향상시킵니다.
Cloud Center of Excellence 생성
다음은 CCoE 생성을위한 기본 원칙입니다.
· 조직이 변화함에 따라 CCoE 구조가 발전하고 변화합니다. 다양한 교차 기능 표현이 핵심입니다.
· 클라우드를 제품으로, 애플리케이션 팀 리더를 고객으로 취급하십시오. 명령 및 제어가 아닌 드라이브 지원.
· 모든 일에 회사 문화를 구축하십시오.
· 조직 변경 관리는 비즈니스 혁신의 핵심입니다. 의도적이고 대상이 지정된 조직 변경 관리를 사용하여 회사 문화와 규범을 변경하십시오.
· 정상적인 변화 방식을 수용하십시오. 응용 프로그램, IT 시스템 및 비즈니스 방향의 변화가 예상됩니다.
· 운영 모델 결정은 사람들이 비즈니스 성과를 달성하는 역할을 수행하는 방법을 결정합니다.
대규모 마이그레이션을위한 CCoE 구조
교차 기능 기술과 경험을 가진 영향을 받는 비즈니스 부문의 사람들을 포함하도록 CCoE를 설계하는 것은 대규모 마이그레이션에 중요합니다. 주제 전문 지식을 구축하고, 바이 인을 달성하고, 조직 전체에서 신뢰를 얻고, 비즈니스 요구 사항의 균형을 유지하는 효과적인 지침을 수립합니다. 모든 사람에게 적합한 단일 조직 구조는 없습니다. 다음 지침은 회사를 나타내는 CCoE를 설계하는 데 도움이 됩니다.
CCoE는 Cloud Business Office (CBO)와 Cloud Engineering (그림 4 참조)의 두 가지 기능 그룹으로 구성됩니다. 각 그룹의 기능은 각 그룹 및 더 큰 CCoE에 포함 할 사람을 결정하는 데 도움이 됩니다.
CBO는 클라우드 서비스가 내부 고객 비즈니스 서비스의 요구를 충족하는지 확인합니다. 비즈니스 서비스 및 이를 지원하는 응용 프로그램은 IT에서 제공하는 클라우드 서비스를 사용합니다. IT는 비즈니스 응용 프로그램 소유자에게 고객 중심 모델을 채택해야 합니다. 이 신조는 대부분의 조직에서 변화를 나타냅니다. 클라우드 운영 모델, CCoE 및 클라우드 팀 접근 방식을 개발할 때 고려해야 할 중요한 사항입니다.
CBO는 조직 변경 관리, 이해 관계자 요구 사항, 거버넌스 및 비용 최적화와 같은 기능을 소유합니다. 사용자 요구 사항을 개발하고 새로운 응용 프로그램과 사용자를 클라우드에 탑재합니다. 또한 공급 업체 관리, 내부 마케팅, 커뮤니케이션 및 사용자에 대한 상태 업데이트도 처리합니다. 클라우드 서비스 비전, 조직 변경 관리, 인사 관리, 재무 관리, 공급 업체 관리 및 엔터프라이즈 아키텍처를 담당하는 IT 리더십을 선택합니다. 한 개인은 여러 기능 영역을 나타내거나 여러 개인이 하나의 기능 영역을 나타낼 수 있습니다.
Cloud Engineering 그룹은 인프라 자동화, 운영 도구 및 프로세스, 보안 도구 및 제어, 마이그레이션 랜딩 영역과 같은 기능을 소유합니다. 비즈니스 부서에서 클라우드 리소스에 액세스하고 사용 패턴을 최적화 할 수 있는 속도를 최적화합니다. Cloud Engineering 그룹은 성능, 가용성 및 보안에 중점을 둡니다.
다음 그림은 회사의 CCoE 내에서 표현이 필요한 기능 그룹을 보여줍니다.
마이그레이션 준비 및 계획
마이그레이션 준비 및 계획 (MRP)은 클라우드 마이그레이션을 위해 기업을 준비하기 위한 도구, 프로세스 및 모범 사례로 구성된 방법입니다. MRP 방법은 AWS Cloud Adoption Framework와 일치하며 실행 중심입니다. MRP는 AWS Professional Services가 제공하는 특정 프로그램을 설명합니다. 그러나 아래에서 주요 주제 영역과 주요 개념을 강조합니다.
마이그레이션 준비 상태 평가
AWS CAF (AWS Cloud Adoption Framework)는 IT 환경을 분석하기위한 프레임 워크입니다. 이 프레임 워크를 사용하면 클라우드 마이그레이션 준비 상태를 결정할 수 있습니다. AWS CAF의 각 관점은 다양한 렌즈를 통해 환경을 바라 보는 방법을 제공하여 비즈니스의 모든 영역을 다룰 수 있도록합니다. 대규모 마이그레이션 이니셔티브를 준비하려면 몇 가지 주요 영역을 준비해야합니다.
고려해야 할 사항 :
· 마이그레이션의 범위와 비즈니스 사례를 명확하게 정의 했습니까?
· AWS CAF 렌즈를 통해 범위 내 환경과 애플리케이션을 평가 했습니까?
· 가상 사설 클라우드 (VPC)는 안전하며 범위 내 모든 응용 프로그램의 랜딩 영역 역할을 할 수 있습니까?
· 변경 사항을 수용하기 위해 운영 및 직원 기술을 검토하고 업데이트 했습니까?
· 범위 내에 있는 기술 스택을 이동하는 데 필요한 경험이 있습니까 (또는 파트너가) 있습니까?
AWS는 각 AWS CAF 관점에서 조직의 현재 마이그레이션 준비 상태를 평가할 수 있도록 일련의 도구와 프로세스를 개발했습니다. MRA (Migration Readiness Assessment) 프로세스는 준비 격차를 식별하고 대규모 마이그레이션 노력에 대비하여 이러한 격차를 메울 것을 권장합니다. MRA는 현재 상태에 대한 공통된 시각을 구축하기 위해 IT 조직의 주요 이해 관계자와 팀 구성원을 포함하는 그룹 간 설정으로 대화식으로 완료됩니다. IT 리더십, 네트워킹, 운영, 보안, 위험 및 규정 준수, 애플리케이션 개발, 엔터프라이즈 아키텍처 및 CCoE 또는 CBO의 담당자가 있을 수 있습니다. MRA 출력에는 히트 맵과 같은 동작 및 다음 단계와 시각 자료가 포함됩니다 (그림 5 참조). MRA는 AWS 또는 AWS 마이그레이션 파트너를 통해 제공됩니다.
응용 프로그램 검색
Application Discovery는 온-프레미스 환경을 이해하고 존재하는 실제 및 가상 서버와 해당 서버에서 실행중인 응용 프로그램을 결정하는 프로세스입니다. 비즈니스 사례를 구축하고 마이그레이션을 계획하려면 기존 온-프레미스 응용 프로그램, 서버 및 기타 리소스 포트폴리오를 확보해야 합니다. 운영 체제 믹스, 응용 프로그램 패턴 및 비즈니스 시나리오를 기반으로 조직의 온-프레미스 환경을 분류 할 수 있습니다. 이 분류는 시작하기 간단 할 수 있습니다. 예를 들어, 단종 된 운영 체제 또는 특정 데이터베이스 또는 하위 시스템에 종속 된 응용 프로그램을 기준으로 응용 프로그램을 그룹화 할 수 있습니다.
Application Discovery는 각 응용 프로그램 그룹에 대한 전략적 접근 방식을 개발하는 데 도움이 됩니다. Application Discovery는 프로젝트 계획 및 비용 추정에 필요한 데이터를 제공합니다. 여러 소스의 데이터 수집이 포함됩니다. 일반적인 소스는 기존 CMDB (Configuration Management Database)입니다. CMDB는 고급 분석에 도움이되지만 충실도가 부족한 경우가 많습니다. 예를 들어 성능 및 사용률 데이터는 리소스를 적절한 AWS 리소스 (예 : Amazon EC2 인스턴스 유형과 일치)와 페어링해야 합니다.
수동으로 검색을 수행하는 데 몇 주 또는 몇 달이 걸릴 수 있으므로 자동 검색 도구를 활용하는 것이 좋습니다. 이러한 검색 도구는 크기 조정, 성능, 사용률 및 종속성을 포함한 모든 응용 프로그램 및 지원 인프라의 검색을 자동화 할 수 있습니다.
고려해야 할 사항 :
· 자동 검색 도구를 사용하는 것이 좋습니다.
· 시간이지나면서 환경이 바뀝니다. 자동 검색 도구를 지속적으로 실행하여 데이터를 최신 상태로 유지하는 방법을 계획하십시오.
· 비즈니스 사례 개발 중에 범위를 정확하게 반영하기 위해 초기 응용 프로그램 검색을 수행하는 것이 유용 할 수 있습니다.
검색 도구
검색 도구는 AWS Marketplace에서 마이그레이션 범주 아래에 있습니다. 또한 AWS는 ADS (Application Discovery Service)를 구축했습니다. ADS는 가상 서버용 어플라이언스 커넥터 또는 실제 또는 가상 호스트에 설치된 에이전트를 통해 서버 인벤토리 및 성능 특성을 감지합니다.
응용 프로그램 검색 도구는 다음을 수행 할 수 있습니다.
· 데이터 센터에서 실행중인 인프라 및 애플리케이션의 인벤토리를 자동으로 검색하고 시스템을 지속적으로 모니터링하여 인벤토리를 유지 관리합니다.
· 응용 프로그램이 서로 또는 기본 인프라에 의존하는 방식을 결정합니다.
· 분석 및 계획을 위한 운영 체제 및 서비스의 인벤토리 버전.
· 호스트에서 실행중인 응용 프로그램 및 프로세스를 측정하여 성능 기준 및 최적화 기회를 결정합니다.
· 응용 프로그램과 서버를 분류하고 마이그레이션 프로젝트에 참여할 사람들에게 의미 있는 방식으로 설명하는 수단을 제공합니다.
이러한 도구를 사용하여 응용 프로그램 및 해당 종속성에 대한 충실한 실시간 모델을 구축 할 수 있습니다. 이는 시간이 많이 걸리는 발견 및 데이터 수집 및 분석 프로세스를 자동화합니다.
고려해야 할 사항 :
· 자동 검색 도구를 사용하면 CMDB를 최신 상태로 만들 때 시간과 에너지를 절약 할 수 있습니다.
· 프로젝트가 진행됨에 따라 재고를 최신 상태로 유지하는 것이 중요하며 도구는 이를 덜 고통스럽게 만듭니다.
· 시장에 나와있는 검색 도구는 각각 특수한 목적 또는 기능을 가지고 있으므로 이를 요구 사항에 맞게 분석하면 환경에 적합한 도구를 선택하는 데 도움이 됩니다.
응용 프로그램 포트폴리오 분석
응용 프로그램 포트폴리오 분석은 응용 프로그램 검색 데이터를 가져온 다음 포트폴리오의 패턴을 기반으로 응용 프로그램을 그룹화하기 시작합니다. 지정된 패턴을 마이그레이션하기위한 마이그레이션 순서 및 마이그레이션 전략 (즉, 요약 된 6 개의 R 중 어떤 것이 사용될 것인지)을 식별합니다. 이 분석의 결과는 공통된 특성으로 정렬 된 광범위한 자원 분류입니다. 특별한 취급이 필요한 특별한 경우도 식별 될 수 있습니다.
이 고급 분석의 예는 다음과 같습니다.
• 대부분의 서버는 일관된 표준 OS 버전의 Windows 기반입니다. 일부 서버는 OS 업그레이드가 필요할 수 있습니다.
• 여러 데이터베이스 플랫폼에 데이터베이스 배포 : 데이터베이스의 80 %는 Oracle이고 20 %는 SQL Server입니다.
• 사업부별로 응용 프로그램 및 서버 그룹화 : 30 % 마케팅 및 판매 응용 프로그램, 20 % HR 응용 프로그램, 40 % 내부 생산성 응용 프로그램 및 10 % 인프라 관리 응용 프로그램.
• 환경 유형에 따른 리소스 그룹화 : 생산 50 %, 테스트 30 % 및 개발 20 %.
• 비용 절감 기회, 응용 프로그램의 비즈니스 중요도, 서버 활용도 및 마이그레이션 복잡성 등 다양한 요인에 따라 점수 지정 및 우선 순위 지정.
• 6 개의 R을 기준으로 그룹화 : 포트폴리오의 30 %가 재 호스트 패턴을 사용할 수 있고, 30 %는 일정 수준의 재 플랫폼 변경을 요구하고, 30 %는 마이그레이션을 위해 애플리케이션 작업 (재 아키텍처)이 필요.
응용 프로그램 검색 작업에서 얻은 데이터 중심 통찰력은 프로젝트의 마이그레이션 준비 단계로 이동할 때 마이그레이션 계획의 기초가 됩니다.
마이그레이션 계획
마이그레이션 계획의 주요 목표는 전체 마이그레이션 노력을 이끌어내는 것입니다. 여기에는 범위, 일정, 자원 계획, 문제 및 위험, 조정 및 모든 이해 관계자와의 커뮤니케이션 관리가 포함됩니다. 여러 팀이 여러 응용 프로그램을 마이그레이션 할 때 계획을 조기에 수행하면 프로젝트를 구성 할 수 있습니다. 마이그레이션 계획에서는 워크로드 마이그레이션 순서, 리소스가 필요한 시기 및 마이그레이션 진행률 추적과 같은 중요한 요소를 고려합니다. 팀은 민첩한 전달 방법론, 프로젝트 제어 모범 사례, 강력한 비즈니스 커뮤니케이션 계획 및 명확하게 정의 된 전달 방법을 사용하는 것이 좋습니다.
권장되는 마이그레이션 계획 활동은 다음과 같습니다.
· 격차를 평가하기위한 프로젝트 관리 방법, 도구 및 기능을 검토합니다.
· 마이그레이션 중에 사용할 프로젝트 관리 방법 및 도구를 정의하십시오.
· 보고 및 에스컬레이션 절차를 포함한 마이그레이션 프로젝트 헌장 / 통신 계획을 정의하고 작성하십시오.
· 프로젝트 계획, 위험 / 완화 로그, 역할 및 책임 매트릭스 (예 : RACI)를 개발하여 프로젝트 중에 발생하는 위험을 관리하고 관련된 각 자원의 소유권을 식별합니다.
· 프로젝트 제공을 지원하기 위해 프로젝트 관리 도구를 조달 및 배포합니다.
· 이 섹션에 정의 된 각 마이그레이션 작업 스트림에 대한 주요 리소스 및 리드를 식별하십시오.
· 계획에 요약 된 조정과 활동을 촉진하십시오.
· 대상 환경을 AWS로 마이그레이션하는 데 필요한 리소스, 타임 라인 및 비용을 설명합니다.
기술 계획
마이그레이션 계획은 비용, 일정 및 범위를 넘어서는 것입니다. 여기에는 애플리케이션 포트폴리오 분석 데이터를 취하고 우선 순위가 지정된 애플리케이션의 초기 백 로그를 작성하는 것이 포함됩니다. 사용 패턴에 대한 데이터를 수집하여 포트폴리오에 대한 심층 분석을 수행하여 백 로그를 작성하십시오. 소규모 팀이 CCoE의 일부인 엔터프라이즈 아키텍처 팀에서 이 프로세스를 주도 할 수 있습니다. 팀은 응용 프로그램 포트폴리오를 분석하고 우선 순위를 정하고 각 응용 프로그램의 현재 아키텍처에 대한 정보를 수집합니다. 미래 아키텍처를 개발하고 워크로드 세부 정보를 캡처하여 간소화 된 마이그레이션을 실행합니다. 계획 실행을 시작하기 전에 모든 응용 프로그램을 통과하는 것은 중요하지 않습니다. 민첩하게 하려면 우선 순위가 지정된 처음 2 ~ 3 개의 앱을 심층 분석 한 다음 마이그레이션을 시작하십시오. 첫 번째 애플리케이션이 마이그레이션되는 동안 다음 애플리케이션에 대한 심층 분석을 계속하십시오.
반복적인 프로세스는 프로젝트 규모에 압도되는 느낌을 피하거나 초기 설계 계획이 날짜가 지날 때 진행 상황을 제한하는 데 도움이 됩니다.
마이그레이션 팀 수, 비용 및 마이그레이션 프로젝트 타임 라인을 결정하기 위해 애플리케이션을 마이그레이션 패턴과 이동 그룹으로 구성하십시오. 전체 프로젝트 계획에서 각 마이그레이션 팀에 대한 애플리케이션 백 로그 (약 2 주 스프린트 3 회)를 유지하십시오. 마이그레이션 할 때 계획 및 실행 프로세스에 구축 할 기술 및 조직 전문 지식을 얻게 됩니다. 애플리케이션 포트폴리오를 진행하면서 최적화 할 수 있는 기회를 활용할 수 있습니다. 반복 프로세스를 통해 프로젝트는 조직, 프로젝트 범위에 맞는 패턴, 사업부, 지리 또는 기타 차원으로 구성된 마이그레이션 팀을 지원하도록 확장 할 수 있습니다.
마이그레이션 단계에서 성능 및 종속성을 결정하려면 정확하고 최신 응용 프로그램 및 인프라 데이터를 제공하는 충실도 모델이 중요합니다. 양질의 데이터가 포함 된 잘 계획된 계획을 세우는 것이 빠른 속도로 마이그레이션을 가능하게하는 핵심 요소 중 하나입니다.
고려해야 할 사항 :
· 응용 프로그램 검색 및 포트폴리오 분석 데이터는 이 단계에서의 분류, 우선 순위 지정 및 계획에 중요합니다.
· 민첩한 접근 방식을 통해 이 데이터를 더 이상 사용되지 않기 전에 마이그레이션에 사용할 수 있습니다.
· 반복은 세부 학습 계획이 새로운 학습으로 발전함에 따라 마이그레이션이 계속되도록 도와줍니다.
