[클라우드 네이티브] 서버리스 기술 아키텍처 분석

1. 서버리스란?

1. 서버리스 기술 소개

이미지-20230628181023269

서버리스 (서버리스 아키텍처)는 상태 비저장 컴퓨팅 컨테이너에서 실행되는 개발자가 구현한 서버측 로직을 의미합니다. 기록됩니다.

서버리스는 개발자가 서버(물리적 머신, 가상 머신, 컨테이너 등)를 직접 다룰 필요가 없습니다. 호스트가 없다는 이점은 서버 유지 관리 측면에서 사용자의 운영 오버헤드를 크게 줄이고 서버 업그레이드에 대해 걱정할 필요가 없으며 호스트가 없다는 것은 애플리케이션에서 모니터링해야 하는 메트릭이 다르다는 것을 의미합니다. 이는 사용되는 대부분의 기본 서비스가 더 이상 CPU, 메모리, 디스크 크기 등과 같은 기존 메트릭을 게시하지 않기 때문입니다. 따라서 더 이상 아키텍처의 기본 운영 세부 사항에 특별한 주의를 기울일 필요가 없습니다.

AWS 클라우드 아키텍처 전략 담당 부사장 인 Adrian Cockcroft는 서버리스를 정의하는 간단한 방법을 제시한 적이 있습니다 . 그리고 A Berkeley View on Serverless Computing 논문의 설명: Serverless = FaaS + BaaS .

위의 서버리스 아키텍처의 기술 논리 다이어그램을 참조하면 서버리스 아키텍처가 타사 서비스(서비스로서의 백엔드 또는 "BaaS"라고도 함) 또는 임시 컨테이너에서 실행되는 사용자 지정 코드(기능 서비스 또는 "FaaS") 애플리케이션 이므로 FaaS와 BaaS는 서버리스의 두 가지 특정 구현으로 간주될 수 있습니다 . 함수는 서버리스 아키텍처에서 추상 언어 런타임의 최소 단위입니다. 이 "use-as-you-go" 아키텍처에서는 기능을 실행하는 데 필요한 CPU, RAM 또는 기타 리소스의 양이 아니라 기능을 실행하는 데 걸리는 시간에 대한 것입니다. 해당 기능이 실행되는 시간.

다음은 서버리스의 장점과 현재의 몇 가지 단점에 대한 간략한 분석입니다.

서버리스 아키텍처의 장점은 다음과 같습니다.

더 빠른 개발 속도 : IaaS 및 PaaS와 비교할 때 서버리스 기술을 기반으로 하는 FaaS 플랫폼은 기존 애플리케이션을 실행하는 과정에서 고객 비즈니스 코드의 논리 부분을 추상화하고 추출합니다( 사용자 기능 코드 + BaaS의 패턴 형성 ). 클라우드 플랫폼 표준 개발 기능 세트에 따르면 개발자는 최하위 계층에서 어떤 프레임워크가 사용되는지 신경 쓸 필요가 없으며 비즈니스 로직만 개발하면 됩니다. 그 중 개발자는 비즈니스 코드에 집중할 수 있습니다.
기본 제공 자동 배포 : 서버리스 아키텍처는 일반적으로 플랫폼에서 제공되는 API 및 다양한 도구를 통해 기본 제공 자동 배포를 구현합니다. 일반적으로 이러한 도구는 소스 코드 리포지토리의 변경 사항을 수신하고 코드가 업데이트되면 자동으로 프로덕션에 배포합니다. 배포하는 동안 도구는 코드를 하나 이상의 기능으로 패키징하고 FaaS 플랫폼에 업로드하고 요청에 대한 응답으로 적절한 URL 및 이벤트 트리거로 구성합니다. 이러한 방식으로 각 요청은 해당 기능의 실행을 트리거하여 코드의 실시간 배포를 실현합니다.
리소스 오버헤드 감소: 함수가 요청되지 않은 경우 함수 인스턴스는 0입니다. 요청이 있으면 클라우드 플랫폼이 신속하게 인스턴스를 끌어와 트래픽을 전달합니다. 더 중요한 것은 기능은 요청에 따라 청구될 수 있다는 것입니다. 즉, 기존 서비스는 인스턴스 사양에 따라 청구되는 반면 각 호출에 대해 한 번만 지불하면 됩니다.

서버리스 아키텍처의 몇 가지 단점 :

상태 관리: 무료 확장을 달성하려면 상태 비저장이 필수입니다. 상태 저장 서비스의 경우 서버리스를 사용하면 유연성이 손실됩니다. 상태 저장 서비스는 스토리지와 상호 작용해야 하므로 필연적으로 대기 시간과 복잡성이 증가합니다.
컴퓨팅 환경은 고도로 표준화되어 있습니다. 서버리스 컴퓨팅 애플리케이션이 실행되는 기본 서버 및 운영 환경은 사용자에게 투명하며 사용자는 선택하거나 최적화할 수 없습니다. 서버리스 컴퓨팅 프로그램이 실행되는 환경은 고도로 표준화되어 있으며 특정 운영 환경, 특정 서버 버전 또는 특정 하드웨어 리소스에 의존하는 일부 종속성은 호환성을 보장하기 어렵습니다.
로컬 테스트 : 현재 서버리스 아키텍처를 사용하는 개발 프로세스에는 아직 성숙한 디버깅 및 개발 도구가 부족합니다.
콜드 스타트 시간

