자동 크기 조정 모범 사례

Azure Monitor 자동 스케일링은 Azure Virtual Machine Scale Sets, Azure Cloud Services, Azure App Service의 Web Apps 기능 및 Azure API Management에만 적용됩니다.

자동 크기 조정 개념

• 하나의 리소스에는 하나의 자동 스케일링 설정만 있을 수 있습니다.
• 자동 스케일링 설정에는 하나 이상의 프로필이 있을 수 있으며, 각 프로필에는 하나 이상의 자동 스케일링 규칙이 있을 수 있습니다.
• 자동 크기 조정 설정은 인스턴스 크기를 수평적으로 조정합니다. 즉, 인스턴스를 늘려 규모를 확장하고 인스턴스 수를 줄여 규모를 감축합니다.
• 자동 크기 조정 설정에는 최대, 최소 및 기본 인스턴스 값이 있습니다.
• 자동 크기 조정 작업에서는 항상 규모 확장 또는 규모 감축에 대해 구성된 임계값에 도달했는지 확인하여 크기를 조정할 연관된 메트릭을 읽습니다. Azure Monitor 자동 크기 조정 공통 메트릭에서 자동 크기 조정을 통해 크기를 조정할 수 있는 메트릭 목록을 볼 수 있습니다.
• 모든 임계값은 인스턴스 수준에서 계산됩니다. 예를 들어 "인스턴스 수가 2일 때 평균 CPU가 80% >인 경우 한 인스턴스씩 스케일 아웃합니다." 이는 모든 인스턴스의 평균 CPU가 80%를 초과하는 경우 스케일 아웃을 의미합니다.
• 모든 자동 스케일링 실패는 활동 로그에 기록됩니다. 그런 다음, 자동 스케일링 오류가 있을 때마다 메일, SMS 또는 웹후크를 통해 알림을 받을 수 있도록 활동 로그 경고를 구성할 수 있습니다.
• 마찬가지로, 모든 성공한 스케일링 작업도 활동 로그에 게시됩니다. 다음으로, 성공적인 자동 스케일링 작업이 있을 때마다 메일, SMS 또는 웹후크를 통해 알림을 받을 수 있도록 활동 로그 경고를 구성할 수 있습니다. 또한 크기 조정 설정의 알림 탭을 통해 성공적인 크기 조정 작업에 대한 알림을 받도록 전자 메일 또는 웹후크 알림을 구성할 수도 있습니다.

자동 크기 조정 모범 사례

자동 크기 조정을 사용할 때 다음 모범 사례를 따르세요.

최댓값과 최솟값이 다르고 둘 사이의 간격이 적당한지 확인

최솟값=2, 최댓값=2 및 현재 인스턴스 수가 2인 설정이 있는 경우에는 발생할 수 있는 스케일링 동작이 없습니다. 최대 인스턴스 수와 최소 인스턴스 수 간에 적당한 간격을 유지하세요(두 숫자 모두 포함). 자동 크기 조정은 항상 이러한 한도 사이에서 크기를 조정합니다.

수동 스케일링이 자동 스케일링 최솟값 및 최댓값으로 다시 설정됨

인스턴스 수를 최댓값 위 또는 아래 값으로 수동으로 업데이트하면 자동 크기 조정 엔진이 최솟값(아래인 경우) 또는 최댓값(위인 경우)으로 다시 자동으로 크기를 조정합니다. 예를 들어 3 및 6 사이의 범위를 설정할 수 있습니다. 실행 중인 인스턴스가 하나 있는 경우 자동 크기 조정 엔진은 다음 실행 시 3개 인스턴스로 확장합니다. 마찬가지로, 크기 조정 인스턴스를 8개로 수동 설정하면 다음에 실행되는 자동 크기 조정에서는 그 다음 실행 시 6개 인스턴스로 다시 돌아갑니다. 수동 스케일링은 자동 스케일링 규칙을 재설정하지 않은 경우에도 임시적입니다.

항상 증가 및 감소를 수행하는 규모 확장 및 감축 규칙 조합 사용

조합의 한 부분만 사용하는 경우 자동 스케일링이 이 프로필에 정의된 최대 또는 최소 인스턴스 수에 도달할 때까지 한 방향(스케일 아웃 또는 인)으로만 작업을 수행합니다. 이것은 최적의 상황이 아닙니다. 가용성을 보장하기 위해 사용량이 많은 시간에 이상적으로 리소스를 스케일 아웃할 수 있습니다. 마찬가지로 사용률이 낮은 시간에 리소스를 스케일 인하여 비용 절감을 실현할 수 있습니다.

