AWS Migration Hub를 활용한 클라우드 이전 전략 수립하기

자체 데이터센터에서 직접 운영 중인 업무시스템을 클라우드로 이전하고 싶어 하는 고객분들이 점점 늘어나고 있습니다. 사용 연한이 다한 오래된 업무시스템의 하드웨어를 새것으로 교체할 때 비용을 줄이기 위해서, 비즈니스 환경 변화에 신속히 대응하기 위해서, 다른 회사들에 뒤처지지 않을까 하는 위기의식 등 여러 가지 이유로 클라우드 도입을 검토하고 있습니다. 이 글에서는 업무시스템을 클라우드로 이전할 때 우선적으로 고려해야 하는 것과 AWS Migration Hub를 클라우드 이전 전략 수립에 사용하는 방법을 설명하고자 합니다.

운영 중인 업무시스템을 클라우드로 이전하기 위한 첫걸음

운영 중인 업무시스템의 환경을 바꾸는 것은 매우 큰 작업입니다. 과거에는 시스템을 새로 구축하는 차세대 프로젝트나 낡은 인프라스트럭처를 새것으로 바꾸는 서버 교체 프로젝트와 같은 대규모 작업을 주기적으로 수행했습니다. 반면에 클라우드 도입은 한꺼번에 모든 시스템을 바꾸는 빅뱅 방식보다는 단계적으로 조금씩 바꿔 나가는 점진적 접근 방식을 좀 더 선호하고 있습니다. 어느 방식을 택하든 경영진은 운영 중인 업무시스템을 클라우드로 옮길 때 얼마의 비용이 드는지, 얼마의 시간이 걸리는지, 얼마나 많은 인력이 필요한 지 등을 궁금해할 것입니다.

AWS의 솔루션즈 아키텍트로서 고객을 만나고 클라우드 도입에 관해 이야기할 때는 우선 현재 운영 중인 업무시스템에 대한 최신 인벤토리 정보를 관리하고 있는지 확인합니다. 인벤토리는 고객이 운영 중인 업무시스템은 어떤 것이 있는지, 몇 대의 서버로 운영하는지, 운영체제는 무엇인지, 어떤 기술 스택을 사용하는지 등을 포함해야 합니다. 고객마다 이런 내용을 관리하는 수준은 매우 다양합니다. IT 서비스 관리 시스템(ITSM)과, 구성관리 데이터베이스(CMDB)로 업무시스템의 모든 하드웨어와 소프트웨어 정보를 상세히 관리하는 고객이 있는가 하면, 서버 모니터링 솔루션(SMS)이나 애플리케이선 성능 관리(APM) 시스템으로 일부 업무시스템에 대한 성능과 가동 현황 정도를 관리하는 경우도 있습니다. 업무시스템 자산 정보를 수작업으로 수집해서 문서 파일로 관리하는 고객도 있었습니다.

업무시스템 현황 조사

업무시스템 현황을 조사할 때 수집하는 정보는 인프라스트럭처에 대한 정보와 애플리케이션에 대한 정보로 나눌 수 있습니다. 인프라스트럭처를 담당하는 팀과 애플리케이션을 담당하는 팀이 다른 경우가 많은데 두 정보를 모아 하나의 인벤토리 테이블로 정리하는 것이 좋습니다.

다음은 업무시스템 현황을 조사할 때 초기에 수집해야 하는 자료입니다.

업무시스템 현황 조사는 초기에 한 번 수행하고 마는 것이 아니고 여러 차례 반복하면서 정보의 양을 늘려가는 것이 필요합니다. 현황 조사 데이터 중에 기술 스택이 특히 중요합니다. 각 서버에서 운영하는 업무시스템의 구성 요소가 무엇이고 어떤 기술의 제품을 사용하는지 상세히 정리해야 합니다. 이런 내용을 바탕으로 어떻게 클라우드로 전환할지에 대한 방향성을 정합니다. 업무시스템에 대한 현황 조사는 이미지의 해상도를 점차 높여나가는 작업으로 생각하는 것이 좋습니다. 현황 조사를 반복하면서 추가로 수집해야 하는 데이터에는 다음과 같은 항목들이 있습니다.

