서버리스(Serverless)

1. 클라우드 서비스의 진화

On-Premise에서 Cloud까지

 

클라우드 시대가 도래하기 전에는 On-Premise 방식을 통해 전산실에 서버를 직접 설치해 운영하는 방식이었다. 하지만 기업들의 환경이 클라우드 기반으로 바뀌면서 시스템 확장의 신속성과 운영 효율이 높아졌다. 클라우드 서비스는 인프라를 제공하는 IaaS(Infrastructure as a Service)부터 다양한 플랫폼이 구비된 PaaS(Platform as a Service)까지 갖추며 구체화 되었다. 기업들은 클라우드 서비스를 활용해 SaaS(Software as a Service)어플리케이션을 만들어 고객에게 제공할 수 있게 되었는데, SaaS 어플리케이션을 보다 효율적으로 구축하고 운영할 수 있도록 돕는 서버리스 아키텍처가 출현하면서 많은 서비스들이 서버리스로 옮겨지는 추세를 보이고 있다.

 

2. 서버리스?

서버리스는 말 그대로 'Server+Less'로 '서버가 필요없다'는 의미지만 실제로는 그렇지 않다. 쉽게 말해 우리가 서버에 관련하여 신경을 쓸 필요가 없어지게 된다 정도의 의미로 보면 된다. 즉, 클라우드 서비스 공급자가 서버를 관리하고 실행하며 요청이나 특정 이벤트가 있을 때마다 클라우드 서버를 이용하거나 서비스 할 어플리케이션을 동작시키는 것이다. 이를 통해(개발자or사용자)는 서버 관리에서 자유로워지며 실제 구현해야 할 기능에 더 집중할 수 있게 된다. 서버리스는 보통 '서버리스 컴퓨팅' 또는 '서버리스 아키텍처'로 불리며, 서버리스의 개념은 어플리케이션 관점에서 BaaS(Backend as a Service)와 FaaS(Function as a Service)로 나누어진다.

Serverless - Event Driven Architecture

BaaS는 단일 웹페이지나 모바일 앱 기반의 서비스에서 필요한 서버 기능들을 사용하기 위해 이용되는 *서드파티 어플리케이션(Third Party Application)이나 클라우드 서비스를 말한다. 쉽게 말해 어플리케이션 개발 시 요구되는 복잡한 백엔드 기능들을 사용자(개발자)가 직접 개발하지 않고 클라우드 공급자가 제공하는 서비스를 이용해 쉽고 안정적으로 구현하는 것이다. 주된 사용 대상이 모바일과 웹 앱이다 보니 MBaaS(Mobile Backend as a Service)라 불리는 시장이 활성화 되는 추세다. 클라우드 데이터베이스 서비스인 Firebase나 클라우드 인증 서비스인 Auth)가BaaS에 해당한다.

 

이처럼 BaaS가 클라우드 서비스 공급자가 제공하는 서버 기능을 단순하게 이용한다면 FaaS는 사용자가 사용할 기능을 함수 단위로 나누어 구현하고 이를 서비스하는 형태다. FaaS는 Event Driven 아키텍처를 구현하는데 적합하며 사용자가 원하는 기능을 미리 작성해놓고 특정 이벤트(예를 들어 HTTP Request, API호출, 특정 조건 등)에 의해 실행된다. 이때 서버는 계속 대기하며 이벤트를 기다리는 것이 아니라 이벤트가 발생할 때마다 실행된다. 비용은 서버가 실행된 횟수와 시간(m/s: 1000분의 1초)에 따라 산정된다. FaaS를 구현한 대표적인 서비스로 AWS Lambda, Microsoft의 Azure Functions, Google의 Google cloud Function 등이 있다.

 

3. 장점과 고려사항

대형 클라우드 벤더가 서버리스를 출시한 이후, 기존 서비스를 서버리스(FaaS)로 이전하는 사례가 늘고 있다. 기업들이 서버리스를 선택하는 이유는 무엇일까?

 

첫째, 운영 비용 절감 효과를 기대할 수 있다. laaS나 PaaS와 같이 상시 운영 중인 서버와 달리 요청에 따라 호출되어 처리되기 때문에 유휴 자원이 발생하지 않는다. 예로 코카콜라의 비용 절감 사례가 그 예다.

둘째, 서버리스는 기존 클라우드 서비스보다 더 유연한 확장성을 제공한다. FaaS의 경우 일반적인 클라우드 서비스와 같이 특정 조건(예를 들어 CPU, RAM의 임계치 도달)과 같은 특정 조건에 따라 확장되는 방식이 아닌, 호출될 때마다 새로운 인스턴스가 가동되어 동작하기 때문에 특정 조건을 설정하지 않아도 급격한 트래픽 변화에 유연하게 대응 가능하다.

셋째, 기능이 함수 단위로 개발되기 때문에 서비스를 빠르고 간단하게 출시할 수 있다.

 

