Serverless computing 란 무엇인가

 서버리스 컴퓨팅에 대한 소개와 도입배경, 현황을 통해 서버리스 컴퓨팅에 대한 정보를 제공한다. 

1. 소프트웨어 아키텍처 패러다임 변화

최근 시스템은 서버에서 가상화를 넘어 컨테이너로 진화하고 있고, 모놀리틱 아키텍처가 마이크로서비스 아키텍처로 점점 변화하고 있다. 또한 서버 구동 방식도 사용자의 요청을 응답할 때까지 대기하는 구조에서 이벤트에 의해 동작하는 이벤트 드리븐 방식으로 진화하고 있다. 이 중 어플리케이션 개발 및 운영의 단순화라는 측면에서 서버리스 컴퓨팅이 새로운 아키텍처 설계 패러다임으로 부각되고 있다.



그림. 클라우드로 인한 기술 패러다임의 변화 


On-premise 는 서버를 구매하고 운영체재를 설치하고, 배포환경을 구축하는데 수 개월이 소요된다. 서비스의 수요 예측에 실패하면 새로운 서버를 추가 구매하거나 서버 사양을 높여야 하는데 여기에 소요되는 시간도 수 개월이다. 그래서 이런 상황을 막고자 주로 오버스팩의 사양을 구매하게 되고 이로 인해 낭비되는 자원이 많다. 
가상머신은 서버 가상화 기술로 On-premise에 비해 서비스 배포 환경을 구축하는데 소요되는 시간을 수 분내로 줄일 수 있고 인프라 제반 관리에 드는 비용도 줄일 수 있다. 또한 필요에 따라 가상서버 수나 사양을 조절하여 자원 효율성을 증대할 수 있다. 


하지만 가상머신은 운영체재 설정, 보안 패치 등의 관리가 필요한데 서버가 늘어날수록 관리가 어렵고 시스템 부하에 따라 자동으로 서버를 추가 및 제거하는 오토스케일링Auto Scaling 기능으로는 꾸준한 트래픽이 증가하는 서비스는 해결이 되겠지만 불예측적이고 폭발적인 트래픽을 처리하기에는 역부족이다. 트래픽이 몰릴 때 서버가 자동으로 추가되어도 수 분의 시간이 소요되고 트래픽을 감당할 만큼의 서버가 추가되기도 전에 트래픽이 감소할 것이기 때문이다. 

컨테이너는 운영체재 가상화 기술로 물리서버나 가상머신을 더 효율적으로 사용할 수 있고 수 초내로 배포가 가능하다. 서비스(서버)가 추가될 때마다 반복적으로 작업했던 서버 초반 설정도 불필요하고 운영체재 패치 작업도 간소화되며 짧은 배포 시간과 오토스케일링 기능으로 불규칙적이고 폭발적인 트래픽도 유연하게 처리할 수 있다. 하지만 컨테이너 기술은 상대적으로 어렵고 복잡해서 컨테이너 기술을 보유한 인재가 없는 곳이라면 컨테이너 기술 도입은 부담이 될 수밖에 없다. 

서버리스 컴퓨팅은 프로그래밍 언어 런타임 가상화 기술로 서버 인프라, 운영체재 설정 등의 관리 요소는 클라우드 서비스 업체(CSP)에서 담당하고 사용자는 코드에만 집중할 수 있어 생산성이 증가하고 시스템 관리 비용을 최소화할 수 있다. 또한 초당 수 천개의 요청까지 자동으로 확장되고 사용한 컴퓨팅 시간에 대해서만 비용이 발생하여 가상머신이나 가상머신 기반 컨테이너에 발생하는 유후 시간 비용이 없어 비용 효율적이다. 

간단히 표현하자면 아래 표와 같다.

특징

On-premise

Virtual Machine

Container

Serverless Computing

배포 시간

Week

Minutes

Seconds

Milliseconds

관리

Everything

OS
Middleware
Source

Middleware
Source

Source

확장

Order
Manual

Manual

Manual

Auto

비용

one-time

Hour or Minute

Hour or Minute

Second
Execute times

고가용성

이중화 필요

이중화 필요

이중화 필요

Auto

추상화

해당없음

