Serverless 아키텍처와 FaaS

Cloud Paradigm

1. 클라우드 서비스 패러다임

1-1. 기존의 관리방식 (Traditional On-Premise)

인터넷이나 인트라넷 환경의 사용자에게 웹 서비스를 제공하기 위해서는 해당 웹 서비스가 구동되기 위한 물리적인 서버가 필요하다. 기존에는 이 물리 서버를 전산실이나 데이터 센터 등의 공간에 두고 전담인력이 직접 관리하였다. 서버에 대한 관리 뿐만 아니라, 물리 서버가 사용하는 스토리지와 서버 간의 통신을 위한 네트워크에 대한 기술적인 관리 또한 웹 서비스를 제공하는 측에서 관리 하였다. 

서비스의 규모가 커지고 범위가 늘어나게 되면서, 물리 서버를 계속 확장하는 기존 방식의 개선이 필요했다. 물리 서버의 경우 서비스의 규모가 커질 때 서버 또한 추가로 구매를 해야 하는데, 이후 여러가지 이유로 서비스의 사용량이 줄어들 경우 오히려, 추가 구매한 서버가 유휴자산이 되어버리는 비용적 손실도 발생했다. 

이러한 배경으로, 클라우드 서비스가 사용되기 시작했다. 클라우드 서비스 공급자(Cloud Service Provider, 이하 CSP) 들은 대규모 데이터 센터를 구축하고 그 안에 BM(Barematal 장비. 물리 서버를 지칭) 들을 구성한 후에 서버 / 네트워크 / 스토리지 등의 물리 자원들을 사용자에게 제공하였다.

이에 사용자는 직접 서버를 관리하지 않고 CSP에게 물리적 인프라 자원들을 요청하고 '자원을 사용한 만큼만' 비용을 지불하는 식으로 서버를 운영할 수 있었다.

1-2. IaaS

IaaS(Infrastructure as a Service) 라고 불리는 이 클라우드 서비스 방식은, 자원 관리에 대한 영역 중 물리 서버(Hardware)와 스토리지, 네트워크에 대한 구성 및 관리를 CSP 가 수행하고, 사용자는 그 이외의 미들웨어, 런타임, 데이터 로직 등에 집중할 수 있는 방식이다. IaaS 방식에서 사용자는 리눅스/윈도우 등의 OS 를 선택할 수 있으며, OS에 대한 최초 구성 또한 CSP에서 담당한다.

IaaS 클라우드 서비스

AWS 의 EC2 인스턴스, GCP 의 Compute Engine 등이 이에 해당하며, 서비스 운영자는 전력 관리 등 물리 서버를 관리할 때 고려해야 하는 요소들을 신경쓰지 않고 서비스 운영에만 집중할 수 있다.

1-3. PaaS

서비스를 개발하고 운영하기 위한 관점에서는 인프라적인 요소 뿐 아니라, 인프라 위에 구성되는 개발 플랫폼에 대한 고려도 필요하다. PaaS(Platform as a Service) 는 이 플랫폼에 대한 부분까지 클라우드의 영역에서 지원해주는 서비스 방식으로, 사용자는 데이터의 처리와 어플리케이션 및 해당 도메인 기반의 로직에만 집중할 수 있다. 

널리 알려진 서비스로 MS Azure, Redhat Openshift 등이 있다. 이러한 CSP에서는 GUI 환경을 제공하여 사용자가 상품 콘솔로 로그인하여, 어플리케이션을 배포하고 테스트 할 수 있다.

1-4. SaaS

어플리케이션 로직 개발을 포함한 모든 영역을 CSP에 위임하는 방식도 있다. SaaS(Software as a Service) 방식으로, 이 방식에서 사용자는, 사용자가 이용하는 어플리케이션의 인프라적인 요소나, 배포 관리 등을 위한 플랫폼 적인 요소를 포함하여 어플리케이션의 선정, 데이터의 관리에 대한 모든 부분에 관여하지 않고 어플리케이션을 활용할 수 있다.

이미 완성된 어플리케이션을 사용자가 바로 사용할 수 있으므로, 비용/시간 등을 절약할 수 있으며 어플리케이션에 대한 업데이트 또한 사용자가 수행할 필요가 없으므로, 사용자는 업데이트 내용을 확인만 하고 서비스를 이용하면 된다. 사용량 증가에 따른 서버 확장, 전력 관리 등의 요소 또한 CSP 측에서 모두 수행해주므로 사용자가 고려할 필요가 전혀 없다. 

잘 알려진 예로는 Google 지메일, 네이버 클라우드, 슬랙(Slack) 등이 있다.

---

2. 서버리스(Serverless)

이렇게 전통의 관리 방식의 구조적 한계를 개선하기 위해, IaaS / PaaS / SaaS 형태의 클라우드 서비스가 널리 활용되었다. 최근에는 또 다른 방식으로 Serverless 개념에 관한 상품들도 다양하게 이용되고 있다.

서버리스(Serverless) 는 'Server + -less' 라는 단어의 의미와 같이, 직역 하면 '서버가 없다' 라는 뜻이다. 물론 실제로 어플리케이션을 실행할 서버가 없다는 의미는 아니며, 사용자가 어플리케이션(도메인 로직에 해당하는 코드)을 실행할 때에만 서버가 구동이 되어 서버를 준비조차 할 필요가 없다는 의미가 된다. 기존 PaaS 방식의 경우 사용자가 어플리케이션과 데이터를 관리해야 했고, SaaS 방식의 경우 Domain Logic 을 사용자가 수정할 수 없었다. Serverless 상품은, 2가지 방식의 중간 계층에서 적절하게 Domain Logic만 사용자가 직접 수행하고, 어플리케이션의 실행과 관련된 처리를 CSP에 일임하는 방식인 셈이다.

