[컴퓨터월드] 2014년 AWS에서 처음으로 선보인 서버리스(ServerLess) 솔루션이 IT 업계 개발자들에 의해 한 달에 수십 조 번이 실행되는 등 큰 호응을 얻고 있다. 서버리스는 서버의 운영·관리를 개발자를 대신해 CSP(Cloud Service Provider)가 도맡아 실행하기 때문에, 실제로 서버는 존재하지만 개발자의 업무에서 사라지는 것처럼 보여 ‘서버리스’ 혹은 ‘서버리스 컴퓨팅’, ‘서버리스 아키텍처’라고 불린다.

서버리스 컴퓨팅은 개발자가 서버를 운영·관리할 필요가 없어 비즈니스와 개발 본연의 업무에 집중하고, 애플리케이션이 구동되는 환경과 컴퓨팅 리소스는 클라우드 서비스가 자동화를 기반으로 대신해준다는 장점이 있다. 이러한 장점을 가진 서버리스 환경은 최근 쿠버네티스, IoT 등 신기술과 결합돼 서비스가 제공돼 향후 시장에서의 고성장이 기대되고 있다.

비용효율성 제고 및 민첩한 개발 가능

클라우드에서 출발한 아키텍처이자 클라우드 컴퓨팅 모델인 ‘서버리스’는 운영상의 책임을 CSP에게 전환해 애플리케이션의 빠른 개발을 가능하게 해준다. 서버리스를 사용하면 개발자들은 서버의 운영과 관리를 고려하지 않고 애플리케이션과 서비스를 구축하고 실행할 수 있다. 이러한 특징을 가진 서버리스를 사용하는 이유는 비용 효율성이 높고 보다 빠르게 최신 애플리케이션을 빌드할 수 있다는 점이다.

개발자들이 기존에 애플리케이션을 개발하던 방식은 개발에 필요한 서버 자원과 애플리케이션을 구동할 때 필요한 서버 자원을 미리 요청한 후 할당받아 애플리케이션을 개발, 운영하는 것이었다.

그러나 최근 들어 많은 개발자들은 클라우드를 개발에 사용하고 있다. 클라우드 사용의 주된 목적 가운데 하나는 ‘비용효율성’이다. 하지만 관련 IT 업계 관계자들은 클라우드 컴퓨팅이 개발자들의 기대만큼 비용상의 장점을 주고 있지는 못하다고 주장한다.

최영락 마이크로소프트 애저 사업부 차장은 “일반적인 클라우드의 과금 체계는 가상머신(VM)을 사용한 만큼, 개발을 위한 프레임워크를 사용한 만큼 과금이 이뤄진다”며 “게임사의 경우 새벽에 비교적 트래픽이 적을 때에도 항상 VM이 할당, 실행되기 때문에 요금을 새벽에도 지속적으로 지불해야 한다. 그렇기에 비용효율성이 그리 높지만은 않다”고 예를 들어 설명했다.

애플리케이션 구동뿐만 아니라 PaaS(서비스형 플랫폼)를 이용하는 고객의 경우에도 비용효율성을 기대하기 어렵기는 마찬가지다. IaaS(서비스형 인프라)보다는 상대적으로 PaaS가 비용이 저렴한데, 개발 라이브러리(프레임워크)가 클라우드에 올라가게 되면 사용하지 않더라도 항상 개발 라이브러리가 VM에 올라가 개발이 마무리되는 시점까지 구동되기 때문에 비용이 꾸준히 발생하게 된다.

서버리스는 이 같은 비용효율성을 고객이 직접 체감할 수 있도록 VM 구동이 아닌, 즉 서버 단위가 아닌 실제로 서버나 코드, 함수(어떤 특정한 기능을 하는 명령어들을 묶어놓은 것) 등을 호출(Call)하는 횟수에 따라 비용을 지불하는 방식이다. 실제로 서버리스는 PaaS와 IaaS보다 상대적으로 사용되는 자원이 적다. 횟수로 혹은 호출된 함수가 실행된 시간에 따라 과금되기 때문에 사용자 입장에서는 사용한 만큼만 지불한다는 클라우드 컴퓨팅의 장점을 보다 확실하게 누릴 수 있다.

김일호 AWS 솔루션즈 아키텍트 매니저는 “클라우드 컴퓨팅의 발전은 IaaS에서 PaaS로 그리고 서버리스로 흘러간다. 또한 애플리케이션 발전 패러다임은 하나의 거대한 덩어리, 모놀리식(Monolithic)에서 잘게 쪼개지는 형태인 마이크로서비스 아키텍처(MSA)로 간다”면서, “클라우드 서비스를 더욱 잘게 나눈 것이 바로 서버리스다. 더 이상 VM 단위가 아닌 함수와 같은 개발 코드를 클라우드로 올리기 때문이다. 이는 곧 비용의 효율성 증가와도 이어진다”고 설명했다.

서버리스가 각광받게 된 또 다른 이유로는 민첩하고 빠르게 애플리케이션을 개발하고, 배포해야 하기 때문이다. 최근 비즈니스는 4차 산업혁명의 물결에 올라타 클라우드 기반의 AI, 머신러닝, 빅데이터 등의 신기술을 활용해 창출되고 있다. 이에 경쟁에서 뒤처지지 않기 위해 보다 뛰어난 기능을 가진 솔루션을 빠르게 배포해야 한다.

이처럼 민첩한 애플리케이션 개발에 대한 수요가 늘어나는 것과 함께 서버리스도 각광받고 있다. 서버리스는 개발자가 직접 서버를 준비하거나 유지, 관리할 필요가 없다. 설치, 유지 또는 관리할 소프트웨어나 런타임이 없기 때문에 개발자는 온전히 코드 개발에만 몰입할 수 있어, 민첩한 애플리케이션 개발이 가능하다는 것이다.

또한 서버리스는 애플리케이션을 구동할 때 기본적으로 클라우드 위에서 구동되므로 유연하게 규모를 조정할 수 있다. 클라우드 컴퓨팅의 일종인 서버리스는 애플리케이션을 자동으로 확장할 수도 있고, 개별 서버 단위가 아닌 사용 단위(처리량, 메모리)를 설정/해제해 용량을 조정할 수 있다.