하드웨어

OS

프로그래밍언어런타임

표. 소프트웨어 구축 환경 별 비교 


2. 서버리스 컴퓨팅 정의

AWS에서 2014년 Lambda 서비스를 선보이며 업계에서 서버리스 컴퓨팅 Serverless Computing 이란 용어를 사용했다. 서버리스 컴퓨팅이란 실제로 서버가 존재하지 않는다는 의미가 아니라 사용자가 서버 설정 없이 함수코드만으로 어플리케이션과 서비스를 구축하고 실행할 수 있음을 의미한다. 함수 서비스라 FaaS Functions as a Services 또는 Function PaaS 로 불리기도 한다. 
서버리스 컴퓨팅을 제공하는 CSP에서는 기존 서버에 필요한 서버 프로비저닝, 패치, 확장 등의 관리를 수행하여 사용자가 자신의 서비스 로직에 집중할 수 있기 때문에 생산성을 향상시킬 수 있다. 또한 코드를 실행한 만큼만 비용이 발생하여 운영 비용을 절감할 수 있다.

서버리스 컴퓨팅은 퍼블릭 CSP의 서비스를 이용하거나 오픈소스 플랫폼으로 자신의 서버에 직접 설치하여 사용할 수 있다. 
대표적인 서버리스 컴퓨팅 서비스 업체들은 자신의 서비스들을 아래와 같이 소개한다.

  • AWS Lambda

서버에 대한 걱정 없이 코드 실행. (생산성 향상)

사용한 컴퓨팅 시간에 대해서만 비용을 지불합니다. (사용한 만큼 비용 지불)

이벤트에 응답하여 코드를 실행하고 자동으로 기본 컴퓨팅 리소스를 관리하는 서버 없는 컴퓨팅 서비스입니다. (이벤트 드리븐, 자동 확장, 서버리스)

  • Azure Functions

서버리스 아키텍처로 앱을 더 신속히 구축. (서버리스)

이벤트 중심의 서버리스 컴퓨팅 환경으로 개발을 가속화하십시오. (이벤트 드리븐, 생산성 향상)

필요에 따라 확장*하고, 사용한 만큼만 비용을 지불하면 됩니다. (사용한 만큼 비용 지불)

  • Google Cloud Functions

이벤트 기반 서버리스 컴퓨팅 플랫폼 (이벤트 드리븐, 서버리스)

클라우드에서 코드를 실행하는 가장 간편한 방법 (생산성 향상)

자동확장, 우수한 가용성, 내결함성. 프로비저닝, 관리, 패치 또는 업데이트가 필요한 서버 없음 (자동 확장)

코드를 실행하는 만큼만 지불. 클라우드 서비스 연결 및 확장 (사용한 만큼 비용 지불)

  • IBM Cloud Functions

수신 이벤트에 대한 응답으로 함수를 실행하고 사용하지 않을 때는 비용이 들지 않는 FaaS 플랫폼입니다. (이벤트 드리븐, 사용한 만큼 비용 지불)

별도의 서버 설정, 구성이나 유지보수 없이도 코드 작성과 최상의 솔루션 빌드에 집중할 수 있습니다. (서버리스, 생산성 향상)

액션 인스턴스는 요구에 정확히 맞게 스케일링된 후 사라집니다. (자동 확장)

CSP들이 공통적으로 설명하는 내용은 서버리스, 이벤트 드리븐**, 생산성 향상, 자동 확장, 사용한 만큼 비용 지불로 동일하다. 이 5가지가 서버리스의 큰 특징이라 할 수 있다. 

*) Azure에서 '필요에 따라 확장하고' 라는 애매한 표현을 사용한 이유는 서버리스 컴퓨팅의 비용 모델이 사용한 만큼 과금되며 자동 확장되는 Consumption plan과 자신의 VM 상에서 지정한 만큼 확장되는App service plan 2가지이기 때문이다. 이 비용모델에 대한 내용은 5.1.3 가격 에서 자세히 작성한다. 

**) 이벤트 드리븐Event-Driven 이란 이벤트에 반응하여 동작을 처리하는 것을 의미한다. 

3. 서버리스 컴퓨팅 현황 분석