2-1. 서버리스 아키텍처의 특징 (장단점)

이렇게 사용자가 함수를 호출할 때에만 서버가 구동이 되어 함수가 실행되는 서버리스 방식은, 그 구성 때문에 장단점이 명확하다. 표로 정리하면 다음과 같다.

장점	- 필요한 시점에 사용 횟수, 작업량에 따라 과금이 되어 비용이 절약  - 인프라 관리(네트워크 / 장비 / 보안 취약점) 에 대한 부분을 고려 X  - 높은 확장성 : Autoscaling 등의 상품으로 트래픽 분산할 필요 없이    ▶ 단순히 다량의 함수를 호출하여 확장  - 다양한 프로그래밍 언어(런타임)로 함수 작성 가능
단점	- 단일 함수의 비용이 높아 단기적 프로세스, 단기 작업에 적합  - 콜드 스타드(Cold start, 컨테이너 로딩의 대기 시간) 존재  - 함수에서 사용할 수 있는 자원의 제한이 존재    ▶ 예-AWS) 함수 당 최대 1500MB 의 메모리, 최대 300초의 처리 시간    ▶ 웹 소켓과 같은 상시 구동 서비스는 사용 불가 (처리 시간이 존재)  - 상태가 없어(stateless) 처리 결과에 대한 별도 저장 필요

(콜드 스타트에 대한 자세한 개념은 별도의 포스팅을 참조)

---

3. FaaS 와 BaaS

서버리스는 보통 '서버리스 컴퓨팅' 또는 '서버리스 아키텍처'로 불리며, 서버리스의 개념은 어플리케이션 관점에서 BaaS와 FaaS로 나누어 살펴보면 이해하기 쉽다.

FaaS(Functions as a Service)는, 사용자가 어플리케이션의 실행 코드를 하나의 함수로 직접 작성하고, 이를 실행할 때마다 서버의 자원을 할당받아 실행하는 방식이다. 대부분의 로직을 사용자가 직접 작성하므로, 후술할 BaaS 방식에 비해 제어의 범위가 넓은 편이며, 알려진 예로는 AWS Lambda, GCP Functions, Azure Functions 등의 상품이 있다.

BaaS(Backend as a Service)는, 어플리케이션 개발 시 필요한 로그인 / 데이터 관리 / 회원 관리와 같은 기능을 클라우드 공급자가 제공하는 서비스를 이용하여 구현하는 것을 말하며, 서비스형 서버리스로도 불린다. 어플리케이션에서 당연히 요구되지만 구현하기 번거로운 데이터 저장소 / 파일 저장소 / SNS 연동 / 위치 정보 검색 / Push 알림 등의 기능을 API 방식으로 제공하기에 어플리케이션 내부에서 기능을 호출하여 사용 가능하다. 알려진 예로는, Google FireBase / Kinvey /  Sendbird / Auth0(클라우드 인증 서비스) 등이 있다.

정리하면 위 그림과 같이 표현할 수 있다. 클라우드 환경에서 미리 지정한 트리거 등에 의해 FaaS (서비스) 가 동작하게 되고, 이 서비스는 필요할 경우 Backend 에 이미 구현되어 있는 알림, 연동 등의 서비스를 사용하기 위해 BaaS (서비스) 를 호출하게 된다. 필요한 경우에만 어플리케이션이 동작하기 위해 Serverlesss 서비스는 이와 같이 FaaS, BaaS (서비스) 를 이용한다.

---

4. Functions Service

위 FaaS, Functions as a Service 에 대하여 조금 더 살펴보자. 여기서는 실제 구동된 함수와 구분하기 위하여 사용자가 콘솔에서 만든 함수를 함수 템플릿이라고 정리한다.

• 함수 템플릿 : 사용자가 만든 함수. 소스 코드 등을 포함하며, 함수 구동에 대한 정보를 저장
• 함수 : 사용자의 요청이나 트리거 등에 의해 실제 생성된 함수(어플리케이션 프로그램)

위에서 설명한 내용처럼, 사용자가 함수 템플릿을 생성하고 어플리케이션 소스 코드를 작성한 이후에도 함수는 바로 생성되지 않는다. 함수는, 사용자가 함수 템플릿을 생성한 시점이 아닌, 호출하는 시점에 (함수가) 생성이 시작된다.

이 때 실제 함수가 생성되기 전에, 함수를 생성할 플랫폼인 컨테이너나 가상 머신 또한 구동이 필요하다. 그래서 최초에 함수 템플릿으로부터 함수를 호출할 경우, 초기 구동 시간이 필요하게 되는데, 이런 현상을 콜드 스타트(Cold Start) 라고 하며, 그 시간을 콜드 스타트 타임이라고 한다. 

최초 호출로 인해 만들어진 함수는 일정 시간 동안 유지되며, 이 시간 동안 다시 사용자가 함수를 호출할 경우에는 별도의 인프라적인 구동 시간이 필요하지 않으므로 바로 함수가 호출 된다. 이러한 호출 응답은 콜드 스타트와 비교 되어 웜 스타트(Warm Start), 웜 스타트 타임이라고 표현한다.

마지막으로 일정 시간 이상 함수가 재 호출 되지 않을 경우, 자원의 절감을 위하여 함수는 삭제 된다. 이러한 현상 혹은 기능을 'Scale to Zero' 라고 하며, 함수를 삭제하기 위하여 대기하는 시간 자체는 'Scale to Zero Time' 이라고 표현한다.

FaaS 를 구현하기 위하여 많은 오픈소스들이 개발 및 관리 되고 있다. Scale to Zero 기능은 FaaS 서비스의 주요 기능 중 하나로 이런 오픈소스들에 의하여 어플리케이션 레벨에서도 지원되고 있다.