스케일 인 및 스케일 아웃 규칙을 사용하는 경우 동일한 메트릭을 사용하여 둘 다 제어하는 것이 좋습니다. 그렇지 않으면 스케일 인 및 스케일 아웃 조건이 동시에 충족되어 어느 정도의 플래핑이 발생할 수 있습니다. 예를 들어, 메모리 사용에 대한 스케일 인 규칙이 없으므로 다음 규칙 조합은 권장되지 않습니다.

• CPU가 90% 초과인 경우 1만큼 스케일 아웃
• 메모리가 90% 초과인 경우 1만큼 스케일 아웃
• CPU가 45% 미만인 경우 1만큼 스케일 인

이 예제에서는 메모리 사용량이 90%를 초과하지만 CPU 사용량이 45% 미만인 상황이 있을 수 있습니다. 이 시나리오는 두 조건이 모두 충족되는 한 플래핑을 유발할 수 있습니다.

진단 메트릭에 적절한 통계 선택

진단 메트릭의 경우 스케일링할 메트릭으로 평균, 최소, 최대 및 합계 중에서 선택할 수 있습니다. 가장 일반적인 통계는 평균입니다.

특정 메트릭의 임계값 조정에 대한 고려 사항

Azure 스토리지 또는 Azure Service Bus 큐 길이 메트릭과 같은 특정 메트릭의 경우 임계값은 현재 인스턴스 수당 사용 가능한 평균 메시지 수입니다. 이 메트릭에 대한 임계값을 신중하게 선택해야 합니다.

동작을 보다 잘 이해할 수 있도록 예를 들어 살펴보겠습니다.

• 스토리지 큐 메시지 수가 50개 이상인 경우 인스턴스 수 1개 증가
• 스토리지 큐 메시지 수가 10개 이하인 경우 인스턴스 수 1개 감소

다음과 같은 시퀀스를 고려해 보세요.

1. 2개의 스토리지 큐 인스턴스가 있습니다.
2. 메시지가 계속 들어오고 있으며 스토리지 큐를 검토했을 때 총 개수가 50개입니다. 자동 크기 조정에서 규모 확장 동작을 시작해야 한다고 생각할 수 있습니다. 그러나 인스턴스당 메시지 수는 여전히 50/2 = 25개입니다. 따라서 스케일 아웃은 발생하지 않습니다. 첫 번째 스케일 아웃 작업이 발생하려면 스토리지 큐의 총 메시지 수가 100개여야 합니다.
3. 이번에는 총 메시지 수가 100개에 도달했다고 가정합니다.
4. 세 번째 스토리지 큐 인스턴스는 스케일 아웃 작업으로 인해 추가됩니다. 150/3 = 50이므로 큐의 총 메시지 수가 150개에 도달할 때까지 다음 스케일 아웃 작업이 발생하지 않습니다.
5. 이제 큐의 메시지 수가 작아집니다. 세 개의 인스턴스가 있는 경우, 인스턴스당 메시지 수는 규모 감축 임계값인 30/3 = 10개이므로 첫 번째 규모 감축 동작은 모든 큐의 총 메시지 수가 30개에 도달한 경우에 발생합니다.

하나의 프로필에 여러 규칙이 구성된 경우 크기 조정에 대한 고려 사항

하나의 프로필에 여러 규칙을 설정해야 할 수 있는 경우가 있습니다. 여러 규칙이 설정된 경우 자동 스케일링 엔진은 다음과 같은 자동 스케일링 규칙을 사용합니다.

• 규모 확장의 경우 임의의 규칙이 충족되면 자동 크기 조정이 실행됩니다.
• 스케일 인의 경우 모든 규칙이 충족되어야 자동 스케일링이 실행됩니다.

이를 설명하기 위해 다음 4가지 자동 스케일링 규칙이 있다고 가정합니다.

• CPU가 30% 미만인 경우 1만큼 스케일 인
• 메모리가 50% 미만인 경우 1만큼 스케일 인
• CPU >가 75%이면 1씩 스케일 아웃
• 메모리 >가 75%이면 1씩 스케일 아웃

그런 다음, 다음 작업이 발생합니다.

• CPU가 76%이고 메모리가 50%인 경우 규모가 확장됩니다.
• CPU가 50%이고 메모리가 76%인 경우 규모가 확장됩니다.

반면, CPU가 25%이고 메모리가 51%인 경우 자동 스케일링에서 스케일 인하지 않습니다. 스케일 인하려면 CPU가 29%이고 메모리가 49%여야 합니다.

