서버리스(Serverless)

개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델이다.
클라우드 컴퓨팅을 통해 서버 구축 기간과 비용, 관리 및 유지보수의 비용을 줄이는 방법이다.

말 그대로 ‘서버(Server)가 없다(-less)’는 뜻으로 애플리케이션의 확장을 관리할 필요가 없는 클라우드 컴퓨팅 모델을 가리킨다.

실제로 서버가 없는 구조는 아니다.
서버리스 모델에도 서버가 존재하긴 하지만, 애플리케이션 개발에서와 달리 추상화되어 있다.
서버에서 처리하는 작업을 클라우드 기반의 서비스로 처리해서 서버 구축 및 관리 비용을 줄이는 구조다.
따라서 개발 기간과 비용을 단축할 수 있을 뿐 아니라, 서버 운영과 유지 보수의 어려움을 크게 줄일 수 있다.

클라우드 제공업체가 서버 인프라에 대한 프로비저닝, 유지 관리, 스케일링 등의 일상적인 작업을 처리하며, 개발자는 배포를 위해 코드를 컨테이너에 패키징하기만 하면 된다.

서버리스 애플리케이션은 배포되고 나면 필요에 따라 자동으로 스케일 업되거나 스케일 다운된다.

퍼블릭 클라우드 제공업체의 서버리스 오퍼링은 일반적으로 이벤트 기반 실행 모델을 통해 온디맨드로 미터링된다.
그러므로 서버리스 기능이 유휴 상태일 때는 아무런 비용도 들지 않는다.

서버리스 아키텍처 개요

서버리스는 클라우드 제공업체가 클라우드 인프라와 애플리케이션의 스케일링을 모두 관리한다는 점에서 다른 클라우드 컴퓨팅 모델과 차이가 있다.
서버리스 애플리케이션은 호출 시 온디맨드로 자동 시작되는 컨테이너에 배포된다.

표준 서비스로서의 인프라(Infrastructure-as-a-Service, IaaS) 클라우드 컴퓨팅 모델에서 사용자는 용량 단위를 사전 구매한다.
애플리케이션을 실행하기 위해 '상시 가용할 수 있는' 서버 구성 요소에 대한 비용을 지불하는 것이다.

즉, 애플리케이션을 구동하기 위해 퍼블릭 클라우드 공급업체에 상시 가동 중인 서버 구성 요소에 대한 비용을 지불해야 한다.
수요가 많을 때 서버 용량을 스케일 업하고 더 이상 그만큼의 용량이 필요하지 않을 때 스케일 다운하는 것 역시 사용자의 책임이다.
애플리케이션을 구동하기 위해 필요한 클라우드 인프라는 애플리케이션이 사용되지 않을 때에도 활성화된 상태다.

그에 반해 서버리스 아키텍처에서는 애플리케이션이 필요할 경우에만 시작된다.
이벤트가 구동을 위한 애플리케이션 코드를 트리거하면 퍼블릭 클라우드 공급업체가 신속하게 해당 코드에 대한 리소스(서버 자원)를 동적으로 할당한다.
코드 실행이 종료되면 비용도 청구되지 않는다.

비용과 효율성이라는 이점 이외에도, 서버리스는 애플리케이션 스케일링 및 서버 프로비저닝과 같은 일상적이고 사소한 태스크에서 개발자의 부담을 덜어준다.

서버리스를 활용하면 운영 체제 및 파일 시스템 관리, 보안 패치, 부하 분산, 용량 관리, 스케일링, 로깅, 모니터링과 같은 일상적인 태스크를 모두 클라우드 서비스 제공업체에 이관할 수 있다.

완전한 서버리스 애플리케이션은 물론, 일부는 서버리스로 일부는 전통적인 마이크로서비스 구성 요소로 이루어진 애플리케이션을 구축할 수도 있다.

클라우드 제공업체의 역할

서버리스 모델에서 클라우드 제공업체는 코드를 프로덕션으로 바로 배포할 수 있는 사용자를 대신하여 물리 서버를 구동하고 리소스를 신속하게 할당한다.

서버리스 컴퓨팅 서비스는 일반적으로 서비스로서의 백엔드(Backend-as-a-Service, BaaS)와 서비스로서의 기능(Function-as-a-Service, FaaS)이라는 두 그룹으로 나뉜다.

