서버리스(Serverless) 아키텍처 백서 – CNCF

본 기술 백서의 PDF 버전은 여기 에서 찾을 수 있습니다 .

이 기술 백서에서는 새롭게 떠오르는 “서버리스(Serverless)” 아키텍처 및 지원 플랫폼으로 구현할 수 있는 새로운 클라우드 네이티브 컴퓨팅 모델에 대해 설명합니다. 서버리스 컴퓨팅이 무엇인지 정의하고 서버리스 컴퓨팅의 사용 사례와 성공적인 예를 강조하며 서버리스 컴퓨팅이 IaaS (Infrastructure-as-a-Service), Platform-as와 같은 다른 클라우드 애플리케이션 개발 모델과 어떻게 다른가 -a-Service (PaaS) 및 컨테이너 오케스트레이션 또는 Containers-as-a-Service (CaaS).

이 백서에는 프로그래밍 모델 및 메시지 형식과 관련된 일반 서버리스 플랫폼의 메커니즘에 대한 논리적 설명이 포함되어 있지만 표준을 규정하지는 않습니다. 여러 산업 서버리스 플랫폼과 그 기능을 소개하지만 특정 구현을 권장하지는 않습니다.

클라우드 네이티브 컴퓨팅을위한 서버리스 컴퓨팅의 채택을 향상시키는 방법에 대한 CNCF 권장 사항으로 마무리됩니다.

WG Chair / TOC 스폰서 : Ken Owens (마스터 카드)

저자 (성별 알파벳) :

Sarah Allen (Google), Chris Aniszczyk (CNCF), Chad Arimura (Oracle), Ben Browning (Red Hat), Lee Calcote (SolarWinds), Amir Chaudhry (Docker), Doug Davis (IBM), Louis Fourie (Huawei), Antonio Gulli (Google), Yaron Haviv (iguazio), Daniel Krook (IBM), Orit Nissan-Messing (iguazio), Chris Munns (AWS), Ken Owens (Mastercard), Mark Peek (VMWare), Cathy Zhang (Huawei)

추가 기고자 (이름으로 알파벳순) :

Kareem Amin (Clay Labs), Amir Chaudhry (Docker), Sarah Conway (Linux Foundation), Zach Corleissen (Linux Foundation), Alex Ellis (VMware), Brian Grant (Google), Lawrence Hecht (The New Stack), Lophy Liu, 다이앤 뮬러 (빨간 모자), 발린 파토, 피터 스 바르 스키 (구름 전문가), 펑 자오 (하이퍼)

서버리스 컴퓨팅

서버리스 컴퓨팅이란 무엇입니까?

서버리스 컴퓨팅은 서버 관리가 필요없는 애플리케이션을 구축하고 실행하는 개념을 말합니다. 하나 이상의 기능으로 번들 된 응용 프로그램이 플랫폼에 업로드 된 후 현재 필요한 정확한 요구에 따라 실행, 확장 및 청구되는보다 세밀한 배포 모델에 대해 설명합니다.

서버리스 컴퓨팅은 더 이상 서버를 사용하여 코드를 호스팅하고 실행하지 않는다는 의미는 아닙니다. 또한 운영 엔지니어가 더 이상 필요하지 않다는 의미도 아닙니다. 오히려 서버리스 컴퓨팅 소비자는 더 이상 서버 프로비저닝, 유지 관리, 업데이트, 확장 및 용량 계획에 시간과 리소스를 소비 할 필요가 없다는 생각을 말합니다. 대신 이러한 모든 작업과 기능은 서버리스 플랫폼에서 처리되며 개발자 및 IT / 운영 팀과 완전히 분리됩니다. 결과적으로 개발자는 응용 프로그램의 비즈니스 논리를 작성하는 데 중점을 둡니다. 운영 엔지니어는보다 중요한 비즈니스 작업에 집중할 수 있습니다.

기본 서버리스 개인 설정에는 두 가지가 있습니다.

  1. 개발자 : 서버가 없거나 코드가 항상 실행되고 있다는 관점을 제공하는 서버리스 플랫폼을위한 코드를 작성하고 서버리스 플랫폼에서 이점을 얻습니다.
  2. 공급자 : 외부 또는 내부 고객을 위해 서버리스 플랫폼을 배포합니다.

서버리스 플랫폼을 실행하려면 서버가 여전히 필요합니다. 제공자는 서버 (또는 가상 머신 또는 컨테이너)를 관리해야합니다. 공급자는 유휴 상태 인 경우에도 플랫폼을 실행하는 데 약간의 비용이 듭니다. 자체 호스팅 시스템은 여전히 ​​서버리스로 간주 될 수 있습니다. 일반적으로 한 팀은 공급자 역할을 하고 다른 팀 은 개발자 역할을합니다 .

서버리스 컴퓨팅 플랫폼은 다음 중 하나 또는 둘 다를 제공 할 수 있습니다.

  1. FaaS (function-as-a-service) : 일반적으로 이벤트 중심 컴퓨팅을 제공합니다. 개발자는 이벤트 또는 HTTP 요청에 의해 트리거되는 기능으로 애플리케이션 코드를 실행하고 관리합니다. 개발자는 작은 코드 단위를 FaaS에 배포합니다. FaaS는 별도의 작업으로 필요에 따라 실행되며 서버 나 기타 기본 인프라를 관리 할 필요없이 확장됩니다.
  2. BaaS (Backend-as-a-Service) : 애플리케이션의 핵심 기능을 대체하는 타사 API 기반 서비스입니다. 이러한 API는 자동 확장 및 투명하게 작동하는 서비스로 제공되므로 개발자에게는 서버가없는 것으로 보입니다.

서버리스 제품 또는 플랫폼은 개발자에게 다음과 같은 이점을 제공합니다.

  1. Zero Server Ops : 서버리스는 서버 리소스 유지 관리와 관련된 오버 헤드를 제거하여 소프트웨어 응용 프로그램 실행 비용 모델을 크게 변경합니다.
    • 서버 인프라 프로비저닝, 업데이트 및 관리가 없습니다. 서버, 가상 시스템 및 컨테이너 관리는 직원 수, 도구, 교육 및 시간이 포함 된 회사의 경우 상당한 오버 헤드 비용입니다. 서버리스는 이런 종류의 비용을 크게 줄입니다.
    • 유연한 확장 성 : 서버리스 FaaS 또는 BaaS 제품은 각 개별 요청을 처리 할 수 ​​있도록 즉각적이고 정확하게 확장 할 수 있습니다. 개발자에게 서버리스 플랫폼에는 “사전 계획된 용량”이라는 개념이 없으며 “자동 확장”트리거 또는 규칙을 구성 할 필요도 없습니다. 스케일링은 개발자의 개입없이 자동으로 발생합니다. 요청 처리가 완료되면 서버리스 FaaS는 컴퓨팅 리소스를 자동으로 축소하여 유휴 용량이 발생하지 않도록합니다.
  2. 유휴 상태 일 때 계산 비용 없음 : 소비자 관점에서 서버리스 제품의 가장 큰 장점 중 하나는 유휴 용량으로 인한 비용이 없다는 것입니다. 예를 들어, 서버리스 컴퓨팅 서비스는 유휴 가상 머신 또는 컨테이너에 대해 요금을 청구하지 않습니다. 다시 말해, 코드가 실행 중이 아니거나 의미있는 작업이 수행되지 않은 경우 비용이 부과되지 않습니다. 데이터베이스의 경우 데이터베이스 엔진 용량이 쿼리를 유휴로 기다리는 데 대한 비용은 없습니다. 물론 여기에는 상태 저장 스토리지 비용 또는 추가 기능 / 기능 / 기능 세트와 같은 다른 비용이 포함되지 않습니다.

서버리스 기술의 짧은 역사

온 디맨드 (on-demand) 또는 “결제에 따른 지불”이라는 아이디어는 2006 년부터 짐키 (Zimki)라는 플랫폼으로 거슬러 올라갈 수 있습니다. 컨테이너 기반의 주문형 분산 작업 플랫폼입니다.

그 이후로 퍼블릭 클라우드와 프라이빗 클라우드 모두에서 더 많은 서버리스 구현이있었습니다. 먼저 2011 년 Parse 및 2012 년 Firebase (각각 Facebook 및 Google이 인수)와 같은 BaaS 오퍼링이있었습니다. 2014 년 11 월 AWS Lambda 가 시작되었고 2016 년 초 에 Bluemix (현재 IBM Cloud Functions, Apache OpenWhisk 로 관리되는 핵심 오픈 소스 프로젝트 ), Google Cloud Functions 및 Microsoft Azure Functions 에서 IBM OpenWhisk에 대한 공지가 있었습니다 . 화웨이 기능 단계수많은 오픈 소스 서버리스 프레임 워크도 있습니다. 공개 및 비공개 프레임 워크 각각에는 이벤트 처리 및 데이터 처리를위한 고유 한 언어 런타임 및 서비스 세트가 있습니다.

이것들은 몇 가지 예일뿐입니다. 보다 완전한 최신 목록은 Serverless Landscape 문서를 참조하십시오 . 상세보기 : 서버를 사용하지 않는 가공 모델 섹션은 전체 FAAS 모델에 대한 자세한 내용을 포함하고 있습니다.

서버리스 사용 사례

서버리스 컴퓨팅은 광범위하게 사용 가능하지만 여전히 비교적 새롭습니다. 일반적으로 워크로드가 다음과 같은 경우 서버리스 접근 방식이 최상의 선택으로 간주되어야합니다.

  • 독립적 인 작업 단위로 비동기식, 동시성, 병렬화 용이
  • 스케일링 요구 사항에서 예측할 수없는 큰 편차로 인해 드물거나 산발적 인 수요가 있음
  • 즉각적인 콜드 스타트 ​​시간을 크게 필요로하지 않는 무국적, 임시,
  • 개발자 속도를 가속화해야하는 변화하는 비즈니스 요구 사항 측면에서 매우 역동적

예를 들어, 일반적인 HTTP 기반 응용 프로그램의 경우 자동화 된 규모와보다 세분화 된 비용 모델 측면에서 명확한 단점이 있습니다. 그러나 서버리스 플랫폼을 사용하는 데에는 몇 가지 장단점이있을 수 있습니다. 예를 들어, 일정 기간 동안 사용하지 않으면 기능을 시작하면 기능의 인스턴스 수가 0으로 떨어지면 성능이 저하 될 수 있습니다. 따라서 서버리스 아키텍처를 채택할지 여부를 선택하려면 컴퓨팅 모델의 기능적 측면과 비 기능적 측면을 모두 면밀히 검토해야합니다.