2. 서버리스 핵심 기술

(1) 이벤트 기반

서버리스 의 "실행할 때만 컴퓨팅" 기능은 "엄격한" 이벤트 기반 컴퓨팅임을 의미합니다. 이벤트 기반 프로그래밍 설계 이 설계 모델은 인터랙티브 프로그램(Interactive program)의 경우에 착안한 것입니다. 이것은 또한 시스템이 프로그래밍 모델에 큰 변화가 있음을 의미합니다. 데스크톱 프로그램 및 웹 프런트 엔드 응용 프로그램과 같은 GUI 프로그램을 작성할 때 버튼, 링크 및 기타 구성 요소에 대한 사용자의 작업을 수신하여 해당 처리 논리를 시작합니다. 이는 사용자가 사용할 때만 사용자의 행동에 응답하는 서버리스와 유사합니다.

(2) 컨테이너 기술

컨테이너 기술은 일반적으로 Serverless 아키텍처에서 Docker를 통해 구현됩니다. 클라우드 서비스 공급자는 각 기능에 대한 코드를 별도의 Docker 컨테이너로 패키징합니다. 컨테이너 내에서 코드가 다른 기능이나 애플리케이션의 작동에 영향을 주지 않고 격리된 환경에서 실행되도록 할 수 있습니다.

요청이 도착하면 클라우드 서비스 공급자는 컨테이너 내부의 기능을 실행하고 완료되면 컨테이너를 파괴합니다. 이 방식은 각 기능의 실행 시간이 짧고 너무 많은 리소스를 차지하지 않도록 하여 리소스 낭비를 방지하는 데 도움이 됩니다.

컨테이너 기술을 사용함으로써 서버리스 아키텍처는 기능이 격리된 환경에서 실행되고 증가하는 수요를 충족하기 위해 빠르게 확장될 수 있도록 보장할 수 있습니다. 동시에 컨테이너 기술은 애플리케이션의 보안을 향상시킬 수 있습니다. 액세스해서는 안 되는 데이터에 액세스하지 못하도록 기능의 권한을 제한할 수 있기 때문입니다.

3. 일반적인 기술 아키텍처와의 비교

(1) 기존 아키텍처-VS-서버리스

전통적인 Java 웹 애플리케이션의 기술 아키텍처는 다음 그림과 같을 수 있습니다.

이러한 아키텍처는 애플리케이션 로직 없이 프론트엔드를 매우 가볍게 만들 수 있으며 사용자 인터페이스를 렌더링하고 HTTP를 통해 백엔드로 요청을 보내는 일만 담당하며 모든 데이터 작업은 백엔드에서 수행합니다. 자바 프로그램. 이러한 아키텍처는 상대적으로 개발하기 쉽지만 유지 관리하기는 매우 복잡합니다.프론트 엔드 개발과 백엔드 개발 모두 매우 전문적인 인력, 환경 구성 및 데이터베이스 유지 및 응용 프로그램 업데이트 및 업그레이드를 위한 특수 인력이 필요합니다.

서버리스 아키텍처에서는 더 이상 세션 상태를 서버 측 코드에 저장할 필요가 없지만 NoSQL에 직접 저장하여 애플리케이션을 상태 비저장 상태로 만들고 탄력적인 확장을 돕습니다. 프런트 엔드는 BaaS를 직접 사용하여 백엔드의 코딩 요구 사항을 줄일 수 있습니다.이 아키텍처는 본질적으로 응용 프로그램 개발의 인건비를 줄이고 인프라 유지 관리의 위험을 줄이며 클라우드 기능을 사용하여 확장 및 빠른 반복을 촉진합니다.

（2）MicroService -VS- 서버리스

마이크로서비스(MicroService)는 소프트웨어 아키텍처 분야의 또 다른 핫 토픽이다. 마이크로서비스가 단일 책임과 기능에 초점을 맞춘 작은 기능 블록을 기반으로 하고 모듈화를 사용하여 복잡한 대규모 애플리케이션을 결합하는 경우 서버리스 아키텍처가 더 많은 "코드 조각화" "소프트웨어 아키텍처 패러다임"을 제공할 수 있다고 생각할 수 있습니다. 이를 FaaS(Function as a Services)라고 합니다. 소위 "함수"(Function)는 마이크로서비스보다 작은 프로그램 단위를 제공합니다. 예를 들어 마이크로서비스는 고객을 위해 모든 CRUD 작업을 수행하는 데 필요한 코드를 나타낼 수 있는 반면 FaaS의 "기능"은 고객이 수행하는 모든 작업(생성, 읽기, 업데이트 및 삭제)을 나타낼 수 있습니다. "계정 생성" 이벤트가 트리거되면 해당 "함수"가 AWS Lambda 함수를 통해 실행됩니다. 이러한 수준의 의미에서 서버리스 아키텍처를 FaaS 개념과 간단히 동일시할 수 있습니다.