BaaS는 개발자가 다양한 제3사 서비스와 애플리케이션에 액세스할 수 있게 해준다.
예를 들어, 클라우드 제공업체는 인증 서비스와 추가 암호화, 클라우드 액세스 가능한 데이터베이스 및 상세한 데이터 사용량을 제공할 수 있다.
BaaS를 활용하는 경우 서버리스 기능은 일반적으로 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 통해 호출된다.

개발자가 서버리스를 언급하는 경우에는 FaaS 모델을 가리키는 경우가 더욱 일반적이다.
FaaS의 경우 개발자는 사용자 정의 서버 측 로직을 작성할 수 있지만, 이러한 로직은 클라우드 서비스 제공업체가 전체를 관리하는 컨테이너에서 구동된다.

주요 퍼블릭 클라우드 공급업체에서는 하나 이상의 FaaS 오퍼링을 제공한다.
여기에는 Amazon Web Services의 AWS Lambda, Microsoft Azure의 Azure Functions, Google Cloud의 여러 오퍼링, IBM Cloud의 IBM Cloud Functions 등이 포함된다.

일부 조직에서는 쿠버네티스용 Knative 프로젝트에 구축된 Red Hat® OpenShift® Serverless를 비롯해, 오픈소스 서버리스 플랫폼을 사용하여 자체적인 FaaS 환경을 운영하기도 한다.

BaaS (Backend-as-a-Service)

백엔드 개발에 필요한 여러 기능을 API로 제공하는 서비스이다.
SNS연동이나 DB와 같이 백엔드에 필요한 기능들을 사용자가 직접 구현 할 필요 없이 제공하는 API로 해당 기능을 구현할 수 있게 해 주는 것이다.

주로 모바일 앱, 웹 앱에 쓰기 때문에 서비스로서의 모바일 백엔드(Mobile BaaS, MBaaS)로도 알려져 있다.
단일 웹페이지나 모바일 앱 기반의 서비스에서 필요한 서버 기능들을 사용하기 위해 이용하는 써드파티(Third Party) 애플리케이션, 혹은 클라우드 서비스다.

애플리케이션 개발 시 복잡한 백앤드(Back-End) 기능들을 개발자가 직접 개발하지 않고 클라우드 공급자가 제공하는 서비스를 이용해 쉽고 안정적으로 구현한다.

예를 들어, 클라우드 제공업체가 인증 서비스와 추가 암호화, 클라우드 액세스 가능한 데이터베이스, 상세한 데이터 사용량 모니터링 등을 '완성해' 제공하고, 개발자 및 서비스는 그것을 바탕에 둔 애플리케이션 및 서비스를 구성하는 것이다.

보통 클라우드 제공업체가 설정한 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API) 호출을 통해 액세스한다.
이러한 기능은 일반기능이며 클라우드 특성에 맞춘 최적화가 필요하기에, 프로젝트를 위해 새로 개발하는 것보다 클라우드 시스템에 통합되어 클라우드 공급자가 제공하는 것을 사용하는 편이 훨씬 간단하다.

대표 서비스 : Firebase, Auth0

FaaS (Function-as-a-Service)

Function, 즉 함수를 서비스로 제공한다.

사용자가 작성한 코드(백엔드)를 서버리스 제공자의 서버에 업로드하게 되면 해당 서버는 업로드한 코드를 함수 단위로 쪼개어 대기 상태로 둔다.
그러다 요청이 들어오면 서버가 대기 상태에 두었던 함수를 실행시켜 처리한 다음 작업이 끝나면 다시 대기 상태로 만드는 구조다.
함수 호출 횟수에 따라 클라우드 사용료가 청구된다.

함수 호출 후 일정 시간이 경과되어도 다시 수면 상태로 들어간다.(AWS Lambda의 경우는 5분)

함수(로직)은 개발자가 설계하되 그것이 일반적인 서버가 아닌 클라우드 제공업체가 관리하는 클라우드 컨테이너에서 작동하는 경우를 의미한다.
함수를 개발자가 특정 프로젝트(서비스)를 위해 작성하기에 BaaS보다 높은 수준의 제어 기능을 포함하므로, 보다 고도화되거나 특성화된 서비스 수행에 적합하다.