IaaS, PaaS 또는 CaaS 솔루션에 적합하지 않은 비 HTTP 중심 및 비 탄력적 규모의 워크로드는 이제 서버리스 아키텍처의 온 디맨드 특성과 효율적인 비용 모델을 활용할 수 있습니다. 이러한 작업 중 일부는 다음과 같습니다.

  • 데이터베이스 변경 (삽입, 업데이트, 트리거, 삭제)에 대한 응답으로 로직 실행
  • IoT 센서 입력 메시지 (예 : MQTT 메시지)에 대한 분석 수행
  • 스트림 처리 처리 (동작중인 데이터 분석 또는 수정)
  • 짧은 시간 동안 많은 처리가 필요한 단일 시간 추출, 변환 및로드 작업 관리 (ETL)
  • 챗봇 인터페이스를 통해인지 컴퓨팅 제공 (비동기 적이지만 상관 관계가있는)
  • cron 또는 배치 스타일 호출과 같은 짧은 시간 동안 수행되는 작업 예약
  • 머신 러닝 및 AI 모델 제공 (테이블, NLP 또는 이미지와 같은 하나 이상의 데이터 요소를 검색하고 사전 학습 된 데이터 모델과 일치시켜 텍스트, 얼굴, 이상 등을 식별)
  • 빌드 슬레이브 호스트 풀이 작업 디스패치를 ​​대기하는 대신 요청시 빌드 작업을위한 자원을 제공하는 지속적인 통합 파이프 라인

이 섹션에서는 기존 및 새로운 워크로드와 서버리스 아키텍처가 뛰어난 사용 사례에 대해 설명합니다. 또한 초기 성공 사례에서 추출한 초기 결과, 패턴 및 모범 사례에 대한 세부 정보도 포함합니다.

이러한 각 시나리오는 서버리스 아키텍처가 IaaS, PaaS 또는 CaaS에서 비효율적이거나 불가능한 기술적 문제를 해결 한 방법을 보여줍니다. 이 예는 다음과 같습니다.

  • 주문형 모델을 사용할 수없는 새로운 문제를 효율적으로 해결
  • 기존 클라우드 문제를 훨씬 더 효율적으로 해결 (성능, 비용)
  • 처리 된 데이터 크기 또는 처리 된 요청 크기에 관계없이 “대형”차원 표시
  • 낮은 오류율로 자동 확장 (위 / 아래)으로 탄력성을 보여줍니다
  • 이전보다 훨씬 빠르게 시장에 출시 할 수있는 솔루션을 얻었습니다 (일-시간)

이 섹션에 나열된 워크로드는 퍼블릭 클라우드 (호스트 된 서버리스 플랫폼), 온 프레미스 또는 에지에서 실행할 수 있습니다.

멀티미디어 처리

일반적인 사용 사례와 가장 빠른 결정화 방법 중 하나는 새로운 파일 업로드에 대한 응답으로 일부 변환 프로세스를 실행하는 함수의 구현입니다. 예를 들어, 이미지가 Amazon S3와 같은 객체 스토리지 서비스에 업로드 된 경우 해당 이벤트는 이미지의 썸네일 버전을 생성하여 다른 객체 스토리지 버킷 또는 Database-as-a-Service에 다시 저장하는 기능을 트리거합니다. 이것은 드물게 실행되고 수요에 따라 확장되는 상당히 원자적이고 병렬 가능한 컴퓨팅 작업의 예입니다.

예를 들면 다음과 같습니다.

  • Santander 는 광학 문자 인식을 사용하여 모바일 수표 입금을 처리하기 위해 서버리스 기능을 사용하여 개념 증명을 구축했습니다. 이러한 유형의 워크로드는 상당히 다양하며, 2 주에 한 번씩 급여일 처리 요구는 지불 기간의 유휴 시간보다 몇 배 더 클 수 있습니다.
  • 배우, 감정 및 사물을 추출하기 위해 각 비디오 프레임을 이미지 인식 서비스 를 통해 통과시킴으로써 필름을 자동 분류하는 단계 ; 또는 피해 지역의 무인 항공기 영상을 처리하여 피해 정도를 추정 할 수 있습니다.

데이터베이스 변경 또는 데이터 캡처 변경 (CDC)

이 시나리오에서는 데이터베이스에서 데이터를 삽입, 수정 또는 삭제할 때 함수가 호출됩니다. 이 경우 기존의 SQL 트리거와 유사하게 주요 동기 흐름과 유사한 부작용이나 동작과 거의 비슷합니다. 그 결과 동일한 데이터베이스 내에서 감사 테이블에 로깅과 같은 내용을 수정하거나 외부 서비스 (이메일 전송 등)를 호출하거나 다음과 같은 추가 데이터베이스를 업데이트 할 수있는 비동기 논리를 실행하는 것이 효과가 있습니다. DB CDC (데이터 변경 변경) 사용 사례. 이러한 사용 사례는 비즈니스 요구 사항과 변경 사항을 처리하는 서비스 배포로 인해 빈도와 원 자성 및 일관성 요구 사항이 다를 수 있습니다.

예를 들면 다음과 같습니다.

  • 데이터베이스에 대한 변경 감사 또는 허용 가능한 변경에 대한 특정 품질 또는 분석 표준을 충족하는지 확인하십시오.
  • 데이터를 입력 한 직후 또는 다른 언어로 자동 번역합니다.

IoT 센서 입력 메시지

네트워크에 연결된 자율 장치가 폭발적으로 증가함에 따라 대량의 트래픽과 HTTP보다 가벼운 프로토콜을 사용하는 추가 트래픽이 발생합니다. 효율적인 클라우드 서비스는 메시지의 급격한 유입 또는 급격한 유입에 따라 신속하게 메시지에 응답하고 확장 할 수 있어야합니다. 서버리스 기능은 IoT 디바이스에서 MQTT 메시지를 효율적으로 관리하고 필터링 할 수 있습니다. 또한 탄력적으로 확장 할 수 있으며로드에서 다운 스트림으로 다른 서비스를 보호 할 수 있습니다.

예를 들면 다음과 같습니다.

  • 쓰레기 수거통의 상대적 완전성을 기반으로 트럭 픽업 경로가 최적화 된 GreenQ의 위생 사용 사례 (쓰레기 인터넷) .
  • IoT 장치 (예 : AWS Greengrass )에서 서버리스를 사용하여 로컬 센서 데이터를 수집하고, 정규화하고, 트리거와 비교하고, 이벤트를 집계 단위 / 클라우드로 푸시합니다.

대규모 스트림 처리

비 트랜잭션, 비 요청 / 응답 유형의 워크로드는 잠재적으로 무한한 메시지 스트림 내에서 데이터를 처리하는 것입니다. 함수는 이벤트 스트림에서 각각 읽고 처리해야하는 메시지 소스에 연결될 수 있습니다. 고성능, 탄력성 및 컴퓨팅 집약적 처리 워크로드를 고려할 때 이는 서버리스에 중요한 역할을 할 수 있습니다. 많은 경우, 스트림 처리는 데이터를 일련의 컨텍스트 객체 (NoSQL 또는 In-mem DB)와 비교하거나 스트림의 데이터를 객체 또는 데이터베이스 시스템으로 집계 및 저장해야합니다.

예를 들면 다음과 같습니다.

봇 채팅

인간과 상호 작용하는 데 반드시 밀리 초의 응답 시간이 필요하지는 않으며, 여러 가지 방법으로 인간에게 응답하는 봇은 대화가 더 자연스럽게 느껴지도록 약간 지연 될 수 있습니다. 이 때문에 콜드 스타트에서 기능이로드되기를 기다리는 초기 대기 시간이 허용 될 수 있습니다. 봇은 Facebook, WhatsApp 또는 Slack과 같은 인기있는 소셜 네트워크에 추가 될 때 확장 성이 매우 높아야하므로 PaaS 또는 IaaS 모델에서 Always-on 데몬을 사전 프로비저닝하는 경우 갑작 스럽거나 피크 수요가 예상되는 것은 아닙니다. 서버리스 방식으로 효율적이거나 비용 효율적입니다.

예를 들면 다음과 같습니다.

  • Facebook 또는 기타 트래픽이 많은 사이트와 같은 대규모 소셜 미디어 서비스에 연결된 지원 및 판매 봇.
  • 메시징 앱 Wuu는 Google 클라우드 기능을 사용하여 사용자가 몇 시간 또는 몇 초 안에 사라지는 콘텐츠 를 만들고 공유 할 수 있도록합니다 .
  • 아래의 HTTP REST API 및 웹 애플리케이션도 참조하십시오.

배치 작업 또는 예약 된 작업

비동기식으로 하루에 몇 분만 강렬한 병렬 계산, IO 또는 네트워크 액세스가 필요한 작업은 서버리스에 매우 적합 할 수 있습니다. 작업은 탄력적 인 방식으로 실행되는 시간 동안 효율적으로 필요한 리소스를 소비 할 수 있으며, 하루 중 사용하지 않는 리소스 비용은 발생하지 않습니다.

예를 들면 다음과 같습니다.

  • 예약 된 작업은 매일 밤 실행되는 백업 작업 일 수 있습니다.
  • 여러 전자 메일을 동시에 수평 확장 기능 인스턴스로 보내는 작업

HTTP REST API 및 웹 애플리케이션

전통적인 요청 / 응답 워크로드는 워크로드가 정적 웹 사이트인지 또는 JavaScript 또는 Python과 같은 프로그래밍 언어를 사용하여 요청시 응답을 생성하는 사이트인지에 관계없이 서버리스에 여전히 적합합니다. 첫 번째 사용자에게는 시작 비용이 발생할 수 있지만 JavaServer Page를 서블릿으로 초기 컴파일하거나 추가로드를 처리하기 위해 새 JVM을 시작하는 등의 다른 컴퓨팅 모델에서는 이러한 유형의 지연이 우선합니다. 이점은 개별 REST 호출 (예 : 마이크로 서비스의 4 개의 GET, POST, UPDATE 및 DELETE 엔드 포인트 각각)이 공통 데이터 백엔드를 공유하더라도 독립적으로 확장되고 별도로 청구될 수 있다는 것입니다.

예를 들면 다음과 같습니다.

모바일 백엔드

모바일 백엔드 작업에 서버리스를 사용하는 것도 매력적입니다. 개발자는 BaaS API보다 REST API 백엔드 워크로드를 구축 할 수 있으므로 모바일 앱을 최적화하는 데 시간을 소비하고 백엔드를 확장하는 데 적은 시간을 소비 할 수 있습니다. 예를 들면 다음과 같습니다. 비디오 게임의 그래픽을 최적화하고 게임이 바이러스 성 히트가 될 때 서버에 투자하지 않습니다. 또는 제품 / 시장에 적합한 제품을 찾기 위해 신속하게 반복해야하거나 시장 출시시기가 중요한 소비자 비즈니스 애플리케이션에 적합합니다. 또 다른 예는 오프라인 우선 경험을 위해 사용자에게 알림을 일괄 처리하거나 다른 비동기 작업을 처리하는 것입니다.

