KubeCon 2022 Europe - Crack the FaaS Cold Start and Scalability BottleNeck

https://youtu.be/RUfcc-OpBAM

What is FaaS?

An Event-Drive Architecture based Computing service

• provided by Cloud Service Providers which allocates containers/MicroVMs on demand
• to run the developers' function code in response to event request.

3 Key Feature

• Automatic On-Demand instantiation of function instances to run the function code, upon a trigger event.
  • 트리거 이벤트가 있을 때, 온디맨드로 사용자의 코드를 실행할 수 있는 환경을 생성하고 실행함
• 온디맨드 AutoScale out / in. User가 traffic을 고려할 필요 없음
• utility-based bidding. 유휴시간 (idle time)에 대한 비용을 내지 않음

 

• Cloud Computing의 미래로 평가받고 있으며, CSP에서 제공하는 서비스 (AWS, GCP, Azure) 사용량과 호출빈도가 늘어나고 있음
• Multi-tenancy / Security 측면에서도 CSP에서 보장함.

FaaS 서비스가 해결해야 하는 Challenge

• Cold Start Latency -> scale down to 0일 경우 invoke에서 실행까지 몇 초는 필요함
• autoscaling speed. 트래픽 증가에 대응하도록 인스턴스를 추가할 때, 할당부터 실행까지 걸리는 시간

 

새로운 microVM을 할당하고 함수가 실행될 때까지의 Containerd context.

1. 이벤트가 들어오면 container가 image를 pull 받아온다
2. root 파일시스템을 구축하고, runtime Shim을 실행한다.
3. runtime Shim은 CNI network를 세팅하고, microVM를 생성한다.
4. microVM의 kernel가 내부적으로 동작할 container를 생성한다.
5. Runc -> Language runtime을 실행하고 코드를 동작시킨다.

현재 CSP가 이 절차를 간소화해서 latency를 줄이기 위한 방법이 몇 가지 있음.

• 1번에서 가져온 image를 로컬에서 삭제하지 않고 유지한다.
• 요청이 끝난 function instance를 바로 삭제하는 대신 idle state로 유지 (15min 정도?)
  • 대신 idle state 비용이 발생하므로 최선의 방법은 아님

강연에서는 SnapShot based Approach를 제안함

 

SnapShot Based Approach

• 1부터 10까지의 과정 중 시간을 특히 많이 쓰는 작업은 1번, 5번 ~ 10번.
• 5번 ~ 10번까지의 작업을 하나의 snapshot으로 저장한 뒤 재사용.
  • 스냅샷의 기준은 코드의 변경 여부.
  • 스냅샷 생성 기준은 사용자가 FaaS platform에 코드를 업로드하는 시점.

 

What is Function Snapshot?

• microVM memory + virtual HW states.
• Test run을 실행해서, 함수가 완전히 실행이 끝난 뒤 다음 trigger 요청을 기다리는 상태일 때 Snapshot 정보를 저장한다.

 

SnapShot을 그대로 활용할 때의 이슈

• 민감정보가 남아 있을 수 있음
• 재사용할 수 없는 정보들
  • Function Instance에서 생성된 정보들 - uuid, 외부 서비스나 DB연결을 위한 network connection
  • MicroVM에서 생성된 정보들 - IP주소, timer, hostname 등
• original Function image + Snapshot 저장으로 볼륨이 커져서 생기는 Latency. 로딩타임이 길어짐

 

그렇다면 Snapshot의 저장 시점을 '모든 동작이 끝났을 때' 가 아니라, '함수를 호출하기 직전'으로 변경하면 어떨까?

 

이렇게 되면, 재사용할 수 없는 값은 snapshot에 저장하지 않고 / 재사용할 수 없는 값이 생성되기 직전의 상태까지를 계속 재활용할 수 있게 된다.

• 정확히는 5번과 6번 상태 사이.

 

소스코드를 두 개로 구분해서 처리할 수도 있다.

• Essential Code block : 대부분의 경우에 호출되는 코드
• Non-Essential Code block : 함수 호출에 필요하지 않거나, 특정한 경우에만 호출되는 코드

구분 방법?

• Test Environment에서 여러 번 코드를 테스트하면서
• microVM의 메모리에 올라가는 코드영역을 체크한다.

-> 실행에 필요한 소스코드 영역을 간소화할 수 있음.

• Essential Code block layer를 먼저 다운로드받도록 하고
• Essential layer의 다운로드가 끝나면 바로 function을 실행하도록 만드는 것.
  • function Create지점을 최대한 앞당겨서 빠르게 실행되도록 하려는 의도.
• Non-Essential의 다운로드 프로세스는 creation 프로세스와 Parallel / Background / only if needed.

 

이렇게 하면 처음 제기한 네 가지 문제점을 해결할 수 있다고... 함

AutoScaling

 

기존 방식은 MicroVM을 계속 생성하는 방식인데, 하나의 microVM에 여러 대의 function Container를 생성하는 식으로의 AutoScale하는 방법을 제안.

• 기존 microVM의 리소스를 재사용한다.

테스트

 

테스트 환경

 

• 언어로는 Java / Python / NodeJs 선정
• 각 언어별로 테스트 함수는 세 개 사용

 

시간 절약을 할 수 있었다.

 

essential Code block layer를 따로 저장해서 실행하도록 했을 때 image size를 줄일 수 있었다.