Knative 연구하기(Auto Scaling)

반응형

Knative AutoScaling 연구하기

안녕하세요 김민욱입니다.

 

이전 포스팅에서 Serving에 대해서 알아보았습니다. 서버리스 서비스들은 일정 시간 동안 요청이 없으면 Pod가 제거 되고, 요청이 오면 Pod를 생성하게 됩니다. 이러한 기능을 Knative에서는 Auto Scaling이라고 부르며, 이번 포스팅에서는 Auto Scaling을 위한 각각의 컴포넌트들과 순차적인 워크플로우에 대해서 살펴보도록 하겠습니다.

 

Knative Auto Scaling

서버리스 서비스가 Pod로 생성되게 되면, 자동적으로 Queue Proxy가 포함되게 됩니다. 해당 컨테이너는 서비스 컨테이너의 요청을 파악하고, 요청이 없다면 다른 컴포넌트에 이를 알려주게 됩니다. 

 

Queue Proxy는 서비스 컨테이너와 함께 사이드카 형태로 함께 배포되는 컨테이너입니다. 주요한 목적으로는 서비스에 대한 요청을 측정하거나 제한하는 기능을 제공합니다. 예로 Revision에서 Concurrency를 5로 제한하였다면, 서비스에 5개 이상의 요청을 수신하지 못하도록 할 수 있습니다. 더 많은 요청 전송시 대기열에 들어가게됩니다. 

 

Autoscaler는 요청에 따라 Pod의 수를 조절하는 컴포넌트로 크게 PodAutoscaler, Collector, Decider로 구분됩니다.  PodAutoscaler는 요청된 Pod의 수에 따라 Deployment에게 Pod 수 조정을 요청하거나, Scaling to zero 혹은 Scaling from zero 상황을 위해 상태를 변경하기도 합니다.  Collector는  서비스 Pod에 있는 Queue-Proxy로부터 메트릭을 수집합니다. Decider는 Collector가 수집한 메트릭을 기반으로 서비스 배포를 확장하거나 삭제하기 위한 Pod수를 결정합니다. 

 

Activator는 Pod 상태에 따라 외부로 들어오는 요청을 버퍼링하여 Pod가 생성 될 때까지 대기하고, Pod가 요청을 받을 수 있는 상태인지 확인한 뒤 들어온 요청을 전달합니다. 한마디로 Pod의 상태에 따라 외부로 들어오는 요청들을 로드밸런싱하여 요청이 누락되지 않게 합니다. 

 

ServerlessService(SKS)는 Kubernetes Service의 추상화 개념으로 들어오는 요청이 Pod로 직접 가거나, Pod가 없다면 Activator로 전달될 수 있는 일종의 표시라고 생각하면 될 것같습니다 . 이렇게 Scaling 상태에 따라 SKS는 두가지 모드가 있습니다. 

  • Serve 모드일 경우 외부 트래픽이 직접 Pod로 향하게 됩니다.
  • Proxy 모드일 경우 외부 트래픽이 Activator로 향하게 됩니다. 

그림 1. Scaling to Zero Workflow[1]

 

아시다시피, 서버리스 서비스들은 요청이 없을 경우 Pod를 제거하게 됩니다. 이러한 과정들은 그림 1에서 나타나 있습니다. 

  1. Autoscaler의 Metric 컴포넌트가 Queue Proxy를 통해 요청이 있는지 확인(Concurrency)
  2. Metric은 Decider에게 해당 상황을 전달 
  3. Decider는 PA에게 Pod의 수를 0으로 수정하도록 전달
  4. PA는 SKS의 모드를 Activator가 요청을 수신할 수있도록 Proxy 모드로 수정
  5. PA는 Deployment를 통해 Replicaset 0으로 수정 
  6. Deployment는 Pod 삭제 
  7. SKS는 Public Service(e.g. Ingress 등)가 요청을 보낼 엔드포인트를 Activator로 변경 

 

그림 2. Scaling From Zero Workflow[1]

그림 2에서는 반대로 Pod가 0개이고, SKS의 모드가 Proxy인 상황에서의 워크플로우를 나타냅니다. 

  1. Ingress(Public Service)를 통해 요청이 들어옴
  2. 현재 SKS 모드는 Proxy이므로 Ingress가 요청을 전달하는 엔드포인트가 Activator이기 때문에 Activator로 전달
  3. 이때, Activator는 요청을 바로 전달할 수 없기 때문에 Buffer로 저장 중
  4. Activator는 요청 수를 Metric에게 리포팅
  5. Metric은 해당 요청수를 Decider에게 알림
  6. Decider는 PA에게 Pod Scale out을 요청
  7. PA는 Deployment를 통해 Replicaset을 증가시키고 Pod를 생성하도록 함
  8. PA SKS의 모드를 Serve(Pod에게 직접 요청이 가는 것)로 변경 
  9. SKS Private Service는 Deployment를 확인하다가 Endpoint가 생성되면 이를 SKS에게 알려줌
  10. Activator는 Private Service를 Watch하고 있기 때문에 마찬가지로 Endpoint 생성을 확인하고, 정상 생성 확인 후 Buffer를 Pod에게 보낸다. 
  11. SKS Public Service의 엔드포인트를 생성된 Pod로 업데이트하고, 이후 요청은 모두 Pod로 전달된다. 

 

 

결론

저번 글에 이어 Auto Scaling에 대해 포스팅을 작성해보았습니다. Auto scaling은 서버리스의 주요한 기능으로 서비스 요청시에만 생성하고 사용하지 않을 때는 삭제를 가능하게 합니다. 

 

이러한 기능은 리소스 및 비용 절약을 가능하게 하지만, 초기 요청시 Pod 생성 과정으로 인한 Cold Start가 유발됩니다. 따라서 Cold Start 해결을 위해, 컨테이너 생성 절차 혹은 서버리스 플랫폼의 위치에서 연구를 해볼 필요가 있을 것같습니다.

 

읽어주셔서 감사드리며, 오류가 있다면 말씀주시면 수정하겠습니다.

감사합니다.

인용글

[1] Knative Serving Github : https://github.com/knative/serving/blob/main/docs/scaling/SYSTEM.md

업데이트로그

--------------------------------------------------------------------------------------------------------------

해당 글은 스스로 연구한 내용을 통한 주관적인 이해를 바탕으로 작성 되었습니다. 수정 할 부분이 있거나, 다른 의견이 있으시다면 언제든지 말씀해주시면 반영하도록 하겠습니다. 읽어 주셔서 감사합니다. 끝으로 불법으로 복제하는 것은 금합니다.

 

반응형

댓글

Designed by JB FACTORY