예를 들면 다음과 같습니다.

  • 소량의 서버 측 로직이 필요한 모바일 앱; 개발자는 네이티브 코드 개발에 노력을 집중할 수 있습니다.
  • 이벤트 트리거 서버리스 컴퓨팅과 함께 Firebase 인증 / 규칙 또는 Amazon Cognito와 같은 구성된 보안 정책을 사용하여 BaaS에 모바일에서 직접 액세스하는 모바일 앱.
  • 회의 전후에 주말에는 수요가 거의 없지만 규모를 크게 확대 및 축소해야하는 대규모 회의용 예약 앱과 같은 “폐기”또는 단기 사용 모바일 응용 프로그램. 월요일과 화요일 오전 이벤트 일정에 대한 일정보기 요구에 따라 기조 연설 이후 급등한 다음 그날 자정에 다시 내려갑니다.

비즈니스 로직

비즈니스 프로세스에서 일련의 단계를 실행하는 마이크로 서비스 워크로드 오케스트레이션은 관리 및 조정 기능과 함께 배치 할 때 서버리스 컴퓨팅의 또 다른 유즈 케이스입니다. 주문 요청 및 승인, 주식 거래 처리 등과 같은 특정 비즈니스 로직을 수행하는 기능은 상태 저장 관리자와 예약하고 조정할 수 있습니다. 이러한 조정 기능을 통해 클라이언트 포털의 이벤트 요청을 처리하고 적절한 서버리스 기능으로 전달할 수 있습니다.

예를 들면 다음과 같습니다.

주식 시장 거래를 처리하고 고객의 거래 주문 및 확인을 처리하는 거래 데스크. 오케 스트레이터는 상태 그래프를 사용하여 거래를 관리합니다. 초기 상태는 클라이언트 포털의 거래 요청을 수락하고 마이크로 서비스 기능에 요청을 전달하여 요청을 구문 분석하고 클라이언트를 인증합니다. 후속 주에서는 매수 또는 매도 거래를 기반으로 워크 플로를 조정하고 펀드 잔액 ​​및 시세 등을 확인하며 고객에게 확인을 보냅니다. 클라이언트로부터 확인 요청 이벤트를 수신하면 후속 상태는 거래 실행을 관리하고 계정을 업데이트하며 거래 완료를 고객에게 알리는 기능을 호출합니다.

지속적인 통합 파이프 라인

기존 CI 파이프 라인에는 작업이 디스패치되기 위해 유휴 대기중인 빌드 슬레이브 호스트 풀이 포함됩니다. 서버리스는 사전 프로비저닝 된 호스트의 필요성을 제거하고 비용을 줄이는 좋은 패턴입니다. 빌드 작업은 새로운 코드 커밋 또는 PR 병합에 의해 트리거됩니다. 빌드 및 테스트 케이스를 실행하기 위해 함수 호출이 호출되어 필요한 시간 동안 만 실행되며 사용하지 않는 동안 비용이 발생하지 않습니다. 이를 통해 비용을 낮추고 자동 확장을 통해 병목 현상을 줄여 수요를 충족시킬 수 있습니다.

예를 들면 다음과 같습니다.

서버리스 및 기타 클라우드 네이티브 기술

클라우드 네이티브 애플리케이션을 호스팅 할 플랫폼을 찾을 때 대부분의 애플리케이션 개발자가 고려할 수있는 세 가지 주요 개발 및 배포 모델이 있습니다. 각 모델에는 오픈 소스 프로젝트, 호스팅 플랫폼 또는 온 프레미스 제품 등 다양한 구현 방식이 있습니다. 이 세 가지 모델은 일반적으로 밀도, 성능, 격리 및 패키징 기능을 위해 컨테이너 기술을 기반으로하지만 컨테이너화가 반드시 필요한 것은 아닙니다.

코드를 실행하는 실제 인프라에서 추상화를 늘리고 개발 된 비즈니스 논리에만 더 중점을두기 위해 컨테이너 오케스트레이션 (또는 컨테이너 서비스), Platform-as-a- 서비스 및 서버리스 (서비스 기능). 이러한 모든 접근 방식은 클라우드 네이티브 애플리케이션을 배포하는 방법을 제공하지만 의도 한 개발자 대상 및 워크로드 유형에 따라 다른 기능적 측면과 비 기능적 측면을 우선 순위로 둡니다. 다음 섹션에는 각각의 주요 특징 중 일부가 나와 있습니다.

단일 클라우드 접근 방식이 모든 클라우드 네이티브 개발 및 배포 문제의 주요 요소는 아닙니다. 이러한 일반적인 클라우드 네이티브 개발 기술 각각의 이점과 단점에 대해 특정 워크로드의 요구 사항을 일치시키는 것이 중요합니다. 또한 응용 프로그램의 하위 구성 요소가 한 접근 방식에 비해 다른 접근 방식에 더 적합 할 수 있으므로 하이브리드 방식이 가능하다는 점을 고려해야합니다.

컨테이너 오케스트레이션

CaaS (Containers-as-a-Service) -인프라를 완전히 제어하고 최대한의 이식성을 확보하십시오. 예 : Kubernetes, Docker Swarm, Apache Mesos

Kubernetes, Swarm 및 Mesos와 같은 컨테이너 오케스트레이션 플랫폼을 통해 팀은 유연성 및 구성 제어 기능을 통해 휴대용 응용 프로그램을 빌드 및 배포 할 수 있으므로 다른 환경에 맞게 재구성 및 배포 할 필요없이 어디에서나 실행할 수 있습니다.

이점은 최대한의 제어, 유연성, 재사용 성 및 기존 컨테이너화 된 앱을 클라우드로 가져올 수있는 용이성을 포함하며,이 모든 기능은 덜 최적화 된 애플리케이션 배포 모델이 제공하는 자유도 때문에 가능합니다.

CaaS의 단점에는 운영 체제 (보안 패치 포함),로드 밸런싱, 용량 관리, 확장, 로깅 및 모니터링에 대한 개발자의 책임이 훨씬 더 많이 포함되어 있습니다.

잠재 고객 타겟팅

  • 응용 프로그램 및 모든 종속 항목의 패키지 및 버전 관리 방식을 제어하려는 개발자 및 운영 팀은 배포 플랫폼에서 이식성과 재사용 성을 보장합니다.
  • 상호 의존적이고 독립적으로 조정 된 마이크로 서비스의 응집력있는 세트 중에서 고성능을 찾는 개발자.
  • 컨테이너를 클라우드로 옮기거나 프라이빗 / 퍼블릭 클라우드에 배포하고 엔드 투 엔드 클러스터 배포 경험이있는 조직.

개발자 / 운영자 경험

  • Kubernetes 클러스터, Docker Swarm 스택 또는 Mesos 리소스 풀을 생성합니다 (한 번 완료).
  • 컨테이너 이미지를 로컬에서 반복하고 빌드하십시오.
  • 태그가 지정된 애플리케이션 이미지를 레지스트리로 푸시하십시오.
  • 컨테이너 이미지를 기반으로 컨테이너를 클러스터에 배포합니다.
  • 생산 적용을 테스트하고 관찰하십시오.

혜택

  • 개발자는 배포 대상에 대해 가장 많은 제어 권한과 그 기능과 함께 제공되는 책임을 갖습니다. 컨테이너 오케 스트레이터를 사용하면 런타임을 제어하는 ​​정책과 함께 배포 할 정확한 이미지 버전과 구성을 정의 할 수 있습니다.
  • 런타임 환경 (예 : 런타임, 버전, 최소 OS, 네트워크 구성)을 제어합니다.
  • 시스템 외부의 컨테이너 이미지의 재사용 성과 이식성이 향상되었습니다.
  • 컨테이너화 된 앱 및 시스템을 클라우드에 제공하는 데 적합합니다.

단점

  • 보안 패치 및 배포 최적화를 포함하여 파일 시스템 이미지 및 실행 환경에 대한 더 많은 책임.
  • 로드 밸런싱 및 스케일링 동작 관리에 대한 추가 책임.
  • 일반적으로 용량 관리에 대한 더 많은 책임.
  • 오늘날 일반적으로 시작 시간이 길어집니다.
  • 일반적으로 응용 프로그램 구조에 대한 의견이 적으므로 가이드 레일이 적습니다.
  • 일반적으로 빌드 및 배포 메커니즘에 대한 책임이 더 높습니다.
  • 일반적으로 모니터링, 로깅 및 기타 공통 서비스의 통합에 대한 책임이 더 높습니다.

서비스 형 플랫폼

PaaS (Platform-as-a-Service) -애플리케이션에 중점을두고 플랫폼이 나머지를 처리하도록합니다.

예 : Cloud Foundry, OpenShift, Deis, Heroku

서비스 형 플랫폼 구현을 통해 팀은 수동으로 구성 할 필요없이 애플리케이션에 구성 정보를 주입하여 광범위한 데이터 세트, AI, IoT 및 보안 서비스에 바인딩하여 광범위한 런타임 세트를 사용하여 애플리케이션을 배치 및 확장 할 수 있습니다. 컨테이너와 OS를 관리합니다. 안정적인 프로그래밍 모델이있는 기존 웹 앱에 매우 적합합니다.

장점은 응용 프로그램의 관리 및 배포가 쉬우 며, 가장 일반적인 응용 프로그램 요구에 맞게 자동 확장 및 사전 구성된 서비스를 포함합니다.

단점은 OS 제어 부족, 세분화 된 컨테이너 이식성 및로드 밸런싱 및 애플리케이션 최적화뿐만 아니라 잠재적 벤더 잠금 및 대부분의 PaaS 플랫폼에서 모니터링 및 로깅 기능을 구축 및 관리해야한다는 점입니다.

잠재 고객 타겟팅

  • OS에 대한 걱정없이 응용 프로그램 소스 코드 및 파일 (패키징이 아닌)에 집중할 수있는 배포 플랫폼을 원하는 개발자.
  • 기본적으로 라우팅 가능한 호스트 이름으로보다 전통적인 HTTP 기반 서비스 (앱 및 API)를 생성하는 개발자. 그러나 일부 PaaS 플랫폼은 이제 일반 TCP 라우팅도 지원합니다.
  • 포괄적 인 문서와 많은 샘플이 지원하는 서버리스와 비교하여보다 확립 된 클라우드 컴퓨팅 모델에 익숙한 조직.

개발자 / 운영자 경험

  • 애플리케이션을 반복하고 로컬 웹 개발 환경에서 빌드 및 테스트하십시오.
  • PaaS로 응용 프로그램을 빌드하고 실행합니다.
  • 생산 적용을 테스트하고 관찰하십시오.
  • 고 가용성을 보장하고 요구에 맞게 확장 할 수 있도록 구성을 업데이트하십시오.

