Serverless opensource : Knative

Serverless Architecture 에서 Function 의 Scale to/from Zero

지난 포스팅에서, Serverless 아키텍처와 FaaS 에 대하여 다루었다. 이번에는 Serverless 아키텍처를 구현한 오픈소스인 Knative 에 대해 정리해본다.

Functions as a Service 에서 사용자는 인프라적인 요소를 고려하지 않고, 선택한 런타임에 사용자가 작성한 비즈니스 로직을 구동하여 실행시키고 그 결과를 전달 받을 수 있다. 이를 위해 FaaS 서비스를 제공하는 Cloud Service Provider (CSP)는 동적으로 사용자의 호출에 반응하여, 런타임 실행 환경의 구동 및 사용자 코드의 배포 등을 수행해야 하며, 사용자가 더 이상 리소스를 호출하지 않을 경우, 실행 환경과 관련된 인프라 자원을 회수하여 리소스 사용을 절감할 수 있어야 한다.

그렇다면 CSP의 입장에서 실제로 이러한 기능을 제공하는 상품을 구현해 본다면 어떨까? 먼저 사용자의 요청을 받아야 하므로 서버가 필요하며, 비정기적인 사용자의 요청을 받을 수 있어야 하므로 이 서버는 항상 구동되어 있어야 한다. 사용자의 요청이 없을 때 런타임 실행 환경은 구동되어 있지 않으므로, 요청이 온 시점에서 이 서버는 '사용자의 요청에 대해서 연결 상태를 유지하면서, 뒤에서는 실행 환경을 구동 시키고, 구동이 완료된 후에 사용자의 요청을 다시 전달해주는 작업까지 제공하는 기능'이 필요하다. 이 기능을 그림으로 표현하면 다음과 같다. 

1) HTTPS 등의 사용자 요청이 왔을 때, 실행 환경이 준비될 때까지 이를 버퍼에 보관 (Queueing)
2) 동적으로 런타임 실행 환경을 구동 
3) 실행 환경에서 사용자 어플리케이션을 배포
4) 사용자 요청을 어플리케이션에 전달하며, 실행 결과를 사용자에게 전달

또한 클라우드 서비스 환경에서 사용자 요청이 많아질 경우, 2)의 실행 환경을 더 많이 구동(Scale-out)할 수도 있어야 하고 4)의 사용자 전달 과정에서 여러 실행 환경에 대한 route handling 또한 필요하다.

추가로, 이렇게 실행 환경이 구동되어 있지 않은(zero) 상태에서, 사용자의 요청에 반응하여 실행 환경을 구동하는 것을 'scale from zero'라고 하며, 반대로 더 이상 사용자의 요청이 없어서 다시 실행 환경을 삭제하여 리소스를 절감하는 것은 'scale to zero'라고 표현한다.

---

Serverless opensource : Knative

knative는 위 과정을 코드 레벨에서 구현한 오픈소스라고 보면 이해하기 쉽다. Google 내부 프로젝트로 개발되어, 2022년 3월에 CNCF(Cloud Native Computing Foundation)에 기증되었고 현재(2023.11)는 Incubating 단계인 serverless opensource 프로젝트이다. 이름과 로고에서 알 수 있듯이, Kubernetes 에 기반한 Serverless 오픈소스인데, 내부적으로는 2개의 주요 프로젝트로 구성되어 있다.

knative Serving 프로젝트는 사용자 요청에 반응하여 실행되는 어플리케이션의 라이프사이클을 관리한다. 위 1)~4)에 해당하는 단계가 모두 Serving 에 해당하며, scale-from/to-zero 와 관련된 핵심 기능만을 구현할 경우, Eventing 모듈 없이 Serving만으로도 FaaS를 구현할수 있다.

