TIL - Serverless(서버리스)

한성봉·2021년 8월 16일
0

Serverless란?

서버리스(Serverless)를 직역하자면, “서버가 없다” 라는 의미가 있습니다. 하지만, 사실상 서버가 없는건 아닙니다. 그저, 특정 작업을 수행하기 위해서 컴퓨터를 혹은 가상머신에 서버를 설정하고, 이를 통하여 처리 하는 것이 아님을 의미합니다. 서버가 없다는 뜻보다는 서버를 관리할 필요가 없다는 뜻에 더 가깝습니다. 서버가 어떤 사양으로 돌아가고있는지, 서버의 갯수를 늘려야 할지, 네트워크는 어떤걸 사용할지, 이런걸 설정할 필요가 없습니다.

그 대신에, BaaS (Backend as a Service) 혹은 FaaS (Function as a Service) 에 의존하여 작업을 처리하게 됩니다. BaaS 를 제공하는 서비스 중에선, Firebase, Parse (지금은 서비스종료 됨), Kinvey 등이 있고, FaaS 를 제공하는 서비스 중에선, AWS Lambda, Azure Functions, Google Cloud Functions 등이 있습니다.

기존에는 서버의 하드웨어와 소프트웨어를 직접관리하는방식(*온프레미스) 으로 관리하였습니다. 하지만 이 방식은 시스템이 엄청 커지면 서버를 유지 할 관리자가 필요할 것이고 거기에 따른 인력과 비용이 든다는 단점이 있었습니다.

*온프레미스(on-premise) : 기업의 서버를 클라우드 같은 원격 환경에서 운영하는 방식이 아닌, 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식을 의미합니다.

IaaS 와 PaaS

이러한 단점을 보완하기 위해 IaaS(InfraStructure as a Service) AWS, Azura 같은 클라우드 서비스가 탄생했습니다. 더 이상 서버자원, 네트워크, 전력 등의 인프라를 모두 직접 구축할 필요가 없어졌습니다. 이후 IaaS 를 조금 더 추상화한 개념인 PaaS(Platform as a Service)가 탄생하였습니다. 대표적으로 AWS Elastic Beanstalk, Azure App Services 등이 있습니다. 이를 사용하면 Auto Scaling 및 Load Balancing 도 손쉽게 적용 할 수 있습니다. 하지만 서버의 물리적인(하드웨어) 부분은 클라우드 서비스를 제공하는 기업이 직접 관리해주지만 여전히 서버의 소프트웨어적인 부분은 사용자가 직접 관리를 해야 합니다. 서버에 깔린 운영체제 등을 업데이트하고, 데이터를 백업하고, 보안에도 신경 써야 하는 등 생각보다 귀찮은 일이 많습니다. 그리고 IaaS모델이나 PaaS모델은 실제 사용자에 관계없이 미리 결제한 용량에 따라 요금을 내야 합니다. 사용자가 1000명이 될 걸 예상하고 그에 맞는 용량의 서비스를 구입했다면 실제 사용자가 1000명이든 0명이든 같은 금액을 내야 하는 것입니다. 이는 크나큰 단점으로 다가옵니다.

서버리스는 동적으로 서버의 자원을 할당합니다. 즉 사용자가 없다면 자원을 할당하지 않고 대기하다가 요청이 들어오면 그 때 자원을 할당해서 요청을 처리하고 다시 대기 상태로 들어가게 됩니다. 자원을 효율적으로 사용할 수 있는 것입니다.

비용 또한 대기상태를 제외한 실제 사용 자원에 대해서만 청구가 되기 때문에 굉장히 경제적입니다. 게다가 이 서버는 클라우드 제공 기업에서 전적으로 관리하기 때문에 사용자는 스케일링, 업데이트, 보안 등 서버에 대해 일절 관리하거나 신경 쓸 필요가 없어집니다. 서버를 고려하지 않고 서비스와 애플리케이션에 집중할 수 있게 되는 것이죠.

요약하자면 '기존 클라우드 컴퓨팅 모델에 비해 경제적이고 가용성이 좋은 모델이 서버리스다' 라고 생각하시면 될 것 같습니다.

BaaS 와 FaaS

서버리스 방식에는 대표적으로 BaaS 와 FaaS 두가지로 나뉘어집니다.

  • BACKED-AS-A-SERVIECE(BaaS)
    • 애플리케이션 개발 시 요구되는 복잡한 백엔드 기능들을 개발자가 직접 개발하지 않고 클라우드 공급자가 제공하는 서비스를 이용해 쉽고 안정적으로 구현 하는 것
    • 단일 웹페이지나 모바일 앱 기반의 서비스에서 필요한 서버 기능들을 사용하기 위해 이용하는 써드파티(Third Party) 애플리케이션이지만 클라우드 서비스
    • 서비스 제공자로부터 미리 만들어진 백엔드 API를 제공받아 사용하는 형태
    • 데이터 저장 및 로드, 사용자 인증, 메시징, 소셜 서비스 등의 백엔드 기능을 완성된 API로 사용할 수 있다.
    • API 사용량 및 서버 사용 시간에 따라 비용을 지불한다.
  • Function-as-a-Service(FaaS)
    • 개발자가 사용자 정의 서버 측 로직을 작성하지만 클라우드 제공 업체가 관리를 전담하는 서버 컨테이너에서 실행 되는 서비스 기능
    • 서버 측 로직을 개발자가 직접 작성
    • 백엔드 코드를 함수형태로 클라우드 서버에 저장
    • 등록한 코드는 대기상태에 있다가 Request, 즉 특정 이벤트(트리거)가 있을 때 자동으로 호출 및 종료된다.
    • 호출한 함수의 횟수와 실행 시간에 따라 비용을 지불한다.
    • 대표적으로 AWS lambda가 있음.
    • 단점으로는 24시간 대기하는 서버에 비해 응답할떄 미세한 차이가 있음.
    • 응답의 미세한 차이도 존재해선 안되는 상황에서는 사용을 고려해봐야함.

장점 과 단점

장점

  • 서버 관리 리소스 감축
  • 서버 스펙을 유연하게 조정 가능 (스케일 업 & 스케일 다운 )
  • 요청 수와 이벤트 작업 량에 따른 과금
  • 배포의 편의
  • 모니터링 용이

단점

  • 단기적 프로세스에 적합, 단기 작업에 적합
  • 지연 시간의 문제
  • 서드파티 업체의 의존도가 높음
  • 디버깅의 어려움
  • 컨테이너 로드의 대기 시간(request 시 응답 대기시간)

결론

서버리스는 사이드 프로젝트(토이 프로젝트)나 최대한 빠르게 시제품(초기 서비스)을 런칭하고 싶은 경우에 추천드립니다. 이런 경우 기존 클라우드 컴퓨팅 모델에 비해 돈과 시간을 모두 절약할 수 있으므로 서버리스가 좋은 선택이 될 수 있습니다.

참고자료 : https://velopert.com/3543
참고자료 : https://brunch.co.kr/@sangjinkang/12

0개의 댓글