하나의 업무시스템은 여러 대의 서버로 구성하는 것이 일반적이기 때문에 빠진 서버는 없는지, 혹은 중복해서 관리하는 것은 아닌지 잘 살펴야 합니다. 데이터베이스의 경우 처리 성능이 좋은 서버에 통합 데이터베이스를 구성하고 여러 업무시스템이 함께 쓰는 일이 많으므로 주의를 기울여야 합니다. 업무시스템을 클라우드로 이전할 때 서로 밀접하게 연결된 시스템들은 함께 옮겨야 하므로 업무시스템 간의 연계 관계도 잘 정리해야 합니다

업무시스템 현황 조사를 위한 AWS의 지원 도구

고객이 IT 자산관리 시스템을 운영 중이거나 SMS, APM과 같은 모니터링 솔루션을 사용하고 있다면 인벤토리 정보를 쉽고 정확하게 수집할 수 있습니다. 만약 고객이 별도의 솔루션을 가지고 있지 않다면 AWS가 제공하는 도구를 사용하는 것도 좋은 방법이 될 수 있습니다. 인벤토리 정보 수집을 위한 AWS의 서비스에는 AWS Application Discovery Service와 AWS Migration Hub가 있습니다.

AWS Application Discovery Service는 고객의 IT 환경 내 서버의 구성 및 사용 현황을 이해하는 데 필요한 정보를 수집해서 AWS Migration Hub로 전달하는 서비스입니다. AWS Migration Hub는 수집한 업무시스템의 인벤토리 데이터를 저장하고, AWS로 이전하는 작업에 대한 계획 수립 및 진척 사항 추적에 대한 중심지 역할을 수행합니다.

업무시스템 서버에서 정보를 수집하는 방식은 Agent 방식, Agentless 방식, Template file upload 방식이 있습니다.

Agent 방식: 데이터 수집 대상(물리서버 혹은 가상서버)에 Agent를 배포하고 Agent는 데이터 수집 대상 서버의 환경 정보, 시스템 사용량 정보, 실행 중인 프로세스 정보, 네트워크 연결 정보 등을 15분 주기로 수집해서 AWS Application Discovery Service로 전달합니다.
Agentless 방식: 가상서버를 관리하는 VMware vCenter 서버에 데이터 수집기 가상서버를 구성하고 데이터 수집기는 vCenter가 관리하는 가상서버에 대한 환경 정보, 시스템 사용량 정보를 AWS Application Discovery Service로 전달합니다.
파일 업로드 방식: 파일 업로드 방식은 데이터 수집 대상의 인벤토리 정보를 문서 파일로 정리해서 AWS Migration Hub에 직접 적재합니다.

여기서는 Agent 방식을 자세히 살펴보겠습니다.

Agent 방식으로 데이터 수집하기

단계 1 : Migration Home Region 지정

Agent 방식으로 데이터를 수집하기 위해서는 먼저 다음과 같은 절차로 AWS Migration Hub의 Migration Home Region을 지정해야 합니다.

마이그레이션 전략 수집에 사용할 AWS 계정에 로그인 한 뒤, AWS Migration Hub 서비스 콘솔로 이동합니다.
- AWS 콘솔의 현재 리전에서 AWS Migration Hub를 지원하지 않을 경우 지원 가능한 리전을 선택하는 화면이 나옵니다. 이 화면에서 원하는 리전을 선택합니다.
- 현재 서울 리전은 AWS Migration Hub의 Migration Home Region으로 사용할 수 없습니다.
AWS Migration Hub 서비스 콘솔의 좌측 네비게이션 영역의 아랫부분에서 Setting을 선택해서 Migration Home Region 설정 화면으로 이동합니다.
Migration Home Region의 옵션 선택 메뉴에서 원하는 리전을 선택합니다.
Automatic redirect to home Region 옵션을 통해 향후 AWS Migration Hub 서비스 콘솔로 이동할 때 자동으로 Migration Home Region으로 전환할지를 정합니다.
Confirm Home Region 버튼으로 Migration Home Region 지정을 확정합니다.