세계 최대 IT리서치 기관인 Gartner의 작년과 올해의 10대 PaaS Hype Cycle을 비교해보면 Function PaaS (서버리스 컴퓨팅 플랫폼)이 한창 핫한 기술에서 성숙/구체화 기술로 넘어가려는 것을 확인할 수 있다. 
2014년에 AWS에서 서버리스 컴퓨팅 서비스인 Lambda를 처음 발표했고 2016년에 MS Azure와 Google Cloud, IBM이 서버리스 컴퓨팅 서비스를 발표하면서 서버리스 컴퓨팅의 관심이 높아졌다. 2017년에는 Oracle과 Pivotal이 오픈소스 서버리스 컴퓨팅 프로젝트를 진행했고 2018년에는 Redhat이 오픈소스 서버리스 컴퓨팅 서비스를 발표했다. 또한 서버리스 컴퓨팅을 관리할 많은 도구들이 생겨나며 계속해서 발전하고 있다. 
서버리스 컴퓨팅은 생산성 증대, 이벤트에 의한 자동 확장, 고가용성, 비용 절감 등의 매력적인 장점이 있는 반면에 구동시간 제한, 동시 실행 수 제한, 공급업체 종속성, 부족한 문서, 신기술이 가진 불안정함 등의 무시할 수 없는 단점들이 존재하여 아직까지 크게 확산되지는 않았지만 차츰 안정화되고 관리 툴들이 계속해서 발전하여 2021년 안에 성숙/구체화 기술이 될 것이라 예상한다. 
서버리스 컴퓨팅의 발전으로 궁극적으로 소프트웨어의 구축의 패러다임이 될 수 있기에 이에 대한 대비가 필요하고 서버리스 컴퓨팅이 적합한 분야에는 적극 도입하거나 검토가 필요하다.


 
그림. Gartner Hype Cycle for PaaS, 2017/2018 

4. 서버리스 컴퓨팅 동작 방식

서버리스 컴퓨팅은 아래와 같은 방식으로 동작한다. 



그림. 서버리스 컴퓨팅 동작원리 

  1. 이벤트 트리거에 의해 서버리스 컴퓨팅을 호출한다.
  2. 서버리스 컴퓨팅이 설치된 서버에서 함수를 처리하기 위한 컨테이너를 할당한다.
  3. 특정 스토리지에서 함수의 코드를 무결성 체크 후 할당된 컨테이너에 등록하고 이벤트 트리거에서 전달한 이벤트 소스와 함께 함수를 호출한다.
  4. 함수 코드를 수행한다.
  5. 결과값을 내보낸다.
  6. 일정 시간이 지나면 할당된 컨테이너를 회수한다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

파일처리(한번에 모두읽기, 라인단위로 읽기, 쓰기, 리스트처리, 특정길이만큼 읽기)

