반응형
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.
- 이벤트가 들어오면 container가 image를 pull 받아온다
- root 파일시스템을 구축하고, runtime Shim을 실행한다.
- runtime Shim은 CNI network를 세팅하고, microVM를 생성한다.
- microVM의 kernel가 내부적으로 동작할 container를 생성한다.
- 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를 줄일 수 있었다.
반응형