이 외에도 서버리스는 가용성 또한 자동화를 기반으로 애플리케이션을 실행하는 서비스에서 기본적으로 제공된다. 그렇기에 개발자들은 더더욱 애플리케이션 개발과 운영에만 몰두할 수 있다.

BaaS와 FaaS 등 2가지로 나뉘어

이와 같은 장점들을 가진 서버리스는 FaaS(Function as a Service)와 BaaS(Backend as a Service) 등 2가지로 나뉜다. 먼저 BaaS는 개발자가 백엔드단에서 개발해야하는 기능들을 미리 만들어 서비스 형태로 제공해 주는 것이다.

예를 들어 모바일 게임을 만들 경우 게임 유저 관리, 레이드 공지 기능, 아이템 관리, 랭킹 시스템 등 모바일 게임의 기본적인 핵심 기능을 CSP가 각사의 클라우드에 구현해 놓는다. 개발자들은 각 기능을 API 형태로 바로 사용할 수 있다. 이를 통해 게임 개발자는 게임 자체의 재미와 다양한 콘텐츠 등에 집중할 수 있기 때문에 시간과 개발에 투입되는 노력을 아낄 수 있으며, 그에 따라 비용도 함께 절감된다.

BaaS는 최근 API 호출을 통해 타사 애플리케이션 및 서비스를 광범위하게 연동할 수 있다는 장점을 기반으로 웹앱(WebApp) 또는 모바일 애플리케이션 개발자들을 위한 MBaaS(Mobile Backend as a Service)로 알려지고 있다. 이에 따라 MBaaS 시장도 활성화될 조짐을 보이고 있다.

MBaaS는 모바일에 특화된 푸시 알림, GPS, 소셜서비스 연계 기능 등을 포함, 백엔드에서 필요한 대부분의 기능들을 간단히 활용할 수 있어 많은 기업들이 활용하고 있다. 구글에서 직접 개발한 것을 사용하는 것보다 각자의 시스템에 통합하는 것이 훨씬 간단하기 때문이다. 대표적인 MBaaS의 사례로 구글의 ‘파이어베이스(Firebase)’를 들 수 있다. 구글의 ‘파이어베이스’는 안드로이드, iOS, 웹 등 플랫폼의 종류에 관계없이 다양한 백엔드 서비스를 API로 제공함으로써 한 번의 애플리케이션 개발로 다양한 플랫폼 지원이 가능하도록 서비스를 제공하고 있다.

한편 BaaS와 달리 서버에서 수행되는 기능들을 직접 애플리케이션 개발자가 코드로 작성하는 경우에도 서버리스가 적용될 수 있다. 바로 FaaS다. FaaS는 애플리케이션을 구성하는 여러 함수(코드, Function)들을 클라우드에서 직접 실행, 배포하는 방식이다. 이를 통해 애플리케이션 개발자는 각각의 함수를 개발해 클라우드에 업로드 한 후 필요할 경우 호출만 하면 되는 방식이다. 이로써 클라우드 상에서 서버를 할당받고, 확장하고, DB를 따로 관리하는 등의 백엔드에서 필요한 작업을 개발자는 전혀 신경 쓸 필요가 없다.

개발자는 로직이 담긴 함수 구현만 신경 쓰면 된다. 함수를 실행하기 위한 서버를 올리는 작업이나 실행시간을 구성하고 코드를 배포해 실행해야 하는 과정을 없애고, 사용자가 원하는 로직을 함수로 작성만 해놓으면 함수가 자동으로 실행된다. 구체적으로 함수가 호출되면 VM이 실행되고 해당 실행시간 내에서 정의해 놓은 함수가 실행된다. 실행 후 VM은 종료된다.

이 같은 함수는 서버가 계속 대기하면서 사용자의 요청을 처리하는 것이 아닌, 이벤트가 있을 때마다 실행된다. 따라서 FaaS는 주요 서비스 사이에서 간단한 작업을 처리하는 용도로 사용되고, BaaS와도 연동돼 사용할 수 있다.

대표적인 FaaS는 ‘AWS 람다(Lambda)’로, AWS의 각종 서비스와 쉽게 연동이 가능하다. 예를 들어 사용자가 이미지를 업로드하면 해당 이미지를 해상도별로 처리해 ‘AWS S3’에 저장하는 로직을 함수로 구현할 수 있다. ‘AWS 람다’는 요청이 많으면 자동적으로 확장돼 서버에 대해 신경 쓸 필요가 없다.

FaaS 솔루션에는 마이크로소프트의 ‘애저 펑션(Azure Function)’, 구글 클라우드의 ‘구글 펑션(Google Function)’, NBP의 ‘클라우드 펑션(Cloud Function)’ 등이 있다.

다만 비용 지불 측면에서 FaaS와 BaaS는 방식이 다르다는 점을 유념해야 한다. FaaS는 함수 단위를 클라우드에 배포하고 이를 얼마나 사용하는지를 측정해 비용을 지불하는 방식이며, BaaS는 백엔드 서비스로 CSP가 제공하는 API를 얼마나 사용했는지를 측정해 비용을 지불하는 방식이다. 비용은 함수가 실행되는 시간과 호출된 회수만큼만 지불한다. 서버를 띄워놓았다면 요청이 없어도 비용을 지불하겠지만 람다는 요청이 없으면 비용도 지불하지 않는다.

오픈소스로 쿠버네티스와 연동 가능…인프라 고민 해소

서버리스는 컨테이너의 인프라를 관리하는 쿠버네티스에 대한 버전 업그레이드 및 유지보수 관리 측면에서 많은 기업들이 갖고 있는 고민을 해소시켜줄 수 있다. 서버리스는 서버가 개발자 입장에서 추상화되므로 인프라에 대한 고민을 할 필요가 없다는 장점이 있다. 여기에 쿠버네티스와의 결합으로 컨테이너 인프라에 대한 고민을 해소할 수 있다는 것도 이점이다.

