다음을 통해 공유

자동 조정

자동 크기 조정은 성능 요구 사항에 맞게 리소스를 동적으로 할당하는 프로세스입니다. 작업 용량이 증가하면 원하는 성능 수준을 유지하고 SLA(서비스 수준 계약)를 충족하기 위해 애플리케이션에 추가 리소스가 필요할 수 있습니다. 수요가 느슨해지고 추가 리소스가 더 이상 필요하지 않으므로 비용을 최소화하기 위해 할당을 해제할 수 있습니다.

자동 크기 조정은 관리 부담을 완화하면서 클라우드에 호스트된 환경의 탄력성을 활용합니다. 이렇게 하면 운영자가 시스템 성능을 지속적으로 모니터링하고 리소스 추가 또는 제거를 결정할 필요가 줄어듭니다.

애플리케이션은 다음 두 가지 주요 방법으로 확장될 수 있습니다.

  • 수직적 크기 조정(스케일 업 및 다운이라고도 함)은 리소스의 용량을 변경하는 것을 의미합니다. 예를 들어 애플리케이션을 더 큰 가상 머신 크기로 이동할 수 있습니다. 수직 크기 조정을 수행하려면 시스템을 다시 배포하는 동안 일시적으로 사용할 수 없게 해야 하는 경우가 많습니다. 따라서 수직 크기 조정을 자동화하는 것이 덜 일반적입니다.

  • 확장 및 축소라고도 하는 수평적 크기 조정은 리소스 인스턴스를 추가하거나 제거하는 것을 의미합니다. 애플리케이션은 새 리소스가 프로비전되는 동안 중단 없이 계속 실행됩니다. 프로비저닝 프로세스가 완료되면 솔루션은 이러한 추가 리소스에 배포됩니다. 수요가 감소하면 추가 리소스를 완전히 종료하고 할당을 취소할 수 있습니다.

Microsoft Azure를 비롯한 많은 클라우드 기반 시스템은 자동 수평 크기 조정을 지원합니다. 이 문서의 나머지 부분에는 수평 크기 조정에 중점을 둡니다.

비고

자동 크기 조정은 주로 컴퓨팅 리소스에 적용됩니다. 데이터베이스 또는 메시지 큐의 크기를 수평적으로 조정할 수 있지만 이 프로세스에는 일반적으로 자동화되지 않은 데이터 분할이 포함됩니다.

자동 크기 조정 구성 요소

자동 크기 조정 전략에는 일반적으로 다음 구성 요소가 포함됩니다.

  • 애플리케이션, 서비스 및 인프라 수준의 계측 및 모니터링 시스템입니다. 이러한 시스템은 응답 시간, 큐 길이, CPU 사용률 및 메모리 사용량과 같은 주요 메트릭을 캡처합니다.

  • 의사 결정 논리는 미리 정의된 임계값 또는 일정에 대해 이러한 라이브 사용 메트릭을 평가하고 크기 조정 여부를 결정합니다.

  • 구성 요소 및 메커니즘은 크기 조정 작업을 수행합니다. 이상적으로 이러한 구성 요소 및 메커니즘은 워크로드 코드 자체에서 분리되고 외부 프로세스로 관리되어야 합니다. 유휴 상태이거나 과부하가 걸리는 코드는 자체 크기 조정을 담당해서는 안 됩니다.

  • 자동 크기 조정 전략에 대한 테스트, 모니터링 및 튜닝 기능을 사용하여 예상대로 작동하는지 확인합니다.

Azure는 일반적인 시나리오를 해결하는 기본 제공 자동 크기 조정 메커니즘을 제공합니다. 특정 서비스 또는 기술에 기본 제공 자동 크기 조정 기능이 없거나 기능을 초과하는 특정 자동 크기 조정 요구 사항이 있는 경우 사용자 지정 구현을 고려합니다. 사용자 지정 구현은 운영 및 시스템 메트릭을 수집하고, 메트릭을 분석하고, 그에 따라 리소스의 크기를 조정합니다.

