AWS ASG Predictive Scaling 작동 원리 파헤치기: Load Metric, Scaling Metric의 이해

Yunhong Min·2021년 10월 13일
0

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이며, 내용을 살펴보면 다음과 같다.

  • Metric: 메트릭은 크게 두가지로 나누어진다. 첫번째 메트릭은 Load Metric으로 전체 사용량 추정에 사용하는 메트릭이다. 두번째 메트릭은 Scaling Metric으로 capcity 추측을 위해 사용하는 인스턴스당 사용량의 평균 메트릭이며, Target Utilization 값도 이 메트릭 기준으로 정한다.
    선택할 수 있는 메트릭은 다음과 같으며, Load Metric과 Scaling Metric을 다르게 선택하는 Custom metric pair 옵션도 제공한다.
    • CPU Utilization: Load Metric에서는 전체 CPU 사용량, Scaling 메트릭에서는 인스턴스당 CPU 사용량의 평균
    • Network In (bytes): Load Metric에서는 전체 네트워크 유입량, Scaling 메트릭에서는 인스턴스당 메트릭 유입량의 평균
    • Network Out (bytes): Load Metric에서는 전체 네트워크 송출량, Scaling 메트릭에서는 인스턴스당 메트릭 송출량의 평균
    • Application Load Balancer request count: ALB에 연결된 경우만 사용 가능. Load Metric에서는 전체 request count, Scaling 메트릭에서는 인스턴스 당 request count의 평균
  • Target Utilization: Scaling Metric의 유닛을 사용하며, 이 수치를 유지하도록 capacity 값이 예측된다. e.g. CPU Utilization의 경우 40%

Predictive Scaling에 대해서 AWS 메뉴얼을 보다보니 Load Metric과 Scaling Metric이 각각 어떤 역할을 하는지 헷갈렸으며, 특히 두 가지 종류를 다르게 설정할 수 있는 Custom Metric Pair 에 대해서는 더욱 이해가 안갔었다. 자료를 찾아보았지만 정확히 원리는 설명해주는 곳은 없어 내가 가진 약간의 ML 지식으로 나라면 이렇게 개발했을 거라 추측해 보았다.

단일 Metric 사용 시

Load Metric의 사용

우선 과거 사용량을 기준으로 미래의 특정 시점의 사용량을 예측해야 한다는 것쯤은 쉽게 추측할 수 있다. 이 때 사용하는 메트릭이 Load Metric이다. 예를 들어 CPU 전체 사용량을 Load Metric으로 선택한 경우, 과거의 특정 시간, 특정 요일의 CPU 전체 사용량을 학습하여, 미래의 특정 시점의 사용량을 예측하도록 한다. 학습하는 데이터를 간단히 적어보면 (학습 시 윈도우는 10분으로 가정한다.)

요일(x1)시간(x2)CPU 사용량(y)
월요일14:002000
월요일14:102050
월요일14:202100
.........

이런 데이터가 충분히 모여서 학습하면 특정 시점의 CPU 사용량 예측을 할 수 있을 것이다.

요일(x1)시간(x2)CPU 사용량(y)
월요일15:00?

이렇게 예측한 Load Metric은 이후에 Scaling Metric 과 함께 capacity를 예측하는데 사용된다.

Scaling Metric의 사용

Load Metric을 통해서 미래의 CPU 전체 사용량까지 마친 시점에서 Scaling Metric은 어떻게 사용할 수 있을까 고민을 해보았다. 다음과 같이 학습 데이터를 준비해 학습한다면 특정 로드에 대한 Target Utilization에 해당하는 capacity 값을 추측할 수 있을 것이다.

Load Metric(x1)Scaling Metric 값(x2)capacity(y)
2000204
2050214
2100185
.........

이 데이터를 학습을 했다면, 미래의 특정 시점에 Load Metric 데이터와 Target Utilization 값을 통해 capacity 값을 파악할 수 있다. Target Utilization을 40%라 한다면 다음 데이터 입력과 학습된 모델을 통하여 capacity 값을 예측할 수 있을 것이다.

Load Metric(x1)Scaling Metric 값(x2)capacity(y)
200040?

Custom Metric Pair 사용 시

단일 Metric 사용 시, Load Metric, Scaling Metric 설명을 통하여 Custom Metric Pair 가 어떠한 방식으로 작동할 지 예측해 볼 수 있다. Load Metric은 Network In 값을 사용하고, Scaling Metric은 CPU Utilization을 사용한 경우를 살펴보자. Target Utlization 값은 40%이라 가정한다.

Load Metric의 사용

단일 Metric 을 사용할 때와 동일하다.

요일(x1)시간(x2)Network In 총량(y)
월요일14:0040000
월요일14:1041000
월요일14:2042000
.........

이러한 데이터의 학습을 통해 생성된 모델을 통해 특점 시점의 Network In 총량을 예측할 수 있다.

요일(x1)시간(x2)Network In 총량(y)
월요일15:00?

Scaling Metric의 사용

단일 Metric과는 다르게 Load Metric과 Scaling Metric의 단위가 다르다.

Load Metric(x1)Scaling Metric 값(x2)capacity(y)
40000204
41000214
42000185
.........

이를 통해 다음 입력과 학습된 모델을 통해 특정 시간의 Target Utilization에 해당하는 capacity 값을 예측할 수 있다.

Load Metric(x1)Scaling Metric 값(x2)capacity(y)
4000040?

주의할 점

단일 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을 학습 시 사용하더라도 모델을 만들기 위한 계산량이나 걸리는 시간은 크게 차이가 없을 것이라 예상되는데, 복수 선택을 할 수 있게 했다면 더 좋았을 것이란 생각이 든다.

profile
좋아서 시작한 개발 지금은...

0개의 댓글