Serverless란?

Serverless

• 개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델
  • 트래픽에 따라 사용자가 직접 서버의 가용량을 증/감 시킬 필요가 없음
• 서버리스 모델에도 서버가 존재하긴 하지만, 애플리케이션 개발에서와 달리 추상화
• 기존 클라우드 컴퓨팅 모델에 비해 경제적이고 가용성이 좋은 모델

특징

• 클라우드 제공업체가 서버 인프라에 대한 프로비저닝, 유지 관리, 스케일링 등의 일상적인 작업을 처리
  • 개발자는 배포를 위해 코드를 컨테이너에 패키징하기만 하면 됨
• serverless 애플리케이션은 배포되고 나면 필요에 따라 자동으로 스케일 업되거나 스케일 다운
• 동적으로 서버의 자원을 할당
  • 사용자가 없으면 자원을 할당하지 않고 대기하다가 요청이 들어오면 그 때 자원을 할당해서 요청을 처리하고 다시 대기 상태로 들어감
  • 대기상태를 제외한 실제 사용 자원에 대해서만 비용이 청구되기 때문에 굉장히 경제적

 

Serverless의 구분

• Serverless는 FaaS와 BaaS로 구분
• FaaS와 BaaS의 차이는 직접 백엔드를 구현했느냐 아니냐의 차이

 

FaaS(Function as a Service)

• FaaS는 Function, 즉 함수를 서비스로 제공
• 사용자가 작성한 코드를 Serverless 제공자의 서버에 업로드하게 되면 해당 서버는 업로드한 코드를 함수 단위로 나누어 대기상태로 두게 됨
• 요청이 들어오면 서버가 대기상태에 두었던 함수를 실행시켜 처리한 다음 작업이 끝나면 다시 대기상태로 만듬 
• 비용은 함수 호출 횟수에 따라 청구
• 함수 호출 후 일정 시간이 경과되어도 다시 대기상태로 들어감
  • AWS Lambda의 경우는 5분
• 대표 서비스 : AWS Lambda, MS Azure Function

 

BaaS(Backend as a Service)

• BaaS는 백엔드 개발에 필요한 여러 기능을 API로 제공하는 서비스
• SNS연동이나 DB와 같이 백엔드에 필요한 기능들을 사용자가 직접 구현 할 필요 없이 제공하는 API로 해당 기능을 구현할 수 있게 해 주는 것
• 클라우드 공급자가 백엔드 개발 환경까지 제공해줌
• 대표 서비스 : Firebase

 

장점

1. 가격
   • 기존 IaaS나 PaaS와는 다르게 실제 사용량에 대해서만 비용이 청구되므로 경제적
2. 애플리케이션의 품질에 집중 가능
   • 서버에 신경 쓸 필요가 없어지므로 사용자는 개발하는 애플리케이션의 품질 향상에 좀 더 집중할 수 있음
3. 높은 가용성과 유연한 확장
   • 요청이 들어올때만 실행되고 동적으로 자원을 할당하기 때문에 가용성이 높고 스케일링에 신경 쓸 필요가 없음

 

단점

1. Cold Start
   • 아무래도 서버가 항시 요청에 대기하고 있는게 아니다보니 IaaS나 PaaS등의 모델보단 느림
   • 프로젝트 규모가 작다면 별로 신경쓸만한 사항은 아니지만 규모가 커지거나 속도를 요구하는 프로젝트라면 Serverless는 좋은 선택이 아닐 수 있음
2. 클라우드 제공 플랫폼에 심하게 종속적
   • 기존 IaaS나 PaaS모델은 플랫폼을 바꾸는게 어렵지 않지만 Serverless는 애플리케이션의 구조 자체를 바꾸기 때문에 다른 플랫폼으로 이전하는게 굉장히 힘듬
   • 이는 곧 사용중인 플랫폼의 가격이나 정책, 서비스 변경에도 민감하게 반응해야됨을 의미
3. 긴 시간을 요하는 작업에 불리함
   • Serverless는 단순 작업에는 적합하지만 긴 시간을 요하는 작업에는 굉장히 비효율적
   • 서버리스는 함수가 1회 호출 될 때 사용할 수 있는 메모리 및 시간에 제한이 있기 때문
   • 작업이 끝나지 않은채로 해당 시간이 지나면 작업이 끝날때까지 일정 시간마다 계속 함수를 다시 호출하므로 굉장히 비효율적

 

Knative와 Serverless 쿠버네티스

자동화된 인프라에서 컨테이너화된 애플리케이션을 실행하는 방법

 

쿠버네티스

• 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼
• 선언적 구성과 자동화를 모두 용이
• 크고, 빠르게 성장하는 생태계를 가지고 있음
• 쿠버네티스 컨테이너 오케스트레이션 플랫폼이 서버리스 환경을 구동하는 데 널리 사용
• 그러나 쿠버네티스 자체만으로는 기본적으로 서버리스 애플리케이션을 구동할 수 없음

 

 

Knative

• Serverless 애플리케이션을 배포, 실행, 관리하기 위해 쿠버네티스에 구성 요소를 추가하는 오픈소스 커뮤니티 프로젝트
• Serverless Knative 환경에서는 코드를 Red Hat OpenShift와 같은 쿠버네티스 플랫폼에 배포할 수 있음
• Knative를 활용하면 컨테이너 이미지로서 코드를 패키징한 다음 시스템으로 전달하면 됨
• Knative는 인스턴스를 자동으로 시작하고 중단하므로 필요할 때에만 코드가 구동
• Knative는 3가지 구성 요소
  • 구축
    • 소스 코드를 컨테이너에 구축하는 유연한 접근 방식
  •  제공
    • 요청 기반 모델을 통해 컨테이너를 신속하게 배포하고 자동 확장하여 온디맨드 기반 워크로드 처리 가능
  • 이벤트
    • 애플리케이션을 활성화하기 위해 이벤트를 사용하고 생산하는 인프라 애플리케이션은 자체 애플리케이션의 이벤트, 다양한 제공업체의 클라우드 서비스, 서비스로서의 소프트웨어 시스템 및 Red Hat AMQ 스트림 등 다양한 소스로부터 트리거됨

사용

• 이전의 Serverless 프레임워크와는 달리, Knative는 모놀리식 애플리케이션에서 마이크로서비스 및 사소한 기능에 이르기까지 모든 현대적인 애플리케이션 워크로드를 배포하도록 설계
• 단일 서비스 제공업체가 제어하는 FaaS 솔루션을 대체할 수 있는 Knative는 쿠버네티스를 구동하는 모든 클라우드 플랫폼에서 실행 가능
• 여기에는 온프레미스 데이터 센터도 포함
• 덕분에 조직에서는 더욱 민첩하고 유연하게 서버리스 워크로드를 구동할 수 있음

 

 

Serverless 역사

서버리스 아키텍처와 FaaS의 개념은 컨테이너와 온디맨드 클라우드 서비스의 인기와 함께 발전해 나감
서버리스의 "1.0" 단계에는 여러 가지 제한 사항이 있었기 때문에, 일반적인 컴퓨팅에는 그리 이상적이지 않았습니다.

 

Serverless 1.0

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

 

쿠버네티스의 출현은 "서버리스 1.5"의 시대로 이어짐
이때부터 많은 서버리스 프레임워크가 컨테이너를 자동 스케일링하기 시작

 

Serverless 1.5

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

 

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

 

Serverless 2.0

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