먼저 서버리스가 컨테이너들을 관리할 수 있는 플랫폼으로 최근 IT 업계에서 각광받는 쿠버네티스에 구축될 시, 서버 또는 쿠버네티스 클러스터 분배와 하부 에코솔루션의 업데이트된 패치 적용, 운영체제 유지·관리, 리소스 분배 등과 같은 인프라 관리 작업을 덜 수 있다.

이러한 장점들로 인해 쿠버네티스는 서버리스 워크로드 및 마이크로서비스 애플리케이션 컨테이너를 관리하는 데 있어 상호 운영성을 얻을 수 있기 때문에 가장 선호되는 플랫폼이다.

쿠버네티스에 서버리스를 직접 구축·적용하기 위해서는 ▲케이네이티브(Knative) ▲피션(Fission) ▲쿠브리스(Kubeless) ▲아파치 오픈위스크(Apache OpenWhisk) 등 주요 프로젝트들을 활용해야 한다. ‘케이네이티브’는 구글이 쿠버네티스에서 서버리스 애플리케이션을 실행하기 위해 제작한 오픈소스 커뮤니티 프로젝트다. 서버리스 클라우드 네이티브 애플리케이션을 배포하고 실행, 관리하기 위해 쿠버네티스에 구성요소를 추가할 수 있다.

양승도 구글 클라우드 코리아 커스터머 엔지니어링 총괄은 “‘케이네이티브’는 쿠버네티스 내 서버리스 워크로드를 위한 기반 빌딩 블록을 제공한다”며 “쿠버네티스 상 어디에도 배포될 수 있는, 컨테이너에 기반한 최신의 클라우드 네이티브 애플리케이션을 생성할 수 있게 해준다”라고 설명했다. 이어 양 총괄은 “소스코드를 컨테이너에 구축하는 방식으로 접근 방식이 유연하며, 요청된 모델을 통해 컨테이너를 신속하게 배포하고 자동으로 확장해 온디맨드 기반 워크로드 처리가 가능하다”고 덧붙였다.

‘케이네이티브’로 활용할 수 있는 기능은 ▲비사용 시 리소스를 줄여 자원을 최적화하는 기능 ▲트래픽에 맞춘 자동 확장 기능 ▲쿠버네티스의 구성과 수정을 진행하는 기능 ▲인클러스터 이미지 빌딩 기능 ▲케이네이티브 기반 구축을 원활하게 해주는 트래픽 분배 ▲이벤트를 새롭게 만들거나 활용할 수 있는 기능 등 여섯 가지다.

양 총괄은 “구글 클라우드에서는 쿠버네티스를 기반으로 커뮤니티에서 개발된 개방형 가이드라인, 툴, 레퍼런스 세트를 제공하는 케이네이티브 서비스를 구축해 개방된 접근방식을 추구한다”며 “개발자는 처음부터 새롭게 개발을 시작할 필요 없이 기존 컨테이너를 사용할 수 있다”고 강조했다.

한편, 레드햇은 ‘케이네이티브’를 자사 ‘오픈시프트’ 플랫폼에 채택한 ‘오픈시프트 서버리스’로 멀티·하이브리드 클라우드를 지원하고 있다. 레드햇은 2018년 구글, SAP, IBM을 비롯한 여러 기업들과 하이브리드 서버리스 워크로드를 가져오기 위해 ‘케이네이티브’ 관련 협력을 체결한 바 있다. 당시 크리스 라이트(Chris Wright) 레드햇 부사장은 “‘케이네이티브’ 커뮤니티에 참여함으로써 엔터프라이즈 쿠버네티스와 오픈소스에 대한 전문성을 결합해 하이브리드 클라우드 전반과 쿠버네티스 상에서 서버리스를 위한 공통 빌딩 블록 생성을 지원할 것”이라고 말했다.

레드햇은 이러한 ‘케이네이티브’ 프로젝트를 기반으로 ‘레드햇 오픈시프트 서버리스’ 솔루션을 출시했다. ‘레드햇 오픈시프트 서버리스’는 하이브리드 클라우드와 멀티 클라우드 환경 전반에 클라우드 이식성과 일관성을 제공할 수 있는 서버리스 플랫폼이다. 또한, 오픈시프트 서비스 메시와 같은 오픈시프트 컨테이너 플랫폼 서비스, 클러스터 모니터링을 통해 애플리케이션을 통합하는 방식으로 서버리스 애플리케이션의 개발과 배포가 가능한 환경을 제공한다.

이러한 ‘레드햇 오픈시프트 서버리스’의 특징은 개발팀이 신속히 프로토타입을 만들고 새로운 콘셉트를 VM 또는 베어메탈보다 낮은 비용에 테스트할 수 있도록 지원한다는 점과 이를 통해 소프트웨어의 혁신을 가속화할 수 있다는 점이다.

‘케이네이티브’ 외에도 ‘피션(Fission)’이라는 쿠버네티스를 기반으로 하는 서버리스 컴퓨팅 프레임워크도 있다. ‘피션’은 관리형 쿠버네티스 회사인 ‘플랫폼9’가 개발하고 운영하는 프로젝트다. ‘피션’의 가장 큰 특징은 단순히 정의 파일만 가지고도 컨테이너를 구축할 필요 없이 FaaS 애플리케이션을 생성할 수 있다는 점이다.

또한, ‘피션’은 헬름(Helm) 차트를 포함하거나 포함하지 않고 설치가 가능하며, 두 가지 버전이 있다. 정식 버전은 로깅을 위한 메시지 큐 및 인플럭스DB를 지원하고, 약식 버전에서는 기본 함수만 제공한다. 주로 정식 버전은 실무 배치를, 약식 버전은 시험 운영에서 사용된다. 특히, ‘피션’은 함수 활동 역시 기록되고 재생될 수 있어 디버깅에 용이하며 아파치 라이선스를 통해 이용이 가능하고 필요할 때마다 자유롭게 개조할 수 있다.

