KubeCon 2022 Europe - Empower Autonomous Driving with Cloud Native Serverless Technologies

https://youtu.be/gPee28M04R8

Empower Autonomous Driving with Cloud Native Serverless Technologies - Benjamin Huo & Xiuming Lu

자율주행 & Cloud Native Serverless.

 

 

OpenFunction: Cloud Native FaaS Platform.

• 왜 사용했는가 / 어떻게 사용하는가.

 

k8s의 등장은 Multi-cloud / hybrid-cloud / distributed cloud 등 여러 형태로 cloud agnostic (클라우드 불가지론) 을 가능하게 했음.

• Cloud Agnostic : refers to tools, platforms, or applications that are compatible with any cloud infrastructure and can be moved to and from different cloud environments without any operational issues.
  • 출처: https://www.cloudzero.com/blog/cloud-agnostic
  • 특정 클라우드 vendor에 종속성 없이 / 모든 클라우드 환경에 호환되는 형태 Application, Tools, Platform을 말함.
• FaaS는 Cloud Agnostic이 어려운 영역 중 하나.
  • 각각의 cloud provider가 FaaS 플랫폼을 직접 운영하고 있으며
  • 각 플랫폼마다 자신들이 보유한 클라우드 백엔드에 종속된 형태로 서비스를 제공했기 때문.
  • 따라서 Compatibility 확보가 어려움. Move without Operation Issues가 쉽지 않음.

 

그러면 Cloud Agnostic한 FaaS 플랫폼은 불가능한가?

• 가능하다. 요즘 나오는 CNCF Serverless Platform을 사용하면 된다.
• 여러 가지가 있지만, 강연에서는 Dapr과 KEDA를 설명함

 

KEDA : 여러 metrics과 source를 토대로 k8s AutoScale이 가능함.

• 오른쪽에 있는 수많은 source : Elasticsearch, Mysql, Cassandra, AWS CloudWatch 등등... 을 토대로 scaling이 가능하다는 듯

 

요런 식으로 stack을 쌓아서 distributed Application과 underlying backend service 간 Decoupling하는 것도 가능하다고 함.

• ex) pub/sub building block을 사용해서 event publisher와 subscriber 간 디커플링.
  • kafka같은 오픈소스 메시지 브로커 / cloud provider의 메시지 브로커 전부 적용이 가능함

 

FaaS 플랫폼에게 필요한 것

• Support Various Language
• 여러 형태의 백엔드 서비스와의 통신

예컨대 강의 슬라이드처럼 5개 언어를 지원한다고 가정하고, 10개의 Message Queue를 지원한다고 하면

• Dapr가 없을 경우 각 언어 - 각 MQ를 SDK로 직접 연결
• Dapr를 사용하면 Dapr가 일종의 Virtual MQ 역할을 담당할 수 있음.
  • 각 언어는 Dapr SDK만 사용해서 REST API 생성하면 됨. -> 언어별 구현만 해내면 된다.

 

일종의 Unified Interface Btwn FaaS <-> Backend Service

 

Dapr를 개발자 커뮤니티에 소개했는데 반응 좋았다고 함

 

---

OpenFunction은 그럼 정확히 무엇인가 : CNCF 기반, 호환 가능한 FaaS 플랫폼

https://github.com/OpenFunction/OpenFunction

• 세 개의 컴포넌트
  • build : 현재 CNCF buildpack를 지원하고 있음. 소스코드를 container image로 변환하는 역할. 슬라이드에 있는 나머지 세 개 - buildah, buildKit, Kaniko - 는 dockerfile relevant build Tech.
  • Serving : 가장 중요한 파트. Async Runtime과 Sync Runtime을 지원함.
    • Sync는 Knative를 지원하고 있으며, KEDA + HTTP 지원 예정. 현재 KEDA의 maintainer이기도 함.
    • Async Runtime을 제공한다는 점이 OpenFunctions의 차별점이라 생각함.
  • Events : Knative Eventing과 유사하며, Argo Events에 영감을 받아 만들어짐.

 

Build : Source Code to Image 절차

1. OpenFunctions에서 빌드 요청
2. ShipWright build를 생성, 빌드 실행
3. BuildStrategy와 결합해서 Tekton task를 생성함.
   1. 실제 build Step은 tekton이 만들고 순차적으로 실행함.

 

Serving

• Sync는 Knative Serving을 사용함.
• Sync / Async건 공통적으로는 Dapr 사용.
  • sync의 경우 dapr component에서 리턴하는 Output만 사용. input은 http로 오기 때문
  • Async의 경우 dapr component의 input / output 둘 다 사용.
• KEDA는 현재 Scaling 용도로 사용 중. 추후엔 KEDA + http 자체를 async runtime으로 적용하려 함.
• Pool Runtime이라는 형태도 추후 지원 예정. Existing pod in a poll을 사용해서 start the function instance (?)
  • 더 빠른 함수 생성을 가능하게 하기 위함.

 

Eventing

• Argo Events를 참고해서 만들어진 구조이지만, Event Bus in Open Function은 underlying Broker와 디커플링을 지향했다는 점이 다름.
  • 디커플링을 위한 도구로 Dapr Pub/Sub building block 사용.
  • 오픈소스 MQ나 Cloud Provider MQ 둘 다 지원됨.