- 한번 정한 Migration Home Region은 콘솔에서 변경할 수 없습니다. 변경을 원할 시 AWS Support에 요청해야 합니다.AWS Migration Hub서비스 콘솔에서 Migration Home Region을 지정해야 합니다. AWS Migration Hub의 Migration Home Region은 업무시스템의 인벤토리 정보를 수집해서 저장하고 마이그레이션 계획에 대한 포트폴리오를 관리하는 단일 리파지토리를 제공합니다.

단계2 : Application Discovery Agent가 사용할 IAM 사용자 계정 만들기

사용자 계정을 만들 때는 Programmatic access가 가능하도록 AWS credential type에서 Access key 체크 박스를 선택으로 설정합니다.
이 사용자 계정에 AWS가 관리하는 AWSApplicationDiscoveryAgentAccess 정책을 부여합니다.

- AWSApplicationDiscoveryAgentAccess 정책은 Application Discovery Agent가 수집한 정보를 AWS에 전송할 때 필요한 권한을 담고 있습니다.

단계 3 : 데이터 수집 대상 서버에 Application Discovery Agent 설치

Linux

linux 서버에 로그인
Agent를 설치할 폴더를 새로 만들고 그 폴더로 이동

리눅스용 Agent 설치파일 다운로드

curl -o ./aws-discovery-agent.tar.gz https://s3-ap-northeast-1.amazonaws.com/aws-discovery-agent.ap-northeast-1/linux/latest/aws-discovery-agent.tar.gz

파일 압축 해제
```
tar -xzf aws-discovery-agent.tar.gz
```

Agent 설치

sudo bash install -r your-home-region -k aws-access-key-id -s aws-secret-access-key

Windows

윈도우 서버에 로그인

윈도우용 Agent 설치파일 다운로드

https://s3.ap-northeast-1.amazonaws.com/aws-discovery-agent.ap-northeast-1/windows/latest/AWSDiscoveryAgentInstaller.exe

윈도우 명령 프롬프트(CMD)를 관리자 권한으로 실행한 뒤 Agent 설치파일이 있는 폴더로 이동해서 Agent 설치
```
.\AWSDiscoveryAgentInstaller.exe REGION="your-home-region" KEY_ID="aws-access-key-id" KEY_SECRET="aws-secret-access-key" /quiet
```

설치된 Agent는 15분 주기로 정보를 수집해서 AWS Application Discovery Service로 전달하고 AWS Application Discovery Service는 수집된 정보를 AWS Migration Hub에 저장해서 관리합니다.

클라우드 서버 리소스 산정

서버 인벤토리 정보는 CPU와 메모리의 최대 사용률을 확인할 수 있도록 2주 정도 수집하는 것이 필요합니다. 월 마감이나 분기 마감 같은 배치 처리 작업을 수행하는 시점이나 할인행사 이벤트같이 시스템 사용률이 급등할 수 있는 시점을 인벤토리 정보 수집 기간에 포함시키는 것이 좋습니다. 업무시스템의 서버 인벤토리 정보를 충분히 수집하고 나면 CPU와 메모리 사용률을 기반으로 클라우드 서버의 인스턴스 유형을 추천해 주는 EC2 Instance Recommendations 기능을 사용할 수 있습니다.

EC2 Instance Recommendations로 클라우드 서버의 인스턴스 유형을 산정할 때 4가지 기준 중 하나를 선택할 수 있습니다.

