마이그레이션 방법 : 물리서버에서 AWS로의 여정

2020. 07. 24 | 블로그

안녕하세요. 디딤365입니다.

지난 6월 17일 디딤365에서 개최한 온라인 세미나 ‘AWS 클라우드 비용 절감법과 효율적 운영 가이드’ 이후 AWS에 대한 문의가 증가했습니다. 그 중에서도 물리서버를 이용하고 있으나 AWS로 이전하고 싶어하는 고객들의 문의가 늘고 있습니다.

이번 포스팅에서는 AWS로 마이그레이션 하는 방법 및 절차를 안내해 드리겠습니다.

웨비나 다시보기 : https://www.allshowtv.com/detail.html?idx=212

클라우드 마이그레이션의 정의 및 방법

클라우드 마이그레이션은 일부 또는 모든 디지털 작업을 클라우드로 이동하는 프로세스입니다. 마이그레이션은 보통 5가지 방법론을 통해 이뤄집니다. 그 중 대표적인 3가지 방법론을 소개해드리겠습니다.

1. Rehost

Lift and Shift 접근 방식으로 불리며, 기존 인프라를 그대로 클라우드에 마이그레이션 하는 방법입니다. 해당 방법으로 마이그레이션을 수행할 시 주변 인프라나 비즈니스 프로세스에 큰 변화가 없으므로 값비싼 개발 및 테스트가 필요 없습니다. 이로 인해 신속하게 마이그레이션이 가능합니다.

2. Replatform

기존 인프라에 몇 가지 간단한 수정 사항을 적용하여 클라우드에 적합한 구성으로 마이그레이션 하는 방법입니다. 해당 방법으로 마이그레이션을 수행할 시 기존 워크로드를 유사하게 가져오면서 Multi-AZ, Cloudfront, Autoscaling, 관리형 서비스(RDS, S3 등)와 같이 인프라에 변화가 적은 클라우드 서비스를 이용하실 수 있습니다. 개발 및 테스트 비용, 마이그레이션 시간, 클라우드 이점 등을 고려했을 때 가장 비용면에서 효율적인 마이그레이션 방법입니다.

3. Refactoring

기존 인프라를 클라우드에 최적화되도록 전면적으로 교체하는 마이그레이션 방법입니다. 하나의 서버를 여러 개의 경량 EC2로 대체하거나, 컨테이너 서비스, 서버리스 서비스 도입 등을 위해 Refactoring을 수행합니다. 이는 대대적인 인프라 개편을 도입해야 하므로, 장기적인 비용 절감을 노릴 수 있으나, 시간 및 개발 비용이 많이 발생합니다.

위와 같이 대표적인 마이그레이션 방법론 3가지를 살펴보았습니다. 하지만 실제 마이그레이션 시 한 가지 방법만을 이용하지 않고 보통 3가지의 방법을 모두 고려합니다.

AWS의 특화 서비스는 기존 인프라 이용 방법과 달라지는 경우가 많습니다. 이에 도입하려는 서비스의 이용 방법을 숙지하고 테스트하는 인력과 시간이 있다면 위에 소개해 드린 Rehost, Replatform, Refactoring 3가지 방법을 점진적으로 적용하는 방안을 추천해 드립니다. 개발 인력과 상황에 따라 다음 단계로 진행할지 현재 단계로 서비스할지 결정하실 수 있습니다.

마이그레이션의 주체 및 역할

마이그레이션은 의사결정권자인 고객사, 기존 인프라를 관리하는 개발자(사), 클라우드 인프라 구축 및 서비스 이관을 진행하는 디딤365가 함께 수행합니다. 안전하고 신속한 마이그레이션을 위해 각자의 역할을 수행해야 합니다.

1. 고객사의 역할

고객사는 클라우드로 마이그레이션 요청 시 제공된 견적서 및 구성도를 확인하고 진행 여부를 확정해야 합니다. 또한 마이그레이션 진행 일정 협의가 필요합니다.

2. 개발자(사)의 역할

기존 인프라의 서버 접속 정보를 디딤365에 공유해 주셔야 디딤365에서 고객의 서버에 접속하여 현황을 파악한 뒤 기존 인프라와 유사한 AWS 환경을 구축합니다. 신규 인프라가 구성되면, 개발자(사)는 필요한 데이터를 AWS로 이관합니다. 마이그레이션 완료 후 서비스별 기능 테스트, 최종 인프라 성능 테스트를 수행합니다.

3. 디딤365의 역할

