서버리스 아키텍쳐

온 프레미스

서버의 하드웨어 부분과 소프트웨어 부분 둘다 직접 관리하는 방식

하드웨어적인 관리 측면이 너무 번거롭고 힘들고, 비용이 크다

 

클라우드

서버의 하드웨어 부분은 빌려서 사용하고, 소프트웨어적인 부분만 직접 관리하는 방식

대부분의 클라우드 서비스들은 가동시간 기준으로 결제가 되는 시스템

 

서버리스

클라우드 서비스 업체가 특정 코드를 실행하는 데 필요한 컴퓨팅 리소스와 스토리지만 동적으로 할당한 다음 그 부분에 대해서만 비용을 청구하는 클라우드 실행 모델

• 개발자가 서버리스에 업로드한 함수는 24시간 내내 돌아가는게 아닌 휴면 상태에 들어간다.
• 그러다가 사용자 요청이 오는 순간 서버리스는 잠들어 있는 함수를 깨우고 실행시켜 요청한 작업을 수행하게 한다. 그리고 다시 함수는 잠에 들게 한다.

대기상태를 제외한 실제 사용 자원에 대해서만 청구가 되기 때문에 굉장히 경제적이며 자원을 효율적으로 사용할 수 있게 된다.

유저가 늘어나면 그만큼 실행 함수도 늘리는 식으로 처리

서버는 클라우드 제공 기업에서 전적으로 관리하기 때문에, 사용자는 스케일링, 업데이트, 보안 등 런타임 관리와 운영에 대해 시간을 소모하지 않고 핵심 제품에 집중할 수 있다

 

BaaS (Backend as a Service)

BaaS 시스템은 앱 개발에 있어서 필요한 다양한 기능들 (데이터베이스, 소셜서비스 연동, 파일시스템 등)을 API로 제공한다

비용은 api 사용 한 만큼 나간다.

서버의 이용자가 순식간에 늘어나도 알아서 확장이 된다.

장점은 개발 시간의 단축, 서버 확장 작업의 불필요함이다.

백엔드에 대해서 심오한 지식이 별로 없더라도, 아주 빠른 속도로 개발이 가능하다.

Firebase 에서는 실시간 데이터베이스를 사용하여 데이터가 새로 생성되거나, 수정되었을 때 소켓을 사용하여 클라이언트에게 바로 반영시켜주는 기능이 있는데, 만일 이러한 기능은 직접 개발하게 된다면 구조 설정에 꽤 많은 시간이 필요 할 수도 있는데 이를 단지 코드 몇줄만으로 구현 할 수 있게 해주는 것이다.

FaaS (Function as a Service)

FaaS는 프로그래밍 수준에서 Function 혹은 메소드를 서비스로 제공한다

사용자는 HTTP 요청을 통해 함수를 호출하고 원하는 파라미터를 전달하여 함수가 리턴 값이 있다면 리턴 값을 받거나 혹은 함수의 동작 시작 이벤트를 발생시킬 수 있다.

FaasS는 개발자가 프로그래밍 로직에만 집중 할 수 있도록 하는 서비스이다

함수들이 실행되는 횟수만큼 비용을 낸다

대표적인 서비스로는 AWS Lambda, MS Azure Function가 있다.

 

서버리스 장점

비용 절감

• 기존 IaaS나 PaaS와는 다르게 실제 사용량에 대해서만 비용이 청구되므로 경제적이다.
• 일정 주기, 조건 등의 이벤트에 함수를 호출하므로 리소스를 낭비하지 않게 되어서 비용이 저렴하다.
• 필요한 만큼 클라우드 기반 컴퓨팅 시간에 대해 비용을 지불

애플리케이션의 품질에 집중 가능

• 서버에 신경 쓸 필요가 없어지므로 사용자는 개발하는 애플리케이션의 품질 향상에 좀 더 집중할 수 있다.

높은 가용성과 유연한 확장

• 요청이 들어올때만 실행되고 동적으로 자원을 할당하기 때문에 가용성이 높고 스케일링에 신경 쓸 필요가 없다.
• 애플리케이션은 자동으로 확장될 수 있고, 개별 서버 단위가 아닌 사용단위(처리량, 메모리)를 설정/해제하여 용량을 조정할 수 있다.
• 동적으로 자원을 할당받아서 단기간 이벤트성 트래픽을 감당하는 경우 효과적