혜택

  • 개발자의 참조 프레임은 응용 프로그램 코드 및 연결되는 데이터 서비스에 있습니다. 실제 런타임에 대한 제어는 적지 만 개발자는 빌드 단계를 피하고 확장 및 배포 옵션을 선택할 수도 있습니다.
  • 기본 OS를 관리 할 필요가 없습니다.
  • 빌드 팩은 런타임에 영향을 주어 원하는만큼 제어 할 수있는 수준 (기본 설정)을 제공합니다.
  • 안정적인 프로그래밍 모델을 사용하여 많은 기존 웹 앱에 적합합니다.

단점

  • 빌드 팩 버전에 따라 OS에 대한 통제력 상실.
  • 응용 프로그램 구조에 대해 더 많은 의견 을 가지고 아키텍처 유연성 비용 으로 12-Factor 마이크로 서비스 모범 사례를 지향 합니다.
  • 잠재적 인 플랫폼 잠금.

서버리스

서비스로서의 기능 (FaaS)

다양한 이벤트에 응답하는 작은 코드 조각으로 논리를 작성하십시오.

예 : AWS Lambda, Azure Functions, Apache OpenWhisk 기반의 IBM Cloud Functions, Google Cloud Functions, Huawei Function Stage and Function Graph, Kubeless, iron.io, funktion, fission, nuclio

서버리스를 통해 개발자는 다양한 트리거에 응답하는 이벤트 중심 기능으로 구성된 애플리케이션에 집중할 수 있으며 트리거-기능 로직, 한 기능에서 다른 기능으로 전달되는 정보, 자동 등 플랫폼이 나머지를 처리 ​​할 수 ​​있습니다. -컨테이너 및 런타임 (언제, 어디서, 무엇) 제공, 자동 확장, ID 관리 등

클라우드 네이티브 패러다임의 인프라 관리에 필요한 요구 사항이 가장 낮습니다. 운영 또는 파일 시스템, 런타임 또는 컨테이너 관리를 고려할 필요가 없습니다. 서버리스는 자동화 된 스케일링, 탄력적로드 밸런싱 및 가장 세부적인 “pay-as-you-go”컴퓨팅 모델을 즐깁니다.

단점은 덜 포괄적이고 안정적인 문서, 샘플, 도구 및 모범 사례를 포함합니다. 도전적인 디버깅; 잠재적으로 느린 응답 시간; 표준화 부족 및 생태계 성숙도 및 플랫폼 잠금 가능성.

잠재 고객 타겟팅

  • 수요에 따라 자동으로 확장되고 거래를 비용과 밀접하게 연계시키는 개별 기능 내에서 비즈니스 로직에 더 집중하고자하는 개발자.
  • 응용 프로그램을보다 빠르게 구축하고 운영 측면에 대한 관심이 적은 개발자
  • 데이터베이스 변경, IoT 판독 값, 사람 입력 등에 응답하는 이벤트 중심 응용 프로그램을 만드는 개발자 및 팀
  • 표준과 모범 사례가 아직 완전히 확립되지 않은 영역에서 최첨단 기술을 채택하는 것이 편한 조직.

개발자 / 운영자 경험

  • 로컬 웹 개발 환경에서 기능, 빌드 및 테스트를 반복합니다.
  • 서버리스 플랫폼에 개별 기능을 업로드하십시오.
  • 이벤트 트리거, 함수 및 런타임 및 이벤트 대 기능 관계를 선언하십시오.
  • 생산 적용을 테스트하고 관찰하십시오.
  • 고 가용성을 보장하고 요구에 맞게 확장하기 위해 구성을 업데이트 할 필요가 없습니다.

혜택

  • 개발자의 관점은 고 가용성 기능의 배포 관리와 같은 운영상의 문제에서 멀어지고 기능 로직 자체로 더 멀리 이동했습니다.
  • 개발자는 수요 / 워크로드에 따라 자동 스케일링을 얻습니다.
  • 타임 코드에 대해서만 청구되는 새로운 “pay-as-you-go”비용 모델을 활용합니다.
  • OS, 런타임 및 컨테이너 수명주기는 완전히 추상화됩니다 (서버리스).
  • IoT, 데이터, 메시지와 관련된 새로운 이벤트 중심 및 예측 불가능한 워크로드에 더 적합합니다.
  • 일반적으로 상태 비 저장, 불변 및 임시 배포. 각 기능은 지정된 역할과 리소스에 대한 잘 정의 된 / 제한된 액세스로 실행됩니다.
  • 미들웨어 계층이 조정 / 최적화되고 시간이 지남에 따라 애플리케이션 성능이 향상됩니다.
  • 대부분의 서버리스 런타임은 각 개별 기능의 크기 또는 실행 시간에 제한을 적용하므로 마이크로 서비스 모델을 강력하게 홍보합니다.
  • 클라이언트 또는 서버에서 유연하게 호출 할 수 있으므로 사용량에 따라 확장 가능한 타사 API를 맞춤형 서버리스 API로 쉽게 통합 할 수 있습니다.

단점

  • 덜 포괄적이고 안정적인 문서, 샘플, 도구 및 모범 사례를 통해 새롭게 등장한 컴퓨팅 모델, 빠른 혁신.
  • 런타임의 동적 특성으로 인해 IaaS 및 PaaS와 비교할 때 디버그하기가 더 어려울 수 있습니다.
  • 주문형 구조로 인해 유휴 상태에서 런타임이 함수의 모든 인스턴스를 제거하면 일부 서버리스 런타임의 “콜드 스타트”측면이 성능 문제가 될 수 있습니다.
  • 더 복잡한 경우 (예 : 다른 기능을 트리거하는 기능), 동일한 양의 로직에 대해 더 많은 작동 표면적이있을 수 있습니다.
  • 표준화 및 생태계 성숙 부족.
  • 플랫폼의 프로그래밍 모델, 이벤트 / 메시지 인터페이스 및 BaaS 오퍼링으로 인한 플랫폼 잠금 가능성.

어떤 Cloud Native Deployment 모델을 사용해야합니까?

특정 요구에 가장 적합한 모델을 결정하려면 각 접근 방식 (및 여러 모델 구현)을 철저히 평가해야합니다. 이 섹션에서는 모든 솔루션에 적합한 솔루션이 없기 때문에 고려할 영역에 대한 몇 가지 제안을 제공합니다.

기능 및 기능 평가

각 접근법을 실험하십시오. 기능 및 개발 경험의 관점에서 사용자 요구에 가장 적합한 것을 찾으십시오. 다음과 같은 질문에 대한 답을 찾으려고합니다.

  • 서버리스가 그 가치를 입증하는 이전 섹션에서 설명한 워크로드를 기반으로 내 애플리케이션이 적합한 것처럼 보입니까? 변경 사항을 정당화하는 대안과 서버리스의 주요 이점이 있습니까?
  • 런타임과 실행 환경에 대해 얼마나 많은 제어가 필요합니까? 사소한 런타임 버전 변경이 나에게 영향을 줍니까? 기본값을 무시할 수 있습니까?
  • 선택한 언어로 제공되는 모든 기능과 라이브러리를 사용할 수 있습니까? 필요한 경우 추가 모듈을 설치할 수 있습니까? 직접 패치하거나 업그레이드해야합니까?
  • 얼마나 많은 운영 제어가 필요합니까? 컨테이너 또는 실행 환경의 수명주기를 포기할 의향이 있습니까?
  • 서비스 코드를 변경해야하는 경우 어떻게합니까? 얼마나 빨리 배포 할 수 있습니까?
  • 서비스를 어떻게 보호합니까? 내가 관리해야합니까? 아니면 더 나은 서비스로 오프로드 할 수 있습니까?

운영 측면 평가 및 측정

PaaS 및 Container Orchestrator를 사용한 복구 시간과 서버리스 플랫폼으로의 콜드 스타트와 같은 성능 수치를 수집하십시오. 다음과 같이 각 플랫폼에서 응용 프로그램의 다른 중요한 비 기능적 특성의 영향을 살펴보고 수량화하십시오.

복원력 :

  • 애플리케이션을 데이터 센터 장애에 탄력적으로 만들려면 어떻게해야합니까?
  • 업데이트를 배포하는 동안 서비스 지속성을 어떻게 보장합니까?
  • 서비스가 실패하면 어떻게합니까? 플랫폼이 자동으로 복구됩니까? 최종 사용자에게는 보이지 않습니까?

확장 성 :

  • 급격한 수요 변화가있는 경우 플랫폼에서 자동 확장을 지원합니까?
  • 내 애플리케이션은 상태 비 저장 확장을 효과적으로 활용하도록 설계 되었습니까?
  • 서버리스 플랫폼이 데이터베이스와 같은 다른 구성 요소를 압도합니까? 역압을 관리하거나 조절할 수 있습니까?

공연:

  • 인스턴스 또는 HTTP 클라이언트 당 초당 몇 개의 함수 호출이 있습니까?
  • 주어진 워크로드에 몇 개의 서버 또는 인스턴스가 필요합니까?
  • 콜드 및 웜 스타트에서 호출에서 응답으로의 지연은 무엇입니까?
  • 마이크로 서비스와 단일 배치 내 동일 위치에있는 기능 간의 지연 시간이 문제입니까?

CNCF Serverless Working Group의 잠재적 결과 중 하나는 특정 모델을 선택할시기와 권장 도구 세트를 테스트하는 방법에 대한 의사 결정 프레임 워크가 될 수 있습니다. 자세한 내용은 결론 섹션을 참조하십시오.

잠재적 비용의 전체 스펙트럼 평가 및 고려

여기에는 개발 비용과 런타임 리소스 비용이 모두 포함됩니다.

  • 모든 사람이 처음부터 개발 활동을 시작할 수있는 것은 아닙니다. 따라서 기존 애플리케이션을 클라우드 기본 모델 중 하나로 마이그레이션하는 비용을 신중하게 고려해야합니다. 컨테이너에 대한 리프트 앤 시프트 모델이 가장 저렴 해 보일 수 있지만 장기적으로 가장 비용 효율적이지는 않을 수 있습니다. 마찬가지로, 서버리스의 온 디맨드 모델은 비용 관점에서 매우 매력적이지만 모 놀리 식 응용 프로그램을 기능으로 분할하는 데 필요한 개발 노력은 어려울 수 있습니다.
  • 종속 서비스와의 통합 비용은 얼마입니까? 서버리스 컴퓨팅은 처음에는 가장 경제적 인 것처럼 보일 수 있지만 더 비싼 타사 서비스 비용이 필요하거나 자동 확장이 매우 빨리 필요할 수 있으므로 사용 요금이 증가 할 수 있습니다.
  • 플랫폼은 어떤 기능 / 서비스를 무료로 제공합니까? 잠재적 인 이식성 비용으로 공급 업체의 생태계에 기꺼이 구매할 수 있습니까?