Knative Eventing 프로젝트는, 서비스 요청에 대한 다양성을 제공한다. 위 1)의 단계에서는 예를 들기 위해 HTTPS 등의 사용자 요청을 언급했으나, 실제 FaaS 서비스의 사용에서 어플리케이션을 실행시키는 트리거의 주체는 Cronjob 을 통하 주기적인 요청이 될 수도 있고 Kafka, RabbitMQ와 같은 Message Queue 서비스에 이벤트가 될 수도 있다. Eventing 프로젝트를 통해 이러한 다양한 이벤트를 사용할 수 있으며, 요청을 필터링 할 수도 있다.

---

Knative Serving

Knative Serving 의 아키텍처는 다음과 같다.

Serving 모듈을 구성하는 기본 컴포넌트는 Service/Routes/Configuration/Revision 으로 이 컴포넌트들은 모두 kubernetes CRD로 구성되어 있다. 각 컴포넌트들을 표현하는 공식 페이지의 글은 다음과 같다.

" A Route provides a named endpoint and a mechanism for routing traffic to Revisions, which are immutable snapshots of code + config, created by a Configuration, which acts as a stream of environments for Revisions."
→ Route 는 명명된 끝점과 트래픽을 Revision 으로 라우팅하기 위한 메커니즘을 제공. Revision 은, Revision 을 위한 환경 스트림 역할을 하는 Configuration 에 의해 생성된 코드 + 구성의 변경 불가능한 스냅샷.

" A Service acts as a top-level container for managing a Route and Configuration which implement a network service."
→ Service  는 네트워크 서비스를 구현하는 Route 및 Configuration 을 관리하기 위한 최상위 컨테이너 역할을 수행.

Component	Responsbilities
Service (KSVC)	워크로드의 전체 수명 주기를 자동으로 관리 트래픽을 항상 최신 개정 또는 고정된 개정으로 라우팅하도록 서비스를 정의 가능 Route 와 Configuration 을 캡슐화(Encapsulates)
Routes	Network endpoint 를 하나 이상의 revision 에 매핑. 부분 트래픽 및 명명된 경로를 포함하여 여러 가지 방법으로 트래픽을 관리 가능 백분율(%) 기준으로 트래픽 분할 지원 일부 또는 모든 revision에 대하여 하위 도메인 할당 가능
Configurations	배포에 대해 원하는 상태를 유지 (상태의 설정 관리) 코드와 구성을 명확하게 분리하고 Twelve-Factor App 방법론을 따름. Configurations 을 수정하면 새 Revision 이 생성.
Revisions	워크로드에 대한 각 수정 사항에 대한 코드 및 구성의 특정 시점 스냅샷. 개정판은 변경할 수 없는 객체이며 유용한 기간 동안 유지 가능. Knative Serving Revisions 는 들어오는 트래픽에 따라 자동으로 확장 및 축소

위 Serving 모듈을 이용하여, 서버리스 컨테이너의 신속한 배포가 가능하며, Scale-to-Zero 와 같은 자동 확장 기능을 제공할 수 있다.

---

Knative Eventing

Eventing 모듈은, 앞에서 서술한 Knative Serving 과 독립적으로 작동하는 이벤트 지원 API들의 집합체이다. 이 이벤트에는 Kubernetes 이벤트나, Knative Serving 자체의 이벤트를 포함하며, 연동을 지원하는 다양한 외부 요청들이 포함된다.

한 예로 PingSource 이벤트의 경우, Linux Cronjob Scheduling과 같은 기능을 제공한다. 사용자가 PingSource 이벤트 객체(CRD)를 생성하면서 스케쥴링 시간과 호출 대상 엔드포인트를 설정하면, 일정 시간마다 주기적으로 Knative Serving 의 지정 엔드포인트(Ex: Function)를 호출하게 된다.

knative에서는 다양한 이벤트 소스를 제공하며 개략적인 표는 하단의 공식 페이지에서 확인 가능하다. (https://knative.dev/docs/eventing/sources/#knative-sources)

serving과 eventing에 대한 상세 내용은 별도 페이지에서 다루기로 한다.