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

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

이 가이드에서는 안정적인 크기 조정 전략을 설계하기 위한 권장 사항을 설명합니다.

정의

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

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

주요 디자인 전략

부하 패턴에 따라 디자인

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

• 정적인: 매일 밤 11시 EST까지 애플리케이션의 활성 사용자 수는 100명 이하로 떨어지고 앱 서버의 CPU 사용률은 모든 노드에서 90% 감소합니다. 이를 처리하기 위해 컴퓨팅 노드의 스케일 다운을 오후 11시에서 오전 6시 EST 사이의 최소 수(2)로 예약할 수 있습니다.

• 동적, 일반 및 예측 가능: 매주 월요일 아침, 여러 지역에 걸쳐 1,000명의 직원이 ERP 시스템에 로그인합니다. 이를 관리하기 위해 첫 번째 지역이 작동을 시작하기 전에 컴퓨팅 노드의 스케일 아웃을 일반 일일 용량으로 예약할 수 있습니다.

• 동적, 불규칙 및 예측 가능: 제품 출시는 해당 월의 첫 날에 발생하며, 이러한 상황에서 트래픽이 증가하는 방법에 대한 이전 출시의 기록 데이터가 있습니다. 이 문제를 해결하기 위해 제품 출시 아침에 컴퓨팅 및 데이터베이스 인스턴스의 일회성 예약된 강화를 정의하고 1주일 후에 축소할 수 있습니다.

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

개별 구성 요소 또는 흐름에 맞게 크기 조정 전략 조정

하나의 크기에 맞는 모든 크기 조정 전략은 없습니다. 클라우드 서비스는 크기 조정에 대한 다양한 지원 수준과 크기 조정에 대한 다양한 접근 방식을 가지고 있습니다. 따라서 전체 크기 조정 전략을 설계하기 위해 모든 워크로드 구성 요소에서 크기 조정이 지원되고 구현되는 방식을 이해하는 것이 중요합니다. 아키텍처 디자인에 따라 개별 구성 요소 수준 또는 흐름 수준에서 크기 조정 전략을 적용할 수 있습니다. 워크로드 전체에서 크기 조정을 구현하는 방법을 결정할 때 다음 요소를 고려합니다.

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

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

• 크기 조정 작업 및 구현된 모든 세션 선호도(또는 세션 고정)로 인해 중단될 수 있는 상태 저장 애플리케이션 요소입니다. 고정은 크기 조정 능력을 제한하고 단일 실패 지점을 도입할 수 있습니다. 워크로드를 실용적 범위까지 상태 비중이 되도록 디자인합니다.

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

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

올바른 기술 선택

크기 조정을 염두에 두고 정보에 입각한 기술을 선택하는 것은 워크로드가 진화함에 따라 워크로드가 안정성 목표를 충족할 수 있도록 하는 데 도움이 됩니다. 유사한 기능을 제공하는 다양한 리소스에 대해 제공되는 크기 조정 기능을 조사하고 향후 성장 계획에 가장 적합한 조합을 선택합니다. 예를 들어 사용할 특정 종류의 데이터베이스를 호스트할 수 있는 데이터 저장소에 대한 몇 가지 옵션이 있을 수 있습니다. 그러나 한 가지 선택은 다른 옵션보다 기본 제공 기능의 크기 조정 기능이 더 우수할 수 있으므로 워크로드에 더 나은 선택이 될 수 있습니다.

• 자동으로 크기를 조정하는 서비스를 활용합니다. 실용적이면 구성이나 입력 없이 자동으로 크기를 조정하는 SaaS 서비스를 사용합니다. Microsoft Entra ID와 같은 글로벌 서비스는 이 기능을 제공합니다. 또한 서버리스 솔루션은 자동 크기 조정을 제공하며 많은 사용 사례에 적합한 선택이 될 수 있습니다.

• 기본 크기 조정을 제공하는 서비스를 활용합니다. 많은 PaaS 서비스는 안정성 요구 사항을 충족하도록 구성할 수 있는 통합되고 사용하기 쉬운 크기 조정 기능을 제공합니다. 예를 들어 Cosmos DB에 대한 처리량 크기 조정을 구성하여 특정 요구 사항을 충족할 수 있습니다.

크기 조정 자동화

워크로드 구성 요소에 대한 크기 조정 작업을 자동화하여 실용적입니다. 구성 가능한 자동 크기 조정 기능이 있는 리소스를 사용하는 경우 구성 논리를 IaC(Infrastructure-as-code) 배포 코드로 빌드합니다. 기본 제공 자동 크기 조정이 제공되지 않는 리소스를 사용하는 경우 자동화를 빌드하여 네이티브 자동화 도구를 사용하여 크기 조정 작업을 수행하고 IaC 코드에 자동화 코드를 포함합니다.

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

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

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

적절한 배율 단위 선택

크기 조정 전략은 확장 단위를 기반으로 하며, 이는 함께 스케일링할 구성 요소의 논리적 그룹화 및 사용할 크기 조정 증가입니다(예: VM SKU에서 다른 VM으로 이동). 고려해야 할 옵션은 다음과 같습니다.

• 리소스 개별적으로 크기 조정: 개별 VM 또는 데이터베이스만 확장해야 할 수 있습니다.

