2018.11.13

10주년 맞이한 마이크로소프트 애저 클라우드의 “어제, 오늘 그리고 내일”

Simon Bisson | InfoWorld
마이크로소프트가 애저(Azure) 클라우드 서비스를 시작한 지 10년이 지났다. 컴퓨팅 분야에서 10년은 매우 긴 시간이므로, 인터넷 아카이브의 웨이백 기기를 타고 과거로 돌아가 다시 애저의 역사를 정리해 보자.

출시 당시 마이크로소프트 애저는 PaaS(Platform as a Service)의 일종이었다. 그 위에 애플리케이션을 구축할 수 있는 클라우드 호스팅 서비스였다. 라이브 서비스(Live Services)가 기기에 통합됐고, SQL 서비스(SQL Services)는 데이터 처리를 담당했다. 닷넷 서비스(.Net Services)는 스테이트리스(stateless) 애플리케이션을 호스팅했으며, 셰어포인트(SharePoint) 및 다이내믹스(Dynamics)를 통합하는 계획이 나온 상태였다.

Image Credit : GettyImagesBank

출시 당시의 애저 : PaaS
애저의 출시 초기를 보면 당시부터 익숙한 것이 꽤 많았음을 알 수 있다. 많은 기반 기술을 자체 개발했는데, 이는 애저 개발 툴의 중추로 자리 잡았다. 그 이면에는 워커 프로세스와 관리형 서비스 패브릭 같은 현재 일반화된 개념이 있었다. 현재 윈도우 또는 리눅스에서 앱을 개발하는 것만큼 유연하지는 않았지만, 각 개발자의 통합개발환경(IDE)에서 퍼블리시(Publish) 버튼을 누르는 것만으로 소프트웨어를 배포하는 새로운 세계로 가는 출발점이 되었다.

그러나 출시 초기 애저는 저항에 부딪혔다. 당시 기업은 스테이스리스, 서버리스 애플리케이션 개발 모델을 수용할 준비가 되지 않은 상태였다. 결국 애저는 한 걸음 물러서서 주요 경쟁사인 AWS(Amazon Web Services)와 비슷하게 맞추는 것으로 방향을 틀었다. 당시 AWS는 가상 인프라를 지원하는 기능적 서비스에 집중했고, 빠른 속도로 시장 점유율을 늘려나가는 상황이었다.

이에 대항한 것이 마이크로소프트의 하이퍼-V 가상화 기술이었다. 애저는 이 기술을 이용해 IaaS(Infrastructure as a Service)로 변신했고, 지난 10년 동안 AWS와 비슷한 길을 걸어왔다. 즉, 가상 네트워크와 가상머신을 기반으로 애플리케이션을 구동하는 서비스를 내놓았다. 단, 원조인 PaaS를 완전히 포기한 것은 아니었다. PaaS는 웹 서비스와 서비스로서의 백엔드(Backend as a Service) 툴을 지원하는 용도로 여전히 사용됐다.

애저의 현재 : 마이크로서비스에 최적화된 클라우드
반전은 클라우드 산업이 발전하면서 시작됐다. 지난 몇 년 동안 애저는 원조 버전으로 회귀하는 움직임을 보이고 있다. 그 결과 오늘날 애저는 우리가 생각하는 것보다 처음 출범할 당시 플랫폼에 훨씬 더 가깝다. 여전히 주요 인프라 구성 요소를 갖고 있지만, 수년 동안 서비스 프레임워크를 발전시켜 오면서 애저는 점차 '플랫폼형 클라우드'로써 위상을 강화하고 있다.

이러한 변화의 가장 큰 요인은 분산형 클라우드 시스템 개발이 점점 더 중요해지고 있기 때문이다. 클라우드 덕분에 무제한에 가까운 컴퓨팅 자원을 쓸 수 있다고 해도 본질적으로는 여전히 개별 서버의 집합일 뿐이다. 인텔이 자사 아키텍처에 다중 처리 시스템용 코어와 지원을 계속 추가하고 있고, 애저가 여전히 스케일업보다는 스케일아웃 방식을 고수하는 것도 이 때문이다. 물론 대형 프로젝트를 위해 애저의 초대형 G 시리즈 기기를 쓸 수는 있지만, 1년에 8만 달러가 훨씬 넘는 비용을 생각하면 지속적 운영이 필요한 클라우드 네이티브 애플리케이션에 적합한 모델이라고 보기 힘들다.