최대 사용률 – 서버의 메모리와 CPU 사용률의 최대치를 기준으로 클라우드 서버 인스턴스 유형을 결정
현재 서버 사양 – 현재 사용 중인 서버의 CPU와 메모리의 사양을 기준으로 서버 인스턴스 유형을 결정
평균 사용률 – 서버의 메모리와 CPU 사용률의 평균치를 기준으로 클라우드 서버 인스턴스 유형을 결정
사용률 백분위수 – 수집한 데이터에 대한 백분위 기준(백분위수 80은 수집한 데이터를 작은 값부터 큰 값으로 순서대로 나열해서 80번째 값)을 지정해서 클라우드 서버 인스턴스 유형을 결정 (데이터 수집 도구를 통해 사용률을 수집한 경우에만 사용 가능)

클라우드 서버의 인스턴스 유형을 산정할 때 여러 기준을 적용한 결과들을 비교하는 것이 좋습니다. 간혹 최대 사용률이 예상보다 높을 수가 있는데 사용률 백분위 결과와 비교해 봄으로써 극단적인 값이 결과에 영향을 준 것은 아닌지 확인할 수 있습니다.

서버의 인스턴스 유형을 산정할 때 선호하는 방식을 지정할 수도 있습니다. 어느 리전에 클라우드 리소스를 구성할지, 전용 인스턴스의 사용 여부, 요금 모델, 산정 결과에서 제외하고 싶은 EC2 인스턴스 유형 등을 지정해서 더욱 정교한 리소스 산정 결과를 얻어 낼 수 있습니다.

리소스 산정 기준과 선호하는 유형을 모두 정하고 난 뒤 Export recommendations 버튼을 사용해 리소스 산정 결과가 압축파일로 내려받을 수 있습니다. 압축파일을 풀면 클라우드 인스턴스 유형 산정 결과가 담겨있는 CSV 파일이 나옵니다.

CSV 파일은 57개의 열로 구성되어 있는데 AS-IS 서버에 대한 정보(Server로 시작하는 열), 설정 구성 정보(UserPreference로 시작하는 열), 산정 기준에 따른 EC2 서버 인스턴스 정보(Recommendations로 시작하는 열) 등으로 구분할 수 있습니다. EC2 서버 인스턴스 유형은 Recommendation.EC2.Instance.Model 열에서 확인할 수 있습니다.

클라우드 리소스에 대한 비용 산정

각 서버에 대한 EC2 인스턴스 권장 사항과 서버 스토리지 용량 정보를 바탕으로 클라우드 서버 구성에 대한 비용을 AWS 요금 계산기를 통해 산정해 볼 수 있습니다. AWS 요금 계산기는 Amazon EC2 리소스에 대한 비용 계산을 효과적으로 수행할 수 있도록 새롭게 디자인한 사용자 인터페이스를 2022년 12월부터 제공하고 있습니다.

AWS Migration Hub 와 AWS Application Discovery Service는 별도의 요금을 부과하지 않는 서비스입니다. 대신에 수집한 정보를 저장하는 데 사용하는 AWS 리소스(Amazon S3, Amazon Athena, Amazon Kinesis Firehose)에 대해서는 비용이 발생합니다.

결론

지금까지 AWS Application Discovery Service로 고객의 IT 환경 내 서버 정보를 수집해서 AWS Migration Hub로 전달하는 과정을 알아보았고, AWS Migration Hub에 수집된 정보를 기반으로 AWS로 이전하는 전략을 수립하는 것을 살펴봤습니다. 업무시스템을 AWS 클라우드로 이전하는 것을 고려하고 계신 고객분들에게 이러한 서비스가 큰 도움이 될 것입니다. 이밖에 좀 더 상세한 서버 구성과 비용 산정 등을 원하실 때 AWS의 영업이나 파트너에게 문의하시면 상세한 총소유비용 분석과 클라우드 전환 방안 수립에 도움을 받으실 수 있습니다.

AWS 기술 블로그