항상 안전한 기본 인스턴스 수 선택

기본 인스턴스 수는 메트릭을 사용할 수 없을 때 자동 스케일링이 서비스 크기를 이 수로 스케일링하므로 중요합니다. 따라서 워크로드에 안전한 기본 인스턴스 수를 선택합니다.

자동 크기 조정 알림 구성

자동 스케일링은 다음 조건 중 하나가 발생할 경우 활동 로그에 게시됩니다.

• 자동 크기 조정에서 크기 조정 작업이 생성되는 경우.
• 자동 크기 조정 서비스에서 크기 조정 작업을 성공적으로 완료하는 경우.
• 자동 크기 조정 서비스에서 크기 조정 작업에 실패한 경우.
• 자동 스케일링 서비스에서 스케일링 결정을 내리는 데 메트릭을 사용할 수 없습니다.
• 크기 조정 결정을 내리는 데 메트릭을 다시 사용할 수 있게 된(복구) 경우.
• 자동 크기 조정에서 플래핑을 검색하고 크기 조정 시도를 중단하는 경우. 이 경우 Flapping 로그 형식이 표시됩니다. 이 로그 형식이 표시되면 임계값이 너무 좁지 않은지 생각해 보세요.
• 자동 크기 조정이 플래핑을 검색하지만 성공적으로 크기를 조정할 수 있는 경우. 이 경우 FlappingOccurred 로그 형식이 표시됩니다. 이 로그 형식이 표시되면 자동 스케일링 엔진이 스케일링을 시도했지만(예: 인스턴스 4개에서 2개로) 이 변경으로 인해 플래핑이 발생하는 것을 확인했습니다. 대신 자동 스케일링 엔진은 다른 수의 인스턴스(예: 2개 대신 3개 인스턴스 사용)로 스케일링되어 더 이상 플래핑이 발생하지 않으므로 이 인스턴스 수로 스케일링되었습니다.

또한 활동 로그 경고를 사용하여 자동 스케일링 엔진의 상태를 모니터링할 수도 있습니다. 한 예제에서 구독의 모든 자동 스케일링 엔진 작업을 모니터링하기 위한 활동 로그 경고를 만드는 방법을 보여줍니다. 또 다른 예제에서는 구독에서 실패한 모든 자동 스케일링 스케일 인/스케일 아웃 작업을 모니터링하기 위한 활동 로그 경고를 만드는 방법을 보여줍니다.

활동 로그 경고를 사용하는 것 외에도 자동 크기 조정 설정의 알림 탭을 통해 크기 조정 작업에 대한 경고를 받도록 이메일 또는 웹후크 알림을 구성할 수도 있습니다.

TLS 1.2를 사용하여 데이터를 안전하게 전송

Azure Monitor로 전송 중인 데이터를 보호하려면 적어도 TLS(전송 계층 보안) 1.2 이상을 사용하도록 에이전트를 구성하는 것이 좋습니다. 이전 버전의 TLS/SSL(Secure Sockets Layer)이 취약한 것으로 확인되었습니다. 현재 여전히 이전 버전과의 호환성을 허용하기 위해 작동하지만 권장되지는 않습니다. 업계에서는 이러한 오래된 프로토콜에 대한 지원을 중단하기 위해 빠르게 움직이고 있습니다.

PCI 보안 표준 위원회는 이전 버전의 TLS/SSL를 사용하지 않고 좀 더 안전한 보안 프로토콜로 업그레이드하는 최종 기한을 2018년 6월 30일로 정했습니다. Azure에서 레거시 지원을 중단한 후, 에이전트가 TLS 1.2 이상을 통해 통신할 수 없는 경우 Azure Monitor 로그에 데이터를 보낼 수 없게 됩니다.

필요한 경우가 아니면 TLS 1.2만 사용하도록 에이전트를 명시적으로 설정하지 않는 것이 좋습니다. 에이전트가 이후 보안 표준을 자동으로 감지, 협상 및 활용할 수 있도록 허용하는 것이 좋습니다. 그렇지 않으면 새로운 표준의 추가된 보안 기능을 이용하지 못할 수 있고 TLS 1.2가 새 표준으로 대체되었을 때 문제가 발생할 수 있습니다.

다음 단계

• 자동 크기 조정 플래핑
• 구독의 모든 자동 크기 조정 엔진 작업을 모니터링하기 위한 활동 로그 경고 만들기
• 구독에서 실패한 모든 자동 크기 조정 스케일 인/스케일 아웃 작업을 모니터링하기 위한 활동 로그 경고 만들기