서버리스는 본질적으로 마이크로서비스 아키텍처를 보완합니다 . 서버리스 애플리케이션에는 자체 게이트웨이, 데이터베이스 및 인터페이스가 있으며 선호하는 언어(서비스 공급자에 따라 제한됨)를 사용하여 서비스를 개발할 수도 있습니다. 즉, Serverless는 이 상황에서 완벽한 마이크로서비스 인스턴스가 될 수 있습니다.

(3) 서버풀 클라우드 -VS- 서버리스 클라우드

기존 클라우드 플랫폼과 서버리스 플랫폼의 세 가지 주요 차이점은 다음과 같습니다.

** 분리된 컴퓨팅 및 스토리지. **스토리지 및 컴퓨팅은 별도로 확장되고 프로비저닝되며 독립적으로 가격이 책정됩니다. 일반적으로 저장소는 별도의 클라우드 서비스에서 제공되며 컴퓨팅은 상태 비저장입니다.
** 리소스 할당을 관리하지 않고 코드를 실행합니다. **사용자는 리소스를 요청하는 대신 코드 조각을 제공하고 클라우드는 해당 코드를 실행할 리소스를 자동으로 제공합니다.
할당된 자원이 아닌 사용된 자원에 비례하여 지불합니다 . 기본 클라우드 플랫폼의 특정 차원(할당된 VM의 크기 및 개수 등)이 아닌 실행과 관련된 특정 차원(실행 시간 등)을 기준으로 과금이 이루어집니다.

기존 클라우드 플랫폼과 서버리스 플랫폼의 기타 기술적 세부 사항 간의 일부 비교(AWS를 예로 들음):

이미지-20230207174034204

4. 서버리스 산업 엔지니어링 관행

AWS Lambda: AWS Lambda Cloud Computing Service 소개_AWS Lambda-AWS Cloud Service 사용 방법(amazon.com)
Alibaba Cloud 함수 컴퓨팅 플랫폼: 함수 컴퓨팅 FC_Serverless Computing_Serverless_Containers and Middleware-Alibaba Cloud(aliyun.com)
오픈 소스 FaaS 플랫폼
등.

둘, FaaS

1、IaaS -> CaaS -> PaaS -> FaaS

이미지-20230207111003095

IaaS(서비스로서의 인프라): 서비스로서의 인프라. 인프라(컴퓨팅, 스토리지, 네트워크 등)를 서비스로 제공하는 것을 말하며, 이를 기반으로 사용자가 자신만의 애플리케이션 환경을 구축할 수 있습니다.
CaaS(서비스로서의 컨테이너): 서비스로서의 컨테이너. 사용자에게 컨테이너 기술을 제공하는 것을 말하며, 사용자는 컨테이너를 통해 자신의 애플리케이션을 실행할 수 있습니다.
PaaS(서비스로서의 플랫폼): 서비스로서의 플랫폼. 개발 플랫폼과 응용 프로그램 관리 도구를 제공하는 것을 말하며 사용자는 응용 프로그램의 개발 및 운영에만 주의를 기울이면 되며 기본 인프라에는 주의를 기울일 필요가 없습니다.
서버리스: 서버리스 아키텍처. 즉, 애플리케이션을 실행하기 위해 서버 리소스를 명시적으로 관리하고 구성할 필요가 없으며 모든 기본 관리 및 유지 관리는 플랫폼 공급자의 책임입니다. 사용자는 자신의 코드를 업로드하고 코드가 자동으로 실행될 때까지 기다리기만 하면 됩니다. 서버리스 = FaaS + BaaS . BaaS(백엔드 서비스)
FaaS(Function as a Service) Function as a Service: 클라우드 컴퓨팅 서비스로서 개발자가 전체 애플리케이션이 아닌 클라우드 제공업체에 개별 기능을 배포할 수 있습니다. 클라우드 공급자는 요청이 도착하면 자동으로 기능을 실행하고 요청이 완료되면 폐기합니다. 그리고 "FaaS"에서 가장 중요한 "F", 즉 함수는 어떻게 정의되는가? OpenFaaS 프로젝트의 창시자인 Alex의 다음 CloudFunction 정의를 참조할 수 있습니다.

2. FaaS의 핵심 기술

FaaS에서 직면해야 하는 몇 가지 주요 기술 솔루션에 대해 간략하게 논의해 보겠습니다.

(1) 탄력적 확장(오케스트레이션 기반으로 K8s)

