Reactive 방식으로 특정 주기마다 metrics server로부터 자원 사용량을 확인하여 미리 지정해둔 threshold를 넘어가면 스케일링이 됨
- 한계점: HPA가 메트릭 서버로부터 폴링하는 주기, 메트릭 서버가 메트릭을 수집하는 주기로 인해 실제 스케일링해야할 값에 대한 대기 시간이 발생하여 적시에 스케일링할 수 없음
특정 구간의 사용량을 예측하여 미리 스케일링함으로써 HPA에서 발생하는 대기 시간 문제를 해결함
- 한계점: 단순한 통계 모델(Linear Regression, Holt-Winters Smoothing)을 사용하여 높은 예측 정확도를 기대하기 어려움
Collect | Update | Predict |
---|---|---|
애플리케이션 메트릭을 수집하여 중앙 집중식 시계열 데이터베이스로 보내 수집된 메트릭을 활용하고 분석 단계에서 사용 | Collector에서 특정 구간의 데이터를 쿼리하여 학습시킨 모델에 적용. 예측된 다음 시점의 워크로드에 대하여 설정한 알고리즘을 바탕으로 다음 시점의 파드 수 예측 | Kubernetes 엔진(kube-apiserver)은 예측 단계로부터 명령을 받아 Pod의 복제본 수를 변경 |
Autoscaling하려는 deployment로부터 생성된 파드들의 CPU 사용량을 합산해 해당 서비스의 총 CPU 사용량을 수집
사용자가 정해둔 CPU limit을 기준으로 딥러닝 모델은 특정 시점의 Pod 개수를 예측
Kubernetes 엔진(kube-apiserver)은 Automatic Scaler의 명령을 통해 적절한 Pod 복제본 수 변경
표준 LSTM과 달리 입력이 양방향으로 흐르고, 양방향의 정보를 활용 시퀀스의 양방향에서 순차적 종속성을 모델링하는 도구 정보 흐름의 방향을 반대로 하는 LSTM 레이어를 추가
최적의 파라미터 및 손실함수 결정
학습된 모델, Kubernetes에서 제공하는 기본 Autoscaler HPA, 오픈소스 Predictice HPA, 총 세 가지 모델에 테스트 트래픽 데이터셋의 일부로 성능 비교 예측 정확도를 바탕으로 개발한 모델의 스케일링 효과를 검증