신뢰할 수 있는 크기 조정 전략을 설계하기 위한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 안정성 검사 목록 권장 사항에 적용됩니다.

RE:06 애플리케이션, 데이터 및 인프라 수준에서 시기 적절하게 안정적인 크기 조정 전략을 구현합니다.

관련 가이드:데이터 분할

이 가이드에서는 신뢰할 수 있는 크기 조정 전략을 설계하기 위한 권장 사항을 설명합니다.

정의

용어 정의
수직 크기 조정 기존 리소스에 컴퓨팅 용량을 추가하는 크기 조정 접근 방식입니다.
수평 크기 조정 지정된 유형의 리소스 인스턴스를 추가하는 크기 조정 접근 방식입니다.
자동 확장 조건 집합이 충족될 때 리소스를 자동으로 추가하거나 제거하는 크기 조정 접근 방식입니다.

참고

크기 조정 작업은 정적(일반 부하 패턴을 수용하기 위해 정기적으로 예약된 일일 크기 조정), 자동(충족되는 조건에 대응하는 자동화된 프로세스) 또는 수동일 수 있습니다(연산자는 예기치 않은 부하 변경에 대응하여 일회성 크기 조정 작업을 수행함). 이러한 메서드를 통해 수직 및 가로 크기 조정을 모두 수행할 수 있습니다. 그러나 자동 수직 크기 조정에는 추가 사용자 지정 자동화 개발이 필요하며 크기 조정되는 리소스에 따라 가동 중지 시간이 발생할 수 있습니다.

주요 디자인 전략

워크로드에 대한 안정적인 크기 조정 전략을 설계하려면 크기 조정 작업으로 이어지는 각 워크로드의 사용자 및 시스템 흐름에 대한 부하 패턴을 식별하는 데 중점을 줍니다. 다양한 부하 패턴의 예는 다음과 같습니다.

  • 정적: 매일 밤 11시 EST까지 활성 사용자 수가 100명 미만이고 앱 서버의 CPU 사용률이 모든 노드에서 90% 감소합니다.

  • 동적, 일반 및 예측 가능: 매주 월요일 아침, 여러 지역의 1,000명의 직원이 ERP 시스템에 로그인합니다.

  • 동적, 불규칙 및 예측 가능: 제품 출시는 월 첫째 날에 발생하며 이러한 상황에서 트래픽이 증가하는 방법에 대한 이전 출시의 기록 데이터가 있습니다.

  • 동적, 불규칙 및 예측할 수 없음: 대규모 이벤트로 인해 제품에 대한 수요가 급증합니다. 예를 들어, 제습기를 제조하고 판매하는 기업은 영향을 받는 지역의 사람들이 집에서 방을 건조시켜야 할 때 허리케인이나 기타 홍수 사건 이후에 갑자기 트래픽이 급증할 수 있습니다.

이러한 유형의 부하 패턴을 식별한 후에는 다음을 수행할 수 있습니다.

  • 각 패턴과 연결된 부하 변경이 인프라에 미치는 영향을 식별합니다.

  • 자동화를 빌드하여 크기 조정을 안정적으로 해결합니다.

이전 예제의 경우 크기 조정 전략은 다음과 같습니다.

  • 정적: 계산 노드의 예약된 배율을 오후 11시에서 오전 6시 EST 사이의 최소 개수(2)로 설정합니다.

  • 동적, 일반 및 예측 가능: 첫 번째 지역이 작동하기 전에 컴퓨팅 노드에서 일반 일일 용량으로 예약된 스케일 아웃이 있습니다.

  • 동적, 불규칙 및 예측 가능: 제품 출시 아침에 컴퓨팅 및 데이터베이스 인스턴스의 일회성 예약 스케일업을 정의하고 1주일 후에 다시 축소합니다.

  • 동적, 불규칙 및 예측할 수 없음: 계획되지 않은 트래픽 급증을 고려하도록 자동 크기 조정 임계값이 정의되어 있습니다.