하지만 서버리스로 전환하기에 앞서 다음의 제약사항은 반드시 확인이 필요하다.

 

첫째, 빠른 응답이 필요한 제품의 경우 서버리스로의 전환은 부적합할 수 있다. 이는 실행되는 함수가 호출되기 위해 컨테이너가 실행되는 대기 시간(Cold Start)가 존재하기 때문이다. 이는 서버가 항시 가동되고 있지 않는 서버리스의 특징에 기인한다.

둘째, 무상태(Stateless)적인 기능으로 구현되어야 한다. 하나의 작은 기능으로 나뉘어진 함수들은 요청마다 새로 기동되어 호출되기 때문에 전후 상태를 공유할 수 없다. 또한 변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없다. 이는 서버리스 벤더에 따라 추가 서비스를 통해 극복 가능하지만, AWS S3, Azure Storage등 일반적인 서버리스는 불가능하다.

셋째, 서버리스 서비스 벤더가 제한을 두는 사항은 그대로 수용해야 한다. 함수 내에서 사용할 수 있는 최대 메모리, 최대 처리 가능 시간 등의 제약이 그것이다. 이에 따라 큰 기능을 잘게 나누어 구현해야 한다. 이를 준수하지 않고서는 서버리스로 이전할 수 없다.

 

4. 사용사례

서버리스는 저렴한 비용으로 새로운 아이디어를 빠르게 테스트할 수 있는 장점이 있으며, 여러 서비스에 적용 가능하다. 서버리스가 적합한 기능으로는 배치 및 자동화 서비스를 들 수 있다. 배치 작업의 경우 24시간 운영되던 서버가 필요 없게 되고, 특정 시간에 수행되던 기능을 서버리스로 옮기는 것만으로도 손쉽게 변경할 수 있다.

이와 비슷한 맥락으로 자동화 작업도 적용이 가능하다. 넷플릭스는 동영상 업로드 시 파일의 인코딩과 검증, 태깅 이후에 공개되는 작업을 AWS Lambda를 통해 자동화 했다. 실시간 비디오 스트리밍 앱 개발사인 페리스코프(Periscope)도 동영상 유해성 여부 확인 기능을 Lambda에서 운영하고 있다.

분석과 모니터링 기능에도 서버리스가 적합하다. 예를 들면 CPU 사용량이 임계치에 도달했을 떄 알림을 받거나 지속적으로 기록되는 로그를 분석하고 리포팅 하는데 사용할 수 있다. 미국 온라인 패션 매거진 버슬(Bustle)은 하루 1억건의 이벤트 처리와 데이터 분석 리포팅에 서버리스를 적용해 84%의 비용을 절감했다.

마지막으로 챗봇(Chat-Bot) 서비스에 서버리스를 적용하면 API 호출 시 요청을 처리하고 유연한 확장이 가능해 많은 사용자에게 안정적인 서비스를 제공할 수 있다. 슬랙(Slack)을 기반으로 하는 챗봇 어플리케이션이나 Amazon Echo 그리고 AWS Lambda를 이용한 음성인식 어플리케이션이 늘어나고 있다.

 

5. 클라우드 패러다임의 전환점

IaaS부터 PaaS 그리고 현재의 서버리스에 이르기까지 컴퓨팅 자원의 효율적인 사용이라는 클라우드 서비스의 발전 목표는 기업의 요구사항에 한층 더 가까워졌다. AWS가 Lambda를 발표한 이후 마이크로소프트의 Azure Functions, 구글의 Google Cloud Functions 등 대형 벤더들이 서비스를 출시하면서 경쟁은 더욱 치열해지고 있다. 서버리스 시장 선점을 위한 대형 회사들의 적극적인 행보는 이미 클라우드의 패러다임이 전환되고 있음을 암시하고 있다.

주요 Serverless 서비스

클라우드 서비스 시장에서 서버리스는 값싸고 빠르게 아이디어를 테스트하고 구현할 수 있는 환경을 제공한다. 물론 PaaS는 여전히 매력적인 서비스이고 서버리스가 가진 제약을 수용할 수 없는 경우에 좋은 대안이 될 수 있습니다. 그럼에도 불구하고 서버리스는 복잡한 기능을 간결화 할 수 있고, 보다 민첩한 서비스를 구현할 수 있을 뿐 아니라, 운영 비용의 절감 효과까지 얻을 수 있기에 관심을 가지고 검토해 볼만한 가치가 있다.

---

*서드파티 어플리케이션(Third Party Application): 제조사에서 만든 기본 탑재 앱이 아닌 일반 앱스토어에서 다운 받을 수 있는 앱. 누구든 만들 수 있어 퍼스트 파티 앱(First Party Application: 제조사 앱)이나 세컨드 파티 앱(Second Party Application: 통신사 앱)에 비해 종류가 다양하다는 특징이 있다.