세 번째로 ‘쿠브리스(Kubeless)’는 인스톨러의 개발자인 비트나미가 개발한 프로젝트로, 쿠버네티스의 네이티브 커스텀 리소스 정의를 이용해 함수를 처리한다. ‘쿠브리스’는 쿠버네티스의 중요 기능을 모두 활용하는 쿠버네티스 네이티브 서버리스 플랫폼이다.

특히, ‘쿠브리스’는 닷넷(.NET), 자바, 파이썬, 노드.js, PHP, 루비, 고, 그리고 심지어 클라우드 네이티브 개발을 위한 최신 발레리나 언어 등 다양한 언어를 지원한다. ‘쿠브리스’의 또 따른 유용한 기능은 바로 ‘AWS 람다’와 명령어 인터페이스(CLI)가 동일하다는 점이다. ‘AWS 람다’로부터 마이그레이션을 하지만 기존의 매니지먼트 스크립팅 유지를 원하는 경우 유용하게 사용이 가능하다. 이 외에도 ‘쿠브리스’는 새로운 명령 세트를 따로 배울 필요가 없으며, 서버리스 프레임워크의 플러그인 역할도 수행할 수 있다.

이 외에도 오픈소스로 제공되는 주요 서버리스 컴퓨팅 프로젝트인 ‘아파치 오픈위스크’는 스칼라(Scala)로 작성된 오픈소스 서버리스 클라우드 플랫폼이다. ‘아파치 오픈위스크’는 주로 HTTP 요청과 같은 트리거(DB, 장치 등에서 발생한 이벤트)에 반응해 자바 스크립트나 스위프트로 작성된 함수를 구동시킨다.

과도기 서버리스 아키텍처, “향후 대세 될 것”

“과거 서비스 아키텍처의 대부분이 모놀리식(Monolithic, 하나의 덩어리)으로 구성돼있었다면 지금은 마이크로서비스 아키텍처(MSA)를 지나 서버리스 아키텍처로 진행하고 있는 과도기 시점이다.”

최영락 마이크로소프트 애저 사업부 차장은 현재 클라우드 기반의 애플리케이션 개발 트렌드가 서버리스 아키텍처로 옮겨가고 있으며, 아직은 과도기라고 강조했다. 사실 과거 모놀리식 아키텍처에서는 전체 서비스, 즉 하나의 거대한 덩어리 형태를 기본단위로 설정했다. 반면, 최근에는 컨테이너 오케스트레이션(다수의 컨테이너를 조율하는 기능)이 중요해지며 점차 하나의 서비스를 구성하는 단위가 작은 서비스로 변화하고 있다.

즉, 점차 서비스 단위가 작아지고 있다는 뜻이다. 이러한 흐름에 따라 향후 서버리스 아키텍처가 주류로 자리를 잡을 것이라고 업계 관계자들은 주장하고 있다. 과거 모놀리식 아키텍처부터 서버리스 아키텍처까지 클라우드 서비스의 제공 방식과 관계가 있다.

모놀리식 아키텍처가 서버 가상화 수준에 적합했다면, MSA는 컨테이너 오케스트레이션에 적합하며 서버리스 아키텍처의 경우 컨테이너 오케스트레이션 수준보다 더 작은 단위의 함수 관리에 적합하다. MSA의 경우 전체의 비즈니스 로직이 여러 개의 마이크로서비스로 쪼개져 각 서비스가 저장계층에서 각각 데이터를 관리하는 구조다. 가령, 보안 서비스에 대한 데이터는 보안 서비스가 갖고 있고, 모니터링 서비스에 대한 데이터는 모니터링 서비스가 갖고 있다. 이를 통해 MSA가 모놀리식 구조보다 서비스를 작은 단위 수준으로 제공이 가능하다.

하지만 서버리스 아키텍처에서는 사용자가 작성한 코드가 API 게이트웨이를 통해 클라우드에서 제공되는 백엔드 서비스를 호출하고, 저장계층이 따로 존재하지 않는 대신 저장 기능 자체가 서비스로 제공되는 방식이다.

이렇듯 아키텍처의 발전 단계가 모놀리식에서 MSA로, 이제 막 서버리스 아키텍처로 넘어가고 있는 상황이다. 서버리스가 여전히 초창기 시장이라고는 하지만 클라우드 컴퓨팅의 다음 물결로 많은 업계 관계자들이 서버리스를 언급하고 있으며, 서버리스 아키텍처가 조직의 개발과 혁신을 일으킬 수 있다는 기대 또한 꾸준히 증가하고 있다.

서버리스 아키텍처는 현재 ▲기술 성숙도 ▲지속 실행 애플리케이션의 문제 등의 단점도 갖고 있다. 하지만 대형 CSP들이 서버리스 아키텍처 지원을 본격화하면서 기술적 성숙도를 높이고 있기 때문에 이러한 단점들도 점차 해소될 것으로 보인다.

기업별 서버리스 컴퓨팅 전략

서버리스 컴퓨팅 시장이 앞으로 더욱 확대될 것으로 예상되면서 대형 CSP들과 PaaS 업체들은 기존의 솔루션에 서버리스 아키텍처를 채택하거나 새롭게 서버리스 애플리케이션 및 플랫폼을 출시하며 국내 고객들의 서버리스 컴퓨팅 지원에 적극 나서고 있다. 이에 AWS, GCP, NBP, MS 등 각 기업별 서버리스 컴퓨팅 전략에 대해 정리해봤다.

 5가지 부문 서버리스 지원으로 고객 혁신 돕는다

AWS에서는 서버리스 애플리케이션을 구축하거나 실행하는 데 사용할 수 있는 완전 관리형 서비스를 제공하고 있다. AWS의 서버리스 애플리케이션은 고객들로 하여금 컴퓨팅, 데이터베이스(DB), 스토리지, 스트림 처리, 메시지 대기열 등의 백엔드 구성요소를 위한 서버를 준비하고, 개발자들이 유지·관리에는 신경 쓰지 않도록 만들어준다. 또한, 애플리케이션 결함성 및 가용성에 대해 고민할 필요 없이 AWS가 백엔드 구성요소부터 서비스까지 대신 처리해 고객이 제품 출시 기간과 혁신에 집중하도록 지원한다.