Auto-scaling은 함수 컴퓨팅 비용 최적화의 핵심 부분입니다 Auto-scaling의 주요 대상은 함수 인스턴스입니다(일부 FaaS 아키텍처에는 함께 시작되는 MQ 트리거 인스턴스도 포함됨). Elastic Scaling의 주요 프로세스는 다음과 같습니다. 지표 감지(탄력적 Scaling 트리거링) -> Scaling Scaling 정책 계산 스케줄링 -> 최종 Scaling 적용 , 위 단계는 k8s HPA와 매우 유사하지만 기능의 특성에 따라 구현 메커니즘이 변경되었습니다. 이러한 방식으로 k8s의 현재 기능도 FaaS의 탄력적 확장 요구 사항을 효과적으로 충족할 수 있으므로 오픈 소스 커뮤니티의 Serverless/FaaS 제품은 기본적으로 k8s./FaaS 제품 개발을 기반으로 구현됩니다.

다음은 k8s 기반 오픈 소스 프로젝트 OpenFaaS의 아키텍처 다이어그램입니다.

이미지-20230628180924633

탄력적 확장과 관련하여 커뮤니티에는 Kubernetes의 HPA 외에도 이벤트 기반 아키텍처 탄력적 프레임워크 KEDA 및 KPA(Knative 구현)가 있습니다. KEDA가 해결하는 핵심 문제는 이벤트 기반 아키텍처(event-triggered scaling) 하의 탄력적 확장과 0 -> 1, 1 -> 0의 인스턴스 문제입니다. KEDA는 Kubernetes Metrics Server로 작동하여 사용자가 다음을 수행할 수 있도록 합니다. 전용 Kubernetes 사용자 지정 리소스 정의를 사용하여 자동 확장 규칙을 정의합니다.

KEDA는 클라우드 및 에지에서 실행될 수 있으며 기본적으로 Kubernetes 구성 요소(예: Horizontal Pod Autoscaler)와 통합될 수 있으며 외부 종속성이 없습니다. KEDA의 전체 구조는 다음과 같습니다.

이미지-20230207163102070

(2) 함수 런타임 및 함수 로딩 메커니즘

FaaS 런타임은 함수 실행을 위한 리소스와 보안 격리된 언어 런타임 환경을 제공해야 하며 호출 이벤트, 컨텍스트 정보 및 응답 정보를 함수에 전달해야 합니다. 함수 런타임에는 다중 언어 액세스를 지원하는 통합 인터페이스 사양과 함수 인스턴스의 수명 주기를 유지하기 위한 전용 모니터링 및 관리 구성 요소(함수 인스턴스로 시작된 에이전트와 유사)가 있어야 합니다 . 업계의 성숙한 FaaS 플랫폼인 AWS의 Lambda를 예로
들면 함수 런타임 아키텍처는 아래 그림과 유사합니다. 오른쪽 점선 상자는 RuntimeAgent ( 즉 , 기능 처리를 위한 API Endpoints) 호출 프로세스 중 기능 프로세스를 모니터링 및 관리하고 실행 데이터를 수집하여 분석 및 기록을 위해 기능 인스턴스 외부의 HostAgent (Lambda 서비스)에 업로드합니다. 프로세스 에는 사용자의 비즈니스를 실행하는 기능 프로세스가 포함됩니다. FaaS 플랫폼에서 제공하는 로직과 Runtime 환경.

Lambda 런타임 API - AWS Lambda

Lambda는 Runtime 및 Runtime API를 통해 여러 언어를 지원합니다 . 런타임 API 및 런타임은 API 사양을 통해 호출되며 사용자 함수는 초기화, 로드 및 호출과 같은 작업을 완료하기 위해 런타임의 특정 인터페이스 기능만 구현하면 됩니다. 또한 런타임은 Lambda와 함수 간에 호출 이벤트, 컨텍스트 정보 및 응답을 전달하기 위한 언어별 환경을 제공합니다. 사용자는 Lambda 플랫폼에서 제공하는 런타임을 사용하거나 자체 런타임을 구축할 수 있습니다.
각 주요 프로그래밍 언어 버전에는 python3.10 또는 nodejs18.x와 같은 고유한 런타임 식별자가 있는 별도의 런타임이 있습니다. 새로운 주요 언어 버전을 사용하도록 함수를 구성하려면 런타임 식별자를 변경해야 합니다. AWS Lambda는 주요 릴리스 간에 이전 버전과의 호환성을 보장할 수 없으므로 이는 고객 임의 작업입니다.
컨테이너 이미지로 정의된 함수의 경우 컨테이너 이미지 생성 시 런타임 및 Linux 배포판을 선택할 수 있습니다 . 런타임을 변경하려면 함수의 구성을 업데이트하고 새 컨테이너 이미지를 생성해야 합니다. 런타임은 Amazon Linux 배포와 쌍을 이룹니다. 기본 실행 환경은 함수 코드에서 액세스할 수 있는 추가 라이브러리 및 환경 변수를 제공합니다.
k8s 클러스터에서 전체 실행 환경 기능 인스턴스는 특정 클러스터에서 포드로 실행되어 다른 k8s 구성 요소 또는 사용자 정의 구성 요소와 상호 작용할 수 있습니다.
이상에서 Lambda는 사용자 함수를 균일하게 패키징하고 런타임에 미러링하여 함수 로딩을 구현함을 알 수 있으며, 사용자 함수 코드 로딩도 디렉토리를 마운트하거나 메모리를 공유하여 구현할 수 있으며 여기서는 확장하지 않습니다.