Azure 솔루션에 대한 자동 크기 조정 구성

Azure는 대부분의 컴퓨팅 옵션에 대한 기본 제공 자동 크기 조정을 제공합니다.

이러한 컴퓨팅 옵션은 모두 Azure Monitor 자동 크기 조정 기능을 사용하여 일반적인 자동 크기 조정 기능 집합을 제공합니다.

  • Azure Functions는 자동 크기 조정 규칙을 구성할 필요가 없으므로 이전 컴퓨팅 옵션과 다릅니다. 대신 Azure Functions는 코드가 실행되면 컴퓨팅 능력을 자동으로 할당합니다. Azure Functions는 부하를 처리하기 위해 필요에 따라 확장됩니다. 자세한 내용은 Azure Functions에 대한 올바른 호스팅 계획 선택을 참조하세요.

사용자 지정 자동 크기 조정 솔루션이 유용할 수 있습니다. 예를 들어 사용자 지정 코드와 함께 Azure Diagnostics 및 애플리케이션 기반 메트릭을 사용하여 애플리케이션 메트릭을 모니터링하고 내보낼 수 있습니다. 그런 다음 이러한 메트릭을 기반으로 사용자 지정 규칙을 정의하고 Azure Resource Manager REST API를 사용하여 자동 크기 조정을 트리거할 수 있습니다. 그러나 사용자 지정 솔루션은 구현이 간단하지 않으며 이전 방법 중 어느 것도 요구 사항을 충족할 수 없는 경우에만 고려해야 합니다.

요구 사항을 충족하는 경우 플랫폼의 기본 제공 자동 크기 조정 기능을 사용합니다. 그렇지 않은 경우 더 복잡한 크기 조정 기능이 필요한지 신중하게 고려합니다. 다른 요구 사항의 예로는 제어의 세분성, 크기 조정을 위한 트리거 이벤트를 검색하는 다양한 방법, 구독 간에 크기 조정 및 다른 유형의 리소스 크기 조정이 포함될 수 있습니다.

Azure Monitor 자동 크기 조정 기능 사용

Azure Monitor 자동 크기 조정 기능은 가상 머신 확장 집합, App Service 및 Azure Cloud Services에 대한 일반적인 자동 크기 조정 기능 집합을 제공합니다. 크기 조정은 일정에 따라 수행하거나 CPU 또는 메모리 사용량과 같은 런타임 메트릭에 따라 수행할 수 있습니다.

다음 예제를 고려하세요.

  • 평일에는 인스턴스를 10개로 확장하고 토요일과 일요일에는 4개의 인스턴스로 확장합니다.

  • 평균 CPU 사용량이%70개를 초과하는 경우 한 인스턴스씩 스케일 아웃하고 CPU 사용량이%50개 미만으로 떨어지면 한 인스턴스씩 스케일 인합니다.

  • 큐의 메시지 수가 특정 임계값을 초과하는 경우 인스턴스를 한 개씩 확장합니다.

부하가 증가할 때 리소스를 확장하여 가용성을 보장합니다. 사용량이 적은 시간에 비용을 최적화할 수 있도록 규모를 축소합니다. 항상 스케일 아웃 및 스케일 인 규칙을 조합하여 사용합니다. 그렇지 않으면 자동 크기 조정은 프로필에 설정된 임계값(최대 또는 최소 인스턴스 수)에 도달할 때까지 한 방향으로만 수행됩니다.

워크로드에 안전한 기본 인스턴스 수를 선택합니다. 최대 또는 최소 인스턴스 수가 설정되지 않은 경우 리소스는 해당 값을 기준으로 확장됩니다.

기본 제공 메트릭 목록은 Azure Monitor 자동 크기 조정 일반 메트릭을 참조하세요. Application Insights를 사용하여 사용자 지정 메트릭을 구현할 수도 있습니다.

