Today Nor Learned

# 서버리스 (Serverless)

#서버 #서버리스

# 서버리스 아키텍쳐 (Serverless Architectrue)

서버리스(Serverless)는 말 그대로 서버가 없다는 의미이다. 하지만, 정말로 서버가 존재하지 않는 건 아니고 사용자가 직접 서버를 관리하지 않아 신경 쓸 필요가 없는 경우를 뜻한다.

서버를 직접 관리할 필요가 없다는 의미는 IaaS와 같은 모델처럼 트래픽에 따라 사용자가 직접 서버의 가용량을 증/감 시킬 필요가 없다는 뜻과 같다.

즉, 서버리스 아키텍처(Serverless Architecture)란 서버를 직접 관리할 필요가 없는 아키텍처를 칭한다.

# 서버리스를 사용하는 이유

과거의 서버는 직접 하드웨어를 구입하고 전원으로 가동시켜 소프트웨어(서버 코드)를 하드웨어에 업로드 해 서비스를 운영했다. 즉, 서버의 하드웨어 + 소프트웨어를 직접 관리했다.

만약 정전이 되거나 서버 전원이 꺼진다면 서버가 다운되고, 유저 유입량에 따라 트래픽이 증가하면 메모리를 사와 서버 메모리를 관리해주어야 한다.

이에 따라 서버 컴퓨터를 빌려 하드웨어 관리는 해당 회사가 하고, 개발자는 코드와 제품 개발에 집중하도록 하기 위해 클라우드가 등장하였다.

# 클라우드 (IaaS / PaaS)

아마존의 AWS EC2를 통해 우리는 아마존에서 제공하는 가상 서버를 사용할 수 있다. 아마존에서 알아서 스토리지를 관리해주기 때문에 서버 성능 및 서버 다운의 문제를 걱정할 필요가 없어진 것이다. 하지만 여전히 서버의 소프트웨어적인 부분은 사용자가 직접 관리를 해야 한다.

운영체제 업데이트, 데이터 백업, 보안 등 관리 해주어야 하는 부분이 많기 때문에 서버를 제대로 가동시키기 위해서는 소프트웨어와 꾸준한 업데이트가 필요하다. 클라우드 컴퓨팅 서비스의 모델 유형 중 IaaS 모델이나 PaaS 모델은 실제 사용자에 관계없이 미리 결제한 용량에 따라 요금을 지불해야 한다. 사용자를 1000명으로 예상했다면 그에 맞는 용량의 서비스를 구입하고 실제 사용자는 상관없이 동일한 금액을 지불하게 된다.

또한 On-demand(쓴 만큼 지불) 서비스를 이용하더라도 대부분의 클라우드 서비스들은 사용자들이 서버를 이용하지 않더라도 가동 시킨 시간마다 결제가 되는 시스템이기 때문에 금전적이 부분에서 부담이 많이 되는 게 사실이다.

Info

IaaS (Infrastructure as a Service)

  • 서비스형 인프라
  • 스토리지, 네트워크 등 기본적인 컴퓨팅 자원을 서비스로 이용자에게 공급
  • 컴퓨터 자원만 공급하기 때문에 데이터나 네트워크, 애플리케이션은 사용자가 직접 관리하고 유지해야 한다.
  • 가상의 컴퓨터를 하나 임대하는 것과 비슷하다.
  • Network + Storage + Computing
  • ex) AWS EC2, Google Cloud Platform, Azure Virtual Machines, Naver Cloud Platform

PaaS (Platform as a Service)

  • 서비스형 플랫폼
  • 응용 프로그램 개발 도구, 컴파일러 등을 클라우드 서비스로 제공
  • 제공자가 지정해준 프로그래밍 언어와 툴로 소비자가 만든 클라우드 환경 또는 애플리케이션을 배포 가능
  • IaaS보다 비싼 비용
  • 인프라(Network + Storage + Computing) + OS + 프로그램 실행에 필요한 Runtime
  • ex) AWS Elastic Beanstalk, Google App Engine, Window Azure, Heroku

SaaS (Software as a Service)

  • 서비스형 소프트웨어
  • 제작되어진 응용 소프트웨어를 클라우드 서비스로 제공
  • 응용 프로그램은 웹 브라우저와 같은 Thine Client를 통해서 접근 후 제어가 가능하다.
  • 중앙에서 해당 소프트웨어를 관리해서 사용자가 일일이 업그레이드나 패치 작업을 할 필요가 없다.
  • 즉, 필요할 때 비용만 내면 어디서든 곧바로 사용할 수 있다.
  • ex) Google Mail, Youtube, Notion

# 서버리스 (Serverless)

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

서버리스 원리

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

대표적인 서버리스 서비스인 AWS Lambda의 경우 백만개의 함수 실행에 20센트의 금액만 지불하면 된다. 따라서 대기 상태를 제외한 실제 사용 자원에 대해서만 청구 되기 때문에 굉장히 경제적이며 자원을 효율적으로 사용할 수 있게 된다.