스케일아웃 방식은 클라우드 하드웨어의 성능과 '일치하는' 아키텍처 접근방식이다. 즉 전 세계 데이터센터 속 오픈 컴퓨트(Open Compute) 서버 랙이 차곡차곡 새 서버로 쌓여갈수록 성능도 똑같이 늘어난다. 각 데이터센터 간에 아키텍처를 복제해 필요할 때마다 용량과 지리적 요건을 고려해 구매해 사용하면 된다. 특히 이 모델은 마이크로서비스에 안성맞춤이다. 마이크로서비스란 애플리케이션을 여러 컴포넌트로 해체하는 것을 가리킨다. 각 컴포넌트는 필요에 따라 독립적으로 확장할 수 있다.

마이크로소프트는 애저를 기반으로 한 클라우드 네이티브 마이크로서비스에 큰 기대를 걸고 있다. 쿠버네티스 툴과 컨테이너를 지원하기 위해 윈도우 서버를 완전히 뜯어고친 것만 봐도 그 기대가 어느 정도인지 짐작할 수 있다. 컨테이너에 최적화된 최신 윈도우 서버를 이용하면 마이크로서비스를 신속하게 확장, 배포할 수 있다. 컨테이너 배포에 적합한 사전 구성 서버 덕분에 새 기능과 추가 컴퓨팅 자원을 할당하는 것이 훨씬 빨라졌다. 코드와 컨테이너를 묶기만 하면 애플리케이션 또는 서비스를 지원할 수 있으므로 더는 컨테이너에서 운영체제가 만들어질 때까지 기다릴 필요가 없다.

이밖에 애저 서비스 패브릭 같은 애저 출시 당시의 서비스는 마이크로서비스에 최적화된 고객 툴이 됐고 컨테이너 및 VM 기반 솔루션에 대한 지원도 개선됐다. 그 결과 개발자는 여러 기술을 동시에 활용해 복잡한 애플리케이션을 개발할 수 있게 됐고, 애저는 이런 새로운 아키텍처를 지원할 수 있도록 진화했다.

애저의 미래 : 분산 애플리케이션의 산실
애저의 과거가 현재가 되었다면 앞으로는 어떻게 될까? 하이퍼스케일 클라우드 플랫폼의 가장 큰 장점은 다양한 개발 모델을 지원한다는 점이다. 앞으로도 2가지 개발이 공존할 것이다. 하나는 온프레미스 애플리케이션을 클라우드로 들어옮기는(Lift and Shift) 마이그레이션이고, 다른 하나는 처음부터 클라우드에서 개발하는 새로운 애플리케이션이다. 따라서 지금 필요한 것은 기존의 획일적인(monolith) 애플리케이션을 분산 애플리케이션으로 마이그레이션하는 방법을 찾는 것이다.

이처럼 기존 일체형 애플리케이션을 해체할 때 유용한 것이 바로 분산형 애플리케이션 디자인 패턴(Distributed application design patterns)이다. 사이드카(sidecar)와 어댑터(adapter) 등의 모델을 이용해 애플리케이션에서 기능을 해체한 후 새로운 마이크로서비스로 이전할 수 있다. 기존 애플리케이션을 계속 실행하면서 이런 기능을 서서히 떼어내는 것이다. 서비스 패브릭(Service Fabric)이 지속적으로 발전하고 있으므로, 이런 패턴에 적합한 호스팅 서비스가 등장할 가능성이 크다. 이런 서비스를 이용하면 가상머신을 계속 관리하면서도 동시에 사이드바와 어댑터 컨테이너를 위한 쿠버네티스 오케스트레이션까지 다룰 수 있다.

또한 분산 컴퓨팅에 대한 새로운 접근 방식도 떠올릴 수 있다. 프로젝트 올린즈(Project Orleans) 팀의 작업 성과를 기반으로 한 것이다. 최신 버전의 분산 트랜잭션 기능을 이용하면 기존보다 더 복잡한 애플리케이션까지 지원할 수 있다. 모든 기업이 글로벌 확장이 필요하지는 않겠지만, 이런 툴을 이용하면 개발자가 여러 병렬 마이크로서비스를 이용해 복잡한 부하를 처리할 수 있다. 중앙 서비스에 안전하게 데이터를 보내기 위해 필요한 가상 개체를 활용하는 것도 가능하다.

