Contents hide

1 자동 스케일링 개념

1.1 임계값 (Threshhold)

2 자동 스케일링 설정하기

2.1 Worst Practices

2.1.1 플래핑(Flapping) 현상이 발생하는 경우

Best Practices

Best Practices란, 특정 분야 및 업무에서 최상의 결과를 달성하기 위해서 검증되고 널리 인정받는 방법이나 절차를 의미한다.

IT업계에서 일하면 아키텍처를 설계할 때 Best Prcatice 즉, 모범 사례를 많이 참고하게 된다. 도입하려고 하는 시스템에 필요한 요소를 Microsoft, Amazon, Goolge 등에서 제공하는 자료에서 참고하여 구축하려는 시스템에 맞게 커스터마이징 하는 것이 훨씬 효율적이고 효과적이기 때문이다.

Tip. 이러한 모범 사례는 지속적으로 개선되고 업데이트되고, 다양한 산업과 활동에서 품질과 성능을 향상시키기 위해 사용된다.

자동 스케일링 개념

자동 스케일링 개념은 인스턴스 수를 수평적(Hrizontally)으로 확장하는 것을 의미한다. 즉, 인스턴스 수를 확장Scale out 하거나, 축소Scale in 한다. 자동 스케일링 설정에는 Max, Minimum 그리고 Default value of instances 인스턴스의 수를 지정할 필요가 있다.

임계값 (Threshhold)

위와 같이 자동 스케일링 작업은 관련 메트릭을 모니터링하여 확장 혹은 축소 작업을 준비하고 있다. 모든 임계값은 인스턴스 레벨에서 계산된다.

이 부분이 중요한데, 만약 관리자가 “평균 CPU 사용률이 80%가 넘으면 인스턴스 1개 추가” 라는 작업을 설정하면, 기본값으로 설정한 수의 인스턴스 전부가 CPU 사용률이 80%가 넘는 경우, 인스턴스가 1개 추가된다.

Tip. 자동 스케일링의 로그는 모두 Azure Acitivity Log에 보존된다.

자동 스케일링 설정하기

이러한 설계를 진행하는 경우, 우선 안 좋은 예시를 확인하는 것이 좋다. Microsoft의 경우 Scale out과Scale in의 조건을 동일하게 설정하지 않는 것을 권장한다고 한다. 그렇다면, 어째서 동일한 임계값을 설정하면 좋지 않은지 이유에 대해서 알아 본다.

Tip.어떤 부분에서 주의를 해야하는지 파악하기 쉽다.

Worst Practices

플래핑(Flapping) 현상이 발생하는 경우

플래핑 현상¹이란, 자동 스케일링이 잘못된 설정값으로 인해 확장과 축소가 빈번하게 반복되는 현상이다.

스레드 메트릭에 대한 자동 스케일링 임계값

Increase instances by one count when Thread Count >= 600
Decrease instances by one count when Thread Count <= 600

Point. 하나의 메트릭에 임계값이 동일하게 설정되어 있다.

인스턴스 수(기본값)가 2이고, 각 인스턴스의 평균(Avg) 스레드 수가 625로 증가한다고 가정한다.
자동 스케일링은 일정 시간동안 메트릭값을 확인하고 인스턴스3를 확장(Scale out)한다.
Tip. 위의 표에서는 최대 5개 까지 확장한다.
각 인스턴스의 평균 스레드가 575로 감소한다고 가정한다.
자동 스케일링은 축소 작업을 실행하기 전 축소 후의 최종 상태 를 계산한다.
575 x 3 (current instance count) = 1,725 / 2 (final number of instances when scaled in) = 862.5 threads.
Tip. 862.5는 확장 임계값보다 크다. 축소 직후에도 다시 확장 작업이 트리거 된다는 것을 의미한다.
자동 스케일링 작업은 위와 같은 루프를 방지하기 위해 축소를 하지 않는다.

위와 같은 경우, 관리자는 각 인스턴스의 평균 스레드 수가575임에도 불구하고, 축소 작업이 동작하지 않아 혼란스러울 수 있다.

Best Practices

CPU 사용률(%) 메트릭에 대한 자동 스케일링 임계값

Increase instances by 1 count when CPU% >= 80
Decrease instances by 1 count when CPU% <= 60

