서버를 위해 준비해야하는 일은 백엔드 코드만 작성해서 끝나는 것이 아니다. 컴퓨터를 구하고, OS를 설치하고, 메모리는 어떤 걸 사용하고, 얼만큼 장착할 건지, CPU는 뭘 쓸지, 에러를 모니터링하고, 보안 작업을 진행하고, 향후 확장은 어떻게 할건지 등의 작업을 해줘야 한다. 이런 부분에 있어 많은 인력비용이 들기도 하면서, 무엇보다 상당히 번거롭다. 이런 부분들을 자동화한 기술이 서버리스이다. 서버리스는 서버를 직접 관리하는 것이 아닌, 클라우드 제공 업체가, 서버를 구성하고 관리 하는 업무를 대신 처리해준다. 개발자는 코드를 작성하고 업로드하기만 하면, 해당 코드에 필요한 인프라를 구성하여 실행환경 만들어준다.
실제 서버를 사용하는 것과 서버리스의 대표적인 차이는 프로비저닝의 여부이다. 즉 개발자가 직접 프로비저닝을 하는가 아니면 프로비저닝이 자동화되어 실행되는 지를 뜻한다.
AWS lambda, Google Cloud Function, Microsoft Azure Function
아니다. EC2는 클라우드를 통해 서버의 업무를 대체하지만 정확히 EC2는 가상서버이다. 하드웨어적인 부분을 자동화를 통해 쉽게 구성하는 것이 가능하지만 선택은 관리자가 한다. 또한, EC2는 IaaS 로서 인프라적 환경을 구성하는 역할을 할 뿐, 서비스 아키텍쳐에 필요한 설계와 기능 설치적인 부분 역시 관리자가 수행해야 한다.
파이어베이스가 서버리스형의 서비스를 제공하는 것은 맞으나 실제 서비리스 서비스하고는 사용방법이 좀 다르다. 정확히는 서버리스 형태의 API 서비스라고 하는게 맞을 거 같다. 파이어베이스는 자체에서 제공하는 API를 활용하여 백엔드 기능을 구현해야 한다면, AWS Lambda의 경우 그냥 함수만 작성해서 넣어주면 인프라적인 용도는 알아서 자동관리한다.
서버리스는 비교적 크지 않은 어플리케이션 사례에 적합하다. 그러나 모든 서비스를 서버리스로 전환하기에 적합한 것은 아니다. 대표적으로 서버리스는 비용 절감을 위해 함수를 사용하는 시간을 제외하고는 컴퓨팅이 꺼진 상태로 대기하게 된다. 즉 요청 마다, 컴퓨터를 깨우고 코드를 실행하고 다시 재우는 과정을 반복해야한다.
자고 있는 컴퓨터를 다시 깨워 코드를 실행하기 까지의 과정을 콜드 스타트 라고 한다.
이러한 부분에 있어 플랫폼 별로 나타나는 소모적 비용이 다 다른데, AWS Lambda의 경우 요청 당 0.1 초 분의 시간과 전체 비용의 1% 정도 차지한다고 한다. 그러나 대규모적 어플리케이션의 경우, 이러한 0.1초의 시간마저도 안정적인 서비스를 제공하고자 24시간 풀가동되는 가상서버를 택하기도 한다. 그외에도 아키텍처 적으로 기업의 관리가 필요하거나, 인프라 적 환경을 서비스에 알맞게 커스텀할 필요가 있거나 등의 이유를 생각한다면, 반드시 서버리스가 정답인것 만은 아니다.
또한 대규모적이 데이터 처리나 트랜잭션 처리의 작업이 필요한 어플리케이션의 경우에는 서버리스를 사용하지 않을 것을 권고하는 편이다. 이 경우는 서버리스 자체도 네트워크 대기 시간과 시작 시간에 대한 추가 비용이 오히려 가상 서버 비용보다 더 크게 나올 수 있다. 서비리스 플랫폼들을 리소스나 사용 시간등을 설정하여 그 이상이 나오는 함수인 경우는 서비스 사용을 제한하고 있다.
참고
서버리스 | 이젠 웹개발자가 꼭 알아야 하는 개념 🎩
서버리스는 서버가 없는걸까? 8분 개념 설명!
0.1초 동안 컴퓨터를 빌려보자 - AWS Lambda