[on-demand computing]
클라우드 컴퓨팅의 모델 중 하나로 사용자가 서버를 직접 관리할 필요가 없는 모델을 말한다.
서버리스란 "서버가 없다"라는 의미이지만, 서버가 없는 것이 아니라,
특정 작업을 수행하기 위해 컴퓨터를 혹은 가상 머신에 서버를 설저하고, 이를 통해 처리하는 것이 아님을 의미한다.
더 자세히 말하자면, 서버에서 처리하는 작업을 클라우드 기반의 서비스로 처리하는 것이다.
서버를 직접 구축하지 않고 서비스를 사용함으로써 구축 및 관리 비용을 낮추고,
서버 운영에 따라 발생하는 유지보수의 어려움을 줄이기 위해 필요한 순간에만 컴퓨팅 서비스를 제공한다.
서버리스 장점
기존 VM과 컨테이너에 비해 적은 Provision Cost를 갖는다.
Provision은 준비, 설비하다 라는 뜻인데 IT 인프라 자원을 고객의 요구 사항에 맞게 할당, 배치, 배포하는 것을 의미한다.
서버의 CPU, Memory 자원을 적절하게 할당하는 것을 서버 자원 프로비저닝이라 하며, OS를 서버에 설치하고 구성 작업하는 것을 OS 프로비저닝이라고 한다.
Serverless는 VM 및 Container에 관한 지식이 없어도 사용할 수 있어 VM, Container를 할당하는 시간을 줄여준다.
서버리스 형태
일반적으로 두 가지 형태로 나눈다.
1. BaaS (Backend as a Service)
그동안 개발자가 직접 구현하던 백엔드의 부분부분을 서비스로 제공받는 것이다. 개발자가 다양한 제3사 서비스와 애플리케이션에 액세스할 수 있게 해준다. 클라우드 제공업체는 인증 서비스(ex) Auth0, AWS Cognito)와 추가 암호화, 클라우드 액세스 가능한 데이터베이스 및 상세한 데이터 사용량을 제공할 수 있다.
대표적인 예로 구글의 모바일 앱 백엔드 서비스인 Firebase가 있다.
BaaS를 활용하는 경우 서버리스 기능은 일반적으로 API를 통해 호출된다.
2. FaaS (Function as a Service)
이벤트 기반 컴퓨팅 실행 모델로, 개발자가 작성하는 로직은 플랫폼에서 전체를 관리하는 컨테이너로 배포된 후 온디맨드로 실행된다. 개발자가 환경을 구성하고 서버 코드를 작성하는 것이 아니라 함수만 구현하면 된다.
BaaS와 달리 FaaS는 사전 작성된 서비스 라이브러리에 의존하지 않고 사용자 정의 애플리케이션을 생성하는 개발자에게 더 많은 제어 권한을 제공합니다.
AWS Lambda가 대표적인 FaaS 이다.
개발자가 서버리스를 언급하는 경우에는 FaaS 모델을 가리키는 경우가 더욱 일반적이다. FaaS의 경우 개발자는 사용자 정의 서버 측 로직을 작성할 수 있지만, 이러한 로직은 클라우드 서비스 제공업체가 전체를 관리하는 컨테이너에서 구동된다.
ex) Amazon S3에 AWS Lambda를 트리거하면 Amazon S3에 업로드를 진행할 때 서버코드를 AWS Lambda로 실행할 수 있다. 요청 수에 맞추어 확장도 가능하다.
[TODO] 실습해보기
우리가 등록한 함수는 특정 이벤트가 발생했을 때 실행된다.
- 주기적으로 실행되게끔 설정 할 수 있다. (ex) 하루마다)
크롤링 작업, 주기적 처리를 할 때 좋다.- 웹 요청을 처리 할 수 있다. 특정 URL 로 들어오면 어떠한 작업을 하게끔 할 수 있다. 👉 백엔드 API 구성 가능
- 콘솔을 통하여 직접 호출 할 수도 있다.
코드는 클라우드 제공업체가 관리하는 컨테이너에 배포된다.
컨테이너의 특징
- Stateless: 데이터 통합이 더욱 간소화됨
- 일회성: 매우 단기간에 실행 가능
- 이벤트에서 trigger: 필요에 따라 자동으로 실행 가능
- 전체 관리형: 클라우드 제공업체가 관리를 전담하므로 상시 가동 애플리케이션 및 서버 대신 필요한 만큼만 비용 지불한다.
FaaS를 활용하면 개발자는 API를 통해 서버리스 애플리케이션을 호출할 수 있고, FaaS 제공업체는 이를 API 게이트웨이를 통해 처리한다.
PaaS와의 주요 차이점
서버 시스템에 대해서 신경쓰지 않아도 된다는 점이 PaaS와 유사하지만 PaaS 의 경우엔, 전체 애플리케이션을 배포하며, 일단 어떠한 서버에서 해당 애플리케이션이 24시간동안 계속 돌아가고 있다는 점아다.
반면 FaaS 는, 애플리케이션이 아닌 함수를 배포하며, 계속 실행되고 있는 것이 아닌, 특정 이벤트가 발생했을 때 실행되며, 실행이 되었다가 작업을 마치면 (혹은 최대 타임아웃 시간을 지나면) 종료된다.
FaaS 장점
- 비용: 필요할 때만 함수가 호출되어 처리되며 함수가 호출된 만큼만 비용이 들기 때문에 비용이 절약된다.
- 인프라 관리: 네트워크, 장비 이런것들에 대한 구성 작업을 신경 쓸 필요가 없다.
- 인프라 보안: 리눅스 업데이트 등 관련 보안에 대해 신경 쓸 필요가 없다.
- 확장성: FaaS 는 확장성 면에서 매우 뛰어나다. 일반적으로, FaaS 를 사용하지 않는다면, 다양한 트래픽에 유연한 대응을 하기 위하여 우리는 AWS 의 Auto Scaling 같은 기술을 사용한다. 이를 통해 CPU 사용량, 네트워크 처리량에 따라 서버의 개수를 늘리는 방식으로 처리를 분산시키는데, FaaS 를 사용하게 되면 이렇게 특정 조건에 따라 자동으로 확장되는 것이 아니다. 그냥, 확장된다. 함수가 1초에 1개가 호출되면 1개가 호출되는것이고, 100,000,00 개가 호출되면 100,000,00 개가 호출되는것입니다. 그리고 호출된 횟수 만큼 돈을 내는 것이다.
[TODO] AWS AutoScaling 공부하자..
단점
- Cold Start
서버가 항시 요청에 대기하고 있는게 아니다보니IaaS나PaaS등의 모델보단 느리다.
프로젝트 규모가 커지거나 속도를 요구하는 프로젝트라면 서버리스는 좋은 선택이 아닐 수 있다. - 제한
모든 코드를 함수로 쪼개서 작업하다보니, 함수에서 사용할 수 있는 자원에 제한이 있다. 하나의 함수가 한번 호출 될 때, AWS 에서는 최대 1500MB 의 메모리까지 사용 가능하며, 처리시간은 최대 300 초까지 사용 가능하다(메모리 및 시간 제한).서버리스는 단순 작업(댓글 쓰기, 이메일 보내기 등)에는 적합하지만 긴 시간을 요하는 작업(동영상 업로드, 데이터 백업 등)에는 굉장히 비효율적.작업이 끝나지 않은채로 해당 시간이 지나면 작업이 끝날때까지 일정 시간마다 계속 함수를 다시 호출하므로 굉장히 비효율적이다. 때문에, 웹소켓같이 계속 켜놔야 하는 것은 사용하기 어렵다. (그 대신에, AWS IoT, Pusher 등의 서비스를 사용하면 된다.)
- FaaS 제공사에 강한 의존: AWS, Azure, Google 등의 FaaS 제공사에 강한 의존을 하게 된다.
- 로컬 데이터 사용 불가능: 함수들은 무상태적(stateless)입니다. 때문에, 데이터를 로컬 스토리지에서 읽고 쓸 수 없다. 그 대신, AWS는 S3, Azure는 Storage를 이용할 수 있다.
사용 용도
Backend, Crawler(주기적), 파일 처리(S3), 로그 분석/실시간 모니터링, 자동화 작업(ex) Netflix-encoding, back up,, etc)
참고 링크