오늘날 애플리케이션은 기본적으로 분산형 애플리케이션이다. 퍼블릭 클라우드의 아키텍처와 기반이 되는 하드웨어의 제한을 고려해 개발된다. 서버 아키텍처가 크게 변화할 때까지는 이러한 기본적 전제가 흔들리지는 않을 것이다. 이런 상황에서 우리가 볼 수 있는 것은 마이크로소프트 같은 클라우드 서비스 업체뿐이다. 이들 업체가 분산 애플리케이션을 지원하는 더 다양하고 개선된 툴을 제공하고, 클라우드에서 개발, 실행하는 방법을 교육하고, 기존 코드를 새로운 환경에서도 사용할 수 있도록 마이그레이션하는 툴을 제공한다.

애저가 바로 이러한 작업을 하기에 적합한 공간이다. 마이크로소프트의 애저 관련 개발자들은 지난 10년 동안 분산 서비스를 개발하고 실행해 온 경험이 있다. 이제 이 경험을 더 많은 커뮤니티와 나눌 때가 됐다. 더구나 툴이 개선되면서 ASFM(Azure Service Fabric Mesh) 같은 서비스가 클라우드 제공 방식을 더 간소화하고 있고 새로운 학습(Learn) 플랫폼은 스스로 학습할 수 있도록 지원한다.

마이크로소프트는 10년 전 애저를 출시할 당시 너무 시대를 앞서 나갔던 것일 수도 있다. 그러나 이후 시장 지형이 크게 바뀌었다. 이제 마이크로소프트는 개발자가 원하는 것을 쫓기만 할 것이 아니라 글로벌 규모 분산 시스템의 장점을 활용할 수 있는 새로운 애플리케이션을 만들도록 개발자를 촉구할 시점이다. 쉽지는 않겠지만 이제 마이크로소프트는 한 걸음 더 다가가야 한다.  editor@itworld.co.kr


2018.11.13

10주년 맞이한 마이크로소프트 애저 클라우드의 “어제, 오늘 그리고 내일”

Simon Bisson | InfoWorld
마이크로소프트가 애저(Azure) 클라우드 서비스를 시작한 지 10년이 지났다. 컴퓨팅 분야에서 10년은 매우 긴 시간이므로, 인터넷 아카이브의 웨이백 기기를 타고 과거로 돌아가 다시 애저의 역사를 정리해 보자.

출시 당시 마이크로소프트 애저는 PaaS(Platform as a Service)의 일종이었다. 그 위에 애플리케이션을 구축할 수 있는 클라우드 호스팅 서비스였다. 라이브 서비스(Live Services)가 기기에 통합됐고, SQL 서비스(SQL Services)는 데이터 처리를 담당했다. 닷넷 서비스(.Net Services)는 스테이트리스(stateless) 애플리케이션을 호스팅했으며, 셰어포인트(SharePoint) 및 다이내믹스(Dynamics)를 통합하는 계획이 나온 상태였다.

Image Credit : GettyImagesBank

출시 당시의 애저 : PaaS
애저의 출시 초기를 보면 당시부터 익숙한 것이 꽤 많았음을 알 수 있다. 많은 기반 기술을 자체 개발했는데, 이는 애저 개발 툴의 중추로 자리 잡았다. 그 이면에는 워커 프로세스와 관리형 서비스 패브릭 같은 현재 일반화된 개념이 있었다. 현재 윈도우 또는 리눅스에서 앱을 개발하는 것만큼 유연하지는 않았지만, 각 개발자의 통합개발환경(IDE)에서 퍼블리시(Publish) 버튼을 누르는 것만으로 소프트웨어를 배포하는 새로운 세계로 가는 출발점이 되었다.

그러나 출시 초기 애저는 저항에 부딪혔다. 당시 기업은 스테이스리스, 서버리스 애플리케이션 개발 모델을 수용할 준비가 되지 않은 상태였다. 결국 애저는 한 걸음 물러서서 주요 경쟁사인 AWS(Amazon Web Services)와 비슷하게 맞추는 것으로 방향을 틀었다. 당시 AWS는 가상 인프라를 지원하는 기능적 서비스에 집중했고, 빠른 속도로 시장 점유율을 늘려나가는 상황이었다.

