하이브리드 클라우드 서비스, VMware Cloud on AWS를 만나다

얼마전 '하이브리드 클라우드 서비스, VMware Cloud on AWS를 만나다'라는 주제를 가지고,

하이브리드 클라우드에 대해 소개하는 자리가 있었습니다.

다른 자료는 제외하고, 실제 도움이 될 수 있는 이야기만 추려보았습니다.

 

일반적으로 클라우드는 크게 퍼블릭 클라우드와 프라이빗 클라우드로 나누어 표기합니다.

 

데이터센터의 위치가 어디인가, 누가 관리하는 것인가에 따라 나뉘게 되는건데,
주로 고객사가 직접 구축/운영/관리하는 데이터센터에 위치한 클라우드를 프라이빗클라우드,
사업자가 구축/운영/관리하는 데이터센터에 위치한 클라우드를 퍼블릭클라우드라고 부릅니다.

 

사실 고객사의 데이터센터는 클라우드 환경이 아니고 일반 레거시 환경일 수도 있습니다.

이 모두를 포함하여 고객사가 직접 관리하는 데이터센터를 On-premise라는 용어로도 부르고 있습니다.

 

요즘에는 프라이빗이나 퍼블릭이냐라는 말보다는

하이브리드 클라우드 또는 멀티클라우드라는 말이 더 많이 들리는 것 같습니다.

일반적으로 퍼블릭클라우드 사용자 분들 중에는 On-premise 데이터센터를 함께 운영중이거나, 
아니면 다른 퍼블릭클라우드도 함께 사용하고 계시는 경우가 종종 있습니다.

이러한 경우, 너도나도 하이브리드 클라우드라는 단어를 사용하고 있습니다.

 

하지만, 여기서 하나 생각해 보아야 할 것이 있는데, 바로 하이브리드 클라우드가 무엇인가?입니다.

대부분 On-premise를 사용하면서 퍼블릭클라우드를 함께 사용하면, 하이브리드 클라우드라고 포장하는 경우가 많습니다.

 

하지만, 그건 하이브리드 클라우드라기 보다는 멀티클라우드라고 분류하는 것이 좋습니다.

단지 다수의 클라우드 서비스를 함께 사용하는 것이며,

아무리 워크로드가 흩어져 있다고 해도 그건 멀티클라우드라고 정의하는 것이 맞습니다.

왜냐하면,

결국 다수의 클라우드 관리를 따로하고,

서로간의 정책과 운영방식이 다르고, 

워크로드 역시 즉시 이동할수 없기 때문입니다.

하이브리드 클라우드라는 이름을 붙히려면, 두개 이상의 클라우드를 이용하는 환경에서

워크로드의 변화없이 서로간의 이동이 가능해야 하고,
기존에 운영하던 정책을 그대로 이어가면서, 더욱 발전시키고,
백업이나 보안등 관리 방법을 이어갈 수 있어야 합니다.
또한, 어느 한쪽으로만 이동이 가능한 것이 아니라 서로간에 양방향으로 움직일 수 있어야 합니다.

하지만, 멀티클라우드 상에서는 이 모든 것이 클라우드 사업자별로 중복되어 발생합니다.

 

그럼 하이브리드 클라우드는 멀티클라우드보다 더 상위 개념인가요? 라고 물으실수도 있습니다.

상황에 따라서 멀티클라우드를 먼저 사용하시면서 일부는 하이브리드 클라우드로,
또는 하이브리드 클라우드를 먼저 사용하다가 멀티클라우드로 발전하는 경우들도 있습니다.
즉, 서로 보완적인 관계입니다.

앞서 하이브리드 클라우드는 다수의 클라우드에서 동일한 운영 환경을 사용한다고 했습니다.

여기서 동일한 운영 환경이란 단일 솔루션을 기반으로 하나의 통일된 환경으로 운영/관리되어야 합니다.

클라우드 구성 솔루션의 단일화가 필수입니다.

 

또한, 워크로드의 양방향 이동이 지원되어야 합니다.

예를 들어 On-premise에서 자원이 부족해질경우, 퍼블릭클라우드에서 이어받아 즉시 워크로드의 확장되어야 합니다.
당연히 On-premise와 퍼블릭클라우드의 인프라 환경이 다른 경우 불가능합니다.