PowerShell, Azure CLI, Azure Resource Manager 템플릿 또는 Azure Portal을 사용하여 자동 크기 조정을 구성할 수 있습니다. 자세한 제어를 위해 Resource Manager REST API를 사용합니다. Azure 모니터링 관리 라이브러리 및 Microsoft Insights 라이브러리(미리 보기)는 다양한 리소스에서 메트릭을 수집하고 REST API를 사용하여 자동 크기 조정을 수행할 수 있는 SDK입니다. Resource Manager 지원을 사용할 수 없거나 Azure Cloud Services를 사용하는 리소스의 경우 서비스 관리 REST API를 자동 크기 조정에 사용할 수 있습니다. 다른 모든 경우에는 Resource Manager를 사용합니다.

자동 크기 조정을 사용하는 경우 다음 사항을 고려합니다.

  • 예약된 자동 크기 조정을 사용할 만큼 애플리케이션의 부하를 정확하게 예측할 수 있는지, 예상 최대 수요에 맞게 인스턴스를 추가 및 제거할 수 있는지 여부를 고려합니다. 불가능한 경우 런타임 메트릭에 따라 반응형 자동 크기 조정을 사용하여 예측할 수 없는 수요 변경을 처리합니다. 일반적으로 이러한 접근 방식을 결합할 수 있습니다.

    예를 들어 애플리케이션이 가장 바쁜 시간을 일정에 따라 리소스를 추가하는 전략을 만듭니다. 추가 리소스는 필요한 경우에 용량이 확보될 수 있도록 도와주며, 새로운 인스턴스를 시작하는 데 지체가 없도록 합니다. 예약된 각 규칙에 대해 해당 기간 동안 사후 자동 크기 조정을 허용하는 메트릭을 정의하여 애플리케이션이 지속적이면서도 예측할 수 없는 수요 최대치를 처리할 수 있도록 합니다.

  • 특히 애플리케이션이 처음 배포될 때 메트릭과 용량 요구 사항 간의 관계를 이해하기가 어려운 경우가 많습니다. 처음에 약간의 추가 용량을 구성한 다음 자동 크기 조정 규칙을 모니터링하고 조정하여 용량을 실제 부하에 더 가깝게 만듭니다.

  • 자동 크기 조정 규칙을 구성한 다음 시간이 지남에 따라 애플리케이션의 성능을 모니터링합니다. 이 모니터링의 결과를 사용하여 필요한 경우 시스템 크기 조정 방식을 조정합니다. 그러나 자동 크기 조정은 즉각적인 프로세스가 아닙니다. 지정된 임계값을 초과하거나 아래로 떨어지는 평균 CPU 사용률과 같은 메트릭에 대응하는 데 시간이 걸립니다.

  • 측정된 트리거 특성을 기반으로 탐지 메커니즘을 사용하는 자동 크기 조정 규칙은 즉각적인 값이 아닌 시간 경과에 따라 집계된 값을 사용하여 자동 크기 조정 작업을 트리거합니다. 트리거 특성에는 CPU 사용량 또는 큐 길이가 포함됩니다. 기본적으로 집계는 값의 평균입니다. 이 방법은 시스템이 너무 빨리 반응하거나 빠른 진동을 유발하지 않도록 방지합니다. 또한 자동으로 시작된 새 인스턴스가 실행 모드로 전환되는 시간을 허용합니다. 새 인스턴스가 시작되는 동안에는 다른 자동 크기 조정 작업이 발생할 수 없습니다. Azure Cloud Services 및 Azure Virtual Machines의 경우 집계의 기본 기간은 45분입니다. 따라서 수요 급증에 대응하여 메트릭이 자동 크기 조정을 트리거하는 데 이 기간까지 걸릴 수 있습니다. SDK를 사용하여 집계 기간을 변경할 수 있지만 25분 미만인 경우 예측할 수 없는 결과가 발생할 수 있습니다. App Service의 Web Apps 기능의 경우 평균 기간이 짧아서 평균 트리거 측정값을 변경한 후 약 5분 후에 새 인스턴스를 사용할 수 있습니다.

  • 스케일 인 및 스케일 아웃 작업이 지속적으로 앞뒤로 이동하는 경우 플래핑 하지 않습니다. 두 개의 인스턴스가 있다고 가정해 보겠습니다. 상한은 80% CPU이며 하한은 60%. 부하가 85%경우 다른 인스턴스가 추가됩니다. 잠시 후 부하가 60%로 감소합니다. 자동 크기 조정 서비스가 인스턴스 수를 줄이기 전에, 인스턴스가 제거될 경우 총 부하(인스턴스 3개)의 분포를 90%로 계산합니다. 즉시 다시 확장해야 합니다. 따라서 크기 조정을 건너뛰고 예상 크기 조정 결과가 표시되지 않을 수 있습니다.

    스케일 아웃과 스케일 인 임계값 간에 적절한 여백을 선택하여 플래핑 상황을 제어할 수 있습니다.

  • 수동 크기 조정은 자동 크기 조정에 사용되는 최대 및 최소 인스턴스 수에 따라 다시 설정됩니다. 인스턴스 수를 최대값보다 높거나 낮은 값으로 수동으로 업데이트하면 자동 크기 조정 엔진이 자동으로 최소값(낮은 경우) 또는 최대값(높은 경우)으로 다시 확장됩니다. 예를 들어 3에서 6 사이의 범위를 설정합니다. 실행 중인 인스턴스가 하나 있는 경우 자동 크기 조정 엔진은 다음 실행에서 세 개의 인스턴스로 확장됩니다. 마찬가지로 크기를 수동으로 8개의 인스턴스로 설정하는 경우 다음 실행에서 자동 크기 조정은 다음 실행 시 6개의 인스턴스로 다시 크기 조정합니다. 자동 크기 조정 규칙도 다시 설정하지 않는 한 수동 크기 조정은 일시적입니다.

  • 자동 크기 조정 엔진은 한 번에 하나의 프로필만 처리합니다. 조건이 충족되지 않으면 다음 프로필을 확인합니다. 해당 프로필이 마지막으로 확인되므로 키 메트릭을 기본 프로필에서 제외합니다. 프로필 내에서 여러 규칙을 가질 수 있습니다. 스케일 아웃할 때 규칙이 충족되면 자동 크기 조정이 실행됩니다. 규모 축소 시 자동 스케일링을 수행하려면 모든 규칙이 충족되어야 합니다.

    Azure Monitor의 크기 조정 방법에 대한 자세한 내용은 자동 크기 조정에 대한 모범 사례를 참조하세요.

  • 포털이 아닌 SDK를 사용하여 자동 크기 조정을 구성하는 경우 규칙이 활성화되는 동안 보다 자세한 일정을 지정할 수 있습니다. 자체 메트릭을 만들고 자동 크기 조정 규칙에서 기존 메트릭을 사용하거나 사용하지 않고 사용할 수도 있습니다. 예를 들어 초당 요청 수 또는 평균 메모리 가용성과 같은 대체 카운터를 사용할 수 있습니다. 또는 사용자 지정 카운터를 사용하여 특정 비즈니스 프로세스를 측정할 수 있습니다.

  • Service Fabric을 자동 크기 조정하는 경우 클러스터의 노드 형식은 백 엔드의 가상 머신 확장 집합으로 만들어지므로 각 노드 유형에 대한 자동 크기 조정 규칙을 설정해야 합니다. 자동 크기 조정을 설정하기 전에 가져야 하는 노드 수를 고려합니다. 안정성 수준은 주 노드 유형에 대해 가져야 하는 최소 노드 수를 구동합니다. 자세한 내용은 자동 크기 조정 규칙을 사용하여 Service Fabric 클러스터 크기 조정 또는 축소를 참조하세요.

  • 포털을 사용하여 Azure SQL Database 인스턴스 및 큐와 같은 리소스를 클라우드 서비스 인스턴스에 연결할 수 있습니다. 이 방법을 사용하면 연결된 각 리소스에 대한 별도의 수동 및 자동 크기 조정 구성 옵션에 더 쉽게 액세스할 수 있습니다. 자세한 내용은 Azure Cloud Services 관리를 참조하세요.

  • 여러 정책 및 규칙을 구성할 때 서로 충돌할 수 있습니다. 자동 크기 조정은 다음 충돌 해결 규칙을 사용하여 항상 충분한 수의 인스턴스가 실행되도록 합니다.

    • 스케일 아웃 작업은 항상 스케일 인 작업보다 우선합니다.

    • 스케일 아웃 작업이 충돌하는 경우 인스턴스 수에서 가장 큰 증가를 시작하는 규칙이 우선합니다.

    • 규모 감축 작업이 충돌하는 경우 인스턴스 수에서 가장 작은 감소를 시작하는 규칙이 우선합니다.

  • App Service Environment에서 모든 작업자 풀 또는 프런트 엔드 메트릭을 사용하여 자동 크기 조정 규칙을 정의할 수 있습니다. 자세한 내용은 App Service Environment 개요를 참조하세요.