확장성이 매우 뛰어나다.
FaaS를 사용하지 않을 경우 일반적으로 다양한 트래픽에 유연한 대응하기 위해 AWS의 Auto Scaling 같은 기술을 사용한다.
이를 통해 CPU 사용량, 네트워크 처리량에 따라 서버의 개수(=처리할 수 있을 트래픽의 양)를 증감하는 방식으로 대응한다.

그런데 FaaS를 사용하면 이 대응을 보다 정교하게 만들 수 있다.
특정 조건에 따라 자동으로 자원 사용량을 가감하는 것이 아닌, 함수를 1초에 1개가 호출하면 자원소모(=컴퓨팅) 1개가 발생하고, 100,000,00 개가 호출되면 100,000,00 개의 자원을 소모하는 식으로 정교하게 트래픽 처리가 발생하게 끔 만들 수 있다.

대표 서비스 : AWS Lambda, MS Azure Function

서버리스 컴퓨팅의 장점

서버 관리가 필요 없어 개발자가 인프라는 대부분 무시하고 코드에 집중할 수 있도록 한다. (개발자 생산성 증가)
서버 프로비저닝 및 관리와 같은 일상 업무의 부담을 줄여, 개발자가 애플리케이션에 더 많은 시간을 할애할 수 있다.
개발자가 프로비저닝하기 위한 작업에 필요한 인프라를 명시적으로 설명할 필요를 줄여줌으로써 DevOps 도입을 지원한다.
서버 사양이 개발자에게 영향을 주지 않으므로 ‘서버리스’인 것이다.

애플리케이션을 활용하여 자유자재로 확장을 구현할 수 있다. (유연한 확장성)

제3사 BaaS 오퍼링의 모든 구성 요소를 통합해 애플리케이션 개발을 더욱 간소화할 수도 있다.

서버리스 모델에서 운영 비용이 낮아지는 이유는 항상 자체 서버를 실행하고 관리하는 대신 필요한 만큼 클라우드 기반 컴퓨팅 시간에 대해 비용을 지불하기 때문이다. (운영 비용 절약)
고정된 서버가 없음은 제한된 가용성이 아님을 의미한다.
가용성을 위한 별도의 설계가 필요 없다. (높은 가용성)

서버리스 컴퓨팅의 단점

자체 서버를 실행하지 않거나 자체 서버측 로직을 제어하지 않는 데 따른 단점이 있다.

클라우드 제공업체는 자사 구성 요소가 상호작용하는 방법을 엄격히 제한할 수 있어, 사용자 시스템의 유연성과 커스터마이징 수준에 영향을 준다.
BaaS 환경의 경우 개발자는 코드 제어 권한이 없는 서비스에 의존해야 할 수 있다.

단순 작업(댓글 쓰기, 이메일 보내기 등)에는 적합하지만 긴 시간을 요하는 작업(동영상 업로드, 데이터 백업 등)에는 굉장히 비효율적이다.

벤더 종속의 문제
: IT 스택의 이러한 측면에 대한 제어 권한을 이전하면 벤더 종속성 문제도 발생할 수 있다.
제공업체를 변경하면 새로운 벤더 사양에 맞추기 위해 시스템을 업그레이드하는 비용이 발생할 수도 있다.
함수가 사용할 수 있는 최대 메모리, 최대 처리 가능 시간 제약 등의 제약을 서버리스 서비스 벤더가 설정하며 서버리스 사용자 및 서버리스 기반의 서비스는 이에 종속된다.
이에 맞춰 벤더가 설정한 제약을 벗어나는 큰 기능은 잘게 나누어 구현해야 한다.

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

무상태(Stateless)적인 기능의 구현 불가
: 작은 기능으로 잘게 나눠진 함수들은 요청마다 새로 기동하도록 호출되기 때문에 기동 전후의 상태를 공유할 수 없다.
변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없다.

참고
https://www.redhat.com/ko/topics/cloud-native-apps/what-is-serverless
https://yozm.wishket.com/magazine/detail/476/
https://tibetsandfox.tistory.com/4
https://velopert.com/3543