서버리스(ServerLess) 개념

이번에 회사에서 HEIC 처리에 대한 방식에 대한 의논을 하게되었고, ImageMagick을 Docker에다가 넣어서 할지, 아니면 AWS Lambda 사용할지 결정하는 것에 대한 책임을 맡게 되었고, 이에 따라서 비용적인 측면과 그동안 몰랐던 개념에 대해 알아보는 시간을 가지려고 한다. 

이번 글에서는 서버리스 개념에 관한 내용을 알아보고자 하려 한다. 

개념

서버리스(Serverless) 직역하면 "서버가 없다"라는 뜻이 된다.

 

하지만 서버리스 모델에도 서버가 존재하지만, 애플리케이션 개발에서와 달리 추상화되어 있다.  

 

클라우드 제공업체가 서버 인프라에 대한 프로비저닝, 유지 관리, 스케일링 등의 일상적인 작업을 처리한다 -> 우리가 직접 서버를 관리하지 않아 신경쓸 필요없는 경우를 뜻한다. 

 

 

서버리스 어키텍처 (Serverless Architecture)

서버를 직접 관리할 필요 없는 아키텍처 칭한다.

 

서버리스는 특히, 사이드 프로젝트나 프로토타입을 출시할 때 빠르고 쉽게 제품을 출시할 수 있고, 돈도 매우 절약할 수 있다.

 

 

왜? 서버리스가 탄생하게 되었는가?

1. 온 프레미스

온프레미스(On-Premise)란 직접 서버를 설치하는 것을 일컫는다. 

 

내 집에 서버를 마련하고 싶다면, 하드웨어를 구입하고 거실에 놓고 전원을 꼽아 직접 가동시키고 소프트웨어(서버 코드)를 하드웨어에 업로드해 서비스 운영한다. 

 

즉, 서버의 하드웨어 부분과 소프트웨어 부분 둘다 직접 관리한다. 

 

서버 컴퓨터를 임대하는 방식으로 하드웨어 관리는 임대하는 회사가, 개발자는 본업인 코딩에 집중하기 위해 나온 기술 이것이 바로 클라우드다. 

 

2. 클라우드 (IaaS / PaaS)

클라우드 컴퓨팅이 등장하면서 덕분에 우리는 거실에 직접 서버를 설치하고 관리하는 대신에, 아마존에게 돈만 내면 아마존이 사용하는 최신식 서버를 빌려서 사용한다. 

 

정전이라던가 각종 사소한 사고에 서버가 다운되는 걱정을 할 필요가 없어졌고, 아마존이 알아서 스토리지를 늘려주고 관리하기 떄문에 서버 성능 역시 걱정할 필요 없어졌다. 

 

하지만 여전히 소프트웨어적인 부분은 사용자 직접 관리한다. 

서버에 깔린 운영체제 업데이트, 데이터를 백업, 보안에도 신경 써야한다.

 

즉, 하드웨어적인 부분만 빌리는거고 서버 자체는 텅 비어있어 서버를 돌리려면 이것저것 소프트웨어를 설치하고 업데이트해줘야 하고 관리해야한다. 

 

laaS, Paas 모델은 실제 사용자에 관계없이 미리 결제한 용량에 따라 요금을 내야 한다. 

사용자가 1000명이 될 걸 예상하고 그에 맞는 용량의 서비스 구매 시, 1000명이든 10000명이든 0명이든 똑같은 요금 지불해야한다.

 

3. 서버리스 

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

 

서버리스 원리

- 개발자가 서버리스에 업로드한 함수는 24시간 내내 돌아가는게 아닌 휴면 상태에 들어간다. 

- 그러다가 사용자 요청이 오는 순간 서버리스는 잠들어 있는 함수를 깨우고 실행시켜 요청한 작업을 수행하게 한다.

그리고 다시 함수는 잠에 들게 한다.

 