애플리케이션 디자인 고려 사항

자동 크기 조정은 인스턴트 솔루션이 아닙니다. 단순히 시스템에 리소스를 추가하거나 프로세스의 인스턴스를 더 많이 실행한다고 해서 시스템의 성능이 향상되는 것은 아닙니다. 자동 크기 조정 전략을 디자인할 때 다음 사항을 고려하십시오.

  • 시스템을 수평적으로 확장할 수 있도록 설계해야 합니다. 인스턴스 선호도를 가정하지 않습니다. 코드가 항상 프로세스의 특정 인스턴스에서 실행되도록 요구하는 솔루션을 디자인하지 마세요. 클라우드 서비스 또는 웹 사이트를 수평으로 스케일링할 때 동일한 원본의 일련의 요청이 항상 동일한 인스턴스로 라우팅된다고 가정하지 마세요. 같은 이유로 애플리케이션에서 일련의 요청을 항상 동일한 서비스 인스턴스로 라우팅할 필요가 없도록 서비스를 상태 비정상으로 디자인합니다. 큐에서 메시지를 읽고 처리하는 서비스를 디자인할 때는 특정 메시지를 처리하는 서비스 인스턴스를 가정하지 마세요. 자동 크기 조정은 큐 길이가 증가함에 따라 서비스의 더 많은 인스턴스를 시작할 수 있습니다. 경쟁 소비자 패턴은 이 시나리오를 처리하는 방법을 설명합니다.

  • 솔루션이 장기 실행 작업을 구현하는 경우 스케일 아웃 및 스케일 인을 모두 지원하도록 이 작업을 디자인합니다. 적절한 디자인이 없으면 이러한 작업으로 인해 시스템이 스케일 인될 때 프로세스 인스턴스가 완전히 종료되지 않도록 방지할 수 있습니다. 또는 프로세스가 강제로 종료되면 데이터가 손실될 수 있습니다. 이상적으로는 장기 실행 작업을 리팩터링하고 수행하는 처리를 더 작은 불연속 청크로 분할하는 것이 좋습니다. 예제는 파이프 및 필터 패턴을 참조하세요.

  • 또는 정기적으로 작업에 대한 상태 정보를 기록하는 검사점 메커니즘을 구현할 수 있습니다. 작업을 실행하는 프로세스의 모든 인스턴스가 액세스할 수 있는 지속성 스토리지에 이 상태 정보를 저장합니다. 따라서 프로세스가 종료되면 다른 인스턴스를 사용하여 마지막 검사점에서 수행된 작업을 다시 시작합니다. NServiceBus 및 MassTransit와 같은 이 기능을 제공하는 라이브러리가 있습니다. 메시지를 Azure Service Bus 큐에서 처리하는 간격에 맞춰 상태를 투명하게 지속합니다.

  • 백그라운드 작업이 클라우드 서비스 호스팅 애플리케이션의 작업자 역할과 같은 별도의 컴퓨팅 인스턴스에서 실행되는 경우 다른 크기 조정 정책을 사용하여 애플리케이션의 여러 부분을 확장해야 할 수 있습니다. 예를 들어 백그라운드 컴퓨팅 인스턴스 수를 늘리지 않고 더 많은 UI(사용자 인터페이스) 컴퓨팅 인스턴스를 배포해야 하거나 그 반대로 배포해야 할 수 있습니다. 기본 및 프리미엄 서비스 패키지와 같은 다양한 수준의 서비스를 제공할 수 있습니다. 프리미엄 서비스 패키지에 대한 컴퓨팅 리소스를 기본 서비스 패키지의 리소스보다 더 적극적으로 확장해야 할 수 있습니다. 이 방법은 SLA를 충족하는 데 도움이 됩니다.

