1. 개요
State of Frontend 2022 설문조사 결과
- 자신만의 서버를 사용하는 사람이 감소하고 있는 추세
- Netlify나 Vercel과 같은 클라우드 플랫폼의 사용 수가 급격히 증가
React를 베이스로 한 Next.js나 Remix 같은 프레임워크를 쓰면 풀스택 웹앱을 간편하게 만들어볼 수 있는데 이 프레임워크들을 써서 Vercel에 배포하기만 하면 마법처럼 잘 되더라~ 가 중요한게 아니라 개발자라면 어떤 원리로 동작하는지 아는 것이 중요할 것이다.
별도의 백엔드 서버 없이 풀스택을 개발 할 수 있게 해주는 정말 중요한 시작 포인트인 Serverless 특징, 장단점에 대해 엘리님이 잘 설명해주시는 것을 보고 공부하고자 정리한다.
2. Serverless란?
-
서비스를 운영하기 위해서 예전처럼 개발자가 직접 서버를 만들고 관리하는 것이 아닌 개발자에게서 서버가 사라진 것을 Serverless라고 한다.
개발자가 직접 서버를 관리할 필요없이 어플리케이션에만 집중해서 개발해나갈 수 있게 되었다.
그렇다고 서버가 이 세상에서 영원히 사라진 것이 서버리스가 아니라 Netlify나 Vercel과 같은 hosting 플랫폼에서 서버를 관리하고 있는 것이다.
그래서 개발자는 서버의 하드웨어 스펙같은 것을 신경쓰지 않아도 웹 어플리케이션을 만들어서 이런 종류의 hosting 플랫폼에 배포만 해두면 플랫폼에서 알아서 관리해주고 우리 서비스를 운영해준다. -
What is ServerLess?
"Serverless" computing is a compute model when the source code runs on servers in the cloud that you as a developer does not have to provision or manage yourself. there are still servers that run your code but they are not your headache any more.
(번역) "서버리스" 컴퓨팅은 개발자가 직접 공급하거나 관리할 필요가 없는 클라우드의 서버에서 소스 코드가 실행되게 하는 개발 모델입니다. 여전히 코드를 실행하는 서버가 있지만 더 이상 골칫거리가 아닙니다.
3. Tranditional Way
기존에는 서버를 직접 관리할 때 머리 아픈 일들이 많았다.
예를 들면
1) 어플리케이션 목적과 사용 빈도수, 트래픽에 따라서 얼마나 큰 용량의 CPU와 램을 사용할 건지 일일이 설정해줘야하고
2) 운영체제에 사용하고 있는 소프트웨어 보안 관련 패치들이 나오면 이것들을 일일이 유지보수해줘야 함.
3) 서버가 잘 동작하는지 모니터링하는 시스템도 별도로 마련해야 하고
4) 사용자가 많아지거나 감소했을 때 업 또는 다운스케일링을 직접 해줘야 한다.
5) 사용자가 있든 없든 서버를 항상 운영해야 하기 때문에 여기에서 발생하는 비용도 무시할 수 없다.
4. Serverless Way
"Serverless" Computing 이라고도 하고 FaaS(Function as a Service) 라고도 한다.
특징
1) 더 이상 개발자가 서버를 구축하고 관리할 필요가 없다.
2) 스케일링을 플랫폼이 알아서 해주기 때문에 신경쓸 필요가 없고 이벤트가 하나 발생하면 함수가 하나 실행되고 이벤트가 만개 발생하면 만개의 함수가 실행되니 클라우드 자체적으로 확장이 쉽다.
-> 이게 무슨 말인지 더 찾아보니 이벤트가 발생한 후 함수가 실행되는 시점에서만 컴퓨팅 자원이 필요하기 때문임. 기존의 서버 아키텍처에서는 서버를 운영하는 동안에도 컴퓨팅 자원을 사용했기 때문에 서버리스 아키텍처에서는 확장성과 효율성면에서 기존의 서버 아키텍처보다 우수하다는 이야기.
동작원리
개발자는 코드를 구성하는 함수 하나를 만들기만 하면 된다.
예를 들면 데이터베이스에서 제품의 정보를 읽어오는 함수를 하나 만들고 이 함수를 Netlify나 Vercel과 같은 클라우드 호스팅 플랫폼에 등록해준다.
내 함수가 플랫폼에 등록되면 제품에 대한 get 요청이 들어올 때 이것을 실행해줘 라고 내 함수를 언제 실행하면 되는지만 플랫폼에 명시해주면 되는 것이다.
플랫폼에서 자동으로 get 요청이 들어올 때 등록된 함수를 실행해서 데이터베이스에서 제품에 대한 정보를 읽어와서 사용자에게 보내준다.
이 플랫폼에서 어떤 CPU, 어떤 메모리, 어떤 서버를 사용하고 있는지 확장은 어떻게 할건지 전혀 신경쓰지 않고 함수를 만드는 것에만 집중하면 된다. 그리고 플랫폼에는 실제로 내 함수가 사용한 만큼의 CPU와 메모리 시간별로 비용을 지불하면 된다.
문제점
현존하는 솔루셔 중에 100% 장점만 가지고 있는 것은 없다. 단점과 주의해야 할 사항을 꼭 개발자로서 알고 있는 것이 중요하다.
1) Cold Start : 처음 시작하는 데 시간이 걸림.
- 요청이 온다고 해서 바로 실행이 되지 않는다. 함수의 코드를 다운로드 받고 실행할 수 있는 환경을 조성하고 인스턴스를 시작하는 데까지 시간이 조금 걸린다. 서버가 계속 운영되고 있는 것이 아니라 클라우드상에 요청이 올 때마다 필요하네?준비해야겠다!하고 실행준비를 함. AWS의 람다가 주장하기를 자신들에게 등록된 함수중에 실제로 콜드 스타트로 빠지는 함수의 케이스는 1%도 안된다라고 함. 간혹 다른 곳의 후기를 보면 내 함수 시작하는 데 1초 이상이 걸린다는 이야기가 있는데 각각의 플랫폼마다 함수를 수행하기 위한 환경을 얼마동안 어떻게 캐싱을 하냐에 따라 즉 전략에 따라 달라질 수 있다는 점.
2) Resource limitation
- 람다 함수로 등록할 수 있는 함수의 메모리 사이즈가 정해져있음. 또 함수가 시작되고 끝날 때까지 주어진 시간이 있는데 예를 들어 15분이라는 시간이 주어졌는데 이것을 초과하면 타임아웃이 발생한다. 즉 무겁고 뚱뚱한 함수를 작성하면 서버리스 함수로 적합하지 않다.
3) No State
상태를 가질 수 없고, 독립적이고 개별적인 함수여야한다.
함수 내부에서 전역 데이터를 참조하거나 상태를 가지거나 할 수 없고 함수 내부에서 다른 데이터베이스에 접근해서 데이터를 읽고 쓰고 하는 것은 괜찮다.
기존에 RESTapi로 만들었다면 상태가 없는 함수로 만든 것이니 걱정하지 않아도 되지 않을까
정리
Netlify와 Vercel 의 경우도 Serverless function을 지원하고 있고 이 두 개의 호스팅도 결국 내부적으로는 AWS Lambda function을 사용하고 있다.
React를 베이스로 한 Next.js나 Remix 같은 프레임워크를 쓰면 풀스택 웹앱을 만들고 Vercel과 같은 클라우드 플랫폼에 배포만 해두면 아주 간편하게 풀스택으로 만들어볼 수 있다. 이게 가능한 이유는 Next.js에서 제공하는 API Routes와 Middleware가 결국은 서버리스 함수로 동작하기 때문이다.
출처
