서버리스(Serverless) 란?
- 클라우드상에 있는 서버에서 소스코드를 동작하게 하는 개발 모델.
- 서버 관리에 대한 복잡성을 최소화하고 애플리케이션 코드를 더욱 집중할 수 있도록 하는 클라우드 컴퓨팅 아키텍처.
- 서버리스 애플리케이션은 일반적으로 클라우드 제공 업체에서 제공되는 기능 서비스(FaaS)를 사용하여 개발되며, 이를 통해 서버 셋업, 환경 설정, 확장, 유지 보수 및 업그레이드와 같은 일부 작업을 클라우드 제공 업체(AWS Lambda, Azure Functions, Google Cloud Functions)가 관리
=> 서버가 없어진 것이 아니라 nelify 나 Vercel과 같은 호스팅 플랫폼(클라우드 플랫폼)에서 서버를 운영 및 관리를 해줌.
서버리스 동작원리
-
FaaS(Function as a Service)
- 사용자는 코드를 구성하는 함수 하나를 만들면 됨.Step1) 구동하고싶은 동작을 포함하는 함수를 하나 만들고
Step2) 클라우드 호스팅 플랫폼에 등록
Step3) GET 요청이 들어오면 함수가 실행될 수 있도록 명시해줌
Step4) 함수를 실행하여 data를 읽어와서 사용자에게 응답을 보내줌
기존 서버의 문제점
- 어플리케이션의 목적과 사용빈도수, 트래픽에 따라서 얼마나 큰 용량의 CPU,RAM을 사용할 건지 일일히 설정을 해줘야함.(하드웨어 스펙)
- 운영체제,사용하고 있는 소프트웨어, 보안패치등의 유지보수가 번거로움(소프트웨어 관리)
- 서버가 잘 동작하고 있는지 서버 모니터링 시스템 구축
- 사용자가 많아지거나 감소했을 때, up/down 스케일링을 직접 해줘야함
- 사용자가 있으나 없으나, 항상 운영해야함 -> 큰 비용 발생
서버리스 장점
-
서버 관리의 부담X: 서버리스 아키텍처는 개발자가 서버 인프라를 관리하지 않아도 되기 때문에, 개발자는 더욱 비즈니스 로직에 집중할 수 있습니다.
-
우수한 확장성: 서버리스 아키텍처는 자동 스케일링을 제공하여 애플리케이션 트래픽의 요구에 맞추어 서버 셋업과 용량 조정을 자동으로 수행합니다. 이는 애플리케이션 성능을 높이는 데 도움이 되며, 개발자는 서버 관리에 덜 신경 쓰고 더 많은 시간을 애플리케이션 개발에 투자할 수 있습니다.
-
저렴한 비용: 서버리스 아키텍처는 사용한 만큼만 비용을 지불하므로, 개발자는 불필요한 서버 비용을 지불할 필요가 없습니다.
-
빠른 배포 속도: 서버리스 아키텍처는 개발자가 코드를 빠르게 업데이트하고 배포할 수 있도록 도와줍니다. 이는 빠른 개발 주기를 유지하면서도 애플리케이션의 신뢰성을 유지하는 데 도움이 됩니다.
-
다양한 클라우드 제공 업체에서 지원됩니다: 서버리스 아키텍처는 AWS Lambda, Azure Functions, Google Cloud Functions 등 다양한 클라우드 제공 업체에서 지원됩니다. 이는 개발자가 다양한 클라우드 제공 업체를 선택할 수 있으며, 자신이 가장 편안하게 작업할 수 있는 환경을 선택할 수 있다는 장점이 있습니다.
서버리스 문제점
- Cold Start
- 처음 시작하는데 시간이 쫌 걸립니다.
- 서버가 계속 켜져 있는것이라니라, 클라우드에 요청이 올 때마다 함수를 실행할 준비를 합니다.
( 그러나 실제 AWS Lambda의 case 중에서, Cold Start의 문제점을 가지는 함수는 전체의 1% 이하이므로 아직은 그렇게 크게 문제되고있는 이슈는 아니라고함 )
- Resource limitation
- Lambda 함수로 등록할 수 있는 리소스의 메모리 용량(max 10,240MB)
- Lambda 함수를 구동시킬 수 있는 시간(max 15분)
- No State
- 상태가 없는, 독립적/개별적인 함수여야함.
- 특정한 이벤트가 발생하면 독립적이고, 개별적으로 수행이되기때문에 함수 내부에서 전역 data를 참조하거나 상태를 가지는 것은 불가능.
- 함수 내부에서 다른 Database에 접근해서 읽고 쓰는 것은 가능
👩🏻💻 느낀점)
내가 프로젝트를 하면서 편하게 이용했던 Vercel과 Nelify도 AWS Lambda를 기반으로 호스팅된 클라우드 플랫폼이라는게 신기했다.
서버리스 클라우드를 사용하면, 개발자가 직접 서버관리에는 크게 신경쓰지 않을 수 있다는 점이 아주 큰 장점인 것 같다. 현재까지도 사용하고 있는 플랫폼은 AWS Lambda 인데, Lambda 함수를 사용하기위한 resource에 제한이 있기 때문에 너무 크고 무거운 코드가 아니라면 계속해서 이용할 것이다.
그러나 상태관리에 대한 부분은 저장이 되지 않으므로 그부분은 어떻게 해결할 건지 고민을 해봐야겠다.