인스턴스 수(기본값)가 2이고, 각 인스턴스의 평균(Avg) CPU 사용률이가 80%으로 증가한다고 가정한다.
자동 스케일링은 일정 시간동안 메트릭값을 확인하고 인스턴스3를 확장(Scale out)한다.
각 인스턴스의 평균 CPU 사용률이 60%로 감소한다고 가정한다.
자동 스케일링은 축소 작업을 실행하기 전 축소 후의 최종 상태 를 계산한다.
60 x 3 (current instance count) = 180 / 2 (final number of instances when scaled in) = 90
Tip. 스케일 아웃의 임계값80 보다 높기 때문에 스케일 인 작업이 트리거 되지 않는다.
각 인스턴스의 평균 CPU 사용률이 50%로 감소한다고 가정한다.
50 x 3 instance = 150 / 2 instances = 75
Tip. 스케일 아웃의 임계값80 보다 낮기 때문에 스케일 인 작업이 트리거 된다.

플래핑 현상을 방지하고 자원과 비용의 효율적인 사용을 위해서는 스케일 아웃과 스케일 인 임계값 사이에 적절한 여유를 두는 것이 중요하다.

여러 규칙 설정하기

자동 스케일링 프로필은 스케일 아웃 및 스케일 인이 트리거 되는 규칙들을 포함하는 설정이다. CPU 사용률(%), 메모리 사용량 등의 메트릭을 기반으로 하는 여러 규칙을 설정할 수 있다.

Point. 스케일 아웃의 경우 하나의 조건을 충족하면 트리거 된다.반면, 스케일 인은 모든 조건을 충족해야 트리거 된다.

아래와 같은 규칙이 설정된 자동 스케일링 프로필이 있다고 가정한다.

If CPU < 30%, scale-in by 1
If Memory < 50%, scale-in by 1
If CPU > 75%, scale out by 1
If Memory > 75%, scale out by 1

If CPU is 76% and Memory is 50%, we scale out.
If CPU is 50% and Memory is 76% we scale out.

활동 로그로 알림 설정하기

Azure Activity log 를 사용하면 자동 스케일링 작업에 대한 알림을 설정할 수 있다. 이를 통해 자동 스케일링 시스템의 상태와 문제를 실시간으로 모니터링하고 필요한 조치를 취할 수 있게 된다.

또한, 알림 탭을 이용하면 이메일 또는 웹 후크²를 이용한 알림 설정이 가능하다.

Tip. 아래와 같은 작업에 대한 알림이 활동 로그에 보존된다.

크기 조정 작업 실행
크기 조정 작업 완료
크기 조정 작업 실패
메트릭 사용 불가 *규칙에 지정한 메트릭을 사용할 수 없는 경우
메트릭 복구

Learning Note

플래핑 현상(Flapping)

플래핑 현상은 자동 스케일링 시스템에서 발생할 수 있는 문제다.

임계값을 적절하게 설정하지 않으면 시스템이 정상적으로 부하의 증가와 감소를 판단하지 못한다.
즉, 사소한 부하 변동에도 민감하게 반응해 버리는 것이다.

이러한 플래핑 현상은 자원과 비용의 낭비뿐만 아니라, 시스템의 안정성에도 부정적인 영향을 미친다.
↩︎
웹 후크(Web hook)

웹 애플리케이션 간에 정보를 자동으로 전달하는 방법이다.

일반적으로 다른 시스템으로 실시간 데이터 전송을 위해 사용된다. 특정 이벤트가 발생했을 때 사전에 설정된 URL로 HTTP요청을 자동으로 보내는 메커니즘이다.

예를 들어, 웹 앱이나 서비스에서 특정 조건이 충족되거나 이벤트가 발생했을 때, 웹 후크는 이 정보를 즉시 다른 서비스나 앱으로 전송한다. 이를 통해 사용자는 실시간으로 주용한 업데이트를 받거나, 서비스 간에 데이터를 자동으로 동기화하는 등 다양한 자동화 작업을 구현할 수 있다.

웹 후크는 다양한 온라인 서비스(ex: GitHub, Slack, Terello) 와 같은 협업 도구에서 많이 사용되고 있으며, 알림 및 데이터 동기화 등 복잡한 통합 작업에 매우 유용하게 사용된다.
↩︎