서버리스는 수행하는 함수만큼만 돈을 내면 된다. 

백만개 함수실행 20센트 비용 지불 

 

https://aws.amazon.com/ko/lambda/pricing/

서버리스 컴퓨팅 – AWS Lambda 요금 – Amazon Web Services

 

퍼포먼스 측면에도 문제가 없다. 유저가 늘어나면 그만큼 실행 함수도 늘리는 식으로 처리하기 때문이다. 

 

서버리스를 활용하면, 백엔드를 서버에 올리는 것이 아닌 백엔드를 작은 함수 단으로 쪼개서 아마존에서 직접관리하는 서버로 올리게 된다. 

 

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

 

서버리스 모델 (Baas, Faas)

 

Baas(Backend as a Service)

보통 우리가 모바일 혹은 웹 애플리케이션을 만들 때 데이터를 저장하고, 다른 기기에서도 접근하고, 공유하기 위해서 백엔드 서버 개발을 진행 

 

서버 개발을 하다보면, 고려할 사항이 꽤 많아진다. 유저가 늘어나게 된다면 서버의 확장도 고려해야하고, 보안성 또한 고려해야 하기 때문이다. 

 

그래서 탄생한 서비스가 Baas(Backend as a Service)이다

 

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

 

 

Faas(Function as a Service)

 

Faas는 Function as a Server 약자로 말 그대로 "함수를 서비스로 제공한다"라는 의미다.

 

여기서 함수가 뜻하는 바는 독자들도 알고 있듯이 프로그래밍 수준에서 Function 혹은 메소드등을 의미한다.

 

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

 

만약 데이터베이스의 읽기 / 쓰기등을 위한 함수 구문을 클라우드에 업로드해둔다면, 어느 프로그램에서도 단순히 함수 호출을 통해 데이터베이스로부터 입출력이 가능할 수 있다. 

 

따라서 S/W 개발자와 IT 업계가 프로그래밍 로직에만 집중 할 수 있도록 하는 것이 바로 Faas와 서버리스 주요한 개념이다. 

 

Faas는 프로젝트를 여러 함수로 쪼개서(혹은 한개의 함수로 만들어서), 매우 거대하고 분산된 컴퓨팅 자원에 준비해둔 함수를 등록하고, 이 함수들이 실행되는 횟수 (그리고 실행된 시간)만큼 비용을 내는 방식

 

Fass 생성 단계 

1. 사용자는 자신의 프로그램 내부에서 Faas 함수를 호출하는 구문을 삽입하고 프로그램을 실행하게 되면, Faas에게 Rest API 형식의 HTTP 요청이 가게 된다.

2. 그럼 Faas는 해당 함수를 저장소로부터 읽어오게 되고

3. 해당 함수를 컨테이너 혹은 가상머신으로 생성하게 된다. 

4. 다음 함수를 포함하고 있는 컨테이너 혹은 가상머신이 생성이 완료되면 함수를 실행하고 결과를 반환하거나 함수가 수행해야하는 동작을 수행하게 된다. 

5. 이후 일정시간 동안 함수의 호출이 없다면 함수를 포함하는 컨테이너 혹은 가상머신은 FaaS 시스템에 의해 삭제 된다. 

 

 

Baas / FaaS 차이점 정리 

 

BaaS 서비스 

- 애플리케이션 개발 시 요구되는 복잡한 백엔드 기능들을 개발자가 직접 개발하지 않고 클라우드 공급자가 제공하는 서비스를 이용해 쉽고 안정적으로 구현하는 것. 

- 서비스 제공자로부터 미리 만들어진 백엔드 API를 제공받아 사용하는 형태 

- 데이터 저장 및 로드, 사용자 인증, 메시징, 소셜 서비스 등의 백엔드 기능을 완성된 API로 사용

- API 사용량 및 서버 사용 시간에 따라 비용을 지불한다. 

 

Faas 서비스 