(3) 콜드 스타트

콜드 스타트는 스케줄링에서 시작하여 서비스를 제공할 수 있을 때까지 사용자 함수 인스턴스의 준비 단계를 말합니다. 기존 k8s 클러스터에서 사용자 함수 및 함수 런타임을 포함하는 미러 컨테이너를 시작하는 것과 관련된 단계를 살펴보겠습니다.

기능 리소스 예약을 신청하기 위해 kube-scheduler는 수요 및 기존 리소스 계산을 기반으로 예약 노드를 지정합니다.
지정된 노드의 kubelet 프로세스는 포드가 노드에 파견되었음을 감지하고 컨테이너 런타임을 호출할 때 레지스트리에서 이미지를 가져옵니다.
하위 수준 컨테이너가 실행 중일 때 컨테이너를 풀업하고 k8s 엔드포인트를 등록하고 상태 확인을 수행합니다(1초마다).
상태 확인이 통과되고 컨테이너가 클러스터에서 성공적으로 초기화됩니다.
(컨테이너 내부: 함수 런타임, 함수 인스턴스, RuntimeAgent 등 초기화 및 함수 등록 완료)

이미지 끌어오기 시간은 몇 초에서 수십 초 또는 심지어 몇 분에 이르기까지 제어할 수 없으며 기능 코드가 이미지에 포함된 경우 기능 이미지의 이질성과 많은 수의 기능 미러링이 존재하기 때문에 재사용하기 어렵습니다. 둘째, kubelet이 컨테이너를 생성하는 데 보통 몇 초가 걸리며, 컨테이너가 시작된 후 컨테이너 내부의 기능 프로세스 시작 시간(런타임 환경 시작, 종속성 준비 등 포함)도 시간이 걸립니다.

요약하면 기능 콜드 스타트 지연은 FaaS의 핵심 문제이며 현재 업계에서는 콜드 스타트 최적화를 위해 다음과 같은 방법을 가지고 있습니다.

이미지 가져오기의 지연을 위해 이미지 코드 분리 방법을 채택할 수 있습니다.이미지 자체가 계층화되어 있으므로 사용자 기능 코드를 기능 런타임, RuntimeAgent 및 기타 환경 종속 계층에서 분리할 수 있으며 노드는 해당 부분을 진행합니다. 변경되지 않는 내용의 미리 당겨서 시간을 절약하십시오.
컨테이너 시작, 컨테이너 내부의 함수 런타임, RuntimeAgent 및 기타 환경, 컨테이너 시작 후 구성 요소 시작으로 인한 시간 손실을 고려하면 함수 인스턴스를 예열, 즉 콜드를 유지하여 지연을 줄일 수 있습니다 . 리소스 풀 시작 FaaS 플랫폼은 콜드 스타트 리소스 풀을 형성하기 위해 비즈니스 기능을 포함하지 않는 기본 컨테이너 배치를 사전 유지 관리할 수 있습니다.콜드 스타트 프로세스 후 사용자 기능 인스턴스에 바인딩되며 **공유저장용량** 또는 온라인에서 직접 코드 불러오기 등을 통해 사용자 함수 인스턴스를 불러 와 서비스 제공을 시작합니다. 콜드 스타트 풀의 용량, 확장 및 축소는 FaaS 플랫폼에서 균일하게 모니터링 및 관리됩니다. (또는 더 가볍고 효율적인 컨테이너 런타임을 사용하십시오. 하나는 Firecracker와 같은 KVM 기반의 경량 가상화 기술이고 다른 하나는 Wasm입니다. AWS의 Lambda 기반 기술은 Firecracker를 사용하며 콜드 스타트 시간은 ms 수준입니다.)
헬스 체크를 위해 OpenFaaS는 RuntimeAgent(watchdog)를 사용하여 K8s 헬스 체크 전에 외부 트래픽을 미리 받아 처리하는 방식으로 레이턴시를 줄이려고 했지만, 이 방법은 문제점이 많아 당장은 추천하지 않는다.
컨테이너 내부에서 사용자 업무 기능 프로세스 인스턴스를 시작하는 데 시간이 많이 걸리는 경우 OpenFaaS에서 캐시 기능 인스턴스를 유지하면서 컨테이너에서 요청당 프로세스를 포크하는 방법을 참조할 수 있습니다.

또한 일반적인 FaaS는 플로우 레이트가 0일 때 함수 인스턴스 인스턴스 트래픽이 0으로 줄어들도록 요구하지만(K8s 네이티브 HPA는 일시적으로 할 수 없지만 KEDA는 할 수 있음) 일부 faas 플랫폼은 이에 대한 제한을 시행하지 않습니다. 예를 들어 , OpenFaaS 오픈 소스 버전은 기본적으로 함수 인스턴스를 실행하여 초기 트래픽을 전달하고 일부 다른 플랫폼은 너무 긴 초기화 문제를 피하기 위해 콜드 스타트 리소스 풀을 유지하는 방법을 채택합니다.

