다음을 통해 공유

자동 확장

  • 아티클

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

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

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

  • 규모 확장 및 규모 축소라고도 하는 수직적 크기 조정은 리소스의 용량을 변경하는 것을 의미합니다. 예를 들어, 애플리케이션을 더 큰 VM 크기로 이동할 수 있습니다. 수직 크기 조정은 종종 재배포되는 동안 해당 시스템을 일시적으로 사용할 수 없게 해야 합니다. 따라서 수직 크기 조정을 자동화하는 것은 일반적이지 않습니다.

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

Microsoft Azure를 포함한 많은 클라우드 기반 시스템이 자동 수평적 크기 조정을 지원합니다. 이 문서의 나머지 부분에서는 수평적 크기 조정에 대해 중점적으로 설명합니다.

참고

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

자동 크기 조정 구성 요소

자동 크기 조정 전략은 일반적으로 다음 측면을 아우릅니다.

  • 애플리케이션, 서비스 및 인프라 수준의 계측 및 모니터링 시스템 이 시스템에서 응답 시간, 큐 길이, CPU 사용률, 메모리 사용량 등의 주요 메트릭 캡처
  • 미리 정의된 임계값 또는 일정에 대해 이러한 메트릭을 평가하고 크기 조정 여부를 결정하는 의사 결정 논리
  • 시스템의 크기를 조정하는 구성 요소
  • 자동 크기 조정 전략을 테스트, 모니터링, 조정하여 예상대로 작동하는지 확인

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

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

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

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

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

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

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

Azure Monitor 자동 크기 조정 사용

Azure Monitor 자동 크기 조정은 Virtual Machine Scale Sets, Azure App Service 및 Azure Cloud Service에 대한 공통 자동 크기 조정 기능 집합을 제공합니다. 크기 조정은 일정에 따라 수행되거나, CPU 또는 메모리 사용량과 같은 런타임 메트릭을 기준으로 수행될 수 있습니다.

예:

  • 평일에는 10개의 인스턴스로 스케일 아웃하고, 토요일과 일요일에는 4개의 인스턴스로 스케일 인합니다.
  • 평균 CPU 사용량이 70%보다 크면 인스턴스를 1개씩 스케일 아웃하고, CPU 사용량이 50% 미만으로 떨어지면 인스턴스를 1개씩 스케일 인합니다.
  • 큐의 메시지 수가 특정 임계값을 초과하는 경우 인스턴스를 1개씩 스케일 아웃합니다.

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

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

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

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