빠른 개발 배포

• 간단한 패키징 및 배포
• 릴리즈 주기 감소
• 높은 생산성
• 유지보수나 기능추가에 효율적이라 관리보다 개발에 집중할 경우

 

서버리스 단점

Cold Start

• 서버리스의 함수들은 요청이 없으면 수면 상태로 된다.그러다 만일 request가 와서 함수를 깨우고 실행하는데 아무래도 시간이 걸린다. 물론 1밀리초로 사람이 인지하기에 아주 짧은 시간이겠지만, 만일 0.01초라도 지연을 허용되지 않는 서비스일 경우는 서버리스는 좋은 선택이 아니다.
• 서버가 항시 요청에 대기하고 있는게 아니다보니 IaaS나 PaaS등의 모델보단 요청시간이 느리다.
• 실시간 서비스에는 적합하지 않음
• 프로젝트 규모가 작다면 별로 신경쓸만한 사항은 아니지만 규모가 커지거나 속도를 요구하는 프로젝트라면 서버리스는 좋은 선택이 아닐 수 있다.

긴 시간을 요하는 작업에 불리함

• 서버리스는 단순 작업(댓글 쓰기, 이메일 보내기 등)에는 적합하지만, 긴 시간을 요하는 작업(동영상 업로드, 데이터 백업 등)에는 굉장히 비효율적이다.
• 서버리스는 함수가 1회 호출 될 때 사용할 수 있는 메모리 및 시간에 제한이 있기 때문이다. 이에 따라 큰 기능을 잘게 나누어 구현해야 한다.

로컬 데이터를 사용할 수 없다. (Stateless)

• 서버리스는 무상태(Stateless)적인 기능으로 구현되어야 한다.
• 하나의 작은 기능으로 나뉘어진 함수들은 요청마다 새로 기동되어 호출되기 때문에 전후 상태를 공유할 수 없기 때문이다.
• 또한 변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없다.

클라우드 제공 플랫폼에 심하게 종속적

• 기존 IaaS나 PaaS모델은 플랫폼을 바꾸는게 어렵지 않지만 서버리스는 애플리케이션의 구조 자체를 바꾸기 때문에 다른 플랫폼으로 이전하는게 굉장히 힘들다.
• 이를 클라우드 서비스 업체에 종속적이라고 일컫는다.
• 이는 곧 사용중인 플랫폼의 가격이나 정책, 서비스 변경에도 민감하게 반응해야됨을 의미한다. 제공업체를 변경하면 새로운 벤더 사양에 맞추기 위해 시스템을 업그레이드하는 비용이 발생할 수도 있다.

 

서버리스 사용 사례

배치 작업

• 데이터를 실시간으로 처리하는게 아니라, 일괄적으로 모아서 처리하는 작업인 배치 작업의 경우 24시간 운영되던 서버가 필요 없으며, 특정 시간에 수행되던 기능을 서버리스로 구현하면 효율적이다.

자동화 작업

• 넷플릭스는 동영상 업로드 시 파일의 인코딩과 검증, 태깅 이후에 공개되는 작업을 AWS Lambda를 통해 자동화 했다.
• 실시간 비디오 스트리밍 앱 개발사인 페리스코프(Periscope)도 동영상의 유해성 여부를 확인하는 기능을 Lambda에서 운영하고 있다.

분석과 모니터링 기능

• CPU 사용량이 임계치에 도달했을 때 알림을 받거나 지속적으로 기록되는 로그를 분석하고 리포팅 하는데 서버리스를 사용할 수 있다.
• 미국 온라인 패션 매거진 버슬(Bustle)은 하루 1억건의 이벤트 처리와 데이터 분석 리포팅에 서버리스를 적용해 84%의 비용을 절감하였다.

챗봇(Chat-Bot) 서비스

• 챗봇을 서버리스로 구현하면 API 호출 시 요청을 처리하고 유연한 확장이 가능해 많은 사용자에게 안정적인 서비스를 제공할 수 있다.
• 슬랙(Slack)을 기반으로 하는 챗봇 어플리케이션이나 Amazon Echo 그리고 AWS Lambda를 이용한 음성인식 어플리케이션이 늘어나고 있다.