여러 플랫폼을 기반으로 응용 프로그램 실행

사용 가능한 다양한 클라우드 호스팅 기술을 살펴보면 분명하지 않지만 모든 배포에 단일 솔루션을 사용해야하는 이유는 없습니다. 실제로 단일 솔루션 내에서 동일한 솔루션을 사용해야하는 이유는 없습니다. 응용 프로그램이 여러 구성 요소 또는 마이크로 서비스로 분리되면 필요에 가장 적합한 경우 완전히 다른 인프라에 각각 개별적으로 배포 할 수 있습니다.

마찬가지로, 각 마이크로 서비스는 특정 목적을 위해 최고의 기술 (예 : 언어)로 개발 될 수도 있습니다. “모노리스의 해체”와 함께 제공되는 자유는 새로운 도전을 가져 오며, 다음 섹션에서는 플랫폼을 선택하고 마이크로 서비스를 개발할 때 고려해야 할 몇 가지 측면을 강조합니다.

배포 대상에서 분할 된 구성 요소

IoT 데모는 PaaS 애플리케이션을 사용하여 연결된 디바이스의 대시 보드에 대한 요청을 처리하고 서버리스 기능 세트를 사용하여 디바이스 자체의 MQTT 메시지 이벤트를 처리 할 수 ​​있습니다. 서버리스는 마법의 총알이 아니라 클라우드 네이티브 아키텍처 내에서 고려해야 할 새로운 옵션입니다.

둘 이상의 배포 대상을위한 설계

또 다른 설계 선택은 코드를 가능한 한 일반적으로 만들고, 로컬에서 테스트하고, 환경 변수와 같은 상황 정보를 사용하여 특정 환경에서 실행되는 방식에 영향을주는 것입니다. 예를 들어, 일반 오래된 Java 오브젝트 세트는 세 가지 주요 환경 중 하나에서 실행될 수 있으며 사용 가능한 환경 변수, 클래스 라이브러리 또는 바인딩 된 서비스를 기반으로하는 정확한 동작입니다.

모든 접근 방식에 대해 DevOps 파이프 라인을 계속 사용하십시오.

대부분의 컨테이너 오케스트레이션 플랫폼, PaaS 구현 및 서버리스 프레임 워크는 명령 행 도구로 구동 할 수 있으며 동일한 컨테이너 이미지를 한 번 빌드하여 각 플랫폼에서 재사용 할 수 있습니다.

모델 간 이식성을 용이하게하는 추상화 고려

현재 PaaS 또는 CaaS에서 실행되는 HTTP 기반 웹 애플리케이션을 서버리스 플랫폼으로 포팅하는 격차를 해소하는 타사 프로젝트 에코 시스템이 증가하고 있습니다. 여기에는 Serverless, Inc. 및 Zappa Framework의 여러 도구가 포함됩니다.

서버리스 프레임 워크는 Python WSGi 및 JAX-RS REST API와 같이 널리 사용되는 웹 애플리케이션 프레임 워크를 사용하여 작성된 애플리케이션이 서버리스 플랫폼에서 실행될 수 있도록하는 어댑터를 제공합니다. 이러한 프레임 워크는 여러 서버리스 플랫폼 간의 차이점에 대한 이식성과 추상화를 제공 할 수도 있습니다.

상세도 : 서버리스 처리 모델

이 섹션에서는 서버리스 프레임 워크 내의 현재 함수 사용법을 요약하고 서버리스 함수 요구 사항, 라이프 사이클, 호출 유형 및 필요한 추상화를 일반화합니다. 동일한 함수를 한 번 코딩하여 다른 서버리스 프레임 워크에서 사용할 수 있도록 서버리스 함수 스펙을 정의하는 것이 목표입니다. 이 섹션에서는 정확한 기능 구성 및 API를 정의하지 않습니다.

다음 다이어그램에 표시된 몇 가지 주요 요소가있는 것으로 FaaS 솔루션을 일반화 할 수 있습니다.

FaaS
  • 이벤트 소스 -하나 이상의 함수 인스턴스로 이벤트를 트리거 또는 스트리밍
  • 기능 인스턴스 -수요에 따라 확장 할 수있는 단일 기능 / 마이크로 서비스
  • FaaS Controller- 기능 인스턴스 및 해당 소스 배포, 제어 및 모니터링
  • 플랫폼 서비스 -FaaS 솔루션에서 사용하는 일반 클러스터 또는 클라우드 서비스 (백엔드 서비스로 지칭 됨)

서버리스 환경에서 함수의 수명주기를 살펴 보자.

기능 수명주기

다음 섹션에서는 함수 수명주기의 다양한 측면과 서버리스 프레임 워크 / 런타임이 일반적으로이를 관리하는 방법에 대해 설명합니다.

기능 배포 파이프 라인

기능 배포 파이프 라인

함수의 수명주기는 코드 작성 및 사양 및 메타 데이터 제공 (아래의 함수 정의 참조)으로 시작합니다. “빌더”엔티티는 코드 및 사양을 가져 와서 컴파일하고이를 아티팩트로 변환합니다 (코드 이진, 패키지 또는 컨테이너). 영상). 그런 다음 아티팩트는 이벤트 트래픽 및 / 또는 인스턴스의로드를 기반으로 기능 인스턴스 수를 조정하는 컨트롤러 엔티티와 함께 ​​클러스터에 배치됩니다.

기능 조작

서버리스 프레임 워크는 다음 조치 및 메소드가 기능 라이프 사이클을 정의하고 제어 할 수 있도록합니다.

  • 작성-스펙 및 코드를 포함하여 새 함수를 작성합니다
  • 공개-클러스터에 배치 할 수있는 새 버전의 함수를 작성합니다.
  • 버전의 별칭 / 레이블 업데이트-버전 별칭 업데이트
  • 실행 / 호출-이벤트 소스를 통하지 않고 특정 버전을 호출합니다.
  • 이벤트 소스 연관-특정 버전의 함수를 이벤트 소스와 연결
  • Get-함수 메타 데이터 및 스펙을 리턴합니다.
  • 업데이트-최신 버전의 함수 수정
  • 삭제-기능을 삭제합니다. 특정 버전 또는 모든 버전의 기능을 삭제할 수 있습니다
  • 목록-기능 및 해당 메타 데이터 목록을 표시합니다.
  • 통계 얻기-함수의 런타임 사용법에 대한 통계를 리턴합니다.
  • 로그 가져 오기-함수에 의해 생성 된 로그를 반환
기능 조작

함수를 작성할 때 함수 작성의 일부로 메타 데이터 (함수 스펙에 설명 됨)를 제공하면 컴파일되어 공개 될 수 있습니다. 기능은 나중에 시작, 비활성화 및 활성화 될 수 있습니다. 기능 배포는 다음 사용 사례를 지원할 수 있어야합니다.

  • 이벤트 스트리밍,이 사용 사례에서는 항상 큐에 이벤트가있을 수 있지만 명시 적 요청을 통해 처리를 일시 중지 / 재개해야 할 수 있습니다.
  • 웜 스타트-함수가 이미 배치되어 이벤트를 제공 할 준비가 되었기 때문에 수신 된 “처음”이벤트가 웜 스타트되도록, 항상 최소한의 인스턴스 수를 갖는 함수 “들어오는”이벤트에 의해 첫 번째 호출에 배치 된 경우)

사용자는 기능을 게시 할 수 있습니다 . 이렇게하면 새 버전 ( “최신”버전의 복사본)이 생성되고 게시 된 버전에는 태그 / 레이블이 지정되거나 별칭이있을 수 있습니다 (아래 참조).

사용자는 디버그 및 개발 프로세스를 위해 함수를 직접 실행 / 호출 (이벤트 소스 또는 API 게이트웨이 무시) 할 수 있습니다. 사용자는 원하는 버전, 동기화 / 비동기 작업, 세부 정보 수준 등과 같은 호출 매개 변수를 지정할 수 있습니다.

사용자는 함수 통계 (예 : 호출 횟수, 평균 런타임, 평균 지연, 실패, 재시도 등)를 얻을 수 있으며 통계는 현재 메트릭 값 또는 시계열 값 (예 : Prometheus 또는 클라우드 공급자 시설에 저장) 일 수 있습니다. (AWS Cloud Watch와 같은).

기능 로그 데이터 를 검색 할 수 있습니다 . 이것은 심각도 수준 및 / 또는 시간 범위 및 / 또는 내용으로 필터링 될 수 있습니다. 로그 데이터는 기능별이며 기능 작성 및 삭제, 명시 적 오류, 경고 또는 디버그 메시지와 같은 이벤트 및 선택적으로 함수의 Stdout 또는 Stderr를 포함합니다. 호출 당 하나의 로그 항목이 있거나 로그 항목을 특정 호출과 연관시키는 방법을 사용하는 것이 좋습니다 (함수 실행 흐름을보다 간단하게 추적 할 수 있도록).

함수 버전 및 별칭

기능에는 여러 버전이있을 수 있으며 사용자에게 베타 / 프로덕션, A / B 테스트 등과 같은 다른 수준의 코드를 실행할 수있는 기능을 제공 할 수 있습니다. 버전 관리를 사용하는 경우 기능 버전은 기본적으로 “최신”버전입니다. 변경 및 업데이트 될 때마다 새로운 빌드 프로세스를 트리거 할 가능성이 있습니다.

사용자가 버전을 고정 하려면 이벤트 소스를 구성 할 때 사용할 수있는 잠재적 인 태그 또는 별명 (예 : “베타”, “생산”)이있는 새 버전을 작성 하는 공개 조작을 사용하여 이벤트 또는 API 호출 특정 기능 버전으로 라우팅 될 수 있습니다. 최신 버전이 아닌 함수 버전은 변경할 수 없으며 (코드 및 일부 또는 모든 함수 사양) 게시 된 후에는 변경할 수 없습니다. 대신 “게시되지 않은”기능을 삭제할 수 없습니다.

오늘날 대부분의 구현에서는 구현과 사용법이 복잡하기 때문에 함수 브랜치 / 포크 (이전 버전 코드 업데이트)를 허용하지 않지만 향후에는이를 원할 수 있습니다.

동일한 기능의 여러 버전이있는 경우 사용자는 작동하려는 기능의 버전과 다른 버전간에 이벤트 트래픽을 나누는 방법을 지정해야합니다 (예 : 사용자가 이벤트 트래픽의 90 %를 라우팅하도록 결정할 수 있음) 안정적인 버전으로, 베타 버전 인 “카나리아 업데이트”로 10 %). 정확한 버전을 지정하거나 버전 별명을 지정하면됩니다. 버전 별명은 일반적으로 특정 기능 버전을 참조합니다.