공유받은 서버 접속정보를 이용하여 현황을 파악하여 AWS에서 구동되는 환경인지 검토 후 수정이 필요한 사항을 개발자(사) 및 고객사와 협의합니다. 그 후 신규 인프라 구축 및 서버 통신 테스트를 수행하여 새로운 환경을 구축합니다.

마이그레이션의 절차

디딤365에서 수행하는 마이그레이션은 아래와 같이 크게 4가지 절차를 통해 진행됩니다.

각 단계에서 어떠한 절차들이 수행되는지 살펴보도록 하겠습니다.

1. 마이그레이션 평가 단계

기존의 인프라 현황을 파악하고 AWS에서 기존 인프라를 운영할 수 있는지 검토하는 단계입니다.

디딤365는 개발자(사)로부터 공유받은 서버 접속정보를 통하여 기존 인프라에서 이용 중인 OS, 애플리케이션의 종류와 버전을 파악합니다. 해당 종류와 버전을 AWS에서 제공하는지 여부를 파악한 뒤 기존 인프라에 대응하는 구성도 및 견적서를 작성하여 고객사 및 개발자(사)로 공유합니다. 추가로 현재 시스템의 구성과 도메인, IP를 확인 후 AWS에서 구동이 가능한지 검토합니다.

2. 마이그레이션 테스트 단계

AWS에서 인프라를 구축하고 기존 인프라에서 데이터를 이관한 뒤 잘 구동되는지 테스트하는 단계입니다.

디딤365는 고객사 및 개발자(사)에게 공유한 신규 인프라 구성도를 바탕으로 AWS에 기존 환경과 유사한 인프라를 구축합니다. 이후 네트워크 구성을 수행하며, 기존에 사용하던 애플리케이션을 설치합니다.

개발자(사)는 신규로 구성된 AWS 인프라에 소스 파일 및 DB 덤프를 이관합니다. 이후 디딤365와 개발자(사)는 AWS 인프라로 구성된 환경에서 기존 서비스가 구동되는지 테스트합니다.

3. 서비스 이관 단계

AWS에서 해당 워크로드가 구동 가능함을 확인한 뒤 실제 서비스 전체를 이관하는 단계입니다.

AWS에 신규 인프라를 구축하고 데이터를 이전했지만, DNS는 변경하지 않아 기존의 물리 서버에서 서비스가 구동되고 있습니다. 마이그레이션 테스트 단계에서 기존 서비스가 AWS에서 구동 가능함을 테스트했다면, DNS를 AWS로 변경하여 실제로 서비스가 AWS에서 구동되도록 변경하는 작업을 수행합니다.

데이터 정합성 및 DNS 변경을 위해 디딤365, 고객사 및 개발자(사)는 마이그레이션이 가능한 일정을 협의해야 합니다.

개발자(사)는 마이그레이션 테스트 단계 직후와 서비스 이관 시점의 데이터 정합성을 위해 다시 한번 기존 인프라에서 최종적으로 AWS 인프라로 데이터를 이관합니다.

디딤365는 기존 서비스의 DNS를 AWS 인프라로 접속할 수 있게 변경하는 작업을 수행합니다.

4. 안정화 단계

실 서비스 이관 후 모니터링 기간을 거쳐 서비스의 안정화를 검토하는 단계입니다.

AWS에 신규 인프라를 구축하고, 데이터를 이전한 뒤 DNS까지 AWS로 변경하였다면, 이제부터 실 서비스는 AWS 위에서 구동됩니다. 물리 서버에서 클라우드로 환경이 변했기 때문에 적응하는 기간이 필요할 수 있습니다.

개발자(사)는 OS 버전 변경, IP 변경, RDS, S3 도입 등 변경된 환경에 따른 소스 코드의 수정이 필요할 수 있습니다. 또한 마이그레이션 후 기능 및 성능 테스트를 수행하여 실 서비스 때에도 문제가 없는지 파악합니다.

디딤365는 마이그레이션 완료 후 일정 기간 AWS 인프라를 모니터링하여 장애 발생 여부 파악 및 조치를 수행합니다.

마치며

사업이 확장됨에 따라 인프라 안정성, 빠른 확장성, 손쉬운 관리, 합리적인 요금 체계를 원하는 고객들의 수요가 발생합니다.

만약 물리 서버를 이용하면서 인프라 교체, 일시적으로 급증하는 트래픽 처리 등으로 곤란한 상황을 겪으셨다면, AWS로 여정을 떠나는 방법도 고려해 보시기 바랍니다. 감사합니다.

– 영업컨설팅2팀