- 개발자가 사용자 정의 서버 측 로직을 작성하지만 클라우드 제공 업체가 관리를 전담하는 서버 컨테이너에서 실행되는 서비스 기능 

- 서버에서 수행될 기능들을 개발자가 직접 코드로 작성하여 등록한다. 

- 실행 가능한 코드(함수)를 미리 등록해놓았다가 특정 이벤트(트리거)가 발생하면 알아서 호출 및 종료되도록 한다. 

- PaaS는 전체 애플리케이션을 배포하여 서버에서 애플리케이션이 항상 실행되지만, FaaS는 애플리케이션을 더 작게 쪼갠 함수를 배포하며 작업을 마치거나 일정 시간이 지나면 종료된다는 차이점을 가지고 있다. 

- 호출한 함수의 횟수와 실행 시간에 따라 비용을 지불한다. 

 

 

 

서버리스 장단점 

 

장점)

1. 비용 절감

1. 실제 사용량에 대해서만 비용이 청구

2. 이벤트 기반의 비용으로, 일정 주기, 조건 등에 함수를 호출하므로 리소스를 낭비하지 않게 되어서 비용이 저렴하다. (AWS Lambda 경우 함수 100만번 실행당 0.2달러)

3. 자체 서버 실행하고 관리하는 대신 필요한 만큼 클라우드 기반 컴퓨팅시간에 대해 비용을 지불 

 

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

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

 

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

1. 요청이 들어올때만 실행되고 동적으로 자원을 할당하기 때문에 가용성이 높고 스케일링에 신경 x

2. 애플리케이션은 자동으로 확장될 수 있고, 개별 서버 단위가 아닌 사용단위(처리량, 메모리)를 설정/해제하여 용량을 조정

3. 동적으로 자원을 할당받아서 단기간 이벤트성 트래픽을 감당하는 경우 효과적 

 

4. 빠른 개발 배포

1. 간단한 패키징 및 배포

2. 릴리즈 주기 감소

3. 높은 생산성

4. 유지보수나 기능 추가에 효율적이라 관리보다 개발에 집중 

 

서비스리스 단점

1. ColdStart 

서버리스 함수들은 요청이 없으면 수면 상태로 된다. 즉, request가 와서 함수를 깨우는데 시간이 조금 발생한다. 

2. 서버가 항시 요청에 대기하고 있는게 아니여서 Iaas, PaaS 등의 모델보단 요청시간이 느리다.

3. 실시간 서비스에는 적합하지 않음

4. 프로젝트 규모가 작다면 별로 신꼉쓸만한 사항은 아니지만 규모가 커지거나 속도를 요구하면 좋은 선택은 아니다.

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

1. 서버리스는 단순 작업(댓글 쓰기, 이메일 보내기 등) 에는 적합하지만, 긴 시간을 요하는 작업(동영상 업로드, 데이터 백업 등)에는 굉장히 비효율적이다.

2. 서버리스는 함수가 1회 호출 될 때, 사용할 수 있는 메모리 제한이 있다. 

 

3. 로컬 데이터를 사용할 수 없다.

1. 서버리스는 무상태로 구현되어야 한다.

2. 하나의 작은 기능으로 나뉘어진 함수들은 요청마다 새로 기동되어 호출되기 때문에 전후 상태를 공유할 수 없기 때문이다.

3. 또한 변수와 데이터의 공유가 불가능하며, 데이터를 로컬 스토리지에서 읽고 쓸 수 없다.

 

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

1. 기존 IaaS, PaaS모델은 플랫폼을 바꾸는게 어렵지 않지만 서버리스는 애플리케이션 구조 자체를 바꾸기 때문에 다른 플랫폼으로 이전하기 힘들다. 

2. 클라우드 서비스 업체에 종속적이다. 

3. 플랫폼의 가격이나 정책, 서비스 변경에도 민감하게 반응해야됨을 의미한다.