AWS Auto Scaling Group (이하 ASG)를 사용하는 이유 중 하나는 들어오는 로드가 증가할 때 유연하게 인스턴스 수(capacity)를 늘려 인스턴스 당 처리량을 적정 수준으로 유지하여 연결된 서비스에 주는 영향을 최소화 하거나, 인스턴스 수에 비해서 로드가 적다면 인스턴스 수를 줄여 낭비되는 리소스를 최소화하기 위해서이다.
이를 위해 ASG에서는 어떤 조건에서 capacity를 조정하도록 하도록 하는 기능을 제공하는 Scaling Policy를 제공한다. 종류로는 Dynamic Scaling policy, Predictive Scaling policy, Scheduled Action policy 등이 있다. 이번 글에서는 이 중에 Predictive Scaling Policy의 작동 원리 추론을 해보고자 한다.
Predictive Scaling Policy는 과거의 CPU 사용량, 네트워크 유입량 등의 로드의 과거 기록을 이용하여 미래에 특정 시점에 적용되어야 할 ASG의 capacity를 기계 학습(Machine Learning)을 통해 예측을 해준다. 가장 중요한 설정값은 Metrics and target utilization이며, 내용을 살펴보면 다음과 같다.
Predictive Scaling에 대해서 AWS 메뉴얼을 보다보니 Load Metric과 Scaling Metric이 각각 어떤 역할을 하는지 헷갈렸으며, 특히 두 가지 종류를 다르게 설정할 수 있는 Custom Metric Pair 에 대해서는 더욱 이해가 안갔었다. 자료를 찾아보았지만 정확히 원리는 설명해주는 곳은 없어 내가 가진 약간의 ML 지식으로 나라면 이렇게 개발했을 거라 추측해 보았다.
우선 과거 사용량을 기준으로 미래의 특정 시점의 사용량을 예측해야 한다는 것쯤은 쉽게 추측할 수 있다. 이 때 사용하는 메트릭이 Load Metric이다. 예를 들어 CPU 전체 사용량을 Load Metric으로 선택한 경우, 과거의 특정 시간, 특정 요일의 CPU 전체 사용량을 학습하여, 미래의 특정 시점의 사용량을 예측하도록 한다. 학습하는 데이터를 간단히 적어보면 (학습 시 윈도우는 10분으로 가정한다.)
요일(x1) | 시간(x2) | CPU 사용량(y) |
---|---|---|
월요일 | 14:00 | 2000 |
월요일 | 14:10 | 2050 |
월요일 | 14:20 | 2100 |
... | ... | ... |
이런 데이터가 충분히 모여서 학습하면 특정 시점의 CPU 사용량 예측을 할 수 있을 것이다.
요일(x1) | 시간(x2) | CPU 사용량(y) |
---|---|---|
월요일 | 15:00 | ? |
이렇게 예측한 Load Metric은 이후에 Scaling Metric 과 함께 capacity를 예측하는데 사용된다.
Load Metric을 통해서 미래의 CPU 전체 사용량까지 마친 시점에서 Scaling Metric은 어떻게 사용할 수 있을까 고민을 해보았다. 다음과 같이 학습 데이터를 준비해 학습한다면 특정 로드에 대한 Target Utilization에 해당하는 capacity 값을 추측할 수 있을 것이다.
Load Metric(x1) | Scaling Metric 값(x2) | capacity(y) |
---|---|---|
2000 | 20 | 4 |
2050 | 21 | 4 |
2100 | 18 | 5 |
... | ... | ... |
이 데이터를 학습을 했다면, 미래의 특정 시점에 Load Metric 데이터와 Target Utilization 값을 통해 capacity 값을 파악할 수 있다. Target Utilization을 40%라 한다면 다음 데이터 입력과 학습된 모델을 통하여 capacity 값을 예측할 수 있을 것이다.
Load Metric(x1) | Scaling Metric 값(x2) | capacity(y) |
---|---|---|
2000 | 40 | ? |
단일 Metric 사용 시, Load Metric, Scaling Metric 설명을 통하여 Custom Metric Pair 가 어떠한 방식으로 작동할 지 예측해 볼 수 있다. Load Metric은 Network In 값을 사용하고, Scaling Metric은 CPU Utilization을 사용한 경우를 살펴보자. Target Utlization 값은 40%이라 가정한다.
단일 Metric 을 사용할 때와 동일하다.
요일(x1) | 시간(x2) | Network In 총량(y) |
---|---|---|
월요일 | 14:00 | 40000 |
월요일 | 14:10 | 41000 |
월요일 | 14:20 | 42000 |
... | ... | ... |
이러한 데이터의 학습을 통해 생성된 모델을 통해 특점 시점의 Network In 총량을 예측할 수 있다.
요일(x1) | 시간(x2) | Network In 총량(y) |
---|---|---|
월요일 | 15:00 | ? |
단일 Metric과는 다르게 Load Metric과 Scaling Metric의 단위가 다르다.
Load Metric(x1) | Scaling Metric 값(x2) | capacity(y) |
---|---|---|
40000 | 20 | 4 |
41000 | 21 | 4 |
42000 | 18 | 5 |
... | ... | ... |
이를 통해 다음 입력과 학습된 모델을 통해 특정 시간의 Target Utilization에 해당하는 capacity 값을 예측할 수 있다.
Load Metric(x1) | Scaling Metric 값(x2) | capacity(y) |
---|---|---|
40000 | 40 | ? |
단일 Metric은 Load Metric과 Scaling Metric이 동일하기 때문에 두 메트릭의 상관 관계가 비교적 Linear하게 유지되어 예측에 문제가 없을 것이다. 그러나 Custom Metric Pair 를 사용하게 된다면 Load Metric과 Scaling Metric의 상관 관계가 명확하지 않은 케이스가 있을 수 있어 주의가 필요하다.
예를 들어 웹 API 서비스를 제공하는 ASG의 경우, API 별로 네트워크 In 은 비교적 비슷한데, CPU 사용량은 매우 상이하다면, 10000이라는 Network In 양이 사용되는 동안 동일 capacity에 대한 CPU 평균 사용량은 어떤 경우는 10%, 어떤 경우는 50%가 되는 경우가 생긴다고 해보자. 이 경우 Custom Metric Pair를 상기 예제처럼 선택한다면, 제대로된 학습을 기대하기 힘들며 예측도 엉망이 될 가능성이 높다.
Predictive Scaling Policy를 알아보면서 아쉬운 점이 있었다. 학습 값으로 Load Metric을 하나밖에 선택할 수 없다는 것이다. 사실 Load Metric으로 제공해주는 모든 종류의 Metric을 학습 시 사용하더라도 모델을 만들기 위한 계산량이나 걸리는 시간은 크게 차이가 없을 것이라 예상되는데, 복수 선택을 할 수 있게 했다면 더 좋았을 것이란 생각이 든다.