서버리스를 활용하면, 백엔드를 서버에 올리는 것이 아닌 백엔드를 작은 함수 단으로 쪼개서 아마존에서 직접 관리하는 서버로 올리게 된다. 즉, 서버는 클라우드 제공 기업에서 전적으로 관리하기 때문에, 사용자는 스케일링, 업데이트, 보안 등 런타임 관리와 운영에 대해 시간을 소모하지 않고 핵심 제품에 집중할 수 있다. 이렇게 서버리스를 활용하면 서버 운영에 소모되는 오버헤드를 줄일 수 있고, 개발자는 시간과 에너지를 확장시켜 안정적이고 훌륭한 제품을 개발할 수 있게 된다.

# 서버리스 모델 (BaaS / FaaS)

# BaaS (Backend as a Service)

보통 애플리케이션을 개발할 때 데이터를 저장하고, 다른 곳에서도 접근 및 공유하기 위해서 백엔드 서버 개발을 진행하게 된다. 하지만 서버 개발을 하다보면, 고려할 사항이 많아지고 유저가 늘어남에 따라 서버의 확장성 및 보안 또한 고려해야 한다.

BaaS 시스템은 개발에 있어서 필요한 다양한 기능들 (데이터베이스, 소셜 서비스 연동, 파일 시스템 등)을 API로 제공해 줌으로서, 개발자들이 서버 개발을 하지 않고도 필요한 기능을 쉽고 빠르게 구현할 수 있게 해주고, 비용은 API 사용량 만큼 지불하게 되는 원리이다.

즉, 클라우드 공급자가 백엔드 개발 환경까지 제공해주어 개발 시간의 단축, 서버 확장 작업의 불필요함이라는 장점을 가지고 있다.

대표적인 BaaS 서비스 중 하나로는 Firebase가 있다.

# FaaS (Function as a Service)

FaaS는 말 그대로 함수를 서비스로 제공한다는 의미이다. 사용자는 Rest API와 같은 HTTP 요청을 통해 함수를 호출하고 원하는 파라미터를 전달하여 함수가 리턴 값이 있다면 리턴 값을 받거나 혹은 함수의 동작 시작 이벤트를 발생시킬 수 있다. 만약 데이터베이스의 읽기 / 쓰기 등을 위한 함수 구문을 클라우드에 업로드 해둔다면, 어느 프로그램에서도 단순히 함수 호출을 통해 데이터베이스로부터 입출력이 가능하게 된다. 따라서 개발자가 프로그래밍 로직에만 집중할 수 있게 된다.

즉, FaaS는 프로젝트를 여러개의 함수로 쪼개서 (혹은 한 개의 함수로 만들어서) 매우 거대하고 분산된 컴퓨팅 자원에 준비해둔 함수를 등록하고, 이 함수들이 실행되는 횟수 (그리고 실행된 시간) 만큼 비용을 내는 방식을 말한다. 대표적인 서비스로는 AWS Lambda, MS Azure Function이 있다.

# 서버리스의 장단점

# 장점

# 1. 비용 절감

  • 기존 IaaS나 PaaS와는 달리 실제 사용량에 대해서만 비용이 청구되므로 경제적이다.
  • 이벤트 기반의 비용으로 일정 주기, 조건 등에 함수를 호출하므로 리소스를 낭비하지 않게 되어 비용이 저렴하다. (AWS Lambda의 경우 함수 100만번 실행 당 0.2 달러)
  • 자체 서버를 실행하고 관리하는 대신 필요한 만큼 클라우드 기반 컴퓨팅 시간에 대한 비용을 지불한다.

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

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

# 3. 높은 가용성과 유연한 확장

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

# 단점

# 1. Cold Start

  • 서버리스 함수는 요청이 없으면 휴면 상태가 된다. 그러다 요청이 와서 함수를 깨우고 실행하는데에 아주 짧은 0.01초라도 시간이 소요되기 때문에 지연을 허용하지 않는 서비스일 경우에는 서버리스는 좋은 선택이 아니다. 이러한 경우 때문에 AWS Lambda의 경우 어떤 함수가 자주 쓰이는지 판단해서 해당 함수는 아예 잠들지 않고 요청에 대응되도록 항상 실행 상태로 유지하는 경우도 있다.
  • 즉, 서버가 항시 요청에 대기하고 있는게 아니다보니 IaaS나 PaaS등의 모델보단 요청 시간이 느리다.
  • 실시간 서비스에는 적합하지 않다.

# 2. 긴 시간을 요하는 작업에 불리

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

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

  • 서버리스는 무상태(Stateless)적인 기능으로 구현되어야 한다.
  • 하나의 작은 기능으로 나뉘어진 함수들은 요청마다 새로 시작되어 호출되기 때문에 전후 상태를 공유할 수 없기 때문이다.
  • 또한 변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없다. (이는 서버리스 벤더에 따라 추가 서비스를 통해 해결할 수 있지만, AWS S3, Azure Storage 등 일반적인 서버리스는 불가능하다.)

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

  • 기존 IaaS나 PaaS 모델은 플렛폼을 바꾸는게 어렵지 않지만 (ex. AWS <-> Google Cloud) 서버리스는 애플리케이션의 구조 자체를 바꾸기 때문에 다른 플랫폼으로 이전하는게 힘들다.
  • 즉, 클라우드 서비스 업체에 종속적이다.
  • 이는 곧 사용중인 플랫폼의 가격이나 정책, 서비스 변경에도 민감하게 대응해야 됨을 의미한다.

← 타입스크립트 소개 →