AWS는 서버리스 애플리케이션을 통해 ▲컴퓨팅 ▲DB ▲API 프록시 ▲분석 ▲개발자 도구 등 다섯 가지 부문을 지원한다. 컴퓨팅에서 지원하는 솔루션은 ‘AWS 람다(Lambda)’와 ‘람다 에지(Lambda Edge)’, ‘AWS 파게이트(Fargate)’ 등 세 가지다.

‘AWS 람다’는 고객이 서버를 프로비저닝하거나 관리할 필요 없이 코드를 실행할 수 있다. 또 사용한 컴퓨팅 시간만큼만 비용을 지불하고, 코드가 실행되지 않을 때에는 요금이 부과되지 않는다는 특징이 있다.

이 뿐만 아니라 ‘람다’와 ‘에지’를 결합한 ‘람다 에지’는 IoT에 서버리스를 결합한 솔루션으로, ‘아마존 클라우드 프론트’ 이벤트에 대한 응답으로 AWS 에지 로케이션에서 ‘람다’를 실행할 수 있다. ‘AWS 파게이트’는 컨테이너 전용으로 설계된 서버리스 컴퓨팅 엔진으로, 컨테이너 실행에 필요한 인프라를 조율하는 오케스트레이션 기능과 관리 기능을 수행할 수 있다.

DB도 AWS는 ‘아마존 오로라’에 서버리스를 결합한 ‘아마존 오로라 서버리스’라는 솔루션을 제공하고 있다. 마이SQL(MySQL)과 호환되는 ‘아마존 오로라’를 위한 온디맨드 오토스케일링 구성을 통해 DB를 자동으로 시작하거나 종료할 수 있고, 애플리케이션의 필요에 따라 용량을 늘리거나 줄일 수 있다.

AWS는 API 프록시도 서버리스로 지원하고 있다. 바로 ‘아마존 API 게이트웨이’라는 솔루션이다. ‘아마존 API 게이트웨이’는 규모에 상관없이 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보호할 수 있도록 지원하는, 즉 AWS가 모든 것을 관리해주는 관리형 서비스다. 이 서비스는 API 관리를 위한 포괄적인 플랫폼을 제공하고 있으며, API 게이트웨이를 통해 수십만 개의 동시 API 호출을 처리하고 이에 따른 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링 및 API 버전 관리 등도 처리할 수 있다.

AWS는 서버리스를 결합한 ‘아마존 키네시스(Kinesis)’로 분석 관련 서비스까지 지원한다. ‘아마존 키네시스(Kinesis)’는 AWS의 스트리밍 데이터를 위한 플랫폼으로, 스트리밍 데이터를 손쉽게 로드하고 분석할 수 있는 서비스를 제공한다. 특히, 특정 요구에 맞게 사용자 지정 스트리밍 데이터 애플리케이션을 구축할 수 있는 기능도 서비스한다.

또 다른 분석 관련 서버리스 솔루션인 ‘아마존 아테나(Athena)’는 표준 SQL을 사용해 아마존 S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스다. ‘아마존 아테나’는 서버리스 형태의 서비스로 제공되기 때문에 관리할 인프라가 없고 실행한 쿼리에 대해서만 비용을 지불하면 된다.

마지막으로 개발자 도구다. AWS는 개발자가 서버리스 애플리케이션 개발 전 과정에 사용할 수 있는 도구와 서비스를 제공하고 있다. AWS와 AWS 파트너 에코시스템을 통해 지속적 통합 및 전달(CI/CD), 테스트, 배포, 모니터링 및 진단, 소프트웨어 개발 키트(SDK), 프레임워크, 통합 개발 환경(IDE) 플러그인 등을 위한 개발자 도구를 제공한다.

[인터뷰] “고객을 최우선에 두고 불필요한 부분 해결하는 게 미션” 김일호 AWS 솔루션즈 아키텍트 매니저 Q. 서버리스 컴퓨팅 관련 AWS의 방향은. AWS는 고객이 원하는 방향과 비즈니스 요구 사항, 혁신하기 위한 부분이 무엇일까라는 데 초점을 맞춰 서버리스 컴퓨팅 부문 방향을 잡고 있다. 이에 고객들의 피드백을 바탕으로 서버리스 서비스를 개발하고 있다. 가령, 고객이 새로운 언어를 지원해달라고 요청을 한다면 AWS의 수많은 개발자들이 피드백을 적극 수용해 고객이 요구한 새로운 언어를 지원할 수 있도록 지원할 것이다. 특히, 서버리스를 중요하게 생각하는 이유가 바로 고객의 시간과 노력을 줄일 수 있는 하나의 아이템이 바로 서버리스이기 때문이다. AWS는 고객의 입장에서 새로운 아키텍처를 적용해 비즈니스의 혁신을 일구고 싶다는 고객의 니즈를 파악하면, 기존의 고객이 하던 일을 하지 않도록 만들어 주는 데 초점을 맞추고 있다. Q. 서버리스를 적용할 때의 고려사항은. AWS는 고객들에게 무조건 서버리스를 사용해야 한다고 말하지는 않는다. 서버리스 컴퓨팅을 반드시 사용해야 할 경우도 있지만 부적절한 경우도 물론 있다. 가령 코드가 직접 클라우드에서 실행되는 환경이라 호환성이 떨어질 가능성이 높은 경우에는 부적절하다. 특히, 오픈소스를 활용해 자체적으로 서버리스 컴퓨팅 환경을 구축할 수 있으나 구축 및 운영비용, 기술적 문제해결에 많은 자원이 소요되기에 자체적으로 구축하는 것이 바람직 하지만은 않다. 서버리스 컴퓨팅은 장시간 지속적으로 실행돼야하는 애플리케이션에도 적절하지 않다. 서버리스 컴퓨팅은 빨리 실행될 수 있는 작은 단위 작업에 적합하기 때문에 장시간 실행되는 애플리케이션에서 사용하는 것은 추천하지 않는다. Q. AWS의 서버리스 컴퓨팅 고객 사례는. CJ 올리브네트웍스와 아모레 퍼시픽이 대표적이다. CJ 올리브네트웍스는 방송 콘텐츠 내의 음원 사용을 관리하는 블록체인 기반의 디지털 저작권 시스템을 구축했다. 이 시스템은 ‘아마존 매니지드 블록체인’, ‘AWS 엘리멘탈 미디어컨버트’, ‘아마존 엘라스틱 컴퓨트 클라우드’, ‘아마존 다이나모DB’, ‘AWS 빈스토크’, ‘AWS 람다’, ‘AWS 코드스타’ 등을 도입해 운영되고 있다. 아모레퍼시픽은 MSA 아키텍처를 기반으로 3,000개의 오프라인과 온라인 스토어를 아우를 수 있는 기존 8개 플랫폼과 40개의 애플리케이션으로 구성된 세일즈 시스템을 AWS를 통해 개발했다. 그 결과 AWS로 초당 222,000개의 트랜잭션을 성공적으로 처리할 수 있는 플랫폼에서 대규모 온라인 마케팅 캠페인을 운용할 수 있게 됐다. 이를 위해 아모레퍼시픽은 ‘AWS EC2’, ‘AWS S3’, ‘AWS 아테나’, ‘AWS 코그니토’, ‘AWS 람다’, ‘AWS 다이나모DB’를 사용하고 있다. Q. AWS가 바라보는 서버리스 컴퓨팅의 미래는. 반드시 서버리스 컴퓨팅은 더더욱 사용이 늘어날 것이다. 디지털 트랜스포메이션이라는 거대한 트렌드가 있기 때문이다. 기존의 모놀리식 아키텍처에서 MSA로 진행하고 있고, 여기에 서버리스가 서서히 중심으로 자리를 잡아가고 있다. 이런 흐름에 따라 고객들은 비즈니스에서 서버리스 채택률을 높이고 서버리스 기능을 애플리케이션에 추가하고 있으며, 이는 고객의 비즈니스 가치 창출에 일조하게 될 것이다. 또한, 비즈니스를 확장할 때 지속적으로 사용하는 서비스의 구성요소가 서버리스 기반이 될 것이며, 비용과 자원 확장과 관련된 고민이 필요 없어지고 서버리스 환경은 더더욱 늘어날 것이다.