사용자가 함수를 작성하거나 업데이트 할 때 변경의 특성에 따라 새 빌드 및 배치를 수행 할 수 있습니다.

이벤트 소스 대 기능 연관

이벤트 소스에 의해 트리거 된 이벤트의 결과로 함수가 호출됩니다. 함수와 이벤트 소스 간에는 : m 맵핑이 있습니다. 각 이벤트 소스는 하나 이상의 함수를 호출하는 데 사용될 수 있으며, 함수는 여러 이벤트 소스에 의해 트리거 될 수 있습니다. 이벤트 소스는 특정 버전의 함수 또는 별명에 맵핑 될 수 있으며, 후자는 기능을 변경하는 수단을 제공하고 이벤트 연관을 변경할 필요없이 새 버전을 배치합니다. 또한 이벤트 소스는 각각에 할당되어야하는 트래픽 양의 정의와 동일한 기능의 다른 버전을 사용하도록 정의 될 수 있습니다.

함수를 작성한 후 또는 나중에 이벤트의 결과로 함수 호출을 트리거해야하는 이벤트 소스를 연관시켜야합니다. 이를 위해서는 다음과 같은 일련의 조치 및 방법이 필요합니다.

  • 이벤트 소스 연관 작성
  • 이벤트 소스 연관 업데이트
  • 이벤트 소스 연관 나열

이벤트 소스

다양한 유형의 이벤트 소스에는 다음이 포함됩니다.

  • 이벤트 및 메시징 서비스 (예 : RabbitMQ, MQTT, SES, SNS, Google Pub / Sub)
  • 스토리지 서비스, 예 : S3, DynamoDB, Kinesis, Cognito, Google Cloud Storage, Azure Blob, iguazio V3IO (객체 / 스트림 / DB)
  • 엔드 포인트 서비스 (예 : IoT, HTTP 게이트웨이, 모바일 장치, Alexa, Google Cloud Endpoints)
  • 구성 리포지토리 (예 : Git, CodeCommit)
  • 언어 별 SDK를 사용하는 사용자 응용 프로그램
  • 예약 된 이벤트-일정한 간격으로 기능을 호출 할 수 있습니다.

이벤트 당 제공되는 데이터는 서로 다른 이벤트 소스마다 다를 수 있지만 이벤트 구조는 이벤트 소스와 관련하여 특정 정보를 캡슐화 할 수있는 능력을 갖추어야합니다 ( 이벤트 데이터 및 메타 데이터 세부 사항 참조 ).

기능 요구 사항

다음 목록은 오늘날의 최신 기술을 기반으로 기능 및 서버리스 런타임이 충족해야하는 공통 요구 사항 세트를 설명합니다.

  • 함수는 다른 이벤트 클래스의 기본 구현에서 분리되어야합니다.
  • 여러 이벤트 소스에서 함수가 호출 될 수 있음
  • 호출 방법마다 다른 기능이 필요 없음
  • 이벤트 소스는 여러 함수를 호출 할 수 있습니다
  • 함수는 기본 플랫폼 서비스와의 오래 지속되는 바인딩 메커니즘이 필요할 수 있으며, 이는 교차 함수 호출 일 수 있습니다. 기능은 수명이 짧을 수 있지만 로깅, 연결, 외부 데이터 소스 마운트와 같은 모든 호출에서 수행되어야하는 경우 부트 스트랩이 비쌀 수 있습니다.
  • 각 함수는 동일한 응용 프로그램 내에서 사용되는 다른 함수와 다른 코드 언어로 작성 될 수 있습니다
  • 함수 런타임은 가능한 경우 이벤트 직렬화 및 역 직렬화 오버 헤드를 최소화해야합니다 (예 : 모국어 구조 또는 효율적인 인코딩 체계 사용)

워크 플로우 관련 요구 사항 :

  • 함수의 결과가 다른 함수의 트리거 인 워크 플로우의 일부로 함수가 호출 될 수 있습니다.
  • 기능은 이벤트 또는 “및 / 또는 이벤트 조합”에 의해 트리거 될 수 있습니다.
  • 하나의 이벤트는 여러 기능을 순차적으로 또는 병렬로 실행할 수 있습니다
  • “및 / 또는 이벤트 조합”은 순차적으로 또는 병렬 또는 분기로 실행되는 m 개의 함수를 트리거 할 수 있습니다.
  • 워크 플로우 도중에 다른 이벤트 또는 함수 결과가 수신 될 수 있으며, 이로 인해 다른 함수로 분기가 트리거됩니다.
  • 함수 결과의 일부 또는 전부를 다른 함수에 대한 입력으로 전달해야합니다.
  • 함수에는 기본 플랫폼 서비스와의 오래 지속되는 바인딩 메커니즘이 필요할 수 있으며, 이는 교차 함수 호출이거나 함수 수명이 짧을 수 있습니다.

함수 호출 유형

다음과 같은 사용 사례에 따라 다른 이벤트 소스에서 함수를 호출 할 수 있습니다.

  1. 동기 요청 (요청 / 요청) , 예 : HTTP 요청, gRPC 호출
    • 클라이언트가 요청을 발행하고 즉각적인 응답을 기다립니다. 차단 통화입니다.
  2. RabbitMQ, AWS SNS, MQTT, 이메일, 객체 (S3) 변경, CRON 작업과 같은 예약 된 이벤트와 같은 비동기 메시지 큐 요청 (Pub / Sub)
    • 메시지가 교환에 게시되고 구독자에게 배포
    • 엄격한 메시지 순서가 없습니다. 정확히 한 번 처리
  3. 메시지 / 레코드 스트림 : 예 : Kafka, AWS Kinesis, AWS DynamoDB 스트림, 데이터베이스 CDC
    • 순서가 지정된 메시지 / 레코드 세트 (순차적으로 처리해야 함)
    • 일반적으로 스트림은 샤드 당 단일 작업자 (샤드 소비자)를 사용하여 여러 파티션 / 샤드로 샤딩됩니다.
    • 메시지, 데이터베이스 업데이트 (저널) 또는 파일 (예 : CSV, Json, Parquet)에서 스트림을 생성 할 수 있습니다.
    • 이벤트는 함수 런타임으로 푸시되거나 함수 런타임에 의해 당겨질 수 있습니다
  4. 배치 작업 ( 예 : ETL 작업, 분산 딥 러닝, HPC 시뮬레이션)
    • 작업은 스케줄되거나 큐에 제출되며, 각각 작업 세트의 하나 이상의 부분 (작업)을 처리하는 여러 기능 인스턴스를 병렬로 사용하여 런타임에 처리됩니다.
    • 모든 병렬 작업자가 모든 계산 작업을 성공적으로 완료하면 작업이 완료됩니다.

기능 코드

기능 코드 및 종속성 및 / 또는 바이너리는 S3 객체 버킷 또는 Git 리포지토리와 같은 외부 리포지토리에 있거나 사용자가 직접 제공 할 수 있습니다. 코드가 외부 저장소에있는 경우 사용자는 경로와 신임 정보를 지정해야합니다.

서버리스 프레임 워크를 통해 사용자는 코드 저장소에서 변경 사항 (예 : 웹 후크 사용)을보고 모든 커밋마다 자동으로 함수 이미지 / 바이너리를 구축 할 수 있습니다.

함수는 외부 라이브러리 또는 바이너리에 의존 할 수 있으며, 빌드 프로세스를 설명하는 방법 (예 : Dockerfile, Zip 사용)을 포함하여 사용자가 제공해야합니다.

또한이 기능은 OCI 이미지와 같은 일부 이진 패키징을 통해 프레임 워크에 제공 될 수 있습니다.

기능 정의

서버리스 함수 정의에는 다음 스펙 및 메타 데이터가 포함될 수 있으며 함수 정의는 버전마다 다릅니다.

  • 고유 ID
  • 이름
  • 기술
  • 라벨 (또는 태그)
  • 버전 ID (및 / 또는 버전 별칭)
  • 버전 생성 시간
  • 최종 수정 시간 (기능 정의)
  • 함수 핸들러
  • 런타임 언어
  • 코드 + 종속성 또는 코드 경로 및 자격 증명
  • 환경 변수
  • 실행 역할과 비밀
  • 리소스 (필요한 CPU, 메모리)
  • 실행 타임 아웃
  • 로그 실패 (Dead Letter Queue)
  • 네트워크 정책 / VPC
  • 데이터 바인딩

메타 데이터 세부 사항

기능 프레임 워크에는 기능에 대한 다음 메타 데이터가 포함될 수 있습니다.

  • 버전 -각 기능 버전에는 고유 식별자가 있어야하며, 버전은 하나 이상의 별명 (예 : “최신”, “생산”, “베타”)을 사용하여 레이블을 지정할 수 있습니다. API 게이트웨이 및 이벤트 소스는 트래픽 / 이벤트를 특정 기능 버전으로 라우팅합니다.
  • 환경 변수 -사용자는 런타임에 함수에 제공 될 환경 변수를 지정할 수 있습니다. 환경 변수는 비밀 및 암호화 된 콘텐츠 또는 플랫폼 변수 (예 : Kubernetes EnvVar 정의)에서 파생 될 수도 있습니다. 환경 변수를 사용하면 개발자가 코드를 수정하거나 기능을 재 구축 할 필요없이 기능 동작 및 매개 변수를 제어 할 수 있으므로 개발자 경험과 기능 재사용이 향상됩니다.
  • 실행 역할 -이 기능은 플랫폼 자원에 대한 액세스 권한을 부여하고 감사하는 특정 사용자 또는 역할 ID로 실행해야합니다.
  • 자원 -기능에서 사용하는 메모리 및 CPU와 같은 필수 또는 최대 하드웨어 자원을 정의하십시오.
  • 제한 시간 -플랫폼이 종료 할 때까지 함수 호출을 실행할 수있는 최대 시간을 지정하십시오.
  • 실패 로그 (Dead Letter Queue) -실패한 기능 실행 목록을 적절한 세부 정보와 함께 저장할 큐 또는 스트림의 경로입니다.
  • 네트워크 정책 -기능에 할당 된 네트워크 도메인 및 정책 (기능이 외부 서비스 / 자원과 통신하기 위해).
  • 실행 시맨틱 -함수 실행 방법을 지정합니다 (예 : 이벤트 당 한 번, 최대 한 번, 정확히 한 번).

데이터 바인딩

일부 서버리스 프레임 워크를 통해 사용자는 함수에서 사용하는 입력 / 출력 데이터 리소스를 지정할 수 있으므로 개발자의 단순성, 성능 (실행간에 데이터 연결이 유지되고 데이터를 미리 가져올 수있는 등) 및 보안 향상 (데이터 리소스)이 가능합니다 자격 증명은 코드가 아닌 컨텍스트의 일부입니다).