1. 이벤트가 들어온다 (EventSource Workload)
2. Call Sync Function Directly / Write event to Event Bus
3. Event Bus에 이벤트가 들어올 경우 -> 적절한 Async 함수를 바로 호출하거나, 필요한 조건에 맞게 filtering할 수 있는 trigger를 실행한다. = open functions의 Events.

Function Framework

Google Cloud Function 참고해서 만들어진 구조.

핵심 component: Context, Plugins, Runtime, Framework.

1. Framework이 Function Context를 읽어들이고, Plugin에 등록한다 (Register the plugins.)
2. Create Function Runtime -> Start runtime. (Sync / Async 함수 생성)
3. Trigger가 들어오면
   1. Execute the Pre-phase hooks.
   2. Execute User functions
   3. Execute the post-phase hooks.
   4. Process the function output.

Proposal : https://github.com/OpenFunction/OpenFunction/blob/main/docs/proposals/202112_functions_framework_refactoring.md

 

Function Tracing

Plugins: function tracing을 위한 기능.

 

FaaS 플랫폼에서는 Function Tracing 기능이 매우 중요함. (Performance 등등)

• Skywalking을 지원하는 듯 하며, 추후 로드맵으로 OpenTelemetry와의 연동을 제시함

 

Usecase example

1. 사용자가 http 요청을 sync function으로 보냄
2. sync function이 kafka로 메시지 생성 -> trigger
3. MQ에서 트리거된 async function이 실행됨

여기서 사용자에게 필요한 정보는 "sync function과 async function이 실행될 때까지 각각 얼마의 시간이 걸렸는가".

• tracing option을 위와 같이 yaml 파일 형태로 선언해서 적용 가능. annotation에 plugins.tracing 필드에 문자열로 선언해서 사용할 수 있다.
  • 예시의 경우 provider로 skywalking을, oapServer 필드값이나 tag를 지정해서 사용한다.
  • skywalking : APM (application performance monitor) system designed for microservices / cloud native / container-based architecture.
  • OAP : Open Access Protocol
  • https://hub.docker.com/r/apache/skywalking-oap-server 나 https://github.com/apache/skywalking
• configmap으로 선언해서 사용할 수도 있다. 이 경우 여러 functions에서 공통적으로 같은 값을 적용할 수 있다고 하는 거 같음

 

따라서 sync / async function의 tracing configuration을 보고 싶으면 skywalking의 ui stack을 사용해서 볼 수 있다.

참고문서

• https://github.com/OpenFunction/samples/tree/main/functions/tracing
• https://demo.skywalking.apache.org/functions <- 강의에 링크는 있는데 안들어가짐
• cf. 네이버가 개발해 쓰고 있는 APM 오픈소스 툴 : pinpoint

 

현재 openfunction을 적용하고 있는 사례들. -> Early Adopters / Contributors들인 셈

• 중국의 low code 플랫폼 중 하나가 OpenFunction 사용 중
• 자율주행차 업계 (UISEE)? 가 쓰고 있다는 듯

 

현재 Golang을 제공중, 나머지 언어도 제공할 예정.

 

Demo

1번 예시는 시간관계상 실습을 보여주진 않음

• https://github.com/OpenFunction/samples/tree/main/functions/async/logs-handler-function

코드로만 간단히 설명했는데

1. kubernetes log을 kafka로 전송하면
2. 로그를 consume하는 여러 개의 async 함수를 생성하고
3. 에러를 탐지할 때마다 실행 -> slack으로 notification 받을 수 있는 구조.

 

2번 예시

• https://github.com/OpenFunction/samples/tree/main/functions/knative/with-output-binding

openfunction CRD를 사용해서 kafka 메시지로 input 받기 / topic binding하기 / output으로 값 전달하기 등이 있음.

---

예시: Using OpenFuntion in Autonomous Driving

• 자율주행차의 대략적인 interaction 흐름도.

 

왜 자율주행차에 Cloud Agnostic FaaS가 필요한가?

• 자율주행의 핵심은 AI 알고리즘, ai 학습을 위한 데이터는 public cloud에 올리기 민감한 정보라 보통 private cloud를 사용함
• 자율주행은 Application 시나리오가 매우 많고 / 각각의 프로세스 로직이 매우 많고 복잡함.
• 실시간으로 들어오는 스트리밍 데이터의 처리 -> Scalability 필요함.
• 기술이 발전하면 데이터 프로세스 로직이 자주 바뀌어야 하는데, FaaS에서 대응할 수 있어야 함.

 

KEDA (Scaling)

• 데이터 프로세싱을 위해 들어오는 데이터가 항상 일정할 수는 없음. 예컨대 주변 트래픽이 혼잡하면 처리해야 할 정보가 더 많아짐.
• 보안 이슈 때문에 데이터 refresh가 빠른 주기로 이루어져야 함

Dapr의 필요성

• 자율주행은 여러 언어로 된 데이터 프로세싱 / AI 관련 모듈을 사용함. 따라서 여러 언어를 지원하는 Dapr는 유용함
• shadow device (abstraction of physical devices in the cloud -> 코드를 실행하고 physical device에 명령을 내리는 역할 수행) 에서는 async를 사용해서 성능이슈와 side effect를 관리함. Dapr의 pub/sub 방식으로 async 처리 가능.

 

• Dapr를 활용해서 Language Dependency를 낮추고 Async 실행이 가능하며
• KEDA로 auto scaling 가능.