이미지
텍스트 파일 한 번에 모두 읽기 (Utility 타입)   대용량 파일일 때는 메모리가 부족할 수 있으므로 ' 텍스트 파일 라인 단위로 읽어서 처리 ' 방식을 사용 public static String read(String filePath) throws IOException {        StringBuilder  stringBuilder;      FileReader     fileReader     = null ;      BufferedReader bufferedReader = null ;      try {          stringBuilder  = new StringBuilder();          fileReader     = new FileReader(filePath);          bufferedReader = new BufferedReader(fileReader);          String line;          while ((line = bufferedReader.readLine()) != null )            ...
자세한 내용 보기

AWS 가용성,확장성

이미지
1.  개요 On-Premise 환경과 마찬가지로 클라우드 환경 하에서 아키텍처 설계 시 연속성 있는 업무 서비스를 제공하기 위하여 시스템 인프라에 대한 고가용성을 고려하여야 한다. 일반적으로 고가용성 확보는 업무 서비스가 수행되는 인프라 구성요소 별로 존재하는 Single Point of Failure(이하 SPoF)를 제거하여, 특정 구성요소에 대한 장애 시 에도 정상 구성요소를 이용하여 정상적인 서비스가 수행되도록 구성하는 것이다.  그러나, On-Premise 환경에서는 초기 물리 장비 도입부터 고가용성을 고려하여 도입을 수행하고 이를 바탕으로 아키텍처 설계가 수행되지만, 이미 물리적인 인프라 환경이 구축되어있는 클라우드 환경의 경우 개별 구성요소에 대한 가용성은 일정 수준 이상 확보가 되어있다고 할 수 있다. 따라서, 클라우드 환경 내에서의 가용성 확보는 구성요소에 대한 가용성 확보보다는 전체 아키텍처 측면에서의 가용성 확보 설계를 중점적으로 수행하는 것이 바람직하다. 또한 가용성 확보 관점에서 클라우드 환경의 특징 중 하나인 [처리 용량을 자유롭게 확장 가능한 아키텍처]와 [장애 시 자동 복구 가능한 아키텍처]을 고려한 어플리케이션/DBMS 등의 설계를 수행하여야 한다. 본 가이드에서는 클라우드 환경 내의 SPoF 구간에 대하여 살펴보고 이를 해결할 수 있는 방안을 설명한다. 2.  가용성 확보 방안 2.1.  센터 On-Premise 환경에서 센터는 평상 시 서비스를 제공하는 주 센터와 주 센터 전체 장애 또는 주 센터에서 운영중인 주요 장비 장애 시 이를 대신하여 업무 처리를 할 수 있도록 하는 DR 센터로 운영 하는 경우가 일반적이다. 해당 센터 간에는 대부분 네트워크로 연결이 되어있으며, 주 센터에서 생성되고 변경되는 데이터에 대하여 실시간/근실시간 동기화를 수행하여 센터 장애 시에 가용성을 확보하고 있다.  클라우드 환경에서의 센터는 특히 본 가이드의 대상이 되는 AWS의 경우 앞서 설명한 바와 같...
자세한 내용 보기

Serverless computing 도입시 고려사항

이미지
  1.  공급업체 종속성 서버리스 컴퓨팅같은 PaaS 서비스는 공급업체 종속성 Vender Lock-in  을 피할 수 없다. PaaS 서비스를 사용하다가 다른 클라우드 업체나 On-Premise로 이전하는 것은 막대한 비용이 발생한다. 또한 서버리스 컴퓨팅 은 제공하는 업체별로 사용 방법이 다르고 트리거 서비스가 각 공급사 서비스별로 연계되지 않기에 멀티 클라우드 전략이 어렵다. 한 예로 AWS Kinesis 라는 데이터 스트림 서비스는 AWS Lambda 와 연결하여 사용하나 Azure Functions 나 Apache OpenWisky에는 연계할 수 없다. 또한 특정 국가에서는 시스템의 서버가 반드시 해당 국가에 위치해야 하는데 CSP의 데이터 센터는 모든 국가에 위치해있지는 않다. 이런 상황에서는 시스템 수출 시 서버리스 컴퓨팅 뿐만 아니라 다른 PaaS 서비스들도 직접 구현해야 할 상황이 발생할 수 있다. 공급업체 종속성을 피하려면 오픈소스 서버리스 컴퓨팅 플랫폼을 이용 해야 한다.  2.  공급업체 마다 상이한 SLA 서버리스 컴퓨팅의 장점 중 하나는 서버 설정 등의 관리를 공급업체에서 진행하는 것이다.  하지만 공급업체의 실수로 장애가 발생할 수 있다.  한 예로 AWS의 Lambda 서비스 초기엔 잘 사용하던 함수가 몇 시간 동안 동작하지 않은 적이 있었고 AWS의 최초 서비스인 S3도 2017년 2월에 장애가 발생하여 이에 연결된 Lambda가 동작하지 않은 적도 있었다. [1]  이런 상황에 대비가 필요하고 필요에 따라서 보상을 받기 위해 SLA나 이용약관을 확인해야 한다.  AWS Lambda는 SLA가 없어 AWS의 문제로 인해 장애가 발생해도 보상 받을 수 없다.  또한 AWS의 Lambda 서비스 이용 약관에는 “AWS Lambda에 업로드된 고객의 컨텐츠가3개월 간 실행되지 않으면 30일 전에 고지하고 삭제할 수 있으며 이에 대해 어떠한 책임도 ...
자세한 내용 보기