바운드 데이터는 파일, 객체, 레코드, 메시지 등의 형태 일 수 있으며, 기능 사양에는 각각 데이터 리소스, 자격 증명 및 사용 매개 변수를 지정하는 데이터 바인딩 정의 배열이 포함될 수 있습니다. 데이터 바인딩은 이벤트 데이터를 참조 할 수 있습니다 (예 : DB 키는 이벤트 “username”필드에서 파생 됨). 자세한 내용은 https://docs.microsoft.com/azure/azure-functions/functions-triggers-bindings를 참조하십시오 .

기능 입력

기능 입력은 이벤트 데이터 및 메타 데이터를 포함하고, 컨텍스트 객체를 포함 할 수있다.

이벤트 데이터 및 메타 데이터

이벤트 세부 사항은 함수 핸들러로 전달되어야하며, 다른 이벤트에는 다양한 메타 데이터가있을 수 있으므로 함수가 이벤트 유형을 판별하고 공통 및 이벤트 특정 메타 데이터를 쉽게 구문 분석 할 수있는 것이 바람직합니다.

이벤트 클래스를 구현에서 분리하는 것이 바람직 할 수 있습니다. 예를 들어, 메시지 스트림을 처리하는 함수는 스트리밍 스토리지가 Kafka인지 Kinesis인지에 관계없이 동일하게 작동합니다. 두 경우 모두, 메시지 본문과 이벤트 메타 데이터를 수신하며, 메시지가 다른 프레임 워크간에 라우팅 될 수 있습니다.

이벤트에는 단일 레코드 (예 : 요청 / 응답 모델)가 포함되거나 여러 레코드 또는 마이크로 배치 (예 : 스트리밍 모드)가 허용 될 수 있습니다.

FaaS 솔루션에서 사용하는 일반적인 이벤트 데이터 및 메타 데이터의 예 :

  • 이벤트 클래스 / 종류
  • 버전
  • 이벤트 ID
  • 이벤트 소스 / 원산지
  • 소스 신원
  • 컨텐츠 타입
  • 메시지 본문
  • 타임 스탬프

이벤트 / 레코드 특정 메타 데이터의 예

  • HTTP : 경로, 메소드, 헤더, 쿼리 인수
  • 메시지 대기열 : 주제, 헤더
  • 레코드 스트림 : 테이블, 키, op, 수정 된 시간, 이전 필드, 새 필드

이벤트 소스 구조의 예 :

일부 구현에서는 이벤트 정보를 함수에 전달하는 메커니즘으로 JSON에 중점을 둡니다. 이것은 고속 기능 (예를 들어, 스트림 처리) 또는 저에너지 장치 (IoT)를 위해 상당한 직렬화 / 직렬화 오버 헤드를 추가 할 수있다. 이러한 경우에는 기본 언어 구조 또는 추가 직렬화 메커니즘을 옵션으로 고려해 볼 가치가 있습니다.

기능 컨텍스트

함수가 호출되면 프레임 워크는 이벤트에 모든 정적 데이터를 배치하거나 모든 호출에서 플랫폼 서비스를 초기화하도록 강제하는 대신 여러 함수 호출에 걸쳐있는 플랫폼 리소스 또는 일반 속성에 대한 액세스를 제공 할 수 있습니다.

컨텍스트는 입력 특성, 환경 변수 또는 글로벌 변수 세트로 제공됩니다. 일부 구현에서는 세 가지를 모두 사용합니다.

문맥의 예 :

  • 기능 이름, 버전, ARN
  • 메모리 제한
  • 요청 ID
  • 클라우드 지역
  • 환경 변수
  • 보안 키 / 토큰
  • 런타임 / 바인 경로
  • 로그
  • 데이터 바인딩

일부 구현은 로그 객체를 사용하여 로그 객체를 초기화합니다 (예 : AWS의 전역 변수 또는 Azure의 컨텍스트 일부). 사용자는 통합 플랫폼 기능을 사용하여 함수 실행을 추적 할 수 있습니다. 기존의 로깅 외에도 향후 구현에서는 플랫폼 컨텍스트의 일부로 카운터 / 모니터링 및 추적 활동을 추상화하여 기능 사용성을 더욱 향상시킬 수 있습니다.

데이터 바인딩은 함수 컨텍스트의 일부이며, 플랫폼은 사용자 구성을 기반으로 외부 데이터 리소스에 대한 연결을 시작하며 이러한 연결은 여러 함수 호출에서 재사용 될 수 있습니다.

기능 출력

함수가 종료되면 다음이 수행 될 수 있습니다.

  • 호출자에게 값을 반환합니다 (예 : HTTP 요청 / 응답 예).
  • 워크 플로우에서 다음 실행 단계로 결과 전달
  • 출력을 로그에 기록

리턴 된 오류 값 또는 종료 코드를 통해 함수가 성공했는지 실패했는지 판별 할 수있는 결정적인 방법이 있어야합니다.

함수 출력은 구조화되거나 (예 : HTTP 응답 객체) 구조화되지 않을 수 있습니다 (예 : 일부 출력 문자열).

서버리스 기능 워크 플로우

서버리스 도메인에서 사용 사례는 다음 범주 중 하나에 속합니다.

  1. 하나의 이벤트가 하나의 기능을 트리거합니다
  2. 이벤트의 조합 및 / 또는 하나의 기능을 트리거
  3. 하나의 이벤트는 순차적으로 또는 병렬로 실행되는 여러 기능을 트리거합니다
  4. 함수의 결과는 다른 함수의 트리거 일 수 있습니다.
  5. N 개의 이벤트 (in 및 / 또는)는 m 개의 기능, 즉 이벤트-함수 인터리브 된 워크 플로우를 트리거한다. event1은 function1을 트리거하고, function2는 event2 및 event 3과 함께 function2를 트리거하며, function2의 다른 결과는 function3 또는 function4로 분기됩니다.

사용자는 서버리스 사용 사례 또는 워크 플로우를 지정하는 방법이 필요합니다. 예를 들어, 하나의 유스 케이스는 “사진이 클라우드 스토리지에 업로드 될 때 사진에서 얼굴 인식을 수행합니다 (사진 스토리지 이벤트 발생)”입니다. 모션 감지 이벤트가 수신 될 때 또 다른 IoT 사용 사례는 “모션 분석 ​​수행”일 수 있습니다. 그런 다음 분석 기능의 결과에 따라 “집 경보 및 경찰서에 전화 걸기”또는 “모바일 이미지를 자세한 내용은 사용 사례 섹션을 참조하십시오.

AWS는 사용자가 워크 플로를 지정할 수 있도록 “단계 함수”기본 (상태 머신 기반 기본)을 제공하지만 단계 함수는 워크 플로에서 어떤 기능을 트리거 할 이벤트 / 이벤트를 지정할 수 없습니다. https://aws.amazon.com/step-functions/ 를 참조하십시오 .

다음 그래프는 이벤트 및 기능과 관련된 사용자 워크 플로의 예입니다. 이러한 함수 그래프를 사용하면 이벤트와 함수 간의 상호 작용은 물론 워크 플로의 함수간에 정보를 전달할 수있는 방법을 쉽게 지정할 수 있습니다.

이미지 대체 텍스트

기능 그래프 상태에는 다음이 포함됩니다.

이벤트 상태이 상태를 사용하면 이벤트 소스에서 이벤트를 기다린 후 기능 실행 또는 여러 기능을 순차적으로 또는 병렬 또는 분기로 실행시킬 수 있습니다.

작동 / 작업 상태이 상태에서는 이벤트를 기다리지 않고 하나 이상의 기능을 순차적으로 또는 병렬로 실행할 수 있습니다.

스위치 / 선택 상태이 상태는 여러 다른 상태로의 전환을 허용합니다 (예 : 이전 기능 결과로 분기 / 전환이 다른 다음 상태로 트리거 됨).

종료 / 중지 상태이 상태는 실패 / 성공으로 워크 플로우를 종료합니다.

통과 상태이 상태는 두 상태 사이의 이벤트 데이터를 주입합니다.

지연 / 대기 상태이 상태는 워크 플로 실행이 지정된 기간 동안 또는 지정된 시간 / 날짜까지 지연되도록합니다.

장애 복구를 위해 상태 및 관련 정보를 일부 영구 저장소에 저장해야합니다. 일부 사용 사례에서 사용자는 한 상태의 정보가 다음 상태로 전달되기를 원할 수 있습니다. 이 정보는 함수 실행 결과의 일부이거나 이벤트 트리거와 연관된 입력 데이터의 일부일 수 있습니다. 상태간에 전달해야하는 정보를 필터링하려면 각 상태마다 정보 필터를 정의해야합니다.

기능 상호 작용 (종종 결과 워크 플로를 시각적으로 표시)을 지정하고 기능 오케스트레이션을 관리하는 방법을 제공하는 것 외에도 워크 플로 도구는 “워크 플로 인스턴스”실행 상태를 파악하고 워크 플로로 이어지는 문제를 해결하는 수단을 제공 할 수 있습니다. 다음 단계로 진행할 수없는 인스턴스. 한 기능에서 다른 기능으로의 워크 플로우 인스턴스 흐름은 모니터링 및 관리가 어려울 수 있습니다.

워크 플로우 도구는 또한 워크 플로우의 모든 이전 실행의 히스토리 데이터를 제공하여 어떤 브랜치가 취해 졌는지, 특정 브랜치를 취하기위한 결정에 참조 된 데이터 등을 문서화 할 수 있습니다. 이 데이터는 감사 로그 (예 : 엄격한 규제 요구 사항이있는 산업) 또는 다기능 워크 플로의 성능을 분석 및 개선하는 데 사용할 수 있습니다.

소프트웨어 컨설팅 업체 인 Esentri 는 Fn Project 및 Zeebe와 함께 개념 증명을 구축하여 수평 확장 가능한 워크 플로우 엔진으로 서버리스 기능을 조정하는 방법을 시연했습니다 .

결론

서버리스 아키텍처는 클라우드 네이티브 워크로드를위한 새롭고 흥미로운 배포 옵션을 제공합니다. 서버리스 워크로드 섹션 에서 보았 듯이 서버리스 기술이 다른 클라우드 호스팅 기술보다 큰 이점을 제공하는 특정 사용 사례가 있습니다.

그러나 서버리스 기술은 모든 경우에 완벽하게 적합하지는 않으며 적절한 경우 신중하게 고려해야합니다. 수명이 짧은 이벤트 중심 처리는 예측 가능한 용량과 인프라 요구로 인해 높은 변화율을 기대하는 비즈니스에 조기 채택 및 사용 사례를 주도하고 있습니다. 참고 항목 추가 참조 더 서버없는 컴퓨팅에 재료와 통찰력을 읽기위한 섹션을 참조하십시오.