이에 대항한 것이 마이크로소프트의 하이퍼-V 가상화 기술이었다. 애저는 이 기술을 이용해 IaaS(Infrastructure as a Service)로 변신했고, 지난 10년 동안 AWS와 비슷한 길을 걸어왔다. 즉, 가상 네트워크와 가상머신을 기반으로 애플리케이션을 구동하는 서비스를 내놓았다. 단, 원조인 PaaS를 완전히 포기한 것은 아니었다. PaaS는 웹 서비스와 서비스로서의 백엔드(Backend as a Service) 툴을 지원하는 용도로 여전히 사용됐다.

애저의 현재 : 마이크로서비스에 최적화된 클라우드
반전은 클라우드 산업이 발전하면서 시작됐다. 지난 몇 년 동안 애저는 원조 버전으로 회귀하는 움직임을 보이고 있다. 그 결과 오늘날 애저는 우리가 생각하는 것보다 처음 출범할 당시 플랫폼에 훨씬 더 가깝다. 여전히 주요 인프라 구성 요소를 갖고 있지만, 수년 동안 서비스 프레임워크를 발전시켜 오면서 애저는 점차 '플랫폼형 클라우드'로써 위상을 강화하고 있다.

이러한 변화의 가장 큰 요인은 분산형 클라우드 시스템 개발이 점점 더 중요해지고 있기 때문이다. 클라우드 덕분에 무제한에 가까운 컴퓨팅 자원을 쓸 수 있다고 해도 본질적으로는 여전히 개별 서버의 집합일 뿐이다. 인텔이 자사 아키텍처에 다중 처리 시스템용 코어와 지원을 계속 추가하고 있고, 애저가 여전히 스케일업보다는 스케일아웃 방식을 고수하는 것도 이 때문이다. 물론 대형 프로젝트를 위해 애저의 초대형 G 시리즈 기기를 쓸 수는 있지만, 1년에 8만 달러가 훨씬 넘는 비용을 생각하면 지속적 운영이 필요한 클라우드 네이티브 애플리케이션에 적합한 모델이라고 보기 힘들다.

스케일아웃 방식은 클라우드 하드웨어의 성능과 '일치하는' 아키텍처 접근방식이다. 즉 전 세계 데이터센터 속 오픈 컴퓨트(Open Compute) 서버 랙이 차곡차곡 새 서버로 쌓여갈수록 성능도 똑같이 늘어난다. 각 데이터센터 간에 아키텍처를 복제해 필요할 때마다 용량과 지리적 요건을 고려해 구매해 사용하면 된다. 특히 이 모델은 마이크로서비스에 안성맞춤이다. 마이크로서비스란 애플리케이션을 여러 컴포넌트로 해체하는 것을 가리킨다. 각 컴포넌트는 필요에 따라 독립적으로 확장할 수 있다.

마이크로소프트는 애저를 기반으로 한 클라우드 네이티브 마이크로서비스에 큰 기대를 걸고 있다. 쿠버네티스 툴과 컨테이너를 지원하기 위해 윈도우 서버를 완전히 뜯어고친 것만 봐도 그 기대가 어느 정도인지 짐작할 수 있다. 컨테이너에 최적화된 최신 윈도우 서버를 이용하면 마이크로서비스를 신속하게 확장, 배포할 수 있다. 컨테이너 배포에 적합한 사전 구성 서버 덕분에 새 기능과 추가 컴퓨팅 자원을 할당하는 것이 훨씬 빨라졌다. 코드와 컨테이너를 묶기만 하면 애플리케이션 또는 서비스를 지원할 수 있으므로 더는 컨테이너에서 운영체제가 만들어질 때까지 기다릴 필요가 없다.

이밖에 애저 서비스 패브릭 같은 애저 출시 당시의 서비스는 마이크로서비스에 최적화된 고객 툴이 됐고 컨테이너 및 VM 기반 솔루션에 대한 지원도 개선됐다. 그 결과 개발자는 여러 기술을 동시에 활용해 복잡한 애플리케이션을 개발할 수 있게 됐고, 애저는 이런 새로운 아키텍처를 지원할 수 있도록 진화했다.

