[논문 리뷰] Understanding Open Source Serverless Platforms: Design Considerations and Performance

Junfeng Li, Sameer G. Kulkarni외 2명|arXiv (Cornell University)|2019. 11. 18.

Peer-to-Peer Network Technologies참고 문헌 7인용 수 19

한 줄 요약

이 논문은 네 가지 컨테이너 기반 오픈소스 서버리스 플랫폼—Knative, Kubeless, Nuclio, OpenFaaS—를 평가하여 성능과 오토스케일링에 결정적인 영향을 미치는 아키텍처 설계 선택 사항을 규명한다. 연구 결과, RPS 기반 및 동시성 기반 오토스케일링만으로는 부족하며, OpenFaaS와 Knative의 트래픽 분배 결함으로 인해 저부하 환경에서 심각한 처리량 저하가 발생한다. 특히 Knative는 잘못된 스케일링 행동으로 인해 1500 RPS에서 200 RPS로 떨어진다.

ABSTRACT

Serverless computing is increasingly popular because of the promise of lower cost and the convenience it provides to users who do not need to focus on server management. This has resulted in the availability of a number of proprietary and open-source serverless solutions. We seek to understand how the performance of serverless computing depends on a number of design issues using several popular open-source serverless platforms. We identify the idiosyncrasies affecting performance (throughput and latency) for different open-source serverless platforms. Further, we observe that just having either resource-based (CPU and memory) or workload-based (request per second (RPS) or concurrent requests) auto-scaling is inadequate to address the needs of the serverless platforms.

연구 동기 및 목표

• 오픈소스 서버리스 플랫폼의 아키텍처 설계 결정이 성능과 오토스케일링 행동에 미치는 영향을 이해하기 위해.
• 다양한 플랫폼 간 요청 라우팅, 함수 파드 스케일링, 자원 활용도에서의 성능 저하 요인을 규명하기 위해.
• 실세계 워크로드에서 RPS 기반 및 동시성 기반 오토스케일링 메커니즘의 한계를 평가하기 위해.
• 게이트웨이, 워치독, 큐 프oxy 등의 플랫폼 전용 구성 요소가 지연과 처리량에 미치는 영향을 조사하기 위해.
• Kubernetes 기반 서버리스 플랫폼의 설계 및 구성 향상을 위한 실질적인 통찰을 제공하기 위해.

제안 방법

• 제어된 워크로드를 사용하여 컨테이너 기반 Kubernetes 클러스터에서 네 가지 오픈소스 서버리스 플랫폼—Knative, Kubeless, Nuclio, OpenFaaS—를 평가하였다.
• 정적 및 버스트 워크로드 하에서 처리량(RPS), 지연, 오토스케일링 행동에 중점을 두고 성능을 측정하였다.
• CPU 활용도를 기반으로 Kubernetes 수평 파드 오토스케일러(HPA)를 구성하여 플랫폼 간 자원 기반 오토스케일링을 평가하였다.
• API 게이트웨이와 인그레스 컨트롤러의 역할을 분석하여 OpenFaaS와 Knative에서의 잘못된 라우팅 문제를 규명하였다.
• 예를 들어 OpenFaaS의 연결 재설정 기능을 비활성화하여 성능 저하 원인을 격리하기 위해 아블레이션 연구를 수행하였다.
• 함수 파드의 CPU 및 메모리 활용도를 측정하여 스케일링 효율성과 자원 오버헤드를 평가하였다.

실험 결과

연구 질문

• RQ1 게이트웨이, 컨트롤러, 함수 런타임 구성 요소의 아키텍처적 차이가 서버리스 플랫폼의 기본 성능과 지연에 미치는 영향는 어떠한가?
• RQ2 RPS 기반 및 동시성 기반 오토스케일링 메커니즘이 독립적으로 워크로드 요구사항을 충족하지 못할 정도로 실패할 수 있는 정도는 어느 정도이며, 그로 인한 성능 결과는 무엇인가?
• RQ3 OpenFaaS는 HPA 설정이 되어 있음에도 불구하고 저연결 수준 워크로드에서 효과적으로 스케일링되지 않는 이유는 무엇이며, 장기 연결 기반 라우팅은 어떤 역할을 하는가?
• RQ4 함수 런타임 선택(예: Kubeless의 요청당 프로세스 분리)이 CPU 활용도, 요청 손실률, 오토스케일링 반응성에 미치는 영향는 어떠한가?
• RQ5 큐 프록시 및 워치독과 같은 플랫폼 전용 구성 요소가 CPU 오버헤드와 오토스케일링 속도에 미치는 영향는 무엇인가?

주요 결과

• Knative는 저부하 상황(9개 동시 요청)에서 오토스케일링을 수행하지 못하며, 유일한 함수 파드를 유지하면서 처리량을 1500 RPS에서 200 RPS로 감소시킨다.
• OpenFaaS는 잘못된 트래픽 분배로 인해 오토스케일링 하에서도 처리량 향상이 떨어지며, 장기 연결이 첫 번째 함수 파드로 모든 트래픽을 라우팅함으로써 다른 파드는 비어 있는 상태로 남아 있다.
• Kubernetes HPA를 통한 자원 기반 오토스케일링은 플랫폼에 따라 다르게 작동한다: Nuclio는 가장 빠르게 스케일링(인스턴스 수를 두 배로 늘리는데 40초 소요), 반면 Kubeless는 요청당 프로세스 분리 모델로 인해 고지연과 요청 손실로 인해 스케일링이 열악하다.
• 오토스케일링이 켜져 있음에도 불구하고 메모리 사용량은 크게 증가하지만 CPU 활용도는 안정적으로 유지되어 일부 플랫폼에서 자원 활용도가 비효율적임을 시사한다.
• API 게이트웨이와 함수 파드 간의 상호작용은 주요 성능 저하 요인이며, 잘못된 라우팅으로 인해 스케일링된 인스턴스가 제대로 활용되지 않는다.
• RPS 기반 또는 동시성 기반 오토스케일링에만 의존하는 것은 부족하며, 과다 또는 부족 제공을 방지하기 위해 하이브리드 또는 워크로드 인식 기반 스케일링 정책이 필요하다.