CNCF Serverless Working Group은 Redpoint Ventures 와 제휴하여 최근에 Serverless Landscape를 발표했습니다 . 생태계에서 사용 가능한 주요 서버리스 프로젝트, 툴링 및 서비스 중 일부를 보여줍니다. 포괄적이고 포괄적 인 서버리스 에코 시스템을 나타 내기위한 것이 아니며, 단순히 환경에 대한 개요 만 보증하는 것이 아닙니다. 각 소유자는 최신 상태를 유지하기 위해 업데이트를 제공해야합니다.

CNCF의 다음 단계

CNCF가이 분야에서해야 할 일과 관련하여 기술 감독위원회가 고려해야 할 사항은 다음과 같습니다.

  • 더 많은 서버리스 기술 공급 업체와 오픈 소스 개발자가 CNCF 에 가입하여 아이디어를 공유하고 서로의 혁신을 구축하도록 장려하십시오 . 예를 들어 Serverless Landscape 문서에 나열된 오픈 소스 프로젝트를 업데이트하고 기능 매트릭스를 유지하십시오.
  • 상호 운용 가능한 API를 설정하여 공급 업체의 약속과 오픈 소스 도구로 상호 운용 가능한 구현을 보장함으로써 개방형 에코 시스템을 육성하십시오 . 플랫폼 제공 업체 및 타사 개발자 라이브러리 제작자의 도움을 받아 CSI 및 CNI 와 유사한 새로운 상호 운용성 및 이식성 노력 . 이들 중 일부는 자체 CNCF 작업 그룹에 가치가 있거나 서버리스 WG의 주도권으로 계속 될 수 있습니다. 예를 들면 다음과 같습니다.
    • 이벤트 : 메타 데이터와 함께 공통 이벤트 형식 및 API를 정의하십시오. 일부 초기 제안은 Serverless WG github repo 에서 찾을 수 있습니다 .
    • 배포 : 서버리스 제공 업체 인 기존 CNCF 멤버를 활용하여 새로운 작업 그룹을 시작하여 일반적인 기능 정의 세트, 메타 데이터와 조화를 이룰 수있는 가능한 작은 단계를 탐색합니다. 예를 들면 다음과 같습니다.
    • 기능 워크 플로우다른 제공 업체의 서버리스 플랫폼 단일 기능을 트리거하는 단일 이벤트를 넘어서는 여러 사용 시나리오가 있으며 순서대로 또는 병렬로 실행되고 여러 이벤트 조합에 의해 트리거되는 여러 기능의 워크 플로우와 워크 플로우의 이전 단계에서 함수의 리턴 값이 트리거됩니다. 개발자가 유스 케이스 워크 플로우를 정의하는 데 사용할 수있는 공통 구성 세트를 정의 할 수 있으면 다른 서버리스 플랫폼에서 사용할 수있는 도구를 작성할 수 있습니다. 이러한 구성은 이벤트와 함수 간의 관계 / 상호 작용, 워크 플로우에서 함수 간의 관계 / 상호 작용, 한 함수에서 다음 단계 함수로 정보를 전달하는 방법 등을 지정합니다.
  • 다음과 같은 우려 영역을 탐색하면서 개발자 채택 및 속도를 가속화하는 오픈 소스 도구 에코 시스템을 육성하십시오.
    • 수단
    • 디버깅 가능성
  • 교육 : 새로운 사용자를위한 일련의 디자인 패턴, 참조 아키텍처 및 공통 어휘를 제공합니다.
    • 용어집 : 게시 된 형태로 용어집 (부록 A)을 유지하고 실무 그룹 문서에서 이러한 용어를 일관되게 사용하도록합니다.
    • 유스 케이스 : 공통 패턴으로 그룹화 된 유스 케이스 목록을 유지하여 공유 된 상위 레벨 어휘를 작성하십시오. 다음 목표를 지원합니다.
      • 서버리스 플랫폼을 처음 사용하는 개발자의 경우 : 일반적인 사용 사례에 대한 이해를 높이고 올바른 진입 점을 식별하십시오.
      • 서버리스 제공 업체 및 라이브러리 / 프레임 워크 작성자의 경우 일반적인 요구 사항을 쉽게 고려할 수 있습니다.
    • 상호 운용성 측면을 강조하거나 각 공급자의 외부 리소스에 연결하는 것을 선호하는 CNCF GitHub 리포지토리의 샘플 응용 프로그램 및 오픈 소스 도구.
  • CaaS 또는 PaaS와 관련하여 서버리스 아키텍처의 기능적 및 비 기능적 특성을 평가하는 방법에 대한 지침을 제공하십시오. 이것은 의사 결정 트리의 형태를 취하거나 CNCF 프로젝트 제품군 내에서 도구 세트를 추천 할 수 있습니다.
  • 서버리스 보안 개발 지침, 서버리스 배포 강화, 적절한 보안 로깅 및 모니터링, 관련 도구 및 절차와 같은 서버리스 보안 주제에 대한 지침을 제공합니다 ( 서버리스 아키텍처에서 가장 중요한 10 가지 보안 위험 참조 ).
  • 이 서버리스 워킹 그룹 및 스토리지 워킹 그룹과 같은 CNCF 출력에 대한 프로세스를 시작하여 시간이 지남에 따라 공동으로 관리 할 수있는 GitHub에서 마크 다운 파일로 작동합니다. 이 공간에서 혁신의 속도.

부록 A : 용어집

이 섹션에서는이 백서에 사용 된 일부 용어를 정의합니다.

백엔드 서비스

응용 프로그램은 종종 응용 프로그램 외부에서 관리되는 서비스 (예 : 원격 저장소 서비스)를 활용합니다. 이를 통해 응용 프로그램은 핵심 비즈니스 논리에 집중할 수 있습니다. 이 타사 서비스 모음을 BaaS (Backend-as-a-Service)라고도합니다. 이들은 전통적인 컴퓨팅 플랫폼 또는 서버리스에서 사용될 수 있지만 BaaS는 서버리스 아키텍처에서 무 상태 기능에 대한 지원 인프라 (예 : 상태 제공)가되기 때문에 서버리스 아키텍처에서 중요한 역할을합니다. BaaS 플랫폼은 서버리스 컴퓨팅을 트리거하는 이벤트를 생성 할 수도 있습니다.

콜드 스타트

“콜드 스타트”는 일반적으로 새 코드를 사용하여 배포되지 않은 상태에서 함수 인스턴스를 시작하는 것을 말합니다.

문맥

서버리스 플랫폼은 일반적으로 트리거 메타 데이터 및 환경 또는이 특정 함수 호출 주변 환경에 대한 기타 정보를 포함하여 기능을 실행할 때 Context 오브젝트를 입력 매개 변수로 제공합니다.

데이터 바인딩

기능에는 백엔드 스토리지 (예 : 마운트 포인트 / 볼륨 / 오브젝트 저장소 등), 데이터베이스 등과 같은 데이터에 오래 연결하기 위해 데이터 바인딩이 필요할 수 있습니다. 데이터 바인딩에는 함수 자체 내에서 보존 할 수없는 비밀과 같은 보안 정보가 포함될 수 있습니다. . 데이터 바인딩은 여러 함수 호출에서 사용될 수 있습니다.

개발 프레임 워크

기능이 개발되는 환경. 로컬 (예 : 랩톱) 또는 호스팅 된 환경 일 수 있습니다.

행사

발생한 일의 알림.

이벤트 협회

이벤트 소스와 이벤트 결과로 실행되는 특정 기능 간의 맵핑

이벤트 데이터

발생한 이벤트와 관련된 정보. 자세한 정보는 이벤트 데이터 및 메타 데이터 를 참조하십시오.

이벤트 소스

HTTP 게이트웨이, 메시지 큐, 스트림 등과 같은 하나 이상의 이벤트 소스 유형을 통해 함수를 호출하거나 데이터베이스 쓰기, IoT 센서 활성화 또는 비활성 기간과 같은 시스템의 변경에 따라 생성 할 수 있습니다.

기능 / 액션

트리거의 결과로 실행되는 코드입니다.

기능 그래프 / 워크 플로우

개발자의 서버리스 시나리오에는 일반적으로 이벤트, 기능, 이벤트 기능 상호 작용 및 기능 간의 조정에 대한 정의가 포함됩니다. 일부 사용 사례에는 여러 개의 이벤트와 여러 기능이 있습니다. 기능 그래프 / 워크 플로우는 이벤트 기능 상호 작용 및 기능 조정을 설명합니다. 사용자는 기능이 순차적으로 또는 병렬로 실행되는지, 기능간에 전환되는지, 워크 플로에서 한 기능에서 다음 기능으로 정보가 전달되는 방식에 따라 이벤트가 어떤 기능을 트리거 하는지를 지정할 수 있습니다. 함수 그래프는 워크 플로 상태 모음과 이러한 상태 간 전환으로 볼 수 있으며 각 상태에는 연결된 이벤트 및 함수가 있습니다. 함수 그래프 / 워크 플로우의 예는 AWS의 단계 함수입니다.

기능 매개 변수

함수가 호출되면 런타임 프레임 워크는 일반적으로이 특정 호출에 대한 메타 데이터를 매개 변수 세트로 제공합니다 (컨텍스트 참조).

서비스 기능

FaaS는 요청시 최종 사용자가 제공하는 기능을 실행하기위한 플랫폼의 핵심 기능을 설명합니다. 서버리스 플랫폼의 핵심 구성 요소로, 자동 규모 조정 및 청구를 포함하여 사용자 대신 기능을 관리하는 추가 서비스 품질 기능이 포함되어 있습니다.

기도

기능을 실행하는 행위. 예를 들어, 이벤트 결과.

런타임 프레임 워크

서버리스 워크 플로우가 실행되는 런타임 환경 / 플랫폼, 트리거가 기능에 맵핑되고, 컨테이너 자원을 호스팅하는 기능 및 언어 패키지 / 라이브러리가 동적으로 프로비저닝되고 해당 기능이 실행됩니다. 때때로 런타임 프레임 워크에는 함수를 작성할 수있는 고정 된 런타임 언어 세트가 있습니다.

방아쇠

기능 실행 요청. 종종 트리거는 HTTP 요청, 데이터베이스 변경 또는 메시지 스트림과 같은 수신 이벤트의 결과입니다.

따뜻한 시작

“따뜻한 시작”은 중지 된 (그러나 배포 된) 상태에서 함수 인스턴스가 시작되는 것을 나타냅니다.

부록 B : 추가 참조

서버리스 컴퓨팅에 대한 추가 리소스를 찾는 사람들을 위해 다음 참조가 제공됩니다.