크기 조정 자동화를 디자인할 때 다음 문제를 고려해야 합니다.

  • 워크로드의 모든 구성 요소가 크기 조정 구현의 후보가 되어야 합니다. 대부분의 경우 Microsoft Entra ID와 같은 글로벌 서비스는 사용자와 고객에게 자동으로 투명하게 확장됩니다. 네트워킹 수신 및 송신 컨트롤러의 크기 조정 기능과 부하 분산 솔루션을 이해해야 합니다.

  • 확장할 수 없는 구성 요소입니다. 예를 들어 분할을 사용하도록 설정하지 않고 큰 영향 없이 리팩터링할 수 없는 대규모 관계형 데이터베이스가 있습니다. 클라우드 공급자가 게시한 리소스 제한을 문서화하고 해당 리소스를 면밀히 모니터링합니다. 확장 가능한 서비스로 마이그레이션하기 위한 향후 계획에 이러한 특정 리소스를 포함합니다.

  • 추가 로드가 인프라에 적중하기 전에 작업이 수행되도록 크기 조정 작업을 수행하는 데 걸리는 시간입니다. 예를 들어 API Management 같은 구성 요소의 크기를 조정하는 데 45분이 걸리는 경우 크기 조정 임계값을 90% 대신 65%로 조정하면 더 일찍 크기를 조정하고 예상 부하 증가를 준비하는 데 도움이 될 수 있습니다.

  • 크기 조정 작업 순서 측면에서 흐름 구성 요소의 관계입니다. 먼저 업스트림 구성 요소를 확장하여 실수로 다운스트림 구성 요소를 오버로드하지 않도록 합니다.

  • 크기 조정 작업 및 구현된 모든 세션 선호도(또는 세션 고정성)로 인해 중단될 수 있는 상태 저장 애플리케이션 요소입니다. 고정은 크기 조정 능력을 제한할 수 있으며 단일 실패 지점을 도입합니다.

  • 잠재적인 병목 현상. 스케일 아웃해도 모든 성능 문제가 해결되지는 않습니다. 예를 들어 백 엔드 데이터베이스가 병목 상태인 경우 웹 서버를 더 추가하는 데 도움이 되지 않습니다. 인스턴스를 더 추가하기 전에 먼저 시스템의 병목 상태를 식별하고 resolve. 일반적으로 시스템의 상태 저장 부분이 병목 상태의 주요 원인입니다.

배포 스탬프 디자인 패턴을 따르면 전반적인 인프라 관리에 도움이 됩니다. 눈금 단위로 스탬프에 크기 조정 디자인을 기반으로 하는 것도 유용합니다. 또한 여러 워크로드 및 워크로드 하위 집합에서 크기 조정 작업을 엄격하게 제어할 수 있습니다. 여러 고유 리소스의 크기 조정 일정 및 자동 크기 조정 임계값을 관리하는 대신 배포 스탬프에 제한된 크기 조정 정의 집합을 적용한 다음 필요에 따라 스탬프 간에 미러 수 있습니다.

절충: 스케일 업은 비용에 영향을 미치므로 가능한 한 빨리 규모를 축소하여 비용을 제어할 수 있도록 전략을 최적화합니다. 스케일 업에 사용하는 자동화에 규모 축소 트리거도 있는지 확인합니다.

Azure 촉진

자동 크기 조정 기능은 많은 Azure 서비스에서 사용할 수 있습니다. 이를 통해 인스턴스를 가로로 자동으로 스케일링하도록 조건을 쉽게 구성할 수 있습니다. 일부 서비스에는 자동으로 스케일 인할 수 있는 기능이 제한되어 있거나 기본 제공 기능이 없으므로 이러한 사례를 문서화하고 스케일 인을 처리하는 프로세스를 정의해야 합니다.

많은 Azure 서비스는 Azure IoT Hub 자동 크기 조정의 코드 샘플과 같은 Azure Automation 사용하여 사용자 지정 자동 크기 조정 작업을 디자인하는 데 사용할 수 있는 API를 제공합니다. Azure Kubernetes Service 및 Azure Container Apps에서 사용할 수 있는 이벤트 기반 자동 크기 조정에 KEDA와 같은 도구를 사용할 수 있습니다.

Azure Monitor 자동 크기 조정은 Azure Virtual Machine Scale Sets, Azure App Service, Azure Spring Apps 등에 대한 일반적인 자동 크기 조정 기능 집합을 제공합니다. 크기 조정은 일정에 따라 또는 CPU 또는 메모리 사용량과 같은 런타임 메트릭에 따라 수행할 수 있습니다. 모범 사례는 Azure Monitor 가이드 를 참조하세요.

균형 유지

자동 크기 조정 고려 사항

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

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

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

또는 정기적으로 작업에 대한 상태 정보를 기록하는 검사점 메커니즘을 구현할 수 있습니다. 그런 다음 작업을 실행하는 프로세스의 instance 액세스할 수 있는 지속성 스토리지에 이 상태를 저장할 수 있습니다. 이러한 방식으로 프로세스가 종료되면 다른 instance 마지막 검사점에서 수행하던 작업을 다시 시작합니다. NServiceBus 및 MassTransit와 같은 이 기능을 제공하는 라이브러리가 있습니다. 간격이 Azure Service Bus 큐의 메시지 처리와 일치하는 상태를 투명하게 유지합니다.

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

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

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

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

자동 크기 조정 결정에 중요한 시간을 사용하려면 라이브러리가 메시지의 헤더를 보내고 처리하는 동안 관련 정보를 자동으로 추가하도록 하는 것이 유용합니다. 이 기능을 제공하는 하나의 라이브러리는 NServiceBus입니다.

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

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

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

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

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

예제

AKS 기준 참조 아키텍처 크기 조정 지침을 참조하세요.

안정성 검사 목록

전체 권장 사항 집합을 참조하세요.

안정성 검사 목록