최근 Gartner 의 조사에 따르면 Fortune 매거진 100대 기업 중 75%가 자체 개발한 애플리케이션을 클라우드로 이전할 때 재설계할 계획이 있다고 응답했습니다. 재설계란 온-프레미스 애플리케이션을 클라우드로 이전하는 방법 중 하나입니다. 많은 기업이 애플리케이션을 클라우드에 이전할 때 단순히 호스팅만 다시 하는 것이 아닌, 퍼블릭 클라우드의 탄력성과 확장성을 바탕으로 서버리스나 마이크로서비스 아키텍처와 같은 최신 설계 방법을 도입하는 클라우드 마이그레이션을 수행하고 있습니다.
이번 베스핀글로벌의 클라우드 인사이트에서는 애플리케이션 클라우드 이전시 고려해야 할 원칙에 대해 알아보고, 6가지의 마이그레이션 전략의 아키텍처부터 사용 시나리오까지 실질적으로 도움되는 지식과 통찰력을 제공합니다.
CONTENTS
- 클라우드 마이그레이션 원칙
- 애플리케이션 클라우드 이전 시 6 가지 전략
- 레거시 애플리케이션을 그대로 VM 에 옮기는 전략
- 레거시 애플리케이션을 그대로 컨테이너 서비스로 옮기는 전략
- 관리형 클라우드 서비스를 활용한 수정 전략
- 클라우드 네이티브 서비스로 재설계하는 전략
- 코드를 완전히 다시쓰는 리빌드 전략
- 새로운 서비스형 SaaS 로 대체하는 전략
- 미래의 애플리케이션 개발 고려사항
뉴스레터 가입
클라우드 관련 최신 소식을 업데이트 받으실 수 있습니다.
1. 용어 정의
1) 온-프레미스란?
온-프레미스(On-Premise)란 줄여서 온-프렘(On-Prem)이라고도 하는데, 소프트웨어를 사용하는 사람이 조직 내에 있는 전산실 서버에 직접 설치해 운영하는 방식을 말합니다. 반대로 오프-프레미스(Off-Premise)는 일반적으로 서비스로서의 소프트웨어(SaaS) 또는 클라우드 컴퓨팅을 말합니다.
2) IaaS 란?
IaaS (Infrastructure as a Service)는 서버, 스토리지, 네트워크와 같은 인프라를 필요한 만큼만 서비스로 제공하는 것입니다. 기본 네트워크 인프라의 다양한 하위 수준 세부 정보를 참조하는 데 사용되는 고급 API를 통해 서비스에 접근할 수 있습니다.
3) CaaS 란?
CaaS (Containers as a Service)는 소프트웨어 개발자 및 IT 부서가 컨테이너 기반 가상화를 사용하여 컨테이너를 업로드, 구성, 실행, 확장, 관리 및 중지 할 수 있는 서비스입니다. 예를 들어, Google Kubernetes Engine (GKE), Amazon EKS 또는 Azure Kubernetes Service (AKS) 들이 CaaS 라고 불리는 서비스들입니다.
4) PaaS 란?
PaaS (Platform as a Service)는 서드파티 공급 업체가 인터넷을 통해 사용자에게 하드웨어 및 소프트웨어, 도구(일반적으로 애플리케이션 개발에 필요한 도구)를 제공하는 클라우드 컴퓨팅 서비스입니다. PaaS 제공 업체는 자체 인프라에서 하드웨어 및 소프트웨어를 호스팅합니다.
5) 서버리스 컴퓨팅이란?
서버리스 컴퓨팅(Serverless Computing)은 클라우드 공급 업체가 서버를 실행하고 머신 리소스 할당을 동적으로 관리하는 클라우드 컴퓨팅 실행 모델을 말합니다. 가격은 사전 구매한 용량 단위가 아니라 애플리케이션이 소비한 실제 리소스 양을 기준으로 하며, 유틸리티 컴퓨팅의 한 형태입니다. 개발 코드를 한 번 제작하면 배포 프로세스를 단순화할 수 있고, 확장, 용량 계획 및 유지 관리 작업을 자동화 할 수 있습니다.
6) 마이크로서비스 아키텍처란?
마이크로서비스(Microservice)는 소프트웨어 개발 아키텍처로, 애플리케이션을 느슨하게 결합된 서비스의 모음으로 구성하는 서비스 기반 아키텍처 (SOA, Service-Oriented Architecture)의 변형입니다. 서비스는 세분화되고 프로토콜은 가벼운 것이 특징이며, 애플리케이션을 다른 작은 서비스로 분해해 모듈성이 향상된다는 장점이 있습니다.
따라서 애플리케이션을 보다 쉽게 이해하고 개발 및 테스트할 수 있으며, 아키텍처 손상에 대해 회복력을 갖게 됩니다. 소규모 팀이 각자의 서비스를 독립적으로 개발, 배포 및 확장 할 수 있도록 하여 개발을 병렬화합니다. 또한 지속적인 코드 리팩토링을 통해 개별 서비스의 아키텍처를 구현할 수 있으며, 지속적인 배포를 용이하게 합니다.
7) 코드 리팩토링 이란?
코드 리팩토링(Code Refactoring)은 외부 동작을 변경하지 않고 기존 컴퓨터 코드를 수정하여 내부 구성을 변경하는 프로세스입니다. 리팩토링은 소프트웨어의 비기능적 속성을 개선하기 위한 것입니다. 코드 가독성 향상 및 복잡성 감소와 같은 장점이 있습니다. 소스 코드 유지 관리성과 확장성을 개선할 수 있으며, 보다 더 분명한 내부 아키텍처 또는 객체 모델을 만들 수 있습니다.
8) 상태가 없는 애플리케이션이란?
상태가 없는(Stateless) 애플리케이션은 해당 클라이언트와의 다음 세션에서 사용하기 위해, 한 세션에서 생성된 클라이언트 데이터를 저장하지 않는 애플리케이션을 말합니다. 각 세션은 처음인 것처럼 초기화되어 수행되며, 응답은 이전 세션의 데이터에 의존하지 않습니다.
2. 클라우드 마이그레이션 원칙
모든 조직은 규모와 상관없이 클라우드 마이그레이션을 위한 애플리케이션을 선택하고 우선순위를 지정하는 클라우드 전략이 있습니다. 이 전략은 마이그레이션 문제일 뿐만 아니라 최적화 문제이기도 합니다.
클라우드 마이그레이션이 원하는 비즈니스 성과와 IT 목표를 달성하고, 애플리케이션을 최적화할 수 있는 기회를 제공하느냐는 다음과 같은 원칙에 달려 있습니다.
1) 자율성의 정도
흔히 PAYG (pay-as-you-go)라 불리는 계량 청구 및 셀프 서비스 특성으로 인해 클라우드 제공 업체로의 애플리케이션 마이그레이션은 팀, 부서 또는 사업부 전략에 따라 자율적으로 결정할 수 있습니다. 자율성의 정도가 마이그레이션 결정에 영향을 주는 이유는, 일부 마이그레이션에 대한 대안은 중앙 IT 부서의 승인 없이 기회주의적인 이유로 선택되기 때문입니다.
2) 폐쇄형 대 개방형 솔루션
쿠버네티스, 도커, 클라우드 파운드리 및 아파치 카프카와 같은 개방형 표준 기반의 솔루션을 선호하는 조직은 클라우드 제공 업체의 서비스 사용을 줄일 수 있습니다. 그 이유는 수많은 클라우드 제공 업체의 기술과 서비스가 폐쇄/독점적이기 때문입니다. 개방형 애플리케이션 구성 요소와 폐쇄형 애플리케이션 구성 요소 사이의 모든 선택은 비용 변화를 수반합니다. 애플리케이션의 모든 구성요소는 폐쇄형 대 개방형 솔루션의 맥락에서 고려해야 합니다. 이러한 구성 요소에는 가상화, 컨테이너, 코드, 애플리케이션 런타임 및 데이터가 포함됩니다.
3) 단일 공급 업체 대 기능별 최고 공급 업체
조직의 소싱 원칙은 기능별 최고 공급 업체의 사용보다 단일 공급 업체의 사용을 지시할 수 있습니다. 이는 애플리케이션 요구사항을 충족하는 마이그레이션 옵션이 여러개일 때 결정에 영향을 줍니다. 현재 플랫폼 공급 업체는 모든 대안에 해당하는 오퍼링을 제공하지 않을 수 있습니다.
4) 플랫폼의 도메인 특수성
아마존웹서비스, 마이크로소프트 애저와 같은 클라우드 플랫폼은 도메인에 구애받지 않고, 모든 도메인의 애플리케이션을 구축하는 데 사용될 수 있습니다. 반대로 Salesforce나 ServiceNow와 같이 특정 도메인에 대한 선호나 편향을 가진 플랫폼도 있습니다. 이처럼 도메인 특수성을 가진 플랫폼에 배포된 어플리케이션은, 이 도메인에 기반하여 기능 또는 템플릿을 확장합니다. 이들을 ‘인접 애플리케이션’이라고도 부릅니다. G Suite for Business 또는 Salesforce CRM에 이미 투자한 조직은, 투자 효과를 최대화하기 위해 ‘인접 애플리케이션’을 만드는 것을 선호할 수 있습니다.
5) 벤더 락인, 이식성, 멀티 클라우드 및 호환성
애플리케이션과 데이터가 마이그레이션 이후에 하나의 클라우드에 계속 머무른다면, 이식성은 고려할 필요가 없습니다. 그러나 현실적으로 플랫폼 락인을 무시하는 것은 위험합니다. 클라우드 아키텍트는 클라우드 이식성의 여러 측면을 위한 멀티 소싱 전략을 고려해야합니다.
3. 애플리케이션 클라우드 이전시 6가지 전략
1) 레거시 애플리케이션을 그대로 VM 에 옮기는 전략
가장 손쉬운 마이그레이션 전략에는 리호스팅이 있습니다. 리호스팅에는 온-프레미스 환경의 레거시 애플리케이션을 그대로 VM에 옮기는 방식과 컨테이너 서비스로 옮기는 두 가지 방식이 있습니다. 먼저 레거시 애플리케이션을 그대로 가상머신(VM)에 옮기는 전략을 사용하면, 애플리케이션을 다른 하드웨어 환경에 재배포할 수 있습니다. 또한 클라우드 상에서 애플리케이션 인프라의 다양한 구성 파일을 변경할 수 있습니다.
리호스팅은 코드 수정은 불가능하지만, 어플리케이션을 재구성해 다른 하드웨어 인프라에서 실행가능한 시스템에서 사용할 수 있습니다. 아키텍처를 변경하지 않고 애플리케이션을 리호스팅하면, 클라우드 제공 업체의 마이그레이션 도구를 사용하여 비교적 짧은 시간 내에 마이그레이션을 수행할 수 있다는 이점이 있습니다.
리호스팅에 적합한 시나리오로는, 웹 호스팅의 임대 만료나 인수합병, 조직 분사, 자연재해 위험으로 인해 데이터센터 사용을 즉시 종료해야 하는 경우가 있습니다.
또는 로컬 리소스나 호스트 OS에 종속되지 않으며, 여러 개의 인스턴스에 효과적으로 부하 분산(로드밸런싱)될 수 있는 상태 없는(Stateless) 웹 어플리케이션에도 적합합니다. 애플리케이션 또는 데이터가 이미 병렬화 가능한 경우 IaaS로의 이전은 탄력적인 확장성을 제공할 수 있습니다.
아키텍처 수정 없이 시스템을 이전할 수 있다는 리호스팅의 장점은 그대로 단점이 되기도 합니다. 아키텍처 수정 없이 클라우드 IaaS로 이전된 애플리케이션은 탄력적 확장성과 같은 클라우드 인프라의 장점을 누리지 못하며, 아키텍처 개선도 불가능합니다.
2) 레거시 애플리케이션을 그대로 컨테이너로 옮기는 전략
클라우드 제공 업체가 제공하는 전통적인 컴퓨팅 서비스의 단위는 VM 인스턴스, 또는 구글 쿠버네티스 엔진(GKE), 아마존 EKS, 애저 쿠버네티스 서비스(AKS)와 같은 CaaS 기반의 컨테이너입니다. 마이그레이션 담당 팀은 애플리케이션 실행 환경을 재구성하기 전에 반드시 완전한 스택으로 구성된 VM 또는 컨테이너 이미지를 만들어야 합니다. 클라우드 공급 업체가 마켓플레이스에서 제공하는 이미지 중 가까운 것을 고를 수도 있으며, 직접 만들 수도 있습니다.
리호스팅 마이그레이션의 중요한 이슈 중 하나는 서드파티 애플리케이션이나 종속 라이브러리의 라이선스를 VM 또는 컨테이너에 배포할 수 있는지 여부입니다. 그렇지 않으면 라이선스 마이그레이션 이슈로 문제가 발생할 수도 있습니다.
클라우드 IaaS 또는 CaaS에 애플리케이션을 배포하는 개발자는 자체 시스템 관리를 수행하고, 새로운 구성 도구를 배우고, 구성 스크립트를 작성하고, 시스템을 패치해야 합니다.
각 클라우드 제공 업체는 관리 및 구성을 위한 서로 다른 API를 가지고 있습니다. 또한 업체별 여러 VM 이미지와 스토리지 형식이 경쟁 관계에 있습니다. 한 벤더의 툴에 락인되면 이 툴을 다른 제공 업체에서 사용할 수 없습니다. VM 이미지 조립에 드는 노력은 클라우드 제공 업체를 바꾸면 무용해질 수 있습니다.
벤더 락인은 클라우드 이전시 중요한 고려사항이지만, 다른 플랫폼 대비 IaaS와 CaaS의 단점은 아닙니다. 또한 리호스팅은 다른 다섯 가지 마이그레이션 전략에 비해 락인 우려가 가장 적은 전략입니다.
3) 관리형 클라우드 서비스를 활용한 수정 전략
이 전략은 기존의 레거시 애플리케이션의 코드를 거의 수정하지 않거나 약간만 수정하여 클라우드에 올리고, 클라우드 스토리지나 클라우드형 데이터베이스, 네트워크 등 관리형 클라우드 서비스를 사용해 리소스 사용을 최소화하는 전략입니다. 주로 소스 코드는 그대로 유지하면서 애플리케이션의 환경 구성 파일만 수정하여 최적화하는 전략입니다.
이 전략은 서비스형 데이터베이스와 같은 매니지드 클라우드 서비스를 사용해 운영 오버헤드(비용)를 줄이는 데 중점을 둡니다. 이 단계에서는 IaaS와 CaaS 외에 특정 서비스형 플랫폼(PaaS) 기능을 선택할 수도 있습니다.
예를 들어, 자체 관리형 Oracle Database를 PostgreSQL 용 Amazon RDS로 전환한 다음, RDS 인스턴스를 향하도록 애플리케이션 구성 연결 문자열을 수정할 수 있습니다. 대체로 코드 변경을 최소화하거나 전혀 변경하지 않으면서, 애플리케이션, 시스템 및 애플리케이션 종속성을 재구성해 인프라와 애플리케이션 지원 서비스를 최적화하게 됩니다.
4) 클라우드 네이티브 서비스로 재설계하는 전략
이 전략은 애플리케이션을 클라우드에 최적화된 아키텍처로 전환해, 클라우드 네이티브한 기능을 최대한 활용할 수 있도록 하는 전략입니다. 재설계는 심도있는 프로젝트이며, 조직의 문화, 기술, 사람, 프로세스 및 플랫폼의 변화를 요구합니다.
재설계는 hcaPaaS, fPaaS, 서버리스를 활용해 어플리케이션을 클라우드 네이티브한 플랫폼으로 이전하는 프로젝트에 적합합니다. 테스트가 쉽고, 안정적이며 확장가능하도록 애플리케이션을 재설계해, 클라우드 컴퓨팅의 특성을 최대한 활용하는 것이 목적입니다.
이 과정에서 CaaS, PaaS 및 fPaaS와 같은 프레임워크나 관리 툴을 사용해, 개발자가 CSP 인프라의 클라우드적인 특성을 최대한 활용하도록 도울 수 있습니다.
모놀리식 Java 애플리케이션을 재설계하고 기능을 더 작은 단위의 서비스로 분해하여 병렬화한 다음, Amazon EC2 컨테이너 서비스에 배포하는 것이 재설계 마이그레이션의 한 예시입니다.
재설계의 장점은, 코드를 현대화 함으로써 클라우드 인프라의 특성을 최대한 활용하도록 애플리케이션을 최적화할 수 있다는 점입니다. 반면에 단점은, 시간이 오래 걸리며, 한 번에 많은 지출을 요구한다는 점입니다. 투자한 금액을 나중에 회수할 수 있을 만큼 애플리케이션의 수명주기가 길 것으로 예상될 때, 재설계를 선택하세요.
5) 코드를 완전히 다시쓰는 리빌드 전략
리빌드 전략은 기존의 레거시 코드를 완전히 제거하는 전략으로, 지금까지 수년 동안 축적된 기존 코드를 제거하고 클라우드 제공업체의 애플리케이션 플랫폼에서 처음부터 솔루션을 다시 구축하는 전략입니다.
리빌드는 기존에 익숙했던 코드와 프레임워크를 버릴 것을 요구하지만, 클라우드 제공 업체의 혁신적인 기능에 접근할 수 있다는 장점이 있습니다. 또한 리빌드를 통해 새로운 아키텍처 패러다임을 도입할 수 있습니다.
이 중 하나인 MASA(메시 앱 및 서비스 아키텍처)는 기업에서 애플리케이션의 민첩성을 높이기 위해 채택한 아키텍처 패턴입니다. 이 패턴은 애플리케이션이 API 및 개방형 표준을 통해 더 많은 채널, 애플리케이션 및 서비스와 상호 작용할 수 있게 합니다.
다른 아키텍처 모델로는 스트리밍, 이벤트 주도, 마이크로 서비스 및 서버리스 아키텍처가 있습니다. 다양한 클라우드 플랫폼 및 클라우드 공급자가 이를 지원합니다. 마이크로서비스란, 개별 기능을 구현하고 독립적으로 배포할 수 있는 세분화된 서비스입니다.
기업은 리빌드를 통해 현재 비즈니스 요구 사항에 더 적합한 새로운 아키텍처 패러다임을 채택할 수 있습니다. 애플리케이션을 단순화해, 생산성이 높은 도구를 사용할 수 있다는 것도 리빌드의 장점입니다. 또한 서버리스나 마이크로서비스와 같은 클라우드 네이티브 플랫폼을 도입하면, 비개발자들도 애플리케이션 개발 및 배포에 참여할 수 있습니다. 이 경우 전문 개발자들은 코드 제공에 집중할 수 있습니다.
리빌드는 최신 뱅킹이나 핀테크 서비스를 구축하는 데 사용될 수 있습니다. 여러 채널을 통해 접근가능하고, 컨테이너에 패키징되며, 쿠버네티스에 배포 및 실행되고, Istio 서비스 메시 및 프로메테우스를 통해 모니터링되는 최신 뱅킹 어플리케이션을 구축할 수 있습니다.
6) 새로운 서비스형 SaaS 로 대체하는 전략
이 전략은 기존의 소프트웨어 패키지 또는 자체개발한 애플리케이션을 모두 포기하고, 새로운 보급형 SaaS로 대체하는 전략입니다. SaaS는 기술적, 자본적 제약 측면에서 진입 장벽이 낮기 때문에, 애플리케이션에 대한 SaaS 전략은 즉시 활용할 수 있습니다.
긴급한 현금 흐름 및 운영 비용 절감 요구가 있을때 SaaS가 흔히 고려됩니다. 초기 비용이 다른 전략보다 저렴할 가능성이 높으며, 공급 업체가 일정기간 무료 체험을 제공하기 때문에 애플리케이션 가치를 빠르게 검증할 수 있습니다. SaaS는 IT 인력을 빠르게 재배치하거나 감원할 수 있는 기회를 제공합니다.
이 전략을 선택할 경우 일반적으로 기존 데이터를 모두 SaaS 환경으로 이관해야 합니다. 애플리케이션 데이터의 가져오기 및 내보내기는 API 또는 구성/관리 콘솔을 통해 수행합니다. 사용자는 웹브라우저나 모바일 기기와 같은 사용자 친화적인 인터페이스를 통해 SaaS에 접속할 수 있습니다.
이 전략은 가장 빠르게 클라우드 네이티브 아키텍처를 가진 서비스로 전환할 수 있는 방법입니다. 그러나 벤더 락인의 리스크가 가장 높은 방법이며, 특히 애플리케이션 커스터마이제이션이 필요할 경우 더욱 그렇습니다.
SaaS는 방대한 사용자 데이터를 바탕으로 제품에 대한 의사결정을 내리기 때문에, 기존 소프트웨어 패키지보다 대체로 사용성이 높습니다. 애플리케이션 구축을 위해 개발 인력을 동원하지 않아도 된다는 점도 SaaS의 큰 장점 중 하나입니다.
4. 미래의 애플리케이션 개발 고려사항
모든 클라우드 서비스 사용에는 공급 업체의 플랫폼과 API에 종속되는 위험이 존재합니다. 따라서 여러분의 조직은 컨테이너, 플랫폼, VM, 코드, 데이터 등을 호환 및 이식 가능하도록 하는 표준화 시도와 공급 업체 지원을 끊임없이 모니터링해야 합니다.
현재 이식성의 추세는 OS 컨테이너를 기반으로 한 보다 세밀한 가상화 형태가 주도하고 있습니다. 지난 4년 동안은 도커가 대중화되어 엄청난 관심을 끌었습니다. 컨테이너 수명주기, 런타임 및 파일 시스템 구조의 표준을 정의하는 국제표준단체 OCI(Open Container Initiative)의 출현으로 도커의 위세는 더 강화되고 있습니다. 또한 컨테이너를 지원하는 수많은 PaaS 프레임워크와 오케스트레이션 툴이 시중에 있습니다. 이를 통해 여러 개의 클라우드 환경으로 워크로드를 이동하는 일은 더 쉬워질 전망입니다.
인프라의 위치에 관계없이 최종 사용자에게 클라우드와 같은 경험을 제공하기 위한 애플리케이션 플랫폼이 있습니다. 이를 ‘클라우드 네이티브 애플리케이션 플랫폼(CNAP)’ 이라고 합니다. CNAP는 애플리케이션과 관련 종속성을 단일 플랫폼에서 빌드하여 대부분의 클라우드 인프라에서 실행할 수 있도록 합니다.
이들 플랫폼은 주로 쿠버네티스 기반이지만, 클라우드 파운드리나 애저 서비스 패브릭(ASF) 형태로 제공되기도 합니다. CNAP는 널리 사용되는 CI/CD 툴체인과 연결할 수 있는 공통 구성요소를 개발자에게 제공합니다. 이 구성요소에는 패키징, 빌드 및 배포 요소, 런타임 환경, API가 있습니다.
컨테이너, 플랫폼 외에도 VM, 코드, 데이터 이식성도 고려해야 합니다. 특히 코드 이식성의 경우, 아직 표준이 없기 때문에 클라우드 파운드리와 오픈시프트의 연합과 같은, 벤더나 서비스 공급자간 연합이 중요하게 작용합니다. 조직에게 이식성은 매우 중요한 이슈인 관계로, 락인 리스크가 높은 PaaS 서비스는 시장에서 살아남기 어렵습니다.
위에 정리한 6개의 마이그레이션 전략을 줄여서 ‘6R’이라고 부르기도 합니다. 요즘은 애플리케이션 포트폴리오를 분석하고 마이그레이션에 대한 준비도와 비용, 방법과 계획을 도출해주는 툴도 존재합니다. 툴을 활용한 애플리케이션 마이그레이션은 앞으로 더 보편화될 전망입니다.
* 본 컨텐츠는 가트너 리서치를 토대로 재구성 되었습니다.
클라우드에 대해 더 알고 싶으세요?
지금 바로 베스핀글로벌 전문 컨설턴트에게 문의하세요. 클라우드와 클라우드 도입에 대해 클라우드 전문가가 차근차근 설명해 드립니다.
▶︎ Contact us
베스핀글로벌에 대해 더 알고 싶다면 아래 링크를 클릭해주세요. 베스핀글로벌을 자세히 알려드립니다.
▶︎ About us