따라서 일관된 인프라 환경을 유지해야 합니다.

 

이를 통해 기존의 워크로드의 변화 없이, 기존의 정책의 변화 없이, 관리 방법이 변화 없이,
사용자가 원할땐 언제든지 가상머신부터 컨테이너까지 관리하실 수 있습니다.
이게 하이브리드 클라우드의 정의이자 특징입니다.

이런 하이브리드 클라우드를 구성할 수 있는 핵심에 VMware Cloud on AWS가 있습니다.
이름에서 바로 감이 오시듯이 AWS 데이터센터에 위치하는 VMware Cloud 서비스입니다.

 

VMware는 On-premise를 위한 데이터센터 가상화, 즉 SDDC로 대표되는 인프라 가상화 솔루션 업체입니다.
아마 우리나라뿐만 아니라 글로벌하게 엔터프라이즈 환경에서 VMware 안쓰는 곳은 찾아보기 힘들 정도로
안정성을 기반으로 흔히 말씀하시는 디팩토스탠다드 가상화 솔루션입니다.

 

AWS는 두말할 필요없이, 퍼블릭클라우드의 최강자로 군림하고 있는 대표주자입니다.

 

이처럼 프라이빗 클라우드의 최강자 VMware와  퍼블릭클라우드의 최강자 AWS가

함께 공동개발하고 지원하는 솔루션이 바로 VMware Cloud on AWS입니다.

왼쪽에 On-premise 데이터센터가 VMware 환경으로 구축되어 있습니다.

서버 하드웨어도 사용자가 구매하고, VMware 가상화 소프트웨어도 사용자가 구매하고, 운영도 사용자가 합니다.
운영은 당연히 vCenter라는 통합된 관리체계를 이용합니다.

가운데 AWS의 데이터센터가 있습니다.
AWS 데이터센터에는 수많은 EC2 타입이 존재하나, EC2 위에 가상화를 위한 하이퍼바이저 설치는 불가능합니다.

하지만, AWS의 베어메탈 EC2 위에 VMware의 하이퍼바이저인 vSphere를 올리는 것이 가능합니다.

바로 VMware가 직접 운영하는 VMware Cloud on AWS를 통해서입니다.

 

VMware Cloud on AWS는,

서버 가상화인 vSphere, 스토리지 가상화인 vSAN, 네트워크 가상화인 NSX를 기반으로 구축됩니다.
역시 On-premise와 동일한 vCenter라는 관리체계를 사용해 관리합니다.

즉 AWS의 데이터센터에 위치한 EC2 위에 VMware 기반의 SDDC 환경이 구축되어 있습니다.

누가 구축하느냐? VMware가 직접합니다. 하드웨어는 AWS가 가상화는 VMware가 직접 지원합니다.

On-premise 데이터센터도 vSphere 환경에서 vCenter로 관리하고, 

AWS 위 SDDC 환경도 vSphere 환경에서 vCenter로 관리합니다.

이 경우 관리방법이 바뀔까요? 아니면 서로간에 워크로드 이동을 위해 변경이 필요할까요? 보안정책은요?
AWS 위에 올라간 VMware Cloud에서 아무런 변화없이 기존에 사용하시던 방법대로 운영합니다.

조금 더 나아가, 오른쪽에 AWS의 EFS, ALB, S3 등등 셀수도 없는 수많은 서비스가 있습니다.

그런데 알고보면, VMware Cloud on AWS는 베어메탈 EC2를 사용하고 이 EC2는 VPC에 속해 있습니다.

즉, VPC를 넘어 AWS의 모든 서비스들과 통신할 수 있습니다.

 

VMware Cloud on AWS의 SDDC는

ENI도 가지고 있고, TGW랑 통신할수도 있고, 인터넷도 나갈수 있고, DX도 직접 연결가능합니다.

On-premis의 워크로드를 그냥 그대로 옮기기만 해도, Native AWS의 모든 서비스를 즉시 이용할 수 있습니다.

일반적으로 On-premise의 vSphere는 VM 기반의 워크로드를 주로 관리합니다.

하지만, VMware Cloud on AWS는 Tanzu라는 브랜드의 K8s 플랫폼을 탑재하고 있습니다.