“3가지 서버리스 솔루션을 타 서비스와 결합해 제공할 것”

마이크로소프트(MS)는 2010년 2월 ‘윈도우 애저’라는 이름으로 클라우드 서비스를 론칭할 때부터 ‘SQL 애저’ 서비스를 포함하고 있었다. 즉, PaaS 시장 초반부터 데이터베이스와 같은 백엔드 클라우드 서비스를 염두에 두고 있었고 FaaS 또한 함께 지원해 나갈 계획을 갖고 있었다는 것이다.

2016년 MS ‘애저 펑션’의 프리뷰가 공개됐고, 같은 해 11월, ‘애저 펑션’이 정식 출시됐다. 이후 꾸준한 버전 업데이트로 2019년 4분기에는 닷넷 코어 3.1 및 노드 12를 기반으로 하는 ‘애저 펑션 3.0’이 출시됐다.

사실 MS의 ‘애저 펑션’은 닷넷(.NET)을 주로 지원했었는데, 최근 들어 닷넷코어(.NET Core)와 리눅스 개발환경부터 다양한 프로그래밍 언어를 지원하기 시작하면서 컨테이너 환경 확장을 위한 방향으로 지속적으로 개선하고 있다.

MS의 주요 서버리스 컴퓨팅 솔루션은 ▲‘애저 펑션’을 비롯해 ▲‘로직 앱스(Logic Apps)’ ▲‘이벤트 그리드(Event Grid)’ 등 세 가지다. 먼저 ‘이벤트 그리드’는 이벤트 중심으로 처리되는 애플리케이션 및 서버를 사용하지 않고 애플리케이션을 강화할 수 있다. ‘이벤트 그리드’가 IoT에 적용되는 경우 데이터가 IoT 게이트웨이로 전송됐다는 알림이 오고, 알림에 뒤이은 작업이 수행된다면 이전 작업 결과에 대해 새롭게 실행해야 할 작업을 알림으로 연이어 보낼 수 있다.

가령, IoT 센서가 부착된 기계의 온도가 40도 이상으로 올라가면 작업을 중단하라는 알림을 보내도록 설정한 후 알림에 따라 작업을 중단할 수 있다. 이후 다시금 온도가 30도로 내려갈 시 재가동하라는 알림을 연이어 보내는 작업을 수행하게 할 수 있다.

다음은 ‘로직 앱스’다. ‘로직 앱스’는 개발자들이 애플리케이션 구동을 설계할 때 순서를 정할 수 있도록 함수를 순서화 시키는 솔루션이다. 일반적으로 10줄의 순서가 정해진 코드를 인터넷 쇼핑에 적용시킨다면, 고객이 인터넷 쇼핑 사이트에 들어오면 첫 번째 코드 실행을 통해 먼저 관심 상품을 노출시키고, 그 다음 두 번째 코드를 실행해 이전에 열람했던 상품들을 다시금 노출시키는 등의 작업을 할 수 있다.

‘애저 펑션’은 서버리스 컴퓨팅으로 애플리케이션 개발을 가속화하고, 간소화가 가능한 MS의 대표 FaaS 솔루션이다. 복잡한 오케스트레이션 문제도 해결이 가능한 이벤트 기반의 서버리스 컴퓨팅 플랫폼으로, 개발자는 보다 개발의 효율성을 높인 상태에서 개발에만 온전히 집중할 수 있도록 지원한다. 또한, 별도의 추가 설정 없이 개발자 PC, 즉 로컬에서 코드를 빌드하고 디버그하며 클라우드에서 대규모로 배포, 운영할 수 있다. 이 외에도 트리거와 바인딩을 사용해 서비스를 통합할 수도 있다.

‘애저 펑션’의 가장 큰 특징은 오픈소스로 구성돼있다는 점이다. ‘깃허브.com/ms’에 ‘애저 펑션’에 대한 기능들이 오픈소스로 풀려있기 때문에 최근 역동적으로 바뀌고 있는 개발환경에 고객별 최적화가 가능하다.