애저의 미래 : 분산 애플리케이션의 산실
애저의 과거가 현재가 되었다면 앞으로는 어떻게 될까? 하이퍼스케일 클라우드 플랫폼의 가장 큰 장점은 다양한 개발 모델을 지원한다는 점이다. 앞으로도 2가지 개발이 공존할 것이다. 하나는 온프레미스 애플리케이션을 클라우드로 들어옮기는(Lift and Shift) 마이그레이션이고, 다른 하나는 처음부터 클라우드에서 개발하는 새로운 애플리케이션이다. 따라서 지금 필요한 것은 기존의 획일적인(monolith) 애플리케이션을 분산 애플리케이션으로 마이그레이션하는 방법을 찾는 것이다.

이처럼 기존 일체형 애플리케이션을 해체할 때 유용한 것이 바로 분산형 애플리케이션 디자인 패턴(Distributed application design patterns)이다. 사이드카(sidecar)와 어댑터(adapter) 등의 모델을 이용해 애플리케이션에서 기능을 해체한 후 새로운 마이크로서비스로 이전할 수 있다. 기존 애플리케이션을 계속 실행하면서 이런 기능을 서서히 떼어내는 것이다. 서비스 패브릭(Service Fabric)이 지속적으로 발전하고 있으므로, 이런 패턴에 적합한 호스팅 서비스가 등장할 가능성이 크다. 이런 서비스를 이용하면 가상머신을 계속 관리하면서도 동시에 사이드바와 어댑터 컨테이너를 위한 쿠버네티스 오케스트레이션까지 다룰 수 있다.

또한 분산 컴퓨팅에 대한 새로운 접근 방식도 떠올릴 수 있다. 프로젝트 올린즈(Project Orleans) 팀의 작업 성과를 기반으로 한 것이다. 최신 버전의 분산 트랜잭션 기능을 이용하면 기존보다 더 복잡한 애플리케이션까지 지원할 수 있다. 모든 기업이 글로벌 확장이 필요하지는 않겠지만, 이런 툴을 이용하면 개발자가 여러 병렬 마이크로서비스를 이용해 복잡한 부하를 처리할 수 있다. 중앙 서비스에 안전하게 데이터를 보내기 위해 필요한 가상 개체를 활용하는 것도 가능하다.

오늘날 애플리케이션은 기본적으로 분산형 애플리케이션이다. 퍼블릭 클라우드의 아키텍처와 기반이 되는 하드웨어의 제한을 고려해 개발된다. 서버 아키텍처가 크게 변화할 때까지는 이러한 기본적 전제가 흔들리지는 않을 것이다. 이런 상황에서 우리가 볼 수 있는 것은 마이크로소프트 같은 클라우드 서비스 업체뿐이다. 이들 업체가 분산 애플리케이션을 지원하는 더 다양하고 개선된 툴을 제공하고, 클라우드에서 개발, 실행하는 방법을 교육하고, 기존 코드를 새로운 환경에서도 사용할 수 있도록 마이그레이션하는 툴을 제공한다.

애저가 바로 이러한 작업을 하기에 적합한 공간이다. 마이크로소프트의 애저 관련 개발자들은 지난 10년 동안 분산 서비스를 개발하고 실행해 온 경험이 있다. 이제 이 경험을 더 많은 커뮤니티와 나눌 때가 됐다. 더구나 툴이 개선되면서 ASFM(Azure Service Fabric Mesh) 같은 서비스가 클라우드 제공 방식을 더 간소화하고 있고 새로운 학습(Learn) 플랫폼은 스스로 학습할 수 있도록 지원한다.

마이크로소프트는 10년 전 애저를 출시할 당시 너무 시대를 앞서 나갔던 것일 수도 있다. 그러나 이후 시장 지형이 크게 바뀌었다. 이제 마이크로소프트는 개발자가 원하는 것을 쫓기만 할 것이 아니라 글로벌 규모 분산 시스템의 장점을 활용할 수 있는 새로운 애플리케이션을 만들도록 개발자를 촉구할 시점이다. 쉽지는 않겠지만 이제 마이크로소프트는 한 걸음 더 다가가야 한다.  editor@itworld.co.kr


X