Azure 자동 크기 조정을 사용하는 경우에는 다음 사항을 고려하세요.

  • 예상되는 수요 최대치를 충족하기 위해 인스턴스를 추가 및 제거하고 예약된 자동 크기 조정을 사용하기에 충분히 정확하게 애플리케이션의 부하를 예측할 수 있는지 여부를 고려합니다. 이것이 불가능한 경우에는 예측 불가능한 수요 변화를 처리할 수 있게 런타임 메트릭을 기준으로 하는 반응형 자동 크기 조정을 사용합니다. 일반적으로 이 방법들을 결합할 수 있습니다. 예를 들어, 애플리케이션이 가장 바쁜 시간의 일정을 기반으로 리소스를 추가하는 전략을 만듭니다. 이렇게 하면 새 인스턴스를 시작할 때 지체하지 않고, 필요할 때 용량을 사용할 수 있게 하는 데 도움이 됩니다. 각 예정된 규칙에 대해 해당 기간 동안 반응형 자동 크기 조정을 할 수 있게 하는 메트릭을 정의하여 애플리케이션이 지속적이면서 수요를 예측할 수 없는 피크를 처리할 수 있게 합니다.

  • 종종 메트릭과 용량 요구 사항의 관계를 이해하기는 어려우며, 특히 애플리케이션이 초기에 배포된 경우에 그렇습니다. 처음에 약간의 추가 용량을 프로비전한 후 자동 크기 조정 규칙을 모니터링하고 조정하여 용량을 실제 부하에 더 근접하게 합니다.

  • 자동 크기 조정 규칙을 구성하고 시간 경과에 따른 애플리케이션의 성능 변화를 모니터링합니다. 이 모니터링 결과를 사용하여 필요한 경우 시스템 크기 조정 방법을 조정합니다. 그러나 자동 크기 조정은 즉각적인 프로세스가 아님을 명심하세요. 지정된 임계값을 초과하는(또는 미달하는) 평균 CPU 사용률과 같은 메트릭에 반응하는 데에는 시간이 걸립니다.

  • 측정된 트리거 특성(CPU 사용량이나 큐 길이 등)을 기반으로 하는 감지 메커니즘을 사용하는 자동 크기 조정 규칙은 즉각적인 값보다는 시간 경과에 따라 집계되는 값을 사용하여 자동 크기 조정 작업을 트리거합니다. 기본적으로 집계는 값의 평균입니다. 이는 시스템이 너무 신속하게 반응하거나 빠른 진동을 일으키는 것을 방지합니다. 또한 자동으로 시작된 새 인스턴스가 실행 모드로 정착할 시간을 허용하여 새 인스턴스가 시작되는 동안 추가 자동 크기 조정 작업이 발생하는 것을 방지합니다. Azure Cloud Services 및 Azure Virtual Machines의 경우 집계에 대한 기본 기간은 45분이므로, 수요 급증에 응답하여 자동 크기 조정을 트리거하는 메트릭에 대해 이 기간을 확보할 수 있습니다. SDK를 사용하여 집계 기간을 변경할 수 있지만 25분 미만의 기간은 예측할 수 없는 결과를 초래할 수 있습니다. Web Apps의 경우, 평균 기간은 더 짧아서 평균 트리거 측정값을 변경한 후 약 5분 후에 새 인스턴스를 사용할 수 있습니다.

  • 스케일 인 및 스케일 아웃 작업이 계속 앞뒤로 진행되는 플래핑을 방지합니다. 두 개의 인스턴스가 있고 상한이 80% CPU이고 하한이 60%라고 가정합니다. 로드가 85%일 때 다른 인스턴스가 추가됩니다. 잠시 후 부하가 60%로 감소합니다. 스케일 인하기 전에 자동 크기 조정 서비스는 인스턴스가 제거될 때 총 부하(인스턴스 3개)의 분포를 계산하여 90%로 만듭니다. 즉, 즉시 다시 스케일 아웃해야 합니다. 따라서 스케일 인을 건너뛰고 예상되는 크기 조정 결과를 볼 수 없을 수도 있습니다.

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

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

  • 자동 크기 조정 엔진은 한 번에 하나의 프로필만 처리합니다. 조건이 충족되지 않으면 다음 프로필을 확인합니다. 해당 프로필이 마지막으로 확인되기 때문에 기본 프로필에서 주요 메트릭을 유지합니다. 프로필 내에서 여러 규칙을 가질 수 있습니다. 규모 확장의 경우 임의의 규칙이 충족되면 자동 크기 조정이 실행됩니다. 규모 감축의 경우 모든 규칙이 충족되어야 자동 크기 조정이 실행됩니다.

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

  • 포털 대신 SDK를 사용하여 자동 크기 조정을 구성하면 규칙이 활성화된 동안 더 상세한 일정을 지정할 수 있습니다. 또한 고유의 메트릭을 만들고 사용자의 자동 크기 조정 규칙에 존재하는 내용과 함께 또는 별도로 사용할 수도 있습니다. 예를 들어, 초당 요청 수 또는 평균 메모리 가용성과 같은 대체 카운터를 사용하거나 사용자 지정 카운터를 사용하여 특정 업무 프로세스를 측정할 수 있습니다.

  • Service Fabric 자동 크기 조정 시 클러스터의 노드 유형은 백 엔드에서 Virtual Machine Scale Sets로 구성되므로 각 노드 유형에 대한 자동 크기 조정 규칙을 설정해야 합니다. 자동 크기 조정을 설정하기 전에 포함해야 할 노드 수를 고려합니다. 기본 노드 형식에 대해 포함해야 할 최소 노드 수는 선택한 안정성 수준에 따라 달라집니다. 자세한 내용은 자동 크기 조정 규칙을 사용하여 Service Fabric 클러스터 크기 조정을 참조하세요.

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

  • 복수의 정책 및 규칙을 구성하는 경우, 서로 충돌할 수 있습니다. 자동 크기 조정은 다음 충돌 해결 규칙을 사용하여 언제나 충분한 수의 인스턴스가 실행되도록 합니다.

    • 스케일 아웃 작업은 언제나 규모 감축 작업보다 우선됩니다.
    • 스케일 아웃 작업이 충돌하는 경우, 인스턴스 수가 가장 많이 증가되는 규칙이 우선됩니다.
    • 규모 감축 작업이 충돌하는 경우, 인스턴스 수가 가장 적게 감소되는 규칙이 우선됩니다.

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

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