최영락 MS 애저사업부 차장은 “MS의 서버리스 발전 방향은 다양한 언어를 지원할 수 있는 체계를 기반으로 ‘서버리스 컴퓨팅 솔루션 3가지를 결합해 지원하는 것”이라고 말했다.

[인터뷰]“다양한 프로그래밍 언어 지원…고객 비즈니스 가치 증진에 일조” 최영락 MS 애저사업부 차장 Q. MS의 서버리스 컴퓨팅 솔루션 발전 과정에 대해 소개해달라. MS의 대표적인 서버리스 컴퓨팅 FaaS 솔루션은 ‘애저 펑션’이다. ‘애저 펑션’은 2016년 3월에 처음 프리뷰가 공개됐고, 2016년 11월에 서비스가 정식 출시됐다. 이후 지속적으로 버전을 업데이트했고, 2018년 9월에 ‘애저 펑션 2.0’이 공개됐다. 2018년 11월에는 IoT 에지 디바이스에서 호스팅이 가능한 환경이 공개됐으며, 2019년 2월에는 자바를 지원하기 시작했다. 같은 해 7월에는 ‘컨숨션 플랜 포 리눅스(Consumption plan for Linux)’가 정식 출시되면서 리눅스도 지원하며, 쿠버네티스 기능이 추가됐다. Q. 서버리스 컴퓨팅을 전환 과정은. 보통은 서버리스 환경으로 이동하려면 아키텍처를 다시 짜야 한다. 개발자들의 입장에서 VM에서 원활히 구동되는 코드가 있는데 이를 굳이 아키텍처를 새로 짜는 공수를 들여가면서까지 서버리스로 전환해야할 필요는 없다. 일반적으로 코드를 간단히 개선해 클라우드 환경에 맞게 부분적으로 재구성하는 ‘리팩토링’이라는 작업을 수행해야 한다. 하지만 ‘리팩토링’이 아니라면 기존의 개발 코드를 새롭게 아키텍처링해 ‘애저 펑션’ 서버리스 환경에 맞게 다시 개발하는 ‘리아키텍처링’ 작업을 해야 한다. 고객 판단 하에 수행되기 때문에 고객의 과정에 적절하게 채택해 사용하는 것이 중요하다. Q. 서버리스로의 전환이 원활하지 않은 이유는. 아직은 과도기다. 서버리스로 전면 전환이 되지 않은 이유는 실제로 사용하는 기술 스택, 환경에 따라 서버리스 상황이 100% 맞지 않기 때문이다. 다른 이유는 개발자들이 갖는 부담감이다. 최근 인프라 기반 개발자와 플랫폼 경험 개발자들은 PaaS에서 제공되는 개발 프레임워크를 사용하고 있다. 하지만 경력이 있는 개발자들이 많아 서버리스로 전면 전환을 시행하기에 재교육에 대한 부담감을 기업과 개발자들이 갖게 된다. Q. MS의 서버리스 컴퓨팅 향후 비즈니스 전략은. A. MS는 오픈소스와 함께 발전하는 것을 골자로 비즈니스 전략을 세우고 있다. 이런 전략에 따라 MS의 ‘애저 펑션’도 오픈소스로 구성됐다. ‘애저 펑션’도 더 이상 닷넷만 지원하는 것이 아닌, 닷넷 코어 3.2를 포함해 노드12, 자바 스크립트 등 다양한 환경과 언어를 지원하고 있다.

“3가지 서버리스 전략으로 차별화 꾀한다”

구글 클라우드는 3가지 서버리스 전략으로 다른 서버리스 솔루션 제공 기업과의 차별화를 꾀하고 있다. 구글 클라우드는 ▲진정한 서버리스 컨테이너 서비스 제공 ▲쿠버네티스에 구축된 케이네이티브로 이동성 구현 ▲DB, 분석, 스토리지 등 포괄적 서비스 제공하는 엔드투엔드(end-to-end) 애플리케이션 구축 등을 전략으로 내세우고 있다.

먼저 구글 클라우드는 진정한 서버리스 컨테이너 서비스를 제공한다는 목표를 갖고 있다. ‘클라우드 런’과 같은 구글의 컨테이너 기반 접근법은 다른 클라우드 기업들과는 다른 방식으로, 이는 개발자들이 그들만의 워크로드를 완전 관리형 플랫폼 내에 운영하고 트래픽에 따라 오토스케일링할 수 있게 지원해준다.

두 번째 구글 클라우드의 전략은 쿠버네티스에 구축된 ‘케이네이티브’를 통해 서버리스 워크로드의 진정한 이동성을 구현한다는 것이다. 구글 클라우드, 온프레미스, 타사 데이터센터 등 원하는 어디로든 워크로드를 옮길 수 있다. ‘케이네이티브’는 서버리스 클라우드 네이티브 애플리케이션을 배포하고 실행, 관리하기 위해 쿠버네티스에 구성요소를 추가할 수 있는 오픈소스 프로젝트다.

세 번째 구글 클라우드의 전략은 DB, 분석, 스토리지 등의 포괄적 서비스를 제공하는 엔드투엔드 애플리케이션을 구축하는 것이다. DB, 분석, 스토리지, 메시징 등의 백엔드 서비스가 서버리스를 활용하기를 원하는 고객들에게 필요하다는 점을 인식해 모든 백엔드 서비스를 완전 관리형으로 제공한다는 계획이다.

이러한 비즈니스 전략을 뒷받침하기 위해 구글 클라우드는 ▲컴퓨팅 ▲DB 및 스토리지 ▲데이터 웨어하우스 및 분석 ▲메시징 ▲머신러닝 ▲스마트 어시스턴트 및 챗봇 ▲데브옵스 등 영역에서 서버리스 솔루션을 제공하고 있다.

