서버리스 아키텍쳐 란?
서버리스(Serverless)는 직역하면 "서버가 없다"라는 뜻이 된다.
하지만 정말로 서버가 없는 것을 뜻하는게 아니다. 서비스를 하는데 있어 어찌되었든 저장소는 필요하고 서버는 필요하기 때문이다.
따라서 정확히 말하자면, 서버리스는 서버가 없는 백엔드 라는 뜻이 아닌 우리가 직접 서버를 관리하지 않아 신경 쓸 필요없는 경우를 뜻한다.
즉, 서버리스 아키텍처(Serverless Architecture)란 서버를 직접 관리할 필요가 없는 아키텍처를 칭한다.
서버리스는 특히, 사이드 프로젝트나 빠르게 프로토타입을 출시할 때 빠르고 쉽게 제품을 출시할 수 있고, 돈도 매우 절약할 수 있다.
서버리스 시장은 지금도 무섭게 성장하고 있어, 관심을 가져서 더 좋은 운영 환경을 고려하는것을 권장한다.
서버리스 탄생 배경
왜 서버리스라는 개념이 탄생했는지 왜 인기가 있는지 이해하기 위해 과거에는 어떻게 어플리케이션을 배포했는지, 그에 따른 장단점을 순차적으로 알아보는 시간을 간단히 가져보자.
1. 온 프레미스
온프레미스(On-Premise)란 직접 서버를 설치하는 것을 일컫는다.
내 집에 서버를 마련하고 싶다면, 하드웨어를 구입하고 거실에 놓고 전원을 꼽아 직접 가동시키고 소프트웨어(서버 코드)를 하드웨어에 업로드해 서비스를 운영한다.
즉, 서버의 하드웨어 부분과 소프트웨어 부분 둘다 직접 관리한다는 것이다.
그런데 만일 내 집이 정전이 되거나, 실수로 서버 전원을 뽑아 버리면 서버가 다운되어 버리는 불상사가 생기게 된다.
그리고 웹사이트의 유저 유입량이 증가해 트래픽이 늘어나면 서버 메모리가 충분하지 않는 현상이 생기게 되고, 직접 메모리 사와서 서버에 꼽아야한다.
이처럼 개발자는 코딩하기도 바빠 죽겠는데 하드웨어적인 관리 측면이 너무 번거롭고 힘들기 된다.
그래서 차라리 PC방 처럼 서버 컴퓨터를 임대하는 방식으로 하드웨어 관리는 임대하는 회사가 하고, 개발자는 본업인 코딩에 집중하도록 나온 기술이 여러분도 알고 있듯이 바로 클라우드 이다.
2. 클라우드 (IaaS / PaaS)
어느날 아마존이 AWS EC2를 선보이며 혁신의 광풍을 일으킨다.
클라우드 컴퓨팅이 등장하면서 덕분에 우리는 거실에 직접 서버 설치하고 관리하는 대신에, 그냥 아마존에게 돈만 내면 아마존이 사용하는 최신식 서버를 빌려서 사용할 수 있게 되었다.
그래서 정전이라던가 각종 사소한 사고에 서버가 다운되는 걱정을 할 필요가 없어졌고, 아마존이 알아서 스토리지를 늘려주고 관리하기 때문에 서버 성능 역시 걱정할 필요 없어졌다.
하지만 여전히 서버의 소프트웨어적인 부분은 사용자가 직접 관리를 해야 한다.
예를 들어 서버에 깔린 운영체제 등을 업데이트하고, 데이터를 백업하고, 보안에도 신경 써야 하는 등 생각보다 귀찮은 일이 많다.
즉, 하드웨어적인 부분만 빌리는거고 서버 자체는 텅 비어있어 서버를 돌리려면 이것저것 소프트웨어를 설치하고 업데이트 해줘야 하고 관리해야 한다.
그리고 IaaS모델이나 PaaS모델은 실제 사용자에 관계없이 미리 결제한 용량에 따라 요금을 내야 한다. 사용자가 1000명이 될 걸 예상하고 그에 맞는 용량의 서비스를 구입했다면 실제 사용자가 1000명이든 0명이든 같은 금액을 내야 하는 것이다.
또한 아무리 On-demand(쓴만큼 지불) 서비스를 이용하더라도 해도 대부분의 클라우드 서비스들은 사용자들이 내 서버를 사용하지 않더라도 그냥 가동만 시켜도 시간마다 결제가 되는 시스템이다. 이는 크던 작던 손실을 일으키게 된다.
이때 서버리스가 등장하게 된다.
3. 서버리스
서버리스 컴퓨팅은 클라우드 서비스 업체가 특정 코드를 실행하는 데 필요한 컴퓨팅 리소스와 스토리지만 동적으로 할당한 다음 그 부분에 대해서만 비용을 청구하는 클라우드 실행 모델이다.
서버리스 원리는 다음과 같다.
- 개발자가 서버리스에 업로드한 함수는 24시간 내내 돌아가는게 아닌 휴면 상태에 들어간다.
- 그러다가 사용자 요청이 오는 순간 서버리스는 잠들어 있는 함수를 깨우고 실행시켜 요청한 작업을 수행하게 한다. 그리고 다시 함수는 잠에 들게 한다.
이전의 경우 유저가 0명이든 1000명이든 같은 돈을 내서 서버를 장만해야됬지만, 서버리스에서는 수행한 함수만큼만 돈을 내면 되는 것이다.
대표적인 서버리스 서비스인 AWS 람다 같은 경우 백만개의 함수실행을 단돈 20센트밖에 안든다.
따라서 대기상태를 제외한 실제 사용 자원에 대해서만 청구가 되기 때문에 굉장히 경제적이며 자원을 효율적으로 사용할 수 있게 된다.
퍼포먼스 측면에도 문제가 없다. 유저가 늘어나면 그만큼 실행 함수도 늘리는 식으로 처리하기 때문이다.
서버리스를 활용하면, 백엔드를 서버에 올리는 것이 아닌 백엔드를 작은 함수 단으로 쪼개서 아마존에서 직접 관리하는 서버로 올리게 된다.
이 말은 서버는 클라우드 제공 기업에서 전적으로 관리하기 때문에, 사용자는 스케일링, 업데이트, 보안 등 런타임 관리와 운영에 대해 시간을 소모하지 않고 핵심 제품에 집중할 수 있다는 뜻이다.
이렇게 서버 운영에 소모되는 오버헤드가 줄어들면 개발자는 시간과 에너지를 확장 가능하고 안정적이고 훌륭한 제품을 개발할 수 있게 된다.
서버리스 모델 (BaaS / FaaS)
BaaS 와 FaaS 는 처음 보는 단어지만, 뭔가 익숙한 단어이다.
클라우드 컴퓨팅에 대해 배울때 IaaS / PaaS / SaaSVisit Website 에 대해 학습한적이 있을텐데, 이와 비슷한 맥락이다.
BaaS (Backend as a Service)
보통, 우리가 모바일 혹은 웹 애플리케이션을 만들때 데이터를 저장하고, 다른 기기에서도 접근하고, 공유하기 위해서 백엔드 서버 개발을 진행하게 된다.
하지만 서버 개발을 하다보면, 고려할 사항이 꽤 많아진다. 유저가 늘어나게 된다면 서버의 확장도 고려해야 하고, 보안성 또한 고려해야 하기 때문이다.
그래서 탄생한 서비스가 BaaS(Backend as a Service) 이다.
BaaS 시스템은 앱 개발에 있어서 필요한 다양한 기능들 (데이터베이스, 소셜서비스 연동, 파일시스템 등)을 API로 제공해 줌으로서, 개발자들이 서버 개발을 하지 않고서도 필요한 기능을 쉽고 빠르게 구현 할 수 있게 해주고, 비용은 api 사용 한 만큼 나가는 원리이다.
즉, 클라우드 공급자가 백엔드 개발 환경까지 제공해 준다고 보면 된다.
서버의 이용자가 순식간에 늘어나도 알아서 확장이 된다.
BaaS를 사용함에 있어서, 가장 큰 장점은 개발 시간의 단축 (회사 입장으로서 생각한다면, 인건비), 서버 확장 작업의 불필요함이다.
백엔드에 대해서 심오한 지식이 별로 없더라도, 아주 빠른 속도로 개발이 가능하다.
대표적인 BaaS의 서비스중 하나인, Firebase 에서는 실시간 데이터베이스를 사용하여 데이터가 새로 생성되거나, 수정되었을 때 소켓을 사용하여 클라이언트에게 바로 반영시켜주는 기능이 있는데, 만일 이러한 기능은 직접 개발하게 된다면 구조 설정에 꽤 많은 시간이 필요 할 수도 있는데 이를 단지 코드 몇줄만으로 구현 할 수 있게 해주는 것이다.
FaaS (Function as a Service)
FaaS는 Function as a Server의 약자로 말 그대로 "함수를 서비스로 제공한다"라는 의미다.
여기서 함수가 뜻하는 바는 독자들도 알고 있듯이 프로그래밍 수준에서 Function 혹은 메소드등을 의미한다.
사용자는 Rest API와 같은 HTTP 요청을 통해 함수를 호출하고 원하는 파라미터를 전달하여 함수가 리턴 값이 있다면 리턴 값을 받거나 혹은 함수의 동작 시작 이벤트를 발생시킬 수 있다.
만약 데이터베이스의 읽기 / 쓰기등을 위한 함수 구문을 클라우드에 업로드해둔다면, 어느 프로그램에서도 단순히 함수 호출을 통해 데이터베이스로부터 입출력이 가능할 수 있다.
따라서 S/W 개발자와 IT 업계가 프로그래밍 로직에만 집중 할 수 있도록 하는것이 바로 FaaS와 서버리스의 주요한 개념이다.
즉, FaaS 는 프로젝트를 여러개의 함수로 쪼개서 (혹은 한개의 함수로 만들어서), 매우 거대하고 분산된 컴퓨팅 자원에 여러분이 준비해둔 함수를 등록하고, 이 함수들이 실행되는 횟수 (그리고 실행된 시간) 만큼 비용을 내는 방식을 말한다.
대표적인 서비스로는 AWS Lambda, MS Azure Function가 있다.
위의 그림에서는 FaaS의 생성 단계를 나타낸다.
- 사용자는 자신의 프로그램 내부에서 FaaS 함수를 호출하는 구문을 삽입하고 프로그램을 실행하게 되면, FaaS에게 Rest API 형식의 HTTP 요청이 가게 된다.
- 그럼 FaaS는 해당 함수를 저장소로 부터 읽어오게 되고
- 해당 함수를 컨테이너 혹은 가상머신으로 생성하게 된다.
- 다음 함수를 포함하고 있는 컨테이너 혹은 가상머신이 생성이 완료되면 함수를 실행하고 결과를 반환하거나 함수가 수행해야하는 동작을 수행하게 된다.
- 이후 일정시간 동안 함수의 호출이 없다면 함수를 포함하는 컨테이너 혹은 가상머신은 FaaS 시스템에 의해 삭제 된다.
BaaS / FaaS 차이점 정리
BaaS 서비스
- 애플리케이션 개발 시 요구되는 복잡한 백엔드 기능들을 개발자가 직접 개발하지 않고 클라우드 공급자가 제공하는 서비스를 이용해 쉽고 안정적으로 구현 하는 것
- 서비스 제공자로부터 미리 만들어진 백엔드 API를 제공받아 사용하는 형태.
- 데이터 저장 및 로드, 사용자 인증, 메시징, 소셜 서비스 등의 백엔드 기능을 완성된 API로 사용할 수 있다.
- API 사용량 및 서버 사용 시간에 따라 비용을 지불한다.
- 게임 백엔드 서비스는 GBaaS (또는 클라우드 게임서버엔진), 모바일은 MBaaS라고 부른다.
FaaS 서비스
- 개발자가 사용자 정의 서버 측 로직을 작성하지만 클라우드 제공 업체가 관리를 전담하는 서버 컨테이너에서 실행 되는 서비스 기능
- 서버에서 수행될 기능들을 개발자가 직접 코드로 작성하여 등록한다.
- 실행 가능한 코드(함수)를 미리 등록해놓았다가 특정 이벤트(트리거)가 발생하면 알아서 호출 및 종료되도록 한다.
- PaaS는 전체 애플리케이션을 배포하여 서버에서 애플리케이션이 항상 실행되지만, FaaS는 애플리케이션을 더 작게 쪼갠 함수를 배포하며 작업을 마치거나 일정 시간이 지나면 종료된다는 차이점이 있다.
- 호출한 함수의 횟수와 실행 시간에 따라 비용을 지불한다.
서버리스 장단점
서버리스 장점
1. 비용 절감
- 기존 IaaS나 PaaS와는 다르게 실제 사용량에 대해서만 비용이 청구되므로 경제적이다.
- 이벤트 기반의 비용으로, 일정 주기, 조건 등에 함수를 호출하므로 리소스를 낭비하지 않게 되어서 비용이 저렴하다. (AWS Lambda의 경우 함수 100만번 실행당 0.2달러)
- 자체 서버를 실행하고 관리하는 대신 필요한 만큼 클라우드 기반 컴퓨팅 시간에 대해 비용을 지불
2. 애플리케이션의 품질에 집중 가능
- 서버에 신경 쓸 필요가 없어지므로 사용자는 개발하는 애플리케이션의 품질 향상에 좀 더 집중할 수 있다.
3. 높은 가용성과 유연한 확장
- 요청이 들어올때만 실행되고 동적으로 자원을 할당하기 때문에 가용성이 높고 스케일링에 신경 쓸 필요가 없다.
- 애플리케이션은 자동으로 확장될 수 있고, 개별 서버 단위가 아닌 사용단위(처리량, 메모리)를 설정/해제하여 용량을 조정할 수 있다.
- 동적으로 자원을 할당받아서 단기간 이벤트성 트래픽을 감당하는 경우 효과적
4. 빠른 개발 배포
- 간단한 패키징 및 배포
- 릴리즈 주기 감소
- 높은 생산성
- 유지보수나 기능추가에 효율적이라 관리보다 개발에 집중할 경우
서버리스 단점
1. Cold Start
- 서버리스의 함수들은 요청이 없으면 수면 상태로 된다.그러다 만일 request가 와서 함수를 깨우고 실행하는데 아무래도 시간이 걸린다물론 1밀리초로 사람이 인지하기에 아주 짧은 시간이겠지만, 만일 0.01초라도 지연을 허용되지 않는 서비스일 경우는 서버리스는 좋은 선택이 아니다. (이러한 경우 때문에 AWS 람다 경우 어떤 함수가 자주 쓰이는지 판단해서 해당 함수는 아예 잠들지않고 리퀘스트에 대응되도록 항상 실행항태로 유지한다)
- 즉, 아무래도 서버가 항시 요청에 대기하고 있는게 아니다보니 IaaS나 PaaS등의 모델보단 요청시간이 느리다.
- 실시간 서비스에는 적합하지 않음
- 프로젝트 규모가 작다면 별로 신경쓸만한 사항은 아니지만 규모가 커지거나 속도를 요구하는 프로젝트라면 서버리스는 좋은 선택이 아닐 수 있다.
2. 긴 시간을 요하는 작업에 불리함
- 서버리스는 단순 작업(댓글 쓰기, 이메일 보내기 등)에는 적합하지만, 긴 시간을 요하는 작업(동영상 업로드, 데이터 백업 등)에는 굉장히 비효율적이다.
- 서버리스는 함수가 1회 호출 될 때 사용할 수 있는 메모리 및 시간에 제한이 있기 때문이다. 이에 따라 큰 기능을 잘게 나누어 구현해야 한다.
3. 로컬 데이터를 사용할 수 없다. (Stateless)
- 서버리스는 무상태(Stateless)적인 기능으로 구현되어야 한다.
- 하나의 작은 기능으로 나뉘어진 함수들은 요청마다 새로 기동되어 호출되기 때문에 전후 상태를 공유할 수 없기 때문이다.
- 또한 변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없다. (이는 서버리스 벤더에 따라 추가 서비스를 통해 극복이 가능하지만, AWS S3, Azure Storage등 일반적인 서버리스는 불가능하다.)
4. 클라우드 제공 플랫폼에 심하게 종속적
- 기존 IaaS나 PaaS모델은 플랫폼을 바꾸는게 어렵지 않지만(ex. AWS에서 Google Cloud로) 서버리스는 애플리케이션의 구조 자체를 바꾸기 때문에 다른 플랫폼으로 이전하는게 굉장히 힘들다.
- 이를 클라우드 서비스 업체에 종속적이라고 일컫는다.
- 이는 곧 사용중인 플랫폼의 가격이나 정책, 서비스 변경에도 민감하게 반응해야됨을 의미한다. 제공업체를 변경하면 새로운 벤더 사양에 맞추기 위해 시스템을 업그레이드하는 비용이 발생할 수도 있다.
서버리스 아키텍처 제공업체
대표적인 서버리스 아키텍처 제공업체는 다음과 같다.
- 네이버 클라우드: Cloud Functions
- Amazon: AWS Lambda
- Microsoft: Azure Functions
- Google: Google Cloud Functions
서버리스 사용 사례
배치 작업
- 데이터를 실시간으로 처리하는게 아니라, 일괄적으로 모아서 처리하는 작업인 배치 작업의 경우 24시간 운영되던 서버가 필요 없으며, 특정 시간에 수행되던 기능을 서버리스로 구현하면 효율적이다.
자동화 작업
- 넷플릭스는 동영상 업로드 시 파일의 인코딩과 검증, 태깅 이후에 공개되는 작업을 AWS Lambda를 통해 자동화 했다.
- 실시간 비디오 스트리밍 앱 개발사인 페리스코프(Periscope)도 동영상의 유해성 여부를 확인하는 기능을 Lambda에서 운영하고 있다.
분석과 모니터링 기능
- CPU 사용량이 임계치에 도달했을 때 알림을 받거나 지속적으로 기록되는 로그를 분석하고 리포팅 하는데 서버리스를 사용할 수 있다.
- 미국 온라인 패션 매거진 버슬(Bustle)은 하루 1억건의 이벤트 처리와 데이터 분석 리포팅에 서버리스를 적용해 84%의 비용을 절감하였다.
챗봇(Chat-Bot) 서비스
- 챗봇을 서버리스로 구현하면 API 호출 시 요청을 처리하고 유연한 확장이 가능해 많은 사용자에게 안정적인 서비스를 제공할 수 있다.
- 슬랙(Slack)을 기반으로 하는 챗봇 어플리케이션이나 Amazon Echo 그리고 AWS Lambda를 이용한 음성인식 어플리케이션이 늘어나고 있다.