On-premise에서는 별도의 제품이지만, VMware Cloud on AWS에서는 기본 제공됩니다.

 

Tanzu는 오픈소스 기반의 K8s 플랫폼으로 엔터프라이즈 레벨의 서비스를 함께 제공합니다.

VMware Cloud on AWS 뿐만 아니라, native AWS에서도, Azure에서도, On-premise 데이터센터에서도 운영 가능합니다.

 

2017년 VMware Cloud on AWS가 출시되었을때는 VM 기반의 클라우드 서비스였다면,

이제는 동일한 비용으로 점차 발전하여 VM뿐만 아니라 컨테이너 기반의 워크로드까지 제공합니다.

즉 VMware Cloud on AWS는,

AWS에 데이터센터에서 VMware의 SDDC가 구축되는 것이고
이를 통해 On-premise의 운영 방식을 그대로 유지할 수 있습니다.

 

또한, On-premise와 AWS에 동일한 가상화 플랫폼이니까, 워크로드도 언제든 이동가능합니다.
여기에 native AWS의 모든 서비스도 가져다 쓸 수 있으며,

VM뿐만 아니라 컨테이너까지 엔터프라이즈 수준으로 지원합니다.

 

이 모든게 VMware Cloud on AWS에 기본으로 포함되어 있습니다.

외국의 컨설팅 업체에서 실제 서비스에 대한 비용 절감 효과를 조사해 보았더니,

기존 On-premise 데이터센터 운영대비 59%의 비용 절감이 발생했습니다.
데이터센터 상면이나 물리적인 보안 위험의 감소는 물론이고,
버전업그레이드, 패치, 운영자 관리, 장애처리 등등 모든 시간적 비용까지 절감되었습니다.

 

마이그레이션에 있어서도 대부분 다수의 복잡한 단계를 거치게 되어 있습니다.
하지만, VMware Cloud on AWS는 On-premise에 VMware만 있다면, 오늘 밤에도 옮길수 있습니다
IP도 안바꾸고 VM을 재부팅하지 않고도 옮길 수 있습니다.

 

최근에는 함께 제공되는 HCX를 통해 On-premise에 VMware 솔루션이 없어도 이동시켜 줄 수 있습니다.

이처럼 VMware Cloud on AWS는 점점 더 강력해지고 있습니다.

 

이런 하이브리드 클라우드 솔루션을 어떤 경우에 쓸 수 있을지, 대표적인 활용 방안을 살펴보겠습니다.

 

첫번째,
On-premise에 업무를 운영하는데, 특정일자에만 서버가 더 필요해한 경우가 있을 수 있습니다.

일반적으로 퍼블릭 클라우드에서 이야기하는 오토스케일링 기능입니다.

하지만, 퍼블릭에서는 당연한 이 기능이 On-premise에서는 어렵습니다.

Application 구성은 그렇다고 쳐도, 확장할 물리적인 서버가 없기 때문입니다.

 

그럼 서버가 넘쳐나는 AWS 데이터센터로 확장한다면 어떨까요?

필요할때 언제든 확장하여 사용하고, 다 쓰면 다시 제거합니다.

그게 바로 클라우드입니다.

두번째, 워크로드의 종류에 따라 옮기는 것이 쉽지 않은 상황들이 있습니다.

솔루션의 라이센스 이슈일수도 있고, 법적인 이슈나 내부 규정등의 다양한 이유때문입니다.

만약 서버의 수명이 다되어가고 있는 경우, 새로 서버를 구매해서 데이터센터를 유지하는게 답일까요?
아니면 단계별로 신규 서버 구매 대신에 VMware Cloud로 옮기고,
IT 자산관리에 쏟을 여유를 모아 본업의 비즈니스에 집중하는게 이득일지 고민해보아야 합니다.

세번째,
DR 구축하려면 데이터센터의 물리적인 공간도 필요하고, 안쓰는 장비까지 똑같이 구매하여 구성합니다.

실제 발생할지 않할지도 모르는 상황때문에, IT자산뿐만 아니라 부동산까지 필요합니다.

이 상황에서 VMware Cloud가 DR이 되어 준다면 어떨까요?
On-prem의 모든 데이터는 항상 DR로 동기화되고 있으며, DR 상황이 발생했을때 즉시 더 크게 확장할 수 있습니다.
장비도 안사고, 부동산도 필요없습니다.

