서버리스(Serverless)란
서버리스란 물리적인 서버를 관리할 필요 없는 환경을 말한다. ‘서버리스’라고 해서 서버가 없다는 말은 아니다. 물리적인 서버는 존재하지만 그 서버를 개발자가 관리할 필요가 없는 환경이다. 서버 관리는 아마존, 구글, 마이크로소프트같은 클라우드 사업자의 몫이다. 따라서 개발자는 어플리케이션 개발에만 집중할 수 있다.
과거 험난했던 배포 과정
예전에는 내가 개발한 어플리케이션을 배포하려면 서버 장비를 집에 두고 전원을 연결해 물리적 서버를 먼저 마련해야 했다. 하드웨어적, 소프트웨어적 관리를 모두 개발자가 직접 해야했다. 만약에 집이 정전됐다? 서버도 같이 다운되는 것이고, 누가 전원 코드를 빼버린다? 당연히 서버가 꺼져서 서버를 다시 연결할 때까지 유저가 서비스에 접속할 수 없다.
그리고 트래픽 100명까지 가능한 서버인데 갑자기 유저가 1000명으로 늘었다면 메모리를 더 사서 서버를 늘려야만 유저 1000명을 수용할 수 있었다. 유저가 100명으로 다시 급감했다면 확충한 서버 용량은 놀게 되는 것이다.
개인 개발자의 구세주, 클라우드 서비스(feat. 갓마존)
이때 등장한 것이 AWS EC2 같은 클라우드 컴퓨팅 서비스다. 클라우드의 등장으로 더이상 개발자가 물리적 서버를 관리할 필요가 없어졌다. AWS에서 서버를 24시간 돌리고 있기 때문에 내 백엔드 서버를 AWS 서버에 올리기만 하면 유저가 언제든 서비스를 이용할 수 있다. 집에 정전이 난다고 해도.
하지만 이것도 단점이 있는데, 서버가 24시간 돌아가다보니 하루에 유저가 달랑 30분만 내 서비스를 이용한다고 해도 꾸준히 요금을 내야한다는 점이다. (그 외에도 보안 이슈라든지 데이터 백업이라든지 업데이트라든지… 물리적 서버 관리 빼고는 전부 개발자가 관리해줘야 한다는 점은 예전과 동일)
서버리스의 등장과 장점
이런 단점을 보완한 것이 서버리스 컴퓨팅이다. AWS Lambda가 서버리스 컴퓨팅을 제공하는 대표적인 서비스다. EC2와는 달리 백엔드를 함수 단위로 업로드해 특정 함수(기능)가 필요할 때 그 함수를 호출해서 사용한다. 아무 호출도 일어나지 않는다면 함수는 동작하지 않는다. 또한 갑자기 트래픽이 몰린다면 서버가 호출 받은 함수를 복제해서 유저 요청을 처리한다. 유저가 빠져나가면 다시 함수는 잠든다.
이런 자동 스케일링 설정으로 서비스를 이용하는 유저 수에 따라 클라우드 스케일을 늘었다 줄였다 할 수 있다. 서버리스는 단위 시간 당 함수가 처리하는 트랜잭션 수와 네트워크 메모리 사용률을 근간으로 하는 ‘Pay as you go’ 방식의 과금 모델이므로 운영 비용을 절감할 수 있다.
또한 개발자는 더이상 서버 사양에 신경쓰지 않아도 되므로 개발에만 온전히 집중할 수 있게 됐다. 빠른 출시가 필요한 서비스나 사이드 프로젝트에 사용하는 데에 적합하다.
서버리스 단점
요청이 들어왔을 때 잠든 함수를 깨워서 작동시켜야 하기 때문에(cold start) 아주 약간의 시간차가 생긴다. 밀리세컨드(ms) 단위의 아주아주아주 짧은 시간이지만 서버가 24/7 눈을 뜨고 대기하는 것에 비해서는 그래도 시차가 존재하는 셈이다.
이 점을 보완하기 위해 AWS에서는 자주 사용하는 함수를 분석해 그 함수는 24시간 돌아가게 해놓았지만, 그럼에도 불구하고 시차를 완벽하게 없앨 순 없기 때문에 동시성이 중요한 서비스에서는 이용하기 어려운 것이 단점이다.
두 번째 단점은 한번 배포한 곳에서 다른 서비스로 갈아타기 쉽지 않다는 점이다. 서버리스 서비스 제공자마다 서버 구조가 다르기 때문에 다른 서비스로 마이그레이트 하기가 쉽지 않다. 물리적 서버만 빌려썼던 EC2와는 다르게 말이다.