자동 크기 조정은 인스턴트 솔루션이 아닙니다. 그저 리소스를 시스템에 추가하거나 프로세스의 더 많은 인스턴스를 추가하기만 해서는 시스템 성능의 향상이 보장되지 않습니다. 자동 크기 조정 전략을 디자인할 때 다음 사항을 고려하십시오.

  • 시스템은 수평 확장이 가능하도록 디자인해야 합니다. 인스턴스 선호도를 가정하지 마십시오. 프로세스의 특정 인스턴스에서 항상 실행되는 코드가 필요한 솔루션을 디자인하지 마십시오. 클라우드 서비스나 웹 사이트를 수평으로 크기 조정하는 경우, 항상 동일한 인스턴스에 라우팅되는 동일한 소스로부터의 일련의 요청을 가정하지 마세요. 같은 이유로 서비스를 상태 비저장으로 디자인하여 항상 서비스의 동일한 인스턴스에 라우팅되는 애플리케이션으로부터의 일련의 요청을 방지하십시오. 큐에서 메시지를 읽고 처리하는 서비스를 디자인하는 경우 특정 메시지를 처리하는 서비스의 인스턴스를 가정하지 마세요. 큐 길이가 늘어나면 자동 크기 조정이 서비스의 추가 인스턴스를 시작할 수 있습니다. 경쟁 소비자 패턴에서는 이 시나리오를 처리하는 방법을 설명합니다.

  • 솔루션이 장기 실행 작업을 구현하는 경우, 이 작업이 규모 확장 및 규모 감축을 모두 지원하도록 디자인하십시오. 기한에 상관 없이, 이러한 작업은 시스템이 규모 감축되었을 때 프로세스의 인스턴스가 완전히 종료되는 것을 방지할 수 있으며, 그러지 않으면 프로세스가 강제로 종료되었을 때 데이터가 손상될 수 있습니다. 이상적으로는 장기 실행 작업을 리팩터링하고 더 작고 이스크리트된 청크로 수행하는 처리를 중단합니다. 파이프 및 필터 패턴에서는 이렇게 할 수 있는 방법의 예를 제공합니다.

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

  • 백그라운드 작업이 별도 컴퓨팅 인스턴스에서 실행되는 경우, 클라우드 서비스에 호스트된 애플리케이션의 작업자 역할에서와 같이 서로 다른 크기 조정 정책을 사용하는 애플리케이션의 서로 다른 부분을 크기 조정해야 할 수 있습니다. 예를 들어 백그라운드 컴퓨팅 인스턴스의 수를 증가시키지 않고 추가 UI(사용자 인터페이스) 컴퓨팅 인스턴스를 배포하거나 그 반대로 해야 할 수 있습니다. 서로 다른 수준의 서비스(기본 및 고급 서비스 패키지 등)를 제공하는 경우, SLA를 충족시키기 위해 기본 서비스 패키지에 대한 컴퓨팅 리소스보다 고급 서비스 패키지에 대한 컴퓨팅 리소스를 더 적극적으로 규모 확장해야 할 수 있습니다.

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

    • 예를 들어 큐에 50,000개의 메시지가 있을 수 있지만 가장 오래된 메시지의 중요한 시간은 500ms이며, 해당 엔드포인트는 전자 메일을 보내기 위한 타사 웹 서비스와의 통합을 처리합니다. 비즈니스 이해 관계자들은 크기 조정을 위해 추가 비용을 지출하는 것을 정당화하지 않는 기간으로 간주할 가능성이 높습니다.
    • 반면, 큐에 500개의 메시지가 있을 수 있으며, 중요한 시간은 500ms이지만, 엔드포인트는 비즈니스 관련자가 100ms 이하의 응답 시간을 정의한 일부 실시간 온라인 게임에서 중요한 경로의 일부입니다. 이 경우 스케일 아웃하는 것이 합리적입니다.
    • 자동 크기 조정 결정에서 중요한 시간을 활용하려면 라이브러리가 메시지의 헤더에 관련 정보를 자동으로 추가하는 동시에 메시지를 보내고 처리하도록 하는 것이 유용합니다. 이 기능을 제공하는 라이브러리 중 하나는 NServiceBus입니다.

  • 시간당 명령 수나 복잡한 트랜잭션의 평균 실행 시간과 같은 비즈니스 프로세스를 측정하는 카운터의 자동 크기 조정 전략에 기반하는 경우, 이 카운터 유형의 결과와 실제 컴퓨팅 용량 요구 간의 관계를 제대로 이해했는지 확인하십시오. 비즈니스 프로세스 카운터의 변경에 대응하여 둘 이상의 구성 요소 또는 컴퓨팅 단위를 확장해야 할 수도 있습니다.

  • 시스템이 과도하게 규모 확장되려는 것을 방지하고 수많은 인스턴스를 실행함으로 인한 비용 발생을 회피하기 위해 자동으로 추가될 수 있는 인스턴스의 최대 수를 제한하는 것이 좋습니다. 대부분의 자동 크기 조정 메커니즘을 사용하면 규칙에 대한 인스턴스의 최소 및 최대 수를 지정할 수 있습니다. 또한 인스턴스의 최대 수가 배포되고 시스템이 여전히 오버로드된 경우 시스템이 제공하는 기능을 적절하게 저하시키는 것이 좋습니다.

  • 자동 크기 조정은 갑작스런 워크로드 버스트를 처리하기에 가장 적합한 메커니즘이 아닐 수도 있다는 점을 명심하십시오. 서비스의 새 인스턴스를 프로비전하고 시작하거나 시스템에 리소스를 추가하는 데에는 시간이 걸리며, 이러한 추가 리소스를 사용할 수 있게 된 무렵에는 피크 수요가 이미 지나갔을 수 있습니다. 이 시나리오에서는 서비스를 제한하는 것이 더 나을 수 있습니다. 자세한 내용은 제한 패턴을 참조하세요.

  • 반대로, 볼륨이 급속하게 증가될 때 모든 요청을 처리할 용량이 필요하고 비용은 주요 고려 사항이 아닌 경우, 추가 인스턴스를 더 빠르게 시작하는 적극적인 자동 크기 조정 전략을 사용하는 것이 좋습니다. 해당 부하가 예상되기 전에 최대 부하에 적합한 충분한 수의 인스턴스를 시작하는 일정 정책을 사용할 수도 있습니다.

  • 자동 크기 조정 메커니즘은 자동 크기 조정 프로세스를 모니터링하고 각 자동 크기 조정 이벤트의 세부 정보(언제 어떻게 트리거되고 어떤 리소스가 추가 또는 제거되었는지)를 기록해야 합니다. 사용자 지정 자동 크기 조정 메커니즘을 만든 경우, 이 기능이 통합되어 있는지 확인하십시오. 정보를 분석하면 자동 크기 조정 전략의 효율성을 측정하고 필요한 경우 조정하는 데 도움이 될 수 있습니다. 단기적으로는 더 명확해지는 사용 패턴, 장기적으로는 사업 확장이나 애플리케이션 요구 사항의 진화에 따라 둘 다 조정할 수 있습니다. 또한 애플리케이션이 자동 크기 조정에 대해 정의된 상한에 도달하면 메커니즘은 필요한 경우 추가 리소스를 수동으로 시작할 수 있는 운영자에게 알립니다. 이 상황에서 운영자는 워크로드를 완화한 후 이 리소스를 수동으로 제거할 수도 있습니다.

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

  • 제한 패턴. 이 패턴에서는 수요 증가가 리소스에 극단적인 부하를 배치한 경우에 애플리케이션이 계속 기능하고 SLA를 충족시킬 수 있는 방법을 설명합니다. 시스템을 규모 확장하는 동안 자동 크기 조정에 제한을 사용하여 시스템 과부하를 방지할 수 있습니다.

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

  • 모니터링 및 진단. 계측 및 원격 분석은 자동 크기 조정 프로세스를 수행할 수 있는 정보를 수집하기 위해 중요합니다.