[인터뷰] “멀티·하이브리드 클라우드 가능한 서버리스 전략 펼친다” 양승도 구글 클라우드 코리아 커스터머 엔지니어링 총괄 Q. 구글 클라우드가 서버리스 컴퓨팅을 지원하는 방법은. 서버리스 컴퓨팅은 최근 VM 및 컨테이너 기술의 향상과 도입에 따라 자연스럽게 발전했다. 개발자는 특정 플랫폼 생태계만을 사용하기 보다는 작업을 수행하는 데 가장 적합한 툴을 사용하기 때문에 멀티 클라우드나 하이브리드 전략을 선호한다. 구글 클라우드는 쿠버네티스를 기반으로 커뮤니티에서 개발된 개방형 가이드라인, 툴, 레퍼런스 세트를 제공하는 ‘케이네이티브’를 구축해 개방된 접근 방식을 추구한다. 이를 통해 모든 플랫폼에서 일관된 경험을 제공하고 워크로드를 이동시킬 수 있도록 지원한다. 또한, 구글 클라우드는 지난해 11월 ‘클라우드 런(Cloud Run)’ GA 버전을 포함해 여러 솔루션을 출시했다. ‘클라우드 런’은 개발자가 기업의 클라우드 트랜스포메이션 과정의 어느 단계에서든 코드를 작성하는 데 주력할 수 있도록 지원한다. 이는 완전 관리형 서버리스 실행 환경으로, 인프라에 대한 걱정 없이 HTTP 기반 컨테이너를 실행할 수 있다. 구글 클라우드는 또한 앤토스(Anthos)용 ‘클라우드 런’을 출시해 온프레미스나 구글 클라우드에서 실행되는 ‘앤토스 GKE(구글 쿠버네티스 엔진)’ 클러스터에 ‘클라우드 런’ 애플리케이션을 배포할 수 있도록 지원한다. 그렇기에 멀티·하이브리드 클라우드 작업을 수행할 수 있다. Q. 서버리스 컴퓨팅의 단점은 무엇이라고 보는지. 기존의 많은 서버리스 솔루션은 확장성과 비용 절감 혜택을 제공하지만 제한된 운영시간이나 벤더 종속과 같은 복잡성이 추가될 수 있다. 이런 이유로 개발자는 서버리스 컴퓨팅의 용이성과 속도, 컨테이너의 유연성과 휴대성 사이에서 균형점을 찾는 데 어려움을 겪는다. 이 외에도 서버리스 플랫폼이 빠르게 도입되면서 플랫폼 내 동작이 파편화돼 멀티 클라우드나 하이브리드 클라우드 구축에 어려움이 발생하고 있다. 구글 클라우드는 이러한 문제를 해결하기 위해 쿠버네티스와 이스티오를 기반으로 ‘케이네이티브’를 구축해 개방된 접근 방식을 추구한다. 개발자들은 이를 통해 클라우드 공급자들과 동일한 API와 컨테이너 계약을 체결해 CSP나 온프레미스 인프라 간 워크로드를 보다 쉽고 안정적으로 실행하거나 이동시킬 수 있다. Q. 향후 서버리스 컴퓨팅의 전망은. 원하는 방식으로 코드를 작성할 수 있게 될 것이며, 연결성이 크게 증가할 것이라고 보고 있다. 점차 고도화되고 있는 서버리스는 민첩성과 경제성 측면에서 이점이 증가할 것이다. 동시에 선호하는 언어, 도구들을 원하는 만큼, 원하는 대로 사용할 수 있게 될 것이다. 또한 서버리스 플랫폼과 다른 서비스들도 연결될 것이다. 구글 클라우드는 서버리스 플랫폼을 타사 서비스, 혹은 G 스위트, 구글 애널리틱스, 구글 어시스턴스, 파이어베이스, 기타 GCP 서비스 등 주요 구글 서비스를 연결하는 가교역할을 수행하며 연결성 확장에 집중하고 있다.

“‘클라우드 펑션’ 솔루션 간 연동 확대해 데브옵스 환경 제공할 것”

네이버 비즈니스 플랫폼(NBP)은 국내 클라우드 제공사 가운데 유일하게 서버리스 컴퓨팅 솔루션을 서비스하고 있는 기업이다. NBP의 ‘클라우드 펑션(Cloud Functions)’이라는 FaaS 솔루션은 자바스크립트, 자바, 파이썬, 닷넷, 고 등 다양한 개발언어를 지원해 고객이 익숙한 언어로 코드를 작성할 수 있다. 다른 기업의 FaaS 솔루션과 마찬가지로 이벤트 방식으로 구동이 가능해 서버 비용도 최소화 할 수 있다.

NBP의 서버리스 컴퓨팅 부문 전략은 ‘클라우드 펑션’의 상품 간 연동을 확대해 고객이 인프라에 대한 고민 없이 코드 및 애플리케이션 개발에만 집중할 수 있는 데브옵스 환경을 제공하도록 지속적으로 개선하는 데 무게를 두고 있다.

NBP가 이러한 전략을 수립한 이유는 최근 고객들이 리프트&시프트(Lift&Shift) 방식의 단순한 클라우드 전환이 아닌 클라우드 네이티브 환경으로 변화하고 싶어 함에 따라, 클라우드 네이티브 환경에서 빠른 실행 및 배포가 가능한 컨테이너 기술과 함께 서버리스 컴퓨팅 솔루션의 활용이 증가될 것으로 예상되기 때문이다. 이에 국내 토종 클라우드 사업자로서 서버리스 컴퓨팅 솔루션인 ‘클라우드 펑션’과 API 게이트웨이, DB, 오브젝트 스토리지, 클라우드 로그 분석 등을 서버리스 서비스로 제공하고 있다.

NBP의 고객은 엔터프라이즈부터 개인 고객까지 다양하며, 각 고객이 사용하는 코드는 현재 세 가지 형태의 트리거를 제공하고 있다. 아울러 NBP는 고객이 가장 많이 물어보는 항목으로 서버 시작/정지, 오브젝트 스토리지 연동 등 자원관리 영역과 무상태(Stateless) 방식의 웹 서비스 구현 등 고객들이 가장 많이 물어보는 서버리스에 대해 3가지 형태의 트리거를 활용해 코드를 실행하도록 지원하고 있다.