크기 조정 비용 최적화를 위한 권장 사항
이 Azure 잘 설계된 프레임워크 비용 최적화 검사 목록 권장 사항에 적용됩니다.
CO:12 | 크기 조정 비용 최적화 배율 단위 내에서 대체 크기 조정을 평가합니다. 대체 크기 조정 구성을 고려하고 비용 모델에 맞춥니다. 고려 사항에는 모든 인스턴스, 리소스 및 배율 단위 경계의 상속 제한에 대한 사용률이 포함되어야 합니다. 수요 및 공급을 제어하기 위한 전략을 사용합니다. |
---|
이 가이드에서는 크기 조정 비용을 최적화하기 위한 권장 사항을 제공합니다. 크기 조정 비용 최적화는 워크로드 크기 조정에서 비효율성을 제거하는 프로세스입니다. 목표는 모든 비기능적 요구 사항을 충족하면서 크기 조정 비용을 줄이는 것입니다. 동일한 결과를 얻기 위해 지출이 줄어듭니다. 크기 조정을 최적화하면 불필요한 비용, 과잉 프로비전 및 낭비를 방지할 수 있습니다. 또한 수요를 제어하고 공급을 제한하여 예기치 않은 비용 급증을 방지할 수 있습니다. 비효율적인 크기 조정 관행은 워크로드 및 운영 비용을 증가시키고 워크로드의 전반적인 재무 상태에 부정적인 영향을 줄 수 있습니다.
정의
용어 | 정의 |
---|---|
자동 확장 | 조건 집합이 충족될 때 리소스를 자동으로 추가하거나 제거하는 크기 조정 접근 방식입니다. |
비용 메트릭 | 워크로드 비용과 관련된 숫자 데이터입니다. |
규모 축소 | 워크로드에 더 적은 리소스를 제공하기 위해 더 낮은 SKU로 전환하는 수직 크기 조정 전략입니다. |
스케일 인 | 워크로드에 더 적은 리소스를 제공하기 위해 인스턴스를 제거하는 수평적 크기 조정 전략입니다. |
확장 | 워크로드에 더 많은 리소스를 제공하기 위해 인스턴스를 추가하는 수평적 크기 조정 전략입니다. |
배율 단위 | 비례적으로 함께 스케일링되는 리소스 그룹입니다. |
강화 | 워크로드에 더 많은 리소스를 제공하기 위해 더 높은 SKU로 전환하는 수직 크기 조정 전략입니다. |
SKU(Stock Keeping Unit) | Azure 서비스에 대한 서비스 계층입니다. |
사용량 현황 데이터 | 사용량 현황 데이터는 작업, 서비스 또는 애플리케이션이 사용되는 양에 대한 직접 정보(실제) 또는 간접/대표 정보(프록시)입니다. |
주요 디자인 전략
크기 조정 비용 최적화의 목표는 확장은 필요한 마지막 순간까지 미루고 축소는 가능한 순간 즉시 실행하는 것입니다. 워크로드 크기 조정을 최적화하기 위해 배율 단위 내에서 대체 가능한 크기 조정 옵션을 평가하고 비용 모델에 맞출 수 있습니다. 배율 단위는 독립적으로 또는 함께 확장할 수 있는 리소스의 특정 그룹을 나타냅니다. 특정 양의 부하를 처리하도록 배율 단위를 디자인해야 하며, 여러 인스턴스, 서버 또는 기타 리소스를 구성할 수 있습니다. 워크로드 배율 단위 및 모델 대체 항목의 비용 효율성을 평가해야 합니다.
크기 조정을 사용하지 않는 경우 워크로드 크기 조정에 대한 지침을 참조하세요. 애플리케이션의 크기를 조정할 수 있는지 확인해야 합니다. 상태 비저장 애플리케이션은 여러 요청을 동시에 처리할 수 있으므로 크기 조정이 더 쉽습니다. 또한 애플리케이션이 분산 시스템 원칙을 사용하여 빌드되었는지 평가합니다. 분산 시스템은 워크로드를 여러 노드에 분산하여 증가된 부하를 처리할 수 있습니다. 그러나 싱글톤 애플리케이션은 지정된 시간에 하나의 인스턴스만 실행되도록 설계되었습니다. 따라서 크기 조정이 모든 워크로드에 적합하지 않을 수 있습니다.
스케일 아웃 평가 및 강화
스케일 아웃과 스케일 업을 평가하려면 가격 책정, 워크로드 요구 사항, 허용 가능한 가동 중지 시간과 같은 다양한 요소를 기반으로 기존 시스템에서 리소스를 늘리거나(스케일 업) 해당 시스템의 인스턴스를 더 추가(스케일 아웃)하는 것 사이에서 가장 비용 효율적인 방식을 결정해야 합니다. 올바른 크기 조정 방식을 선택하면 성능 및 안정성 표준을 충족하면서 필요한 만큼만 비용을 지불함으로써 상당한 비용 절약 효과를 얻을 수 있습니다.
목표는 서비스 계층 가격 책정, 워크로드 특성, 허용 가능한 가동 중지 시간 및 비용 모델을 기반으로 가장 비용 효율적인 선택을 결정하는 것입니다. 일부의 경우 더 적은 수로 더 비싼 인스턴스를 선택하는 것이 더 경제적일 수 있습니다. 반대로, 다른 사용자에게는 더 많은 인스턴스가 있는 저렴한 계층이 더 좋을 수 있습니다. 정보에 입각한 결정을 내리려면 설정에서 실제 또는 대표 데이터를 분석하고 각 전략의 상대적 비용 장점을 평가해야 합니다. 가장 비용 효율적인 방법을 평가하려면 다음 권장 사항을 고려하세요.
사용량 현황 데이터 수집: 워크로드 사용 패턴 및 리소스 사용률을 나타내는 실제 프로덕션 데이터 또는 프록시 데이터를 수집합니다. 이 데이터에는 CPU 사용량, 메모리 사용량, 네트워크 트래픽 및 크기 조정 비용에 영향을 주는 기타 관련 메트릭과 같은 메트릭이 포함되어야 합니다.
비용 메트릭 정의: 시간당 비용, 트랜잭션당 비용 또는 리소스 사용량 단위당 비용 등 워크로드와 관련된 비용 메트릭을 식별합니다. 이러한 메트릭은 다양한 크기 조정 옵션의 비용 효율성을 비교하는 데 도움이 됩니다.
사용량 현황 데이터 수집: 워크로드 사용 패턴 및 리소스 사용률을 나타내는 실제 프로덕션 데이터 또는 프록시 데이터를 수집합니다. 이 데이터에는 CPU 사용량, 메모리 사용량, 네트워크 트래픽 및 크기 조정 비용에 영향을 주는 기타 관련 메트릭과 같은 메트릭이 포함되어야 합니다.
비용 메트릭 정의: 시간당 비용, 트랜잭션당 비용 또는 리소스 사용량 단위당 비용 등 워크로드와 관련된 비용 메트릭을 식별합니다. 이러한 메트릭은 다양한 크기 조정 옵션의 비용 효율성을 비교하는 데 도움이 됩니다.
요구 사항 참조: 스케일 아웃 전략과 스케일 업 전략 중에서 결정할 때 워크로드의 안정성, 성능 및 크기 조정 요구 사항을 고려합니다. 스케일 아웃하면 중복성을 통해 안정성이 향상될 수 있습니다. 강화하면 리소스의 용량이 증가하지만 확장할 수 있는 용량에 제한이 있을 수 있습니다.
리소스 제한 고려: 크기 조정 옵션을 평가할 때 모든 인스턴스, 리소스 및 배율 단위 경계의 고유 한도를 고려하는 것이 중요합니다. 각 리소스에 대한 상위 크기 조정 한도에 유의하고 그에 따라 계획을 세워야 합니다. 또한 구독 및 기타 리소스의 제한에 유의하세요.
테스트 크기 조정: 스케일 아웃 및 스케일 업 옵션을 포함하여 다양한 크기 조정 시나리오에 대한 테스트를 만듭니다. 사용량 현황 데이터를 적용하여 다양한 크기 조정 구성에서 워크로드 동작을 시뮬레이션합니다. 모델링된 크기 조정 시나리오를 사용하여 실제 테스트를 수행합니다.
비용 계산: 수집된 데이터 및 비용 메트릭을 사용하여 각 크기 조정 구성과 관련된 비용을 계산합니다. 인스턴스 가격 책정, 리소스 사용률 및 크기 조정과 관련된 추가 비용과 같은 요소를 고려합니다.
자동 크기 조정 최적화
자동 크기 조정 정책을 최적화하려면 워크로드의 비기능적 요구 사항에 따라 부하 변경에 대응하도록 자동 크기 조정을 구체화해야 합니다. 임계값을 조정하고 적절한 쿨다운 기간을 사용하여 과도한 크기 조정 작업을 제한할 수 있습니다. 자동 크기 조정을 최적화하려면 다음 권장 사항을 고려하세요.
현재 자동 크기 조정 정책 분석: 다양한 부하 수준에 대한 응답으로 기존 정책 및 해당 동작을 이해합니다.
비기능 요구 사항 참조: 응답 시간, 리소스 사용률 또는 비용과 같이 고려해야 하는 특정 비기능적 요구 사항을 식별합니다.
크기 조정 임계값 조정: 워크로드 특성 및 비기능 요구 사항에 따라 크기 조정 임계값을 조정합니다. 시간별 CPU 사용률, 네트워크 트래픽 또는 큐 길이와 같은 요인에 따라 확장 또는 축소에 대한 임계값을 설정합니다.
쿨다운 기간 조정: 임시 부하 급증에 의해 트리거되는 과도한 크기 조정 작업을 방지하도록 쿨다운 기간을 조정합니다. 쿨다운 기간에는 크기 조정 이벤트 간에 지연이 발생하므로 추가 크기 조정 작업 전에 시스템이 안정화됩니다.
모니터링 및 미세 조정: 시스템의 동작 및 성능을 지속적으로 모니터링합니다. 크기 조정 작업을 분석하고 필요에 따라 정책을 조정하여 비용을 최적화하고 원하는 비기능적 요구 사항을 충족합니다.
절충: 크기 조정 이벤트 수를 줄이면 크기 조정과 관련된 문제가 발생할 가능성이 높아질 수 있습니다. 이는 잠재적인 문제 또는 크기 조정 지연을 관리하는 데 도움이 될 수 있는 추가 쿠션 또는 버퍼를 제거한다는 것을 의미합니다.
이벤트 기반 크기 조정 사용
이벤트 기반 자동 크기 조정을 사용하면 애플리케이션이 CPU 또는 메모리 사용률과 같은 기존 메트릭이 아닌 특정 이벤트 또는 트리거에 따라 리소스를 동적으로 조정할 수 있습니다. 예를 들어 Kubernetes KEDA(이벤트 기반 자동 크기 조정)는 Kafka 토픽의 길이와 같은 스칼라에 따라 애플리케이션의 크기를 조정할 수 있습니다. 정밀도는 불필요한 크기 조정 변동 및 리소스 낭비를 방지하는 데 도움이 됩니다. 높은 수준의 정밀도는 궁극적으로 비용을 최적화합니다. 이벤트 기반 크기 조정을 사용하려면 다음 단계를 수행합니다.
이벤트 원본 선택: 배율 단위의 크기 조정을 트리거하는 이벤트 원본을 결정합니다. 원본은 메시지 큐, 스트리밍 플랫폼 또는 기타 이벤트 기반 시스템일 수 있습니다.
이벤트 수집 설정: 선택한 이벤트 원본의 이벤트를 사용하도록 애플리케이션을 구성합니다. 일반적으로 연결을 설정하고, 관련 항목 또는 큐를 구독하고, 들어오는 이벤트를 처리하는 작업이 포함됩니다.
크기 조정 논리 구현: 들어오는 이벤트에 따라 배율 단위의 크기를 조정하는 시기와 방법을 결정하는 논리를 작성합니다. 이 논리는 이벤트 수, 들어오는 이벤트 속도 또는 기타 관련 메트릭과 같은 요소를 고려해야 합니다.
크기 조정 메커니즘과 통합: 애플리케이션의 런타임 환경에 따라 다른 크기 조정 메커니즘을 사용하여 애플리케이션에 할당된 리소스를 조정할 수 있습니다.
크기 조정 규칙 구성: 이벤트에 대한 응답으로 배율 단위의 크기를 조정하는 방법을 지정하는 크기 조정 규칙을 정의합니다. 이러한 규칙은 임계값, 패턴 또는 애플리케이션의 요구 사항에 맞는 다른 조건을 기반으로 할 수 있습니다. 크기 조정 임계값은 비즈니스 메트릭과 관련이 있어야 합니다. 예를 들어 인스턴스를 두 개 더 추가하는 경우 장바구니 처리에서 50명의 사용자를 더 지원할 수 있습니다.
테스트 및 모니터링: 다양한 이벤트 시나리오를 사용하여 테스트하여 이벤트 기반 크기 조정 구현의 동작의 유효성을 검사합니다. 크기 조정 작업을 모니터링하고 작업이 예상과 일치하는지 확인합니다.
절충 구성 및 미세 조정 이벤트 기반 자동 크기 조정은 복잡할 수 있으며 부적절한 구성으로 인해 리소스가 과도하게 프로비저닝되거나 프로비저닝이 부족해질 수 있습니다.
수요 및 공급 최적화
공급에 대한 수요를 제어합니다. 사용량에 따라 크기 조정이 결정되는 워크로드에서 비용은 크기 조정과 상관 관계가 있습니다. 크기 조정 비용을 최적화하려면 크기 조정 지출을 최소화할 수 있습니다. 다른 리소스에 수요를 분산하여 수요를 오프로드하거나 우선 순위 큐, 게이트웨이 오프로드, 버퍼링 및 속도 제한을 구현하여 수요를 줄일 수 있습니다. 두 전략 모두 크기 조정 및 리소스 사용으로 인해 원치 않는 비용을 방지할 수 있습니다. 크기 조정 제한을 제한하여 공급을 제어할 수도 있습니다. 워크로드 수요 및 공급을 최적화하려면 다음 권장 사항을 고려하세요.
오프로드 수요
수요 오프로드는 리소스 수요를 다른 리소스 또는 서비스로 분배하거나 이전하는 방법을 의미합니다. 다음과 같은 다양한 기술 또는 전략을 사용할 수 있습니다.
캐싱: 캐싱을 사용하여 자주 액세스하는 데이터 또는 콘텐츠를 저장하여 백 엔드 인프라의 부하를 줄입니다. 예를 들어 CDN(콘텐츠 배달 네트워크)을 사용하여 정적 콘텐츠를 캐시하고 제공하므로 백 엔드 크기를 조정하지 않아도 됩니다. 그러나 모든 워크로드가 데이터를 캐시할 수 있는 것은 아닙니다. 거래 또는 게임 워크로드와 같은 최신 및 실시간 데이터가 필요한 워크로드는 캐시를 사용하면 안 됩니다. 캐시된 데이터는 오래되었으며 사용자와 관련이 없습니다.
절충. 캐싱은 캐시 무효화, 일관성 및 캐시 만료 관리 측면에서 문제가 발생할 수 있습니다. 잠재적인 절충을 방지하기 위해 캐싱 전략을 신중하게 디자인하고 구현하는 것이 중요합니다.
콘텐츠 오프로드: 인프라의 워크로드를 줄이기 위해 외부 서비스 또는 플랫폼에 콘텐츠를 오프로드합니다. 예를 들어 주 서버에 비디오 파일을 저장하는 대신 주 서버와 독립적인 별도의 스토리지 서비스에 이러한 파일을 호스트할 수 있습니다. 스토리지 서비스에서 직접 이러한 대용량 파일을 로드할 수 있습니다. 이 방법을 사용하면 서버의 리소스를 확보하여 더 작은 서버를 사용할 수 있습니다. 대용량 파일을 별도의 데이터 저장소에 저장하는 것이 더 저렴할 수 있습니다. CDN을 사용하여 성능을 향상시킬 수 있습니다.
부하 분산: 부하 분산을 사용하여 들어오는 요청을 여러 서버에 분산합니다. 부하 분산은 워크로드를 균등하게 분산하고 단일 서버가 과부하되는 것을 방지합니다. 부하 분산 장치는 리소스 사용률을 최적화하고 인프라의 효율성을 향상시킵니다.
데이터베이스 오프로드: 데이터베이스 작업을 별도의 데이터베이스 서버 또는 특수 서비스로 오프로드하여 주 애플리케이션 서버의 부하를 줄입니다. 예를 들어 정적 콘텐츠 캐싱에 CDN을 사용하고 동적 콘텐츠(데이터베이스의 데이터) 캐싱에 Redis 캐시를 사용합니다. 데이터베이스 분할, 읽기 복제본 또는 관리되는 데이터베이스 서비스를 사용하는 등의 기술도 부하를 줄일 수 있습니다.
절충: 특정 작업을 대체 리소스로 오프로드하면 크기 조정과 관련된 추가 크기 조정 및 비용을 줄이거나 방지하는 데 도움이 됩니다. 그러나 오프로드에서 발생할 수 있는 운영 및 유지 관리 문제를 고려하는 것이 중요합니다. 워크로드에 가장 적합한 오프로드 기술을 선택할 때 포괄적인 비용 혜택 분석을 수행하는 것이 중요합니다. 이 분석을 통해 예상되는 절감 및 운영 복잡성과 관련하여 선택한 방법이 효율적이고 실현 가능합니다.
수요 감소
리소스 수요를 줄이는 것은 워크로드에서 리소스 사용률을 최소화하는 데 도움이 되는 전략을 구현하는 것을 의미합니다. 수요를 오프로드하면 수요가 다른 리소스로 이동됩니다. 수요를 줄이면 워크로드에 대한 수요가 감소합니다. 수요를 줄이면 리소스의 오버프로비전을 방지하고 사용되지 않는 용량에 대한 비용 지출을 피할 수 있습니다. 코드 수준 디자인 패턴을 사용하여 워크로드 리소스에 대한 수요를 줄여야 합니다. 디자인 패턴을 통해 수요를 줄이려면 다음 단계를 수행합니다.
디자인 패턴 이해: 리소스 최적화를 촉진하는 다양한 디자인 패턴을 숙지합니다.
워크로드 요구 사항 분석: 예상 수요 패턴, 최대 부하 및 리소스 요구 사항을 포함하여 워크로드의 특정 요구 사항을 평가합니다.
적절한 디자인 패턴 선택: 워크로드의 요구 사항 및 목표에 맞는 디자인 패턴을 선택합니다. 예를 들어 워크로드가 수요 변동을 경험하는 경우 이벤트 기반 크기 조정 및 제한 패턴은 리소스를 동적으로 할당하여 워크로드를 관리하는 데 도움이 될 수 있습니다. 선택한 디자인 패턴을 워크로드 아키텍처에 적용합니다. 워크로드 구성 요소를 분리하고, 애플리케이션을 컨테이너화하고, 스토리지 사용률을 최적화하는 등의 작업을 수행해야 할 수 있습니다.
지속적인 모니터링 및 최적화: 구현된 디자인 패턴의 효과를 정기적으로 평가하고 필요에 따라 조정합니다. 리소스 사용량, 성능 메트릭 및 비용 최적화 기회를 모니터링합니다.
이러한 단계를 수행하고 적절한 디자인 패턴을 사용하여 리소스 수요를 줄이고, 비용을 최적화하고, 워크로드의 효율적인 운영을 보장할 수 있습니다.
다음 디자인 패턴을 사용하여 수요를 줄입니다.
캐시 제외: 패턴은 캐시를 검사하여 데이터가 이미 메모리에 저장되어 있는지 확인합니다. 캐시에 데이터가 있으면 애플리케이션에서 데이터를 신속하게 검색하고 반환하여 영구 데이터 저장소를 쿼리할 필요가 줄어듭니다.
클레임 검사: 이 패턴은 메시징 흐름에서 데이터를 분리하여 메시지의 크기를 줄이고 보다 비용 효율적인 메시징 솔루션을 지원합니다.
경쟁 소비자: 이 패턴은 분산 및 동시 처리를 적용하여 큐의 항목을 효율적으로 처리합니다. 이 디자인 패턴은 큐 깊이를 기반으로 크기를 조정하고 최대 동시 소비자 인스턴스에 대한 제한을 설정하여 비용을 최적화합니다.
컴퓨팅 리소스 통합: 이 패턴은 공유 인프라에서 여러 애플리케이션 또는 구성 요소를 결합하여 밀도를 높이고 컴퓨팅 리소스를 통합합니다. 리소스 사용률을 최대화하여 사용하지 않는 프로비전된 용량을 방지하고 비용을 절감합니다.
배포 스탬프: 배포 스탬프를 사용하면 디바이스 그룹 지역 배포, 특정 스탬프에 새 기능 배포, 디바이스당 비용 관찰 등 여러 가지 이점이 있습니다. 배포 스탬프를 사용하면 확장성, 내결함성 및 효율적인 리소스 사용률을 높일 수 있습니다.
게이트웨이 오프로드: 이 패턴은 게이트웨이 디바이스에서 요청 처리를 오프로드하여 노드별 리소스에서 게이트웨이 구현으로 비용을 리디렉션합니다. 이 디자인 패턴을 사용하면 중앙 집중식 처리 모델에서 소유 비용이 낮아질 수 있습니다.
게시자/구독자: 이 패턴은 아키텍처의 구성 요소를 분리하여 직접 통신을 중간 메시지 브로커 또는 이벤트 버스로 대체합니다. 이를 통해 이벤트 기반 접근 방식과 소비 기반 청구를 통해 과잉 프로비전을 방지할 수 있습니다.
큐 기반 부하 평준화: 패턴은 큐에서 들어오는 요청 또는 작업을 버퍼링합니다. 버퍼링은 워크로드를 원활하게 처리하고 최대 부하를 처리하기 위해 리소스를 과도하게 프로비전할 필요성을 줄입니다. 들어오는 요청은 비용을 줄이기 위해 비동기적으로 처리됩니다.
분할: 이 패턴은 특정 요청을 논리 대상으로 전달하여 데이터 공동 배치를 사용하여 최적화할 수 있도록 합니다. 분할은 낮은 사양 컴퓨팅 또는 스토리지 리소스의 여러 인스턴스를 사용하여 비용을 절감할 수 있습니다.
정적 콘텐츠 호스팅: 이 패턴은 이 목적을 위해 설계된 호스팅 플랫폼을 사용하여 정적 콘텐츠를 효율적으로 제공합니다. 더 비싼 동적 애플리케이션 호스트를 사용하지 않도록 하여 리소스 사용률을 최적화합니다.
제한: 이 패턴은 리소스 또는 구성 요소에 들어오는 요청의 속도(속도 제한) 또는 처리량에 제한을 줍니다. 비용 모델링을 알리는 데 도움이 되며 애플리케이션의 비즈니스 모델에 직접 연결할 수 있습니다.
발렛 키: 이 패턴은 더 많은 구성 요소를 포함하지 않고 리소스에 대한 안전하고 독점적인 액세스를 부여하여 중간 리소스의 필요성을 줄이고 효율성을 개선합니다.
제어 공급
특정 리소스 또는 서비스에 지출하려는 금액에 대한 상한을 정의하는 것은 공급을 제어하는 한 가지 방법입니다. 비용을 제어하고 비용이 특정 수준을 초과하지 않도록 하기 위한 중요한 전략입니다. 예산을 설정하고 지출을 모니터링하여 정의된 금액 내에 유지되도록 합니다. 비용 관리 플랫폼, 예산 경고 또는 사용량 및 지출 패턴 추적을 사용할 수 있습니다. 일부 서비스를 사용하면 공급을 제한하고 요금을 제한할 수 있으며 도움이 되는 경우 이러한 기능을 사용해야 합니다.
공급 제어는 특정 리소스 또는 서비스에 지출하는 금액에 상한선을 정하는 것을 의미합니다. 이는 비용을 제어하고 비용이 일정 수준을 초과하지 않도록 돕는 중요한 전략입니다. 예산을 설정하고 지출을 모니터링하여 정의된 임계값 내에 유지되도록 합니다. 비용 관리 플랫폼, 예산 경고 또는 사용량 및 지출 패턴 추적을 사용할 수 있습니다. 일부 서비스를 사용하면 공급을 제한하고 요금을 제한할 수 있으며 도움이 되는 경우 이러한 기능을 사용해야 합니다.
절충: 더 엄격한 제한으로 인해 수요가 증가할 때 확장할 기회가 누락되어 사용자 환경에 영향을 미칠 수 있습니다. 종료가 발생하거나 부하에 응답하지 못할 수 있습니다. 비용 최적화와 비즈니스 요구 사항을 충족하기에 충분한 리소스가 있는지 확인하는 것 사이의 균형을 맞추는 것이 중요합니다.
Azure 촉진
스케일 아웃 및 스케일 업 평가: Azure는 다양한 크기 조정 구성을 배포하고 테스트할 수 있는 테스트 환경을 제공합니다. 실제 워크로드 데이터 또는 프록시 데이터를 사용하여 실제 시나리오를 시뮬레이션하고 비용에 미치는 영향을 측정할 수 있습니다. Azure는 성능 테스트, 부하 테스트 및 모니터링을 위한 도구와 서비스를 제공하므로 스케일 아웃 및 스케일 업 옵션의 비용 효율성을 평가하는 데 도움이 될 수 있습니다.
Azure는 Azure Advisor와 같은 다양한 도구 및 서비스를 통해 비용 관리 권장 사항을 제공합니다. 이러한 권장 사항은 사용 패턴, 리소스 사용률 및 크기 조정 구성을 분석하여 비용 최적화를 위한 인사이트와 제안을 제공합니다.
Azure Load Testing 은 대규모 부하를 생성하는 완전 관리형 부하 테스트 서비스입니다. 애플리케이션이 호스트되는 위치에 관계없이 이 서비스는 애플리케이션에 대한 트래픽을 시뮬레이션합니다. 개발자, 테스터 및 QA(품질 보증) 엔지니어는 부하 테스트를 사용하여 애플리케이션 성능, 확장성 또는 용량을 최적화할 수 있습니다.
자동 크기 조정 최적화: 많은 Azure 컴퓨팅 서비스는 여러 동일한 인스턴스를 배포하고 크기 조정 임계값 및 정책을 신속하게 조정하는 것을 지원합니다. Azure는 워크로드 수요에 따라 인스턴스 또는 리소스 수를 자동으로 조정할 수 있는 자동 크기 조정 기능을 제공합니다. 스케일 아웃 또는 스케일 인 작업을 트리거하는 크기 조정 규칙 및 임계값을 정의할 수 있습니다. 자동 크기 조정을 사용하면 실제 수요에 따라 리소스를 동적으로 크기 조정하여 리소스 할당 및 비용 효율성을 최적화할 수 있습니다.
Azure는 구독 및 서비스 제한 목록을 유지 관리합니다. 일부 예외를 제외하고 각 리소스 그룹에 배포할 수 있는 리소스 인스턴스 수에는 일반적인 제한이 있습니다. 자세한 내용은 리소스 그룹당 리소스 인스턴스 제한을 참조 하세요.
수요 및 공급 최적화: Azure Monitor는 애플리케이션 및 인프라의 성능 및 상태에 대한 인사이트를 제공합니다. Azure Monitor를 사용하여 리소스의 부하를 모니터링하고 시간에 따른 추세를 분석할 수 있습니다. Azure Monitor에서 수집한 메트릭 및 로그를 사용하여 크기 조정이 필요할 수 있는 영역을 식별할 수 있습니다. 이 정보는 자동 크기 조정 정책의 구체화를 안내하여 비기능 요구 사항 및 비용 최적화 목표에 부합하도록 할 수 있습니다.
공급 오프로드: Azure에는 Azure Front Door 및 캐싱 서비스(Azure Cache for Redis 및 Azure HPC Cache)라는 최신 클라우드 CDN(Content Delivery Network)이 있습니다. CDN은 최종 사용자에게 더 가까운 콘텐츠를 캐시하여 네트워크 대기 시간을 줄이고 응답 시간을 개선합니다. 캐싱은 기본 데이터 저장소 앞에 데이터 복사본을 저장하므로 백 엔드에 대한 반복 요청이 필요하지 않습니다. CDN 및 캐싱 서비스를 사용하면 성능을 최적화하고 서버의 부하를 줄여 비용을 절감할 수 있습니다.
공급 제어: Azure를 사용하면 클라우드 워크로드에 대한 리소스 제한을 설정할 수도 있습니다. 리소스 제한을 정의하여 워크로드가 할당된 리소스 내에 유지되도록 하고 불필요한 비용을 방지할 수 있습니다. Azure는 할당량, 정책 및 예산 경고와 같은 리소스 제한을 설정하기 위한 다양한 메커니즘을 제공합니다. 이러한 메커니즘은 리소스 사용량을 모니터링하고 제어하는 데 도움이 됩니다.
API Management 는 제한을 평가하고 요청을 제한할 수 있습니다. 들어오는 요청을 제한하는 것은 Azure API Management의 중요한 역할입니다. Azure API Management는 요청 속도 또는 전송된 총 요청/데이터를 제어하여 API 공급자가 자신의 API가 남용되지 않도록 보호하고 다양한 API 제품 계층에 대해 가치를 창출할 수 있도록 합니다.
관련 링크
- 워크로드 크기 조정
- Azure Advisor 비용 권장 사항
- Azure Load Testing이란?
- Azure 구독 및 서비스 제한, 할당량 및 제약 조건
- 리소스 그룹당 800개의 인스턴스로 제한되지 않는 리소스
- Azure Front Door란?
- Azure Cache for Redis란?
- Azure HPC Cache란?
- Azure API Management로 고급 요청 제한
비용 최적화 검사 목록
전체 권장 사항 집합을 참조하세요.