마지막으로,
native AWS의 다양한 서비스와 연동이 필요한데, On-premise는 물리적으로 너무 멀리 있습니다.

DB같이 지연시간에 민간한 애플리케이션들이 있을 수도 있고, 

신규 서비스와 연동이 필요한데, On-premise에 신규로 구축하기에는 시간이 너무 오래 걸립니다.

만약 다수의 애플리케이션이 서로 같은 DB를 바라 봐야한다면? 당연히 같은 데이터센터에 있는게 좋습니다.

VMware Cloud에서는 모든 AWS 서비스를 즉시 활용할 수 있습니다.

예시로 하이브리드 클라우드 환경에서의 워크로드의 구성을 한번 생각해 봅시다.

 

외부의 이용자는 AWS의 IGW를 통해 인터넷으로부터 들어오고, AWS의 WAF나 Shield같은 보안서비스를 거쳐야 합니다.

WEB은 EC2에 WAS는 VMware에 있으며, DB는 On-premise 환경에 있다고 가정해 보겠습니다.

그리고 WAS는 평상시에는 On-premise에 있다가, 갑작스런 증가가 필요할때만 VMware Cloud로도 옮겨갈수 있습니다.

VMware Cloud에 위치한다면, WAS는 언제든 S3나 EFS의 데이터를 가져올 수 있습니다.

전체가 하나처럼 운영되는 하이브리드 클라우드 환경입니다.

 

완전히 동일하진 않지만 국내 대부분 고객사에서 이렇게 사용하고 있습니다.

기존의 워크로드는 마이그레이션을 통해 VMware Cloud에 올려두고,

AWS의 보안서비스를 통해 인터넷으로 연결되고, 로드밸런서나, EFS 같은 서비스를 함께 이용하며,
남아야 하는 워크로드는 On-premise에 남아 있습니다.

이렇게 좋은 VMware Cloud 서비스는 AWS에만 있지 않으며, 대부분의 퍼블릭 클라우드에서 서비스합니다.

Azure에도 있고, GCP에도 있고, Oracle에도 있으며, 심지어 KT와 네이버 클라우드, 알리바바 클라우드에도 있습니다.

왜 거의 모든 퍼블릭클라우드 사업자 안에 VMware Cloud가 있을까요?
모두들 On-premise에서 VMware의 파워가 어느정도 인지 알고 있으며,
하이브리드 클라우드 구축을 위한 최적의 방법임을 알고 있기 때문이라고 보여집니다.

 

그럼 VMware Cloud on AWS가 다른 퍼블릭 클라우드의 VMware Cloud와의 차이점은 무엇이 있을까요?

 

먼저 국내 리전 및 다수의 레퍼런스를 보유하고 있습니다.

둘째 가장 많은 인스턴스 타입를 보유하고 있습니다.

가장 중요한 셋째, VMware의 전문 SRE팀이 직접 운영합니다.

VMware Cloud인데 VMware가 직접 운영합니다.
다른 퍼블릭클라우드에서는 VMware의 파트너사를 통해 운영합니다.
VMware Cloud에 새로운 기능이나 서비스가 생기면 제일 먼저 적용되고,

보안같은 이슈에 대한 패치들도 제일 먼저 지원됩니다.

챗을 통한 지원이나 SR을 통한 지원도 바로바로 제공됩니다.

 

예를 들어 작년에 log4j같은 문제가 생겼을때도 가장 먼저 패치가 진행되었습니다.

사용자가 패치하는 것이 아니라 VMware의 전문 SRE팀이 스케줄에 의해, 사용자 서비스에 영향없이 즉시 적용합니다.

VMware에 의해 직접 운영/지원되는 VMware Cloud 서비스라는 것만으로 다른 모든 장점을 뛰어넘는 엄청난 장점입니다.

클라우드 마이그레이션에는 많은 준비가 필요하고, 모든 워크로드가 마이그레이션 될 수 있는 것도 아닙니다.

하지만, VMC에서는 마이그레이션을 위한 방법까지도 함께 제시합니다.
이를 통해 VM이 켜진상태에서 이동한다던가, 100개 이상의 워크로드를 동시에 넘긴다던가 하는 일들이 가능합니다.