(4) 함수 호출/트리거 방법

웹 기능 아키텍처 기반 : 그 본질은 HTTP를 통해 기능을 호출하는 것입니다. 여기서 핵심은 함수 인스턴스의 런타임 환경이 웹 프레임워크와 웹 서버를 제공해야 하고 사용자 함수는 요청이 런타임에 진입한 후 호출된다는 것입니다. 각 함수는 기본적으로 HTTP 트리거를 구성하고 고정된 독립 도메인 이름을 할당합니다.도메인 이름이 요청되는 한 HTTP 트리거 함수로 실행될 수 있습니다.함수는 해당 인터페이스를 구현하는 한 요청을 처리할 수 있습니다. , 그리고 마지막으로 FaaS 플랫폼에서 제공하는 API 게이트웨이를 통해 함수 인스턴스 인터페이스 요청의 중앙 집중식 처리를 수행합니다.
이벤트 기반 아키텍처 : 커뮤니티 및 퍼블릭 클라우드 제품 모두 트리거 개념이 있습니다. 소위 트리거는 실제로 이벤트 소스입니다.이벤트 소스는 통합 사이드카 컨테이너에서 수신한 다음 HTTP로 함수를 호출할 수 있으며, 각 함수 런타임에서 직접 수신한 다음 함수를 호출할 수도 있습니다.
메시지 대기열 MQ 기반: MQ 소비는 비즈니스 시나리오에서 일반적인 비즈니스 유형입니다.오프라인 데이터 계산이든 온라인 실시간 메시지이든 MQ는 미들웨어로 선택되어 비동기식으로 비즈니스를 처리하고 분리합니다.따라서 MQ 메시지 대기열은 전체 FaaS 플랫폼의 가장 큰 트래픽 입구로 사용됩니다.
사용자 정의 트리거링 방법: 예를 들어 OpenFaaS의 Connector라는 구성 요소를 통해 개발자는 함수의 트리거링 방법을 사용자 정의할 수 있습니다.

(5) 기타

다음은 제가 개인적으로 정리한 FaaS 관련 몇 가지 기술적인 사항으로 완벽하지 않을 수 있으며 참고용으로만 참고하시기 바랍니다.

이미지-20230722162525559

3. 클라우드 네이티브 FaaS 프레임워크

(1) 오픈펑션

OpenFunction은 최신 클라우드 네이티브 FaaS(Function as a Service) 프레임워크로 Knative, Tekton, Shipwright, Dapr, KEDA 등을 포함하여 많은 우수한 오픈 소스 기술 스택을 도입합니다. 가능성은 무궁무진합니다.

Shipwright는 사용자가 기능 구성 프로세스 중에 이미지 구성을 위한 도구를 자유롭게 선택하고 전환할 수 있도록 하며 통합 API를 제공하기 위해 이를 추상화합니다.
Knative는 강력한 자동 크기 조정 기능과 함께 우수한 동기 함수 런타임을 제공합니다.
KEDA는 더 많은 유형의 지표에 따라 자동으로 확장할 수 있으며 더 유연합니다.
Dapr은 다양한 애플리케이션의 일반 기능을 추상화하고 분산 애플리케이션 개발 작업량을 줄일 수 있습니다.

(2) OpenFaaS

OpenFaaS는 오랫동안 개발된 FaaS 오픈 소스 프로젝트로 GitHub에서 더 많은 주목을 받았으며 CloudFunction이 실행 중일 때 요청을 처리하는 모드에서 더 많은 탐색을 했습니다. 이 기사의 세 번째 섹션에서는 FaaS 사례 소개에 중점을 둘 것입니다.

(3) Knative：홈 - Knative

Knative는 컨테이너화된 애플리케이션의 개발, 배포 및 관리 프로세스를 간소화하고 가속화하도록 설계된 오픈 소스 Kubernetes 기반 플랫폼입니다. 개발자가 최신 클라우드 네이티브 애플리케이션을 Kubernetes 클러스터에 배포하고 서버리스 아키텍처(Serverless) 및 자동화된 컨테이너 오케스트레이션을 구현하는 데 도움이 되는 일련의 빌딩 블록 및 도구를 제공합니다.

3. FaaS 사례 - OpenFaaS

1. 개요

(1) 무엇입니까

OpenFaaS는 사용자가 자체 기능을 배포하고 실행할 수 있는 오픈 소스 FaaS 프레임워크입니다. OpenFaaS는 Docker 컨테이너를 기본 기술로 사용하며 모든 클라우드 환경 또는 프라이빗 클라우드에서 실행할 수 있습니다. OpenFaaS 프로젝트는 Kubernetes 클러스터 또는 독립 실행형 가상 머신과 같은 저수준 인프라를 서버리스 기능을 관리하기 위한 고수준 플랫폼으로 전환하는 것을 목표로 합니다.

(2) 무엇을 했습니까?

이미지-20230210145258300

