최근에 serverless 라는 개념에 대해서 듣게 되었다. 처음에 단어만 보고 진짜 서버가 없는 서비스라고 생각해서 매우 놀랐었는데, 조금 검색해보니 역시 그건 아니었다.
서비스명이 좀 더 직관적이면 얼마나 좋을까 :\
어쨌든 서버리스는 정말로 서버가 없는 것이 아니라, 서버를 직접 관리하지 않아도 되는 아키텍쳐라고 한다!
1. Severless 아키텍쳐
기존의 서비스들은 IaaS (Infrastructure-as-a-Servie) 혹은 PaaS (Platform-as-a-Service) 방식으로 "전산실"의 개념에서 많은 회사들이 자유로워졌다. 사용자는 클라우드 서비스를 활용해서 네트워크와 하드웨어를 설정하고, 거기에 운영체제를 설치해서 애플리케이션을 구동 할 수 있게 되었다. 또한 관리자 페이지를 통해 사용량을 쉽게 모니터링 할 수 있게 되었다. 배포만 하면 어플리케이션을 바로 구동할 수 있는 환경이 생긴 것!
IaaS와 PaaS에서 더 발전한 개념이 Serverless Architecture로, 작업을 처리하는 서버를 만드는 것은 똑같지만 "서버의 존재"에 대해서 신경을 쓰지 않아도 되고 서버에 대한 설정을 따로 하지 않아도 동적으로 자원을 처리해주는 시스템이다.
서버 스케일링, 유지 관리, 보안 등 서버 관리에 필요한 모든 것을 외부 업체가 관리해주기 때문에 서버에 대한 신경을 끄고 비지니스 로직 개발에 더 집중할 수 있다.
🖥️ Serverless 서비스 과정
보편적으로 많이 사용하는 방식의 서버리스 서비스의 과정은:
- 개발자가 백엔드 로직을 구현하고 작은 함수 단위로 쪼갠다.
- 쪼개어진 함수를 관리 업체 (ex. 아마존)에 업로드한다.
- 서버리스에 업로드한 함수는 24시간 내내 돌아가는게 아닌 휴면 상태에 들어간다.
- 사용자 요청이 오는 순간 서버리스는 잠들어 있는 함수를 깨우고 실행시켜 요청한 작업을 수행하게 한다.
- 작업을 마치고 함수는 다시 휴면 상태로 전환한다.
대기 상태를 제외하고 실제로 사용된 자원에 대해서만 비용이 청구되기 때문에 매우 경제적이라고 한다.
이전의 경우 유저가 0명이든 1000명이든 같은 돈을 내서 서버를 장만해야됬지만, 서버리스에서는 수행한 함수만큼만 돈을 내면 되는 것이다.
2. FaaS, BaaS
서버리스는 FaaS (Function-as-a-Service)와 BaaS (Backend-as-a-Service) 두가지로 나눠지고, 보통 서버리스라고 하면 FaaS를 의미하는 경우가 많다고 한다.
🖥️ FaaS (Function-as-a-Service)
보편적으로 서버리스 서비스를 칭할 때 의미하는 모델로, 함수를 서비스로 제공하는 방식이다.
개발자가 직접 서비스에 필요한 로직을 구현하고 해당 로직을 함수 단위로 쪼갠 다음, 서비스 제공처가 관리하는 컨테이너에 해당 코드를 업로드한다.
FaaS 방식은 플랫폼이 제공하는 백엔드 라이브러리를 사용하지 않기 때문에 코드를 작성한 개발자가 제어 권한이 있으며, 업로드된 함수(코드)는 사용자 요청이 오면 실행된다.
더 정확한 과정을 보자면:
- 개발자는 프로그램 내부에 FaaS 컨테이너에 담겨있는 함수를 호출하는 구문을 삽입한다.
- 프로그램이 실행되고 사용자가 요청을 보내면 FaaS에 REST Api 형식으로 HTTP 리퀘스트가 보내진다.
- 요청을 받게되면 FaaS는 함수들이 담겨있는 저장소에서 요청에 해당하는 함수를 읽는다.
- 읽어온 함수를 컨테이너, 혹은 가상머신(Virtual Machine)으로 생성한다.
- 요청에 해당하는 함수가 담긴 컨테이너, 가상머신 생성이 완료되면 함수가 실행된다.
- 함수의 값을 리턴하고 수행되어야 하는 동작이 완료되고 일정시간 동안 요청이 없을 때 생성되었던 가상머신은 FaaS에 의해 삭제된다.
FaaS의 특성
- 무상태성 (Stateless)을 유지한다.
- 함수가 실행되는 동안에만 관련된 자원을 할당하게 되며, 함수가 항상 같은 머신에서 실행된다는 보장이 없다. 따라서 함수 실행 시 로컬에서 어떤 상태(State)가 유지될 수 없다.
- 이벤트에 실행되기 때문에 필요에 따라 자동으로 실행된다.
- 클라우드 제공업체가 관리를 전담하므로 상시 가동 애플리케이션 및 서버 대신 필요한 만큼만 비용을 지불한다.
🖥️ BaaS (Backend-as-a-Service)
FaaS 서비스 사용 시 개발자가 모든 로직을 구현했다면, BaaS는 이미 만들어진 백엔드 API를 제공하는 서비스다.
개발자는 BaaS가 제공하는 사용자 인증과 관리, 클라우드 액세스가 가능한 DB, 소셜 서비스 연동등과 같은 백엔드 관련 외부 서비스를 API 요청을 통해 사용할 수 있다.
API 호출을 통해 서비스를 사용하기 때문에 API 사용량 및 서버 사용 시간에 따라 비용을 지불한다.
3. Serverless 장단점
🖥️ 장점
- 실제 사용량에 대해서만 지불하기 때문에 경제적이다.
- 요청이 들어올때만 실행되고 동적으로 자원을 할당하기 때문에 가용성이 높고 스케일링에 신경 쓸 필요가 없다.
- 단기간 이벤트성 트래픽을 감당하는 경우 효과적이다.
- 서버를 신경쓰지 않아도 되기 때문에 개발 시간이 단축되고 개발자 자체의 리소스도 확보 된다.
- 특히 BaaS 서비스의 경우, 백엔드 로직을 직접 구현하지 않을 수 있기 때문에 Backend 개발에 있어 한정된 지식을 가진 Frontend 개발자와 빠르게 개발하기 원하는 Backend 개발자 모두가 사용할 수 있다
🖥️ 단점
- 서버가 상시 대기 상태가 아니기 때문에 응답 시간이 느리다.
- FaaS 서비스의 경우, 요청이 없는 경우 휴면 상태로 전환되기 때문에 응답 속도가 느릴 수 있다.
- 매우 짧기 때문에 사람이 인지할 수 없는 정도겠지만, 짧은 지연이라도 치명적일 수 있는 경우 권장하지 않는다.
- 긴 시간을 요구하는 작업의 경우 실행 시간의 한계가 있다.
- FaaS 서버리스는 함수가 1회 호출 될 때 사용할 수 있는 메모리 및 시간에 제한이 있기 때문에 작업이 끝나지 않은채로 해당 시간이 지나면 작업이 완료될때까지 일정 시간마다 계속 함수를 다시 호출하게 된다.
- Stateless 하기 때문에 데이터를 로컬 스토리지에서 읽고 쓸 수 없다.
- 서버리스 제공처에 따라 추가 서비스 구매 시 구현이 가능하지만, 해당 서비스를 제공하지 않는 업체도 있다고 한다.
- 플랫폼에 심하게 종속적이다.
- 서버리스의 경우, 어플리케이션 구조 자체를 변경해야할 수 있기 때문에 플랫폼을 옮기기가 매우 어렵다.
- 사용중인 플랫폼의 가격이나 정책, 서비스 변경에도 민감하게 반응해야됨을 의미하며, 제공업체를 변경하면 새로운 벤더 사양에 맞추기 위해 시스템을 업그레이드하는 비용이 발생할 수도 있다.
- BaaS 환경의 경우 개발자는 코드 제어 권한이 없는 서비스에 의존해야한다.
- 디버깅 및 테스트가 불편하다.
툴이나 프레임워크와 같이 기술과 관련된 인프라는 장단점을 잘 따져서 사용해야할 것 같다.
서버리스의 경우도 장점이 뚜렷한만큼 단점도 뚜렷하기 때문에 실제 서비스에서 어떤 문제가 일어날지 모르기 때문에 사실 일반적인 회사에서 사용하기엔 어려워보인다.
보통 서버리스를 사용하는 경우는 사이드 프로젝트(토이 프로젝트)나 빠르게 시제품(초기 서비스)을 런칭하고 싶은 경우라고 한다.
실제 사용 사례는 서비스의 자동화, 분석, 모니터링 등 변경될 여지가 많지 않는 기능에서 서버리스를 사용한다고 한다.
출처:
