서버리스란?

서버리스(serverless)란 개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델입니다.

서버리스 모델에도 서버가 존재하긴 하지만, 애플리케이션 개발에서와 달리 추상화되어 있습니다. 클라우드 제공업체가 서버 인프라에 대한 프로비저닝, 유지 관리, 스케일링 등의 일상적인 작업을 처리하며, 개발자는 배포를 위해 코드를 컨테이너에 패키징하기만 하면 됩니다.

서버리스 애플리케이션은 배포되고 나면 필요에 따라 자동으로 스케일 업되거나 스케일 다운됩니다. 퍼블릭 클라우드 제공업체의 서버리스 오퍼링은 일반적으로 이벤트 기반 실행 모델을 통해 온디맨드로 미터링됩니다. 그러므로 서버리스 기능이 유휴 상태일 때는 아무런 비용도 들지 않습니다.

서버리스는 클라우드 제공업체가 클라우드 인프라와 애플리케이션의 스케일링을 모두 관리한다는 점에서 다른 클라우드 컴퓨팅 모델과 차이를 보입니다. 서버리스 애플리케이션은 호출 시 온디맨드로 자동 시작되는 컨테이너에 배포됩니다.

표준 서비스로서의 인프라(Infrastructure-as-a-Service, IaaS) 클라우드 컴퓨팅 모델에서 사용자는 용량 단위를 사전 구매하게 됩니다. 즉, 애플리케이션을 구동하기 위해 퍼블릭 클라우드 공급업체에 상시 가동 중인 서버 구성 요소에 대한 비용을 지불해야 합니다. 수요가 많을 때 서버 용량을 스케일 업하고 더 이상 그만큼의 용량이 필요하지 않을 때 스케일 다운하는 것 역시 사용자의 책임입니다. 애플리케이션을 구동하기 위해 필요한 클라우드 인프라는 애플리케이션이 사용되지 않을 때에도 활성화된 상태입니다.

그에 반해 서버리스 아키텍처에서는 애플리케이션이 필요할 경우에만 시작됩니다. 이벤트가 구동을 위한 애플리케이션 코드를 트리거하면 퍼블릭 클라우드 공급업체가 신속하게 해당 코드에 대한 리소스를 할당합니다. 코드 실행이 종료되면 비용도 청구되지 않습니다. 비용과 효율성이라는 이점 이외에도, 서버리스는 애플리케이션 스케일링 및 서버 프로비저닝과 같은 일상적이고 사소한 태스크에서 개발자의 부담을 덜어줍니다.

서버리스를 활용하면 운영 체제 및 파일 시스템 관리, 보안 패치, 부하 분산, 용량 관리, 스케일링, 로깅, 모니터링과 같은 일상적인 태스크를 모두 클라우드 서비스 제공업체에 이관할 수 있습니다.

완전한 서버리스 애플리케이션은 물론, 일부는 서버리스로 일부는 전통적인 마이크로서비스 구성 요소로 이루어진 애플리케이션을 구축할 수도 있습니다.

서버리스 모델에서 클라우드 제공업체는 코드를 프로덕션으로 바로 배포할 수 있는 사용자를 대신하여 물리 서버를 구동하고 리소스를 신속하게 할당합니다.

서버리스 컴퓨팅 서비스는 일반적으로 서비스로서의 백엔드(Backend-as-a-Service, BaaS)와 서비스로서의 기능(Function-as-a-Service, FaaS)이라는 두 그룹으로 나뉩니다.  

BaaS는 개발자가 다양한 제3사 서비스와 애플리케이션에 액세스할 수 있게 해줍니다. 예를 들어, 클라우드 제공업체는 인증 서비스와 추가 암호화, 클라우드 액세스 가능한 데이터베이스 및 상세한 데이터 사용량을 제공할 수 있습니다. BaaS를 활용하는 경우 서버리스 기능은 일반적으로 애플리케이션 프로그래밍 인터페이스(Application Programming Interface, API)를 통해 호출됩니다.

개발자가 서버리스를 언급하는 경우에는 FaaS 모델을 가리키는 경우가 더욱 일반적입니다. FaaS의 경우 개발자는 사용자 정의 서버 측 로직을 작성할 수 있지만, 이러한 로직은 클라우드 서비스 제공업체가 전체를 관리하는 컨테이너에서 구동됩니다. 

주요 퍼블릭 클라우드 공급업체에서는 하나 이상의 FaaS 오퍼링을 제공합니다. 여기에는 Amazon Web Services의 AWS Lambda, Microsoft Azure의 Azure Functions, Google Cloud의 여러 오퍼링, IBM Cloud의 IBM Cloud Functions 등이 포함됩니다. 

일부 조직에서는 쿠버네티스용 Knative 프로젝트에 구축된 Red Hat® OpenShift® Serverless를 비롯해, 오픈소스 서버리스 플랫폼을 사용하여 자체적인 FaaS 환경을 운영하기도 합니다.

서비스로서의 기능(FaaS)은 이벤트 기반 컴퓨팅 실행 모델로, 개발자가 작성하는 로직은 플랫폼에서 전체를 관리하는 컨테이너로 배포된 후 온디맨드로 실행됩니다.

BaaS와 달리 FaaS는 사전 작성된 서비스 라이브러리에 의존하지 않고 사용자 정의 애플리케이션을 생성하는 개발자에게 더 많은 제어 권한을 제공합니다. 

코드는 클라우드 제공업체가 관리하는 컨테이너에 배포됩니다. 이러한 컨테이너에는 다음과 같은 특징이 있습니다.

• 스테이트리스(stateless): 데이터 통합이 더욱 간소화됨
• 일회성: 매우 단기간에 실행 가능
• 이벤트에서 트리거: 필요에 따라 자동으로 실행 가능
• 전체 관리형: 클라우드 제공업체가 관리를 전담하므로 상시 가동 애플리케이션 및 서버 대신 필요한 만큼만 비용 지불

FaaS를 활용하면 개발자는 API를 통해 서버리스 애플리케이션을 호출할 수 있고, FaaS 제공업체는 이를 API 게이트웨이를 통해 처리합니다.

서버리스 아키텍처는 즉시 시작할 수 있는 비동기식, 스테이트리스 애플리케이션에 이상적입니다. 또한 드물게 예측할 수 없는 수요 급증이 있는 경우에도 좋습니다.

수신되는 이미지 파일을 일괄 처리하는 태스크를 예로 들 수 있습니다. 드물지만 한꺼번에 대량의 이미지가 도착하는 경우를 대비해야 하기 때문입니다. 또는 데이터베이스에 수신되는 변경 사항을 모니터링하여 품질 표준에 반하는 변경 사항을 확인하거나, 자동으로 변환하는 등 일련의 기능을 적용하는 태스크도 마찬가지입니다.

서버리스 애플리케이션은 수신 데이터 스트림, 채팅 봇, 예정된 태스크, 비즈니스 로직과 관련된 활용 사례에도 이상적입니다.

일반적인 서버리스 활용 사례로는 백엔드 API, 웹 애플리케이션, 비즈니스 프로세스 자동화, 서버리스 웹사이트, 여러 시스템 전반에 대한 통합이 있습니다.

자동화된 인프라에서 컨테이너화된 애플리케이션을 실행하는 방법으로, 쿠버네티스 컨테이너 오케스트레이션 플랫폼이 서버리스 환경을 구동하는 데 널리 사용되는 것은 그리 놀라운 일이 아닙니다. 그러나 쿠버네티스 자체만으로는 기본적으로 서버리스 애플리케이션을 구동할 수 없습니다.

Knative는 서버리스 애플리케이션을 배포, 실행, 관리하기 위해 쿠버네티스에 구성 요소를 추가하는 오픈소스 커뮤니티 프로젝트입니다.

서버리스 Knative 환경에서는 코드를 Red Hat OpenShift와 같은 쿠버네티스 플랫폼에 배포할 수 있습니다. Knative를 활용하면 컨테이너 이미지로서 코드를 패키징한 다음 시스템으로 전달하면 됩니다. Knative는 인스턴스를 자동으로 시작하고 중단하므로 필요할 때에만 코드가 구동됩니다.

Knative는 다음 3가지 구성 요소로 이루어져 있습니다.

• 구축 - 소스 코드를 컨테이너에 구축하는 유연한 접근 방식
• 제공 - 요청 기반 모델을 통해 컨테이너를 신속하게 배포하고 자동 확장하여 온디맨드 기반 워크로드 처리 가능
• 이벤트 - 애플리케이션을 활성화하기 위해 이벤트를 사용하고 생산하는 인프라 애플리케이션은 자체 애플리케이션의 이벤트, 다양한 제공업체의 클라우드 서비스, 서비스로서의 소프트웨어(Software-as-a-Service, SaaS) 시스템 및 Red Hat AMQ 스트림 등 다양한 소스로부터 트리거됩니다.

이전의 서버리스 프레임워크와는 달리, Knative는 모놀리식 애플리케이션에서 마이크로서비스 및 사소한 기능에 이르기까지 모든 현대적인 애플리케이션 워크로드를 배포하도록 설계되었습니다.

단일 서비스 제공업체가 제어하는 FaaS 솔루션을 대체할 수 있는 Knative는 쿠버네티스를 구동하는 모든 클라우드 플랫폼에서 실행 가능합니다. 여기에는 온프레미스 데이터 센터도 포함됩니다. 덕분에 조직에서는 더욱 민첩하고 유연하게 서버리스 워크로드를 구동할 수 있습니다.

장점

• 서버리스 컴퓨팅은 개발자 생산성을 높이고 운영 비용을 줄일 수 있습니다. 서버 프로비저닝 및 관리와 같은 일상 업무의 부담을 줄여, 개발자가 애플리케이션에 더 많은 시간을 할애할 수 있습니다. 
• 서버리스는 개발자가 프로비저닝하기 위한 작업에 필요한 인프라를 명시적으로 설명할 필요를 줄여줌으로써 DevOps 도입을 지원합니다.  
• 제3사 BaaS 오퍼링의 모든 구성 요소를 통합해 애플리케이션 개발을 더욱 간소화할 수도 있습니다.
• 서버리스 모델에서 운영 비용이 낮아지는 이유는 항상 자체 서버를 실행하고 관리하는 대신 필요한 만큼 클라우드 기반 컴퓨팅 시간에 대해 비용을 지불하기 때문입니다.

단점

• 자체 서버를 실행하지 않거나 자체 서버측 로직을 제어하지 않는 데 따른 단점이 있습니다.
• 클라우드 제공업체는 자사 구성 요소가 상호작용하는 방법을 엄격히 제한할 수 있어, 사용자 시스템의 유연성과 커스터마이징 수준에 영향을 주게 됩니다. BaaS 환경의 경우 개발자는 코드 제어 권한이 없는 서비스에 의존해야 할 수 있습니다.
• IT 스택의 이러한 측면에 대한 제어 권한을 이전하면 벤더 종속성 문제도 발생할 수 있습니다. 제공업체를 변경하면 새로운 벤더 사양에 맞추기 위해 시스템을 업그레이드하는 비용이 발생할 수도 있습니다.

서버리스 아키텍처와 FaaS의 개념은 컨테이너와 온디맨드 클라우드 서비스의 인기와 함께 발전해 나갔습니다. Red Hat과 공동으로 작성된 451 Research 리포트는 서버리스의 진화를 3단계로 나눕니다.

서버리스의 "1.0" 단계에는 여러 가지 제한 사항이 있었기 때문에, 일반적인 컴퓨팅에는 그리 이상적이지 않았습니다. 서버리스 1.0의 특징은 다음과 같습니다.

• HTTP 및 소수의 기타 소스
• 기능만 가능
• 제한된 실행 시간(5~10분)
• 오케스트레이션 없음
• 로컬 개발 환경 제한

쿠버네티스의 출현은 "서버리스 1.5"의 시대로 이어졌고, 이때부터 많은 서버리스 프레임워크가 컨테이너를 자동 스케일링하기 시작했습니다. 서버리스 1.5의 특징은 다음과 같습니다.

• Knative
• 쿠버네티스 기반 자동 스케일링
• 마이크로서비스 및 기능
• 간편하게 로컬에서 디버그 및 검증
• 다중 언어 지원(Polyglot) 및 이식 가능

현재는 통합과 상태가 추가된 "서버리스 2.0"의 시대가 다가오고 있습니다. 제공업체에서는 서버리스를 일반적인 비즈니스 워크로드에 활용할 수 있도록 부족한 부분을 채워나가고 있습니다. 서버리스 2.0의 특징은 다음과 같습니다.

• 기본 상태 처리
• 엔터프라이즈 통합 패턴 사용
• 고급 메시징 기능
• 엔터프라이즈 PaaS와 통합
• 엔터프라이즈 레디 이벤트 소스
• 상태 및 통합