Serverless
개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델
서버리스 모델 역시 물리적 서버가 존재하지만 클라우드 제공 업체(CSP)가 인프라에 대한 프로비저닝, 유지 관리, 스케일링 등의 작업을 처리하여 추상화되어 있다.
온프레미스, IssS 모델 환경에서 개발자/서비스 제공자는 서비스 제공에 필요한 인프라 자원을 사전에 구매하여 준비한 뒤 동작 시키는 과정이 필요했다. 또한 서비스 부하에 따라 인프라 자원을 스케일링하는 것 또한 개발자의 몫이다.
반면 서버리스 모델에서는 인프라 자원을 동적으로 할당하기 때문에 서비스가 대기 상태에 있다가 실제 요청이 들어오면 인프라 자원을 할당하여 서비스를 처리한 뒤 자원을 해제한다. 인프라 자원이 상시 동작하지 않아 보다 효율적인 자원 사용과 비용 절감을 기대할 수 있다.
유형
서버리스 서비스는 일반적으로 BaaS(Backend as s Service), FaaS(Function as a Service)로 나눌 수 있다.
다만 일반적으로 서버리스를 말할 때는 FaaS를 의미하는 것 같다.
BaaS (Backend as s Service)
DB, Storage, 인증 등의 Backend 기능을 서비스로 제공한다.
안드로이드와 같은 클라이언트 중심으로 개발되어 백엔드에 필요한 기능을 사용자가 직접 구현할 필요 없이 API로 구현할 수 있게 한다.
Google Firebase가 대표적인 BaaS에 해당된다.
FaaS (Function as a Service)
이벤트 기반 실행 모델로 함수를 서비스로 제공한다.
애플리케이션이 아니라 함수를 배포하며, 배포된 함수는 분산 컴퓨팅 자원에 등록된다. 함수는 대기 상태에 있다가 요청이 들어오면 실행되고 다시 대기 상태로 들어간다. FaaS는 함수가 실행된 수와 시간만큼 비용이 부과된다.
함수는 특정 이벤트가 발생했을 때 실행시킬 수 있는데 주기적으로 실행하거나, 특정 URL로 웹 요청이 들어오거나 콘솔을 통해 직접 호출하여 실행시킬 수 있다.
AWS Lamda, Microsoft Azure Function, Google Cloud Functions 등이 해당된다.
장단점
장점
- 인프라 관리 업무 부담 절감 => 비즈니스 로직 집중 가능
- 사용한 컴퓨팅 시간과 횟수에 따른 비용 부과로 인한 경제성
- 간단한 패키징과 배포
- 자동 스케일 업/다운
단점
- 서버 측 로직 직접 제어 불가
- 트리거에 의해 서버를 실행하고 반복하기 때문에 실행 시간이 느리다.
- CSP에 종속성을 가진다.
- 디버깅 및 테스트에 대한 어려움
참고 문서
https://www.redhat.com/ko/topics/cloud-native-apps/what-is-serverless
https://ssup2.github.io/theory_analysis/Serverless_Architecture_BaaS_FaaS/
https://oi.readthedocs.io/en/latest/dl/platform&hw/serverless.html