일반적으로 제시되는 마이그레이션 전략(7R) 중 VMware Cloud on AWS는 Relocate와 Rehost에 해당합니다.

VMware를 사용중이라면 relocate를 통해 마이그레이션되며, 사용하고 있지 않을때 rehost가 발생합니다.

VMware Cloud on AWS에서의 Rehost 전략은,

일반적인 베어메탈 기반의 물리서버거나, 가상화서버지만 vSphere 기반이 아닌 경우 HCX 솔루션을 통해 제공됩니다.

P2V 방식으로 운영체제 상에 Agent를 설치하여 vSphere 기반의 가상머신으로 마이그레이션 합니다.

 

Relocate는,

기존에 vSphere 환경에서 사용중인 가상머신을 하이퍼바이저 위치만 바꾸어 즉시 이전하는 전략입니다.

HCX만 연결되어 있다면, 거리나 버전등에 상관없이 즉시 이동 또는 복제가 가능합니다.

가상머신의 전원도 켜진 상태에서 재부팅 없이 이동도 가능합니다.

이 모든 마이그레이션은 HCX라는 VMware Cloud on AWS와 함께 제공되는 솔루션을 통해 이루어집니다.

VMC에서 HCX를 자동으로 배포하고, On-premise의 데이터센터에 HCX를 배포하고, 
VMware Cloud on AWS와 연결하고, 워크로드를 마이그레이션 적용하면 됩니다.

여기서의 배포과정은 다 패키지화 되어 있으며, IP나 단순한 네트워크 설정만으로 완료됩니다.

 

HCX가 구성되고 나면, On-premise와 VMware Cloud on AWS간에 언제든지 양방향으로 마이그레이션 할 수 있습니다.

국내 사례 중에는 On-premise의 7개가 넘는 vCenter에 HCX를 설치하고,

필요할 때마다 VMware Cloud on AWS로 넘기고 있는 경우도 있고,

해되 사례 중에는 기존 타 CSP의 VMware Cloud의 워크로드를 VMware Cloud on AWS로 넘기는 경우도 있습니다.

HCX는 단순히 마이그레이션을 위한 복제만 하는게 아니라,

복제되는 파일을 일일이 검사하여, 중복제거하고, 전송되는 패킷을 압축하여 전송합니다.

DX로 가면 제일 좋겠지만, VPN이나 일반 인터넷망을 통해서도 가능합니다.

 

또한, 서로간의 vSphere 버전이 달라도 마이그레이션 하고, L2 네트워크를 확장하기도 합니다.
HCX는 똑똑하게 마이그레이션 합니다.

HCX는 기존 환경의 플랫폼을 가리지 않습니다.
vSphere 환경이라면 더욱 쉽게 가능하고, 만약 VMware 환경이 아니라 하더라도 가능합니다.
단종된 OS의 경우에도 VMware 환경에서 사용중이시라면 마이그레이션 합니다.

실제 사례로 보면, native EC2로 가지 못하는 워크로드들만 VMware Cloud에 남기기도 합니다.
RHEL4나 Windows 2009 같은 구형 OS들을 VMware Cloud on AWS에서 운영하면서,

native EC2위에 구성된 서비스들과 연동하여 사용하는 경우도 많이 있습니다.

클라우드 마이그레이션 엔지니어 1명이

일반적인 워크로드의 경우 직접 뜯어서 옮긴다면 한달에 6개 정도 옮길수 있습니다.

그냥 그대로 EC2로 Cloud Endure(현재 단종)나 Application migration Service 같은 솔루션을 쓴다면

한달에 30개 정도 옮길수 있습니다.

동일한 상황에서 VMware Cloud on AWS로 마이그레이션한다면, HCX 구성만 되면, 네트워크 성능만큼 쭉쭉 넘어갑니다.

보통 하룻밤에 10개 이상의 VM에 대해 마이그레이션 가능하며, 낯과 주말까지 한다면 더욱 빠르게 가능합니다.

실제 사례중에는 계획한 워크로드보다 너무 빨리 옮겨가서 40% 이상의 VM을 더 넘긴 적도 있습니다.

이게 바로 HCX의 힘입니다.