• 전체 구성 요소의 크기를 동시에 조정합니다 . 예를 들어 동시에 크기를 조정해야 하는 App Service, 데이터베이스 및 큐로 구성된 마이크로 서비스 API가 있을 수 있습니다.

• 전체 솔루션 크기 조정: 복잡하거나 중요 업무용 워크로드의 경우 전체 솔루션을 배포 스탬프 로 확장하면 크기 조정 전략을 간소화할 수 있습니다. 여러 고유 리소스의 크기 조정 일정 및 자동 크기 조정 임계값을 관리하는 대신 배포 스탬프에 제한된 크기 조정 정의 집합을 적용한 다음 필요에 따라 스탬프 간에 미러링할 수 있습니다.

배율 단위 초기화 시간 최적화

크기 조정 전략을 설계할 때는 서로 다른 서비스가 서로 다른 시간대에 확장된다는 점을 명심하세요. 거의 즉각적으로 크기를 조정하는 일부 서비스와 훨씬 느리게 확장되는 서비스가 있습니다. 예를 들어 API Management 인스턴스는 크기 조정 작업을 완료하는 데 최대 45분이 걸릴 수 있습니다. 크기 조정 작업의 시간 표시줄을 고려하려면 예상되는 증가된 부하가 워크로드에 적중하기 전에 크기 조정 작업을 제대로 수행하도록 계획합니다. 고려해야 할 다른 권장 사항은 다음과 같습니다.

• 초기화에 필요한 시간을 줄이기 위해 배포될 노드를 미리 초기화합니다.

• 추가 변경을 하거나 드문 방식으로 시스템을 사용하기 전에 구성 변경에 대한 버퍼 시간을 허용합니다. 예를 들어 규칙 변경을 통해 App Gateway 백 엔드 인스턴스의 할당을 취소할 수 있습니다. 안전하게 제거하려면 해당 인스턴스에서 연결이 드레이닝될 때까지 기다려야 합니다.

• 크기 조정이 진행되는 동안 증가된 부하를 처리하도록 리소스를 과도하게 프로비전합니다. VM은 일반적으로 75% 사용률 용량에서 실행되어 수평적 크기 조정이 진행되는 동안 증가된 부하를 처리할 수 있는지 확인할 수 있습니다.

• 모니터링을 사용하여 크기 조정 임계값을 미세 조정합니다. 용량 모니터링을 사용하여 크기 조정 임계값을 확인하여 크기 조정 작업을 트리거합니다.

분할 및 분할을 사용하여 데이터 저장소 크기 조정

크기 조정 전략에 포함시켜 데이터 자산의 안정성을 최적화합니다. 데이터를 분할하면 데이터베이스가 논리 또는 물리적 스토리지 리소스에 분산되며 단일 실패 지점이 제거됩니다. 사용 사례에 가장 적합한 분할 전략을 선택합니다.

• 가로 분할(분할): 파티션(분할)은 별도의 데이터 저장소에 배치되지만 모든 파티션에는 동일한 스키마가 있습니다. 각 분할된 데이터베이스는 데이터베이스의 하위 집합을 보유합니다. 이는 부하 분산을 용이하게 하고 문제를 처리할 때 작업에 대한 부담을 최소화하는 데 도움이 되므로 안정성을 최적화하는 좋은 방법입니다. 더 높은 안정성을 위해 분할된 데이터베이스를 복제할 수 있습니다.

• 수직 분할: 각 파티션은 데이터 저장소의 항목에 대한 필드의 하위 집합을 보유합니다. 필드는 사용 패턴에 따라 나뉩니다.

• 기능 분할: 시스템의 각 바인딩된 컨텍스트에서 데이터를 사용하는 방법에 따라 데이터가 집계됩니다.

분할 체계를 디자인할 때 이러한 전략을 결합하는 것이 좋습니다. 예를 들어 데이터를 분할된 데이터베이스로 나눈 다음 수직 분할을 사용하여 각 분할된 데이터베이스의 데이터를 추가로 세분화할 수 있습니다.

확장성을 위해 파티션 전략을 최적화합니다. 데이터 액세스 패턴을 분석하여 가장 많은 처리 리소스가 필요한 작업을 결정하고 파티션의 균형을 조정하여 각 작업에 확장성 요구 사항을 처리할 수 있는 충분한 리소스가 있는지 확인합니다.

분할 및 분할에 대한 자세한 지침은 디자인 가이드를 참조하세요.

크기 조정 작업 모니터링

자동 크기 조정 메커니즘은 자동 크기 조정 프로세스를 모니터링하고 각 자동 크기 조정 이벤트의 세부 정보(트리거된 이벤트, 추가 또는 제거된 리소스 및 시기)를 기록해야 합니다. 사용자 지정 자동 크기 조정 메커니즘을 만드는 경우 이 기능을 통합하는지 확인합니다. 자동 크기 조정 전략의 효율성을 측정하는 데 도움이 되도록 정보를 사전에 분석하고 필요한 경우 튜닝합니다.

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 가이드 를 참조하세요.

장단점

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

예시

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

관련 링크

• 성능 효율성 크기 조정
• 자동 크기 조정 모범 사례

안정성 검사 목록

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