기타 크기 조정 조건

  • UI 및 백그라운드 컴퓨팅 인스턴스가 통신하는 큐의 길이를 고려합니다. 자동 크기 조정 전략의 기준으로 사용합니다. 이 조건은 현재 로드와 백그라운드 작업의 처리 용량 간의 불균형 또는 차이를 나타낼 수 있습니다. 기본 크기 조정 결정에는 약간 더 복잡하지만 더 나은 특성이 있습니다. 메시지를 보낸 시간과 처리가 완료된 시점( 중요한 시간이라고 함) 사이의 시간을 사용합니다. 이 중요한 시간 값이 의미 있는 비즈니스 임계값보다 낮으면 큐 길이가 길더라도 크기를 조정할 필요가 없습니다.

    • 예를 들어 큐에 50,000개의 메시지가 있을 수 있습니다. 그러나 가장 오래된 메시지의 중요한 시간은 500ms이며, 해당 엔드포인트는 전자 메일을 보내기 위해 파트너 웹 서비스와의 통합을 처리합니다. 비즈니스 이해 관계자들은 이 시나리오를 스케일 아웃 비용을 정당화할 만큼 시급하다고 생각하지 않을 수 있습니다.

    • 반면에 큐에 500개의 메시지가 있을 수 있으며, 중요한 시간은 500ms입니다. 그러나 엔드포인트는 비즈니스 이해 관계자가 100ms 이하의 응답 시간을 정의한 실시간 온라인 게임에서 중요한 경로의 일부입니다. 이 경우 스케일 아웃하는 것이 좋습니다.

    • 자동 크기 조정 결정에 중요한 시간을 활용하기 위해 라이브러리가 전송 및 처리 중에 메시지 헤더에 관련 정보를 자동으로 추가하도록 하는 것이 유용합니다. 이 기능을 제공하는 라이브러리 중 하나는 NServiceBus입니다.

  • 비즈니스 프로세스를 측정하는 카운터에 자동 크기 조정 전략을 기반으로 하는 경우 이러한 유형의 카운터 결과와 실제 컴퓨팅 용량 요구 사항 간의 관계를 완전히 이해해야 합니다. 카운터의 예로는 매시간 주문 횟수 또는 복합 트랜잭션의 평균 런타임이 있습니다. 비즈니스 프로세스 카운터의 변경에 대응하여 둘 이상의 구성 요소 또는 컴퓨팅 단위를 확장해야 할 수 있습니다.

  • 시스템이 과도하게 스케일 아웃을 시도하지 않도록 하려면 자동으로 추가될 수 있는 최대 인스턴스 수를 제한하는 것이 좋습니다. 또한 이 방법은 수천 개의 인스턴스를 실행하는 것과 관련된 비용을 방지합니다. 대부분의 자동 크기 조정 메커니즘을 사용하면 규칙에 대한 최소 및 최대 인스턴스 수를 지정할 수 있습니다. 또한 최대 인스턴스 수를 배포하고 시스템이 여전히 오버로드되는 경우 시스템에서 제공하는 기능을 정상적으로 저하시키는 것이 좋습니다.

  • 자동 크기 조정은 워크로드의 갑작스러운 버스트를 처리하는 가장 적절한 메커니즘이 아닐 수 있습니다. 서비스의 새 인스턴스를 설정하고 시작하거나 시스템에 리소스를 추가하는 데 시간이 걸립니다. 그리고 이러한 추가 리소스를 사용할 수 있을 때쯤이면 최대 수요가 이미 지나갈 수도 있습니다. 이 시나리오에서는 서비스를 제한하는 것이 더 좋을 수 있습니다. 자세한 내용은 제한 패턴을 참조하세요.

  • 반대로 볼륨이 빠르게 변동할 때 모든 요청을 처리할 수 있는 용량이 필요한 경우 추가 인스턴스를 더 빨리 시작하는 공격적인 자동 크기 조정 전략을 사용하는 것이 좋습니다. 비용이 주요 기여 요인이 아닌지 확인합니다. 로드가 예상되기 전에 최대 부하를 충족하기에 충분한 수의 인스턴스를 시작하는 예약된 정책을 사용할 수도 있습니다.

  • 자동 크기 조정 메커니즘은 자동 크기 조정 프로세스를 모니터링하고 각 자동 크기 조정 이벤트의 세부 정보를 기록해야 합니다. 이러한 세부 정보에는 이벤트를 트리거한 내용, 추가 또는 제거된 리소스 및 이벤트가 발생한 시기가 포함됩니다. 사용자 지정 자동 크기 조정 메커니즘을 만드는 경우 이 기능을 통합하는지 확인합니다. 자동 크기 조정 전략의 효과를 측정하는 데 도움이 되는 정보를 분석하고 필요한 경우 조정합니다. 비즈니스가 확장되거나 애플리케이션의 요구 사항이 진화함에 따라 사용 패턴이 더 분명해짐에 따라 장기적으로 둘 다 조정할 수 있습니다. 애플리케이션이 자동 크기 조정에 대해 정의된 상한에 도달하면 필요한 경우 추가 리소스를 수동으로 시작할 수 있는 운영자에게 경고할 수도 있습니다. 이러한 상황에서 운영자는 워크로드가 완화된 후 이러한 리소스를 수동으로 제거할 수도 있습니다.

다음 패턴 및 지침은 자동 크기 조정을 구현할 때 시나리오와도 관련이 있을 수 있습니다.

  • 제한 패턴은 수요 증가로 리소스에 대한 부하가 증가할 때 애플리케이션이 SLA를 계속 작동하고 충족하는 방법을 설명합니다. 시스템이 스케일 아웃되는 동안 시스템이 과부하되는 것을 방지하기 위해 자동 크기 조정과 함께 제한을 사용할 수 있습니다.

  • 경쟁 소비자 패턴은 모든 애플리케이션 인스턴스의 메시지를 처리할 수 있는 서비스 인스턴스 풀을 구현하는 방법을 설명합니다. 자동 크기 조정을 사용하여 예상되는 워크로드에 맞게 서비스 인스턴스를 시작하고 중지할 수 있습니다. 이 접근 방식을 사용하면 시스템에서 여러 메시지를 동시에 처리하여 처리량을 최적화하고 확장성 및 가용성을 개선하며 워크로드의 균형을 맞출 수 있습니다.

  • 계측 및 메트릭을 포함한 모니터링 및 진단은 자동 크기 조정 프로세스를 구동할 수 있는 정보를 수집하는 데 매우 중요합니다.