함수 호출 : WatchDog는 함수 및 마이크로서비스 실행을 위한 리버스 프록시 역할을 하는 Cloud 함수 호출 및 모니터링을 위한 OpenFaaS의 핵심 구현입니다. 독립적으로 사용하거나 OpenFaaS 컨테이너용 EntryPoint로 사용할 수 있으며 함수 컨테이너에서 " 초기화 프로세스 "로 시작할 수 있습니다. 동시 요청, 시간 초과 및 상태 확인과 같은 기능을 제공하는 Golang에서 구현된 기본 제공 HttpServer가 있습니다. 이를 통해 개발자는 다양한 환경 변수를 로드하여 기능을 사용자 정의할 수 있습니다.
자동 조정: OpenFaaS는 자체 설계된 AutoScaler를 사용하여 기능을 자동으로 조정합니다.
콜드 스타트: OpenFaaS는 아키텍처 설계에 중점을 둡니다.OpenFaaS는 콜드 스타트 풀을 유지하지 않고 필요에 따라 비즈니스 코드를 로드합니다.읽기 전용 파일 시스템을 유지하기를 희망합니다.컨테이너 캐리어는 예측 가능성을 얻기 위해 변경 불가능한 단위로 설계되었습니다. 최대 보안을 얻을 수 있습니다. 따라서 OpenFaaS는 트래픽이 없을 때 기본적으로 기능 인스턴스 수를 0으로 줄이지 않고 기능 세분화를 위한 선택적 구성으로만 활성화합니다.전체 콜드 스타트 데이터 트래픽은 가장 작은 인스턴스에서 새 인스턴스에 필요한 리소스 예약, 바이너리 풀, 프로세스 시작 및 상태 확인은 엄청난 콜드 스타트 오버헤드를 생성합니다.

(3) 사용 방법

개요 - OpenFaaS

OpenFaaS 는 helm을 통해 기본 K8에 배포됩니다.

2. 주요 기술 구성 요소

OpenFaaS 기술 개요 다이어그램:

이미지-20230210161252264

위 그림은 OpenFaaS의 추상 서비스 프로세스이며, 다음은 각 노드에 대한 간략한 소개입니다.

Gateway : 사용자 요청 및 내부 지침을 수신하기 위한 HTTP 게이트웨이.

NATS 스트리밍: 함수를 비동기적으로 실행하는 데 사용됩니다.

Prometheus / AlertManager: 서비스 지표를 수집하고 작업을 확장하는 데 사용됩니다.

faas -netes: K8S용 공급자, Docker Swarm과 같은 다른 공급자를 사용자 지정할 수 있습니다.

Docker Registry: 함수 이미지를 가져오기 위한 리포지토리입니다.

(1) 감시견

WatchDog는 Cloud Function을 호출하고 모니터링하기 위한 OpenFaaS의 핵심 구현입니다. 최신 of-watchdog은 기능 또는 마이크로 서비스 실행을 위한 리버스 프록시 역할을 합니다 . 독립 실행형으로 사용하거나 OpenFaaS 컨테이너의 EntryPoint 로 사용할 수 있으며 함수 컨테이너에서 " 초기화 프로세스 "로 시작할 수 있습니다. 동시 요청, 시간 초과 및 상태 확인과 같은 기능을 제공하는 Golang에서 구현된 기본 제공 HttpServer가 있습니다. 이를 통해 개발자는 다양한 환경 변수를 로드하여 기능을 사용자 정의할 수 있습니다. OpenFaaS는 ClassicWatchdog 및 of-Watchdog의 두 가지 Watchdog 모드를 출시했습니다. 다음을 각각 소개합니다.

클래식 WatchDog 작업 모드:

이 모드에서 watchdog은 포트 8080 에서 수신 대기하는 경량 HTTP 서버를 시작하고 들어오는 각 요청은 다음을 수행합니다.

요청 헤더 및 요청 본문 읽기
실제 함수를 포함하는 실행 파일을 fork 또는 exec
요청 헤더와 요청 본문을 함수 프로세스의 stdin 에 씁니다.
기능 프로세스 종료 대기(또는 시간 초과)
함수 프로세스의 stdout 및 stderr 읽기
HTTP 응답에서 읽지 않은 바이트를 호출자에게 다시 보냅니다.

위의 논리는 기존의 CGI(Common Gateway Interface) 와 유사합니다 . 한편으로는 각 함수 호출에 대해 별도의 프로세스를 시작하는 것이 비효율적으로 보이지만 다른 한편으로는 I/O 처리를 위해 stdio 스트림을 사용하는 모든 프로그램(CLI 도구 포함)을 OpenFaaS 함수로 배포할 수 있기 때문에 매우 편리합니다. .

격리 에 관해서는 함수 와 호출을 구분해야 합니다 .

OpenFaaS의 다른 기능은 항상 다른 컨테이너에 배포됩니다.
함수는 크기 조정 옵션에 따라 하나 이상의 컨테이너를 가질 수 있습니다.
동일한 함수에 대한 독립적인 호출은 동일한 컨테이너에서 종료될 수 있습니다.
동일한 함수의 독립적인 호출은 항상 다른 프로세스를 사용하여 이루어집니다.

