📌 서버리스란
- 서버가 없다는 것이 아니라, 개발자가 관리해야할 서버가 없다는 것을 의미
- 사이드 프로젝트, 빠른 프로토타입 출시에 사용
📌 서버의 역사
1. 온 프레미스
- 직접 물리적 서버를 설치
- 서버의 하드웨어와 소프트웨어 둘 다 직접 관리 필요
👿 단점
- 정전 또는 실수로 서버 전원을 뽑아버리는 경우에 서버가 다운 될 위험이 있음
- 웹 사이트의 유저 유입량이 증가해 트래픽이 증가하면 서버 메모리가 충분하지 않게되고, 직접 메모리를 사와서 물리적으로 서버에 꼽아야함
2. 클라우드
- 물리적 서버가 아니라, AWS, Azure, GCP등 클라우드 서비스 업체에 돈을 내고 클라우드 서버를 받아 사용
😃 장점
- 정전 등 사고에 의해 서버가 다운 될 걱정 X
- 클라우드 서비스 업체가 auto scaling 제공
👿 단점
- 여전히 서버의 소프트웨어적인 부분은 사용자의 직접관리 필요
- 서버에 설치된 운영체제 업데이트, 데이터 백업, 보안 관리 등은 필요
- 사용자의 수에 관계없이 미리 결제한 용량에 따라서 요금 계산
- 사용자가 내 서버를 사용하지 않고, 그냥 가동만 시켜도 시간마다 결제
3. 서버리스
- 클라우드 서비스 업체가 특정 코드를 실행하는 데 필요한 컴퓨팅 리소스와 스토리지만 동적으로 할당하고 사용한 시간만큼만 비용을 청구
원리
- 개발자가 서버리스에 업로드한 함수는 평상시에는 휴면 상태
- 사용자 요청이 오는 순간, 서버리스는 잠들어 있는 함수를 깨우고 실행시켜 요청한 작업 수행
- 작업이 끝나면 다시 함수는 휴면 상태
😃 장점
서버리스에서는 수행한 함수 만큼만 돈을 지불
-> 경제적, 효율적 자원 사용 가능
성능 측면에서도 유저가 늘어난 만큼 동적으로 실행함수를 늘리는 식으로 처리해 문제가 없다.
서버리스를 활용하면, 백엔드를 서버에 올리는 것이 아닌, 백엔드를 작은 함수 단으로 쪼개서 아마존에서 직접 관리하는 서버로 올리게 된다.
즉, 클라우드 서비스 업체에서 전적으로 관리하기에, 개발자는 스케일링, 업데이트, 보안 등에 대해서 신경쓰지 않고, 핵심 코드 개발에만 집중할 수 있다.
📌 종류
1. Baas(Backend as a Service)
- 예)
Firebase
- 앱 개발에 있어서 필요한 다양한 기능들(DB, 소셜 서비스 연동, 파일 시스템)을 API로 제공
- 비용은 api를 사용한 만큼 지불
2. FaaS(Function as a Service)
- 예)
AWS Lambda,MS Azure Function
- 사용자는 Rest API와 같은 HTTP 요청을 통해서 함수를 호출
- 프로젝트를 여러개의 함수로 쪼개서, 매우 거대하고 분산된 컴퓨팅 자원에 함수를 등록, 함수가 실행되는 횟수(실행된 시간)만큼만 비용을 지불
차이점 비교 : BaaS vs FaaS
BaaS : 복잡한 백엔드 기능을 개발자가 직접 개발하지 않고, 클라우드 공급자가 제공하는(API) 서비스를 이용해 쉽고 안정적으로 구현
- 데이터 저장 및 로드, 사용자 인증, 메시징, 소셜 서비스 등의 백엔드 기능을 완성된 API로 사용 가능
FaaS : 개발자가 서버에서 수행될 기능을 직접 코드로 작성해 함수로 등록, 클라우드 제공 업체가 관리를 전담하는 서버 컨테이너에서 함수 실행됨
📌 서버리스 장단점
👍🏻 장점
1. 비용 절감
- 실제 사용량에 대해서만 비용이 청구되므로 경제적
- 이벤트 기반으로 리소스를 사용하고 평상시는 휴면이기에 리소스 낭비를 덜하게 되고, 비용이 저렴하다
2. 애플리케이션 품질에 집중 가능 = 개발자는 코드 개발에만 집중 가능
- 서버 관리 필요 없음
3. 높은 가용성과 유연한 확장
- 요청이 들어올 때만 실행되고, 동적으로 확장 가능
- 단기간 이벤트성 트래픽을 감당하는 경우 효과적
4. 빠른 개발 배포
👎🏻 단점
1. Cold Start
- 서버리스 함수들은 평상시에는 수면 상태
- request와서 함수를 깨우고 실행하는 데 시간이 걸림
- 물론 1밀리초로 사람이 인지하기에는 짧은 시간- AWS 람다의 경우, 자주 쓰이는 함수는 해당 함수는 항상 깨어있도록 유지 가능
- 실시간 서비스에 적합 X
- 큰 규모, 빠른 응답 속도를 요구하는 프로젝트라면 서버리스와 맞지 않음
2. 긴 시간을 요하는 작업에 불리
- 단순 작업(댓글 작성, 이메일 보내기)에는 적합하나, 긴 시간을 요하는 작업(동영상 업로드, 데이터 백업)에는 굉장히 비효율적
- 서버리스는 함수가 1회 호출 될 때 사용할 수 있는 메모리 및 시간에 제한이 있어 큰 기능은 잘게 나누어 구현해야함
3. 로컬 데이터 사용 불가 (Stateless)
- 서버리스는 무상태적인 기능으로 구현되어야함
- 각 함수들은 요청마다 새로 기동되어 호출되기에 전후 상태 공유 불가
- 변수와 데이터의 공유가 불가능, 데이터를 로컬 스토리지에서 읽고 쓸 수 없음
- AWS S3, Azure Stroage 등의 추가 서비스로 극복 가능
4. 클라우드 제공 플랫폼에 심하게 종속적
- IaaS, PaaS 모델은 플랫폼을 바꾸는 것이 어렵지 않지만, 서버리스는 애플리케이션 구조 자체를 바꾸기에 다른 플랫폼으로 이전하는 것이 어렵다.
📌 서버리스 사용 예
1. 배치 작업
- 데이터를 실시간으로 처리하는 게 아닌, 일괄적으로 모아서 처리하는 작업인 배치 작업은 24시간 운영될 필요가 없으므로, 특정 시간에 잠깐 수행되도록 서버리스로 구현하면 효율적
2. 자동화 작업
- 예) 넷플릭스는 동영상 업로드시 파일의 인코딩, 검증, 태깅 이후에 공개되는 작업을 AWS Lambda를 통해 자동화 했음
3. 분석과 모니터링 기능
- CPU 사용량 임계치 도달시 알림 받기 or 지속적으로 기록되는 로그 분석, 리포팅에 서버리스를 사용할 수 있다.
4. 챗봇 서비스
- 챗봇을 서버리스로 구현하면 API 호출시 요청을 처리, 유연한 확장이 가능해 많은 사용자에게 안정적인 서비스 제공 가능
- Amazon Echo, AWS Lambda를 이용한 음성인식 어플리케이션이 늘어나고 있음