리버스 프록시 워치독 작동 모드:

클래식 런타임이 CGI와 유사한 경우 이 런타임 모드는 최신 FastCGI 와 유사합니다 . 런타임은 함수가 호출될 때마다 새 프로세스를 생성하는 대신 워치독 뒤에 장기 실행 HTTP 서버가 있을 것으로 예상합니다. 이것은 본질적으로 watchdog 구성 요소를 리버스 프록시로 바꿉니다 . 컨테이너가 시작되면 리버스 프록시 watchdog도 포트 8080 에서 수신 대기하는 경량 HTTP 서버를 생성합니다 . 그러나 클래식 워치독 과 달리 리버스 프록시 워치독은 함수의 프로세스를 한 번만 생성하고 이를 (장기 실행) 업스트림 서버로 취급합니다. 그런 다음 함수 호출은 해당 업스트림에 대한 HTTP 요청으로 바뀝니다.

그러나 리버스 프록시 모드는 클래식 모드를 대체하기 위한 것이 아닙니다 . 클래식 모드의 강점은 기능이 매우 간단하게 작성된다는 것입니다. HTTP 서버가 없는 코드에 대한 유일한 옵션이기도 합니다. 예를 들어 Cobol, bash 또는 PowerShell 스크립트 등으로 작성된 함수입니다.

리버스 프록시 런타임 모드를 사용하는 경우 :

함수는 호출 간에 상태를 유지해야 합니다.
- 은닉처
- 지속적인 연결(예: 함수에서 데이터베이스로의 연결을 열린 상태로 유지)
- 상태 저장 기능
함수당 프로세스를 시작하는 것은 비용이 많이 들 수 있으며 각 호출에 대기 시간이 발생할 수 있습니다.
(마이크로)서비스를 기능으로 실행하고 싶습니다.

OpenFaaS, FaaS , 특히 OpenFaaS 의 창시자인 Alex Ellis 에 따르면 서버 추상화에 의존하지 않고 마이크로서비스를 배포하는 단순화된 방법 으로 볼 수 있습니다 . 즉, FaaS는 서버리스 아키텍처의 정식 예입니다.

따라서 함수는 리버스 프록시 접근 방식을 사용하여 마이크로 서비스를 배포하는 독단적인 방법으로 볼 수 있습니다. 편리하고 빠르고 쉽습니다. 그러나 상태 저장 함수를 사용하는 경우 여러 호출이 동일한 프로세스에서 종료될 수 있으므로 경고에 유의하십시오.

한 프로세스에서 종료되는 동시 호출은 코드에서 경쟁 조건을 트리거할 수 있습니다(예: 잠금으로 보호되지 않는 전역 변수가 있는 Go 함수).
하나의 프로세스에서 끝나는 후속 호출은 교차 호출 데이터 유출로 이어질 수 있습니다(물론 기존 마이크로서비스와 마찬가지로).
프로세스는 호출 간에 재사용되므로 코드의 메모리 누수는 할당 해제되지 않습니다.

wathdog와 리버스 프록시 워치독 간의 작업 모드 비교:

이미지-20230209164843629

(2) API게이트웨이

이미지-20230210171540735

Openfaas 게이트웨이는 맞춤형 기능, 내장 UI, faas-cli 및 API 요청을 위한 RESTful 인터페이스의 외부 라우팅을 제공하며 Openfaas 게이트웨이에서 처리 및 배포됩니다.

또한 Openfaas 게이트웨이는 Prometheus를 통합하여 기능 및 서비스에 대한 모니터링 기능을 제공하고 faas 공급자 API를 호출하여 컨테이너를 관리할 수도 있습니다.

Faas 공급자는 Openfaas 공급자 Http REST API 표준을 준수하는 go 언어로 구현된 SDK 도구 집합입니다.

OpenFaaS API 게이트웨이의 주요 책임:

함수에 대한 CRUD 작업
프록시 함수 호출 서비스
함수 컨테이너의 크기 조정 관리
컨테이너 키 관리
통나무 배수

(3)FaaS-제공자 인터페이스/페이즈넷

참고 자료: OpenFaaS(alexellis.io)에서 인터페이스의 힘

(3) 자동 스케일링

참고 자료: 자동 크기 조정 - OpenFaaS , OpenFaaS를 사용하여 0으로 조정하고 다시 되돌리기

(4) NATS 기반 비동기 함수 호출

다음 두 그림은 PDF 파일 기능을 업로드하기 위한 동기/비동기 호출 프로세스를 간략하게 설명하고 NATS를 통해 비동기 기능 호출을 구현하는 방법을 설명합니다.

3. 기타

(1) OpenFaaS 개발자 관점

이미지-20230210170127630

추가 정보:

- Alibaba Cloud Shutong과의 대화: 2022년 클라우드 네이티브의 발전을 어떻게 보고, 2023년에는 어떤 기술에 주목해야 할까요? - 너겟(juejin.cn)

- 캘리포니아 버클리의 Serverless View(버클리 뷰)