크기 조정 및 분할 최적화를 위한 권장 사항
이 Azure Well-Architected Framework 성능 효율성 검사 목록 권장 사항에 적용됩니다.
| PE:05 | 크기 조정 및 분할을 최적화합니다. 안정적이고 제어된 크기 조정 및 분할을 통합합니다. 워크로드의 배율 단위 디자인은 크기 조정 및 분할 전략의 기초입니다. |
|---|
이 가이드에서는 워크로드 크기 조정 및 분할에 대한 권장 사항을 설명합니다. 크기 조정은 수요에 따라 워크로드에 할당된 리소스를 늘리거나 줄이는 기능입니다. 분할에는 워크로드를 더 작고 관리 가능한 단위로 나누어 데이터를 여러 리소스에 분산하고 처리하는 작업이 포함됩니다. 스케일링 또는 파티션이 없는 워크로드는 수요가 많은 기간에 성능이 저하되고 수요가 적은 기간에는 사용량이 부족할 수 있습니다.
정의
| 용어 | 정의 |
|---|---|
| 자동 크기 조정 | 미리 정의된 구성에 따라 서비스의 용량 제한을 자동으로 조정하여 필요에 따라 확장 또는 축소할 수 있도록 하는 기능입니다. |
| 용량 | 지정된 서비스 또는 기능의 상한 또는 최대 용량입니다. |
| 클라이언트 선호도(세션 선호도) | 단일 클라이언트에서 단일 서버로의 요청의 의도적인 라우팅은 일관된 세션 관리를 보장하기 위해 instance. |
| 일관성(분산 데이터베이스) | 분산 데이터베이스의 여러 노드에서 데이터의 균일성을 통해 모든 복제본이 지정된 시점에 동일한 데이터를 갖도록 합니다. |
| 일관성(관계형 데이터베이스) | 데이터베이스를 유효한 상태에서 다른 상태로 가져와 데이터 무결성을 유지하는 트랜잭션의 속성입니다. |
| 일관성 수준 | 분산 데이터베이스 시스템에서 데이터가 복제되는 방법과 시기를 정의하여 일관성과 성능 간의 절충을 결정하는 구성입니다. |
| 데이터 잠금 | 동일한 데이터에 대한 동시 업데이트를 방지하는 데 사용되는 메커니즘입니다. |
| 수평 크기 조정 | 지정된 유형의 리소스 인스턴스를 추가하는 크기 조정 접근 방식입니다. |
| 낙관적 동시성 | 기존 잠금 메커니즘 대신 스냅샷을 사용하여 업데이트를 만드는 데이터베이스를 업데이트하는 방법입니다. |
| 분할 | 데이터를 별도의 데이터 저장소로 물리적으로 나누는 프로세스입니다. |
| 확장성 | 다양한 수준의 수요를 수용하기 위해 용량 제한을 동적으로 변경하는 워크로드의 기능입니다. |
| 배율 단위 | 비례적으로 함께 스케일링되는 리소스 그룹입니다. |
| 상태 선호도 | 동일한 서버가 동일한 클라이언트의 후속 요청을 처리할 수 있도록 단일 서버에 클라이언트 세션 데이터의 스토리지입니다. |
| 수직 크기 조정 | 기존 리소스에 컴퓨팅 용량을 추가하는 크기 조정 접근 방식입니다. |
주요 디자인 전략
크기 조정 및 분할은 모두 리소스가 효과적으로 사용되고 워크로드가 다양한 부하를 처리할 수 있도록 하여 성능 효율성에 기여합니다. 이러한 사례는 애플리케이션이 변화하는 요구에 유연하고 적응력이 있어야 하는 클라우드 환경에서 특히 중요합니다. 크기를 조정하면 증가하는 요구에 맞게 워크로드 용량을 확장할 수 있습니다. 분할을 사용하면 이러한 증가하는 요구 사항을 처리하기 위해 작업 또는 데이터를 효율적으로 나눌 수 있습니다. 이러한 두 프로세스의 기초는 워크로드의 배율 단위 디자인입니다. 워크로드가 작업을 확장하고 배포하는 방법을 결정합니다. 크기 조정 및 분할에 안정적이고 제어된 접근 방식을 통합하면 잠재적인 워크로드 비효율성을 제거할 수 있습니다.
크기 조정 최적화
크기 조정 최적화는 워크로드의 변동 요구를 충족하도록 서버, 인스턴스 또는 리소스 수를 조정하는 프로세스입니다. 성능 저하 또는 가동 중지 시간을 경험하지 않고 워크로드가 증가된 트래픽 또는 요구를 처리할 수 있도록 합니다.
크기 조정 전략 선택
크기 조정 전략을 선택하려면 특정 요구 사항에 따라 워크로드의 용량을 향상시키기 위해 수직 또는 수평 방법 중에서 결정해야 합니다. 올바른 전략을 선택하면 과용이나 낭비 없이 워크로드 요구를 충족하도록 리소스를 효율적으로 조정할 수 있습니다. 올바른 크기 조정 전략을 선택하려면 수직 및 수평 크기 조정의 사용 사례와 워크로드의 요구 사항을 충족하는 방법을 이해해야 합니다.
수직 크기 조정을 이해합니다. 수직 크기 조정을 사용하면 더 큰 서버 또는 instance 크기로 업그레이드하는 등 단일 리소스의 용량을 늘릴 수 있습니다. 수직 크기 조정은 워크로드가 단일 instance 내의 향상된 처리 능력, 메모리 또는 기타 리소스를 활용할 수 있는 경우에 유용합니다. 수직 크기 조정은 더 작은 부분으로 쉽게 구분되지 않거나 애플리케이션 아키텍처가 수평 크기 조정을 지원하지 않는 워크로드에 적합합니다.
수평 크기 조정을 이해합니다. 수평 크기 조정을 사용하여 더 많은 인스턴스 또는 리소스를 추가하여 여러 서버에 워크로드를 분산할 수 있습니다. 수평 크기 조정은 향상된 복원력, 용량 증가 및 증가된 트래픽 또는 워크로드 요구를 처리하는 기능과 같은 이점을 제공합니다. 여러 노드에서 실행되도록 설계된 클라우드 네이티브 애플리케이션에 효과적입니다. 수평적 크기 조정은 독립적으로 실행되는 더 작은 부분으로 나눌 수 있는 워크로드에 적합합니다.
워크로드를 이해합니다. 수직 또는 수평 크기 조정의 적합성은 워크로드의 특정 특성 및 요구 사항에 따라 달라집니다. 다음 영역에서 정기적인 성능 모니터링 및 테스트는 시간이 지남에 따라 크기 조정 전략을 최적화하는 데 도움이 될 수 있습니다.
요구 사항: 리소스 요구 사항, 확장성 요구 사항 및 워크로드의 제한 사항과 같은 요소를 고려하여 워크로드의 특정 요구 사항을 이해합니다.
배율 단위: 함께 확장될 것으로 예상되는 구성 요소에 대한 배율 단위 디자인을 만듭니다. 예를 들어 100개의 가상 머신은 추가 워크로드를 처리하기 위해 큐 2개와 스토리지 계정 3개가 필요할 수 있습니다. 배율 단위는 100개의 가상 머신, 2개의 큐 및 3개의 스토리지 계정입니다. 용량 사용 변동이 발생하는 모든 구성 요소를 독립적으로 확장해야 합니다.
아키텍처: 애플리케이션 아키텍처의 디자인을 평가합니다. 일부 애플리케이션은 기본적으로 여러 인스턴스에 쉽게 배포할 수 있는 상태 비정상 구성 요소를 사용하여 수평적으로 확장하도록 설계될 수 있습니다. 다른 애플리케이션에는 수직 크기 조정을 보다 적절하게 만드는 상태 저장 구성 요소 또는 종속성이 있을 수 있습니다. 워크로드의 확장성 및 탄력성 요구 사항을 평가합니다.
크기를 조정할 인프라 설계
확장할 인프라 설계는 필요에 따라 리소스를 추가하거나 조정하여 증가하는 요구 및 워크로드를 처리할 수 있는 아키텍처를 만드는 프로세스입니다. 성장을 수용하기 위해 가로 또는 세로로 확장할 수 있는 솔루션을 계획하고 구현하는 작업이 포함됩니다. 전략에는 병목 상태가 될 수 있는 싱글톤을 방지하고 독립적인 확장성을 보장하기 위해 애플리케이션 구성 요소를 분리하는 것이 포함됩니다. 워크로드를 확장 가능하도록 디자인할 때 여러 리소스에 워크로드를 효과적으로 분산하여 병목 현상을 방지하고 리소스 사용률을 최대화할 수 있습니다.
싱글톤을 사용하지 마세요. 전체 워크로드에 중앙 집중식 단일 리소스를 사용하지 않아야 합니다. 대신 확장성, 내결함성 및 성능을 향상하기 위해 여러 리소스에 워크로드를 분산합니다. 워크로드 리소스에서 싱글톤을 방지하려면 몇 가지 특정 예제 및 디자인 고려 사항을 살펴봅니다.
큐 기반 부하 평준화: 단일 큐를 사용하여 메시지를 처리하는 대신 여러 큐에 워크로드를 분할하여 처리 부하를 분산하는 것이 좋습니다. 더 나은 확장성 및 병렬 처리를 제공합니다.
데이터 처리: 싱글톤 패턴은 처리가 팬아웃되지 않는 데이터 처리 시나리오에 나타나는 경우가 많습니다. 장기 실행 작업을 더 작은 작업으로 분할하여 여러 리소스에 워크로드를 분산하고 병렬 처리를 활용할 수 있습니다.
디자인 패턴: 팬아웃/팬인 또는파이프 및 필터와 같은 디자인 패턴은 워크플로에서 싱글톤을 방지하는 데 도움이 될 수 있습니다. 이러한 패턴을 사용하면 여러 리소스에서 처리 작업을 배포하고 확장성과 유연성을 촉진할 수 있습니다.
구성 요소를 분리합니다. 애플리케이션 구성 요소를 분리하는 것은 확장성을 위한 디자인의 중요한 측면입니다. 애플리케이션을 특정 워크로드 요구 사항에 따라 독립적으로 작동하고 확장할 수 있는 더 작고 독립적인 구성 요소로 분할하는 작업이 포함됩니다. 예를 들어 수요 증가로 인해 한 구성 요소에 더 많은 리소스가 필요한 경우 다른 구성 요소에 영향을 주지 않고 해당 구성 요소를 확장할 수 있습니다. 이러한 유연성은 효율적인 리소스 할당을 보장하고 병목 상태를 방지합니다. 구성 요소를 분리하여 오류를 격리하고 전체 애플리케이션에 미치는 영향을 최소화할 수 있습니다. 한 구성 요소가 실패하면 다른 구성 요소는 독립적으로 계속 작동할 수 있습니다.
분리된 구성 요소는 유지 관리 및 업데이트가 더 쉽습니다. 한 구성 요소에 대한 변경 또는 업데이트는 독립적이므로 다른 구성 요소에 영향을 주지 않고 수행할 수 있습니다. 확장성을 위해 애플리케이션 구성 요소를 분리하려면 다음 지침을 따릅니다.
문제 분리: 애플리케이션의 책임과 기능을 식별합니다. 책임을 특정 작업에 따라 별도의 구성 요소로 나눕니다. 예를 들어 사용자 인증, 데이터 처리 및 UI에 대한 별도의 구성 요소가 있을 수 있습니다.
느슨한 결합: 잘 정의된 인터페이스 및 프로토콜을 통해 서로 통신하도록 구성 요소를 디자인합니다. 이 디자인은 구성 요소 간의 종속성을 줄이고 개별 구성 요소를 더 쉽게 교체하거나 스케일링할 수 있도록 합니다.
비동기 통신: 메시지 큐 또는 이벤트 기반 아키텍처와 같은 비동기 통신 패턴을 사용하여 구성 요소를 추가로 분리합니다. 이러한 패턴을 사용하면 구성 요소가 고유한 속도로 독립적으로 작업을 처리하여 전반적인 확장성을 향상시킬 수 있습니다.
마이크로 서비스: 특정 비즈니스 기능에 중점을 둔 소규모 독립 서비스인 마이크로 서비스를 구현하는 것이 좋습니다. 각 마이크로 서비스를 독립적으로 개발, 배포 및 확장할 수 있으므로 유연성과 확장성이 향상됩니다.
크기를 조정할 애플리케이션 설계
워크로드를 확장할 때 부하를 분산하도록 애플리케이션을 디자인해야 합니다. 인프라 수준에서 더 많은 복제본을 추가할 수 있다고 해서 애플리케이션에서 복제본을 사용할 수 있는 것은 아닙니다. 크기를 조정하도록 애플리케이션을 설계하는 것은 애플리케이션을 구조화하여 리소스 간에 워크로드를 분산하여 증가하는 요구를 처리할 수 있도록 하는 것입니다. 가능한 경우 단일 instance 클라이언트 선호도, 데이터 잠금 또는 상태 선호도가 필요한 솔루션을 사용하지 마세요. 클라이언트 또는 프로세스를 사용 가능한 용량이 있는 리소스로 라우팅하려고 합니다. 애플리케이션 확장성을 위해 설계하려면 다음 전략을 고려합니다.
서버 쪽 세션 상태를 제거합니다. 가능한 경우 애플리케이션을 상태 비스테이션으로 디자인해야 합니다. 상태 저장 애플리케이션의 경우 서버 외부에 있는 상태 저장소를 사용해야 합니다. 세션 상태를 외부화하는 것은 애플리케이션 서버 또는 컨테이너 외부에 세션 데이터를 저장하는 방법입니다. 세션 상태를 외부화하여 여러 서버 또는 서비스에 세션 데이터를 배포하여 분산 환경에서 원활한 세션 관리를 가능하게 할 수 있습니다. 세션 상태를 외부화할 때 다음을 고려합니다.
세션 요구 사항을 평가합니다. 저장 및 관리해야 하는 세션 데이터를 이해합니다. 세션 특성, 세션 시간 제한 및 세션 복제 또는 지속성에 대한 특정 요구 사항을 고려합니다. 세션 상태의 크기와 읽기 및 쓰기 작업의 빈도를 결정합니다.
솔루션을 선택합니다. 성능 및 확장성 요구 사항에 맞는 스토리지 솔루션을 선택합니다. 옵션에는 분산 캐시, 데이터베이스 또는 세션 상태 서비스 사용이 포함됩니다. 선택할 때 데이터 일관성, 대기 시간 및 확장성과 같은 요소를 고려합니다.
애플리케이션 설치 선택한 세션 상태 스토리지 솔루션을 사용하도록 애플리케이션을 업데이트합니다. 외부 스토리지 서비스에 연결하려면 애플리케이션의 구성 파일 또는 코드를 변경해야 할 수 있습니다.
논리를 업데이트합니다. 외부 스토리지 솔루션에서 세션 데이터를 저장하고 검색하도록 애플리케이션의 세션 관리 논리를 변경합니다. 스토리지 솔루션에서 제공하는 API 또는 라이브러리를 사용하여 세션 상태를 관리해야 할 수 있습니다.
클라이언트 선호도를 제거합니다. 클라이언트 선호도를 세션 선호도 또는 고정 세션이라고도 합니다. 클라이언트 선호도를 제거하면 클라이언트의 모든 요청을 동일한 복제본(replica) 라우팅하지 않고 여러 복제본 또는 서버에 클라이언트 요청을 균등하게 분산합니다. 이 구성은 사용 가능한 모든 복제본(replica) 요청을 처리할 수 있도록 하여 애플리케이션의 확장성 및 성능을 향상시킬 수 있습니다.
부하 분산 알고리즘을 검토합니다. 부하 분산 알고리즘은 너무 많은 요청이 하나의 백 엔드 instance 전송되는 의도하지 않은 인공 클라이언트 고정을 일으킬 수 있습니다. 고정은 알고리즘이 항상 동일한 사용자의 요청을 동일한 instance 보내도록 설정된 경우에 발생할 수 있습니다. 요청이 서로 너무 유사한 경우에도 발생할 수 있습니다.
데이터 잠금을 제거합니다. 데이터 잠금은 일관성을 보장하지만 성능에 단점이 있습니다. 잠금 에스컬레이션이 발생하고 동시성, 대기 시간 및 가용성에 부정적인 영향을 줄 수 있습니다. 데이터 잠금을 제거하려면 낙관적 동시성을 구현해야 합니다. 비관계 데이터베이스는 낙관적 동시성 제어 를 사용하고 올바른 일관성 수준을 가져야 합니다. 데이터 분할 전략도 동시성 요구 사항을 지원해야 합니다.
동적 서비스 검색을 사용합니다. 동적 서비스 검색은 분산 시스템에서 서비스를 자동으로 검색하고 등록하는 프로세스입니다. 이를 통해 클라이언트는 특정 인스턴스와 긴밀하게 결합되지 않고 사용 가능한 서비스를 검색할 수 있습니다. 클라이언트는 워크로드의 특정 instance 직접 종속성을 사용할 수 없습니다. 이러한 종속성을 방지하려면 프록시를 사용하여 클라이언트 연결을 배포하고 재배포해야 합니다. 프록시는 클라이언트와 서비스 간의 중개자 역할을 하며 클라이언트에 영향을 주지 않고 서비스를 추가하거나 제거할 수 있는 추상화 계층을 제공합니다.
백그라운드 작업을 사용합니다. 애플리케이션의 크기를 조정하면 증가하는 워크로드 또는 더 많은 수의 동시 요청을 처리할 수 있습니다. 백그라운드 작업으로 집약적인 작업을 오프로드하면 기본 애플리케이션이 리소스를 많이 사용하는 작업 없이 사용자 요청을 처리할 수 있습니다. 다음 단계에 따라 작업을 백그라운드 작업으로 오프로드합니다.
오프로드할 수 있는 애플리케이션에서 CPU 집약적 및 I/O 집약적 작업을 찾습니다. 이러한 작업에는 일반적으로 데이터베이스 또는 네트워크 작업과 같은 외부 리소스와의 과도한 계산 또는 상호 작용이 포함됩니다.
백그라운드 작업을 지원하도록 애플리케이션을 디자인합니다. 기본 애플리케이션 논리에서 집약적인 작업을 분리하고 백그라운드 작업을 시작하고 관리하는 메커니즘을 제공합니다.
적절한 기술 또는 프레임워크를 사용하여 백그라운드 작업 처리를 구현합니다. 비동기 프로그래밍, 스레딩 또는 작업 큐와 같은 프로그래밍 언어 또는 플랫폼에서 제공하는 기능을 포함합니다. 별도의 작업 또는 스레드에서 집중적인 작업을 포함하며, 이러한 작업은 동시에 실행되거나 특정 간격으로 실행되도록 예약할 수 있습니다.
백그라운드 작업이 많거나 작업에 상당한 시간 또는 리소스가 필요한 경우 백그라운드 작업을 배포합니다. 한 가지 가능한 솔루션에 대해서는 경쟁 소비자 패턴을 참조하세요.
크기 조정 구성
크기 조정 구성은 워크로드 요구에 따라 리소스를 동적으로 할당하도록 매개 변수를 설정하고 조정하는 프로세스입니다. 여기에는 자동 크기 조정 기능 사용, 서비스 크기 조정 경계 이해 및 의미 있는 부하 메트릭 구현과 같은 전략이 포함됩니다. 적절한 구성은 애플리케이션이 효율성을 극대화하면서 다양한 요구에 대응할 수 있도록 합니다. 크기 조정을 구성할 때 다음 전략을 고려합니다.
자동 크기 조정과 함께 서비스를 사용합니다. 자동 크기 조정 기능은 수요에 맞게 인프라를 자동으로 스케일링합니다. 기본 제공 자동 크기 조정 기능을 사용하여 PaaS(Platform as a Service) 제품을 사용합니다. PaaS의 크기 조정이 용이성이 주요 이점입니다. 예를 들어 가상 머신을 스케일 아웃하려면 별도의 부하 분산 장치, 클라이언트 요청 처리 및 외부에 저장된 상태가 필요합니다. PaaS 제품은 이러한 작업의 대부분을 처리합니다.
자동 크기 조정을 제한합니다. 자동 크기 조정 제한을 설정하여 불필요한 비용을 초래할 수 있는 과잉 스케일링을 최소화합니다. 경우에 따라 크기 조정 제한을 설정할 수 없습니다. 이러한 경우 구성 요소가 최대 크기 제한에 도달하고 확장이 초과된 경우 알림을 표시하도록 경고를 설정해야 합니다.
서비스 크기 조정 경계를 이해합니다. 서비스 크기 조정 제한, 증가 및 제한을 이해하는 경우 서비스를 선택할 때 정보에 입각한 결정을 내릴 수 있습니다. 경계 크기 조정은 선택한 서비스가 예상 워크로드를 처리하고, 효율적으로 스케일링하고, 애플리케이션의 성능 요구 사항을 충족할 수 있는지 여부를 결정합니다. 고려할 경계 크기 조정은 다음과 같습니다.
크기 조정 제한: 크기 조정 제한은 위치 또는 서비스에서 처리할 수 있는 최대 용량입니다. 서비스가 예상 워크로드를 수용하고 성능 저하 없이 최대 사용량을 처리할 수 있도록 하기 위해 이러한 제한을 알고 있는 것이 중요합니다. 모든 리소스에는 상한이 있습니다. 확장 제한을 초과해야 하는 경우 워크로드를 분할해야 합니다.
크기 조정 증분: 정의된 증분에서 서비스 크기 조정 예를 들어 컴퓨팅 서비스는 인스턴스 및 Pod별로 확장될 수 있지만 데이터베이스는 인스턴스, 트랜잭션 단위 및 가상 코어별로 확장될 수 있습니다. 리소스 할당을 최적화하고 리소스 플래핑을 방지하려면 이러한 증분을 이해하는 것이 중요합니다.
크기 조정 제한: 일부 서비스를 사용하면 스케일 업 또는 스케일 아웃할 수 있지만 크기 조정을 자동으로 역방향으로 설정하는 기능을 제한할 수 있습니다. 수동으로 스케일 인해야 하거나 새 리소스를 다시 배포해야 할 수 있습니다. 이러한 제한 사항은 워크로드를 보호하기 위한 경우가 많습니다. 스케일 다운 또는 스케일 인은 워크로드의 가용성 및 성능에 영향을 미칠 수 있습니다. 서비스는 워크로드에 효과적으로 작동할 수 있는 충분한 리소스가 있는지 확인하기 위해 특정 제한 사항 또는 제약 조건을 적용할 수 있습니다. 이러한 제한 사항은 특히 분산 시스템에서 데이터 일관성 및 동기화에 영향을 줄 수 있습니다. 서비스에는 스케일 업 또는 스케일 아웃 중에 데이터 복제 및 일관성을 처리하는 메커니즘이 있을 수 있지만 축소 또는 축소에 대해 동일한 수준의 지원을 제공하지 않을 수 있습니다.
의미 있는 로드 메트릭을 사용합니다. 크기 조정은 의미 있는 로드 메트릭을 크기 조정 트리거로 사용해야 합니다. 의미 있는 로드 메트릭에는 CPU 또는 메모리와 같은 간단한 메트릭이 포함됩니다. 또한 큐 깊이, SQL 쿼리, 사용자 지정 메트릭 쿼리 및 HTTP 큐 길이와 같은 고급 메트릭도 포함됩니다. 단순 및 고급 부하 메트릭의 조합을 크기 조정 트리거로 사용하는 것이 좋습니다.
버퍼를 사용합니다. 버퍼는 수요 급증을 처리하는 데 사용할 수 있는 사용되지 않는 용량입니다. 워크로드의 예기치 않은 급증에 대한 잘 설계된 워크로드 계획입니다. 가로 및 세로 크기 조정에 대한 급증을 처리하는 버퍼를 추가해야 합니다.
펄럭이는 것을 방지합니다. 플래핑은 하나의 크기 조정 이벤트가 반대 크기 조정 이벤트를 트리거하여 연속적인 앞뒤로 크기 조정 작업을 생성할 때 발생하는 반복 조건입니다. 예를 들어 의 크기를 조정하면 인스턴스 수가 줄어들면 나머지 인스턴스에서 CPU 사용량이 증가하여 스케일 아웃 이벤트가 트리거될 수 있습니다. 스케일 아웃 이벤트로 인해 CPU 사용량이 감소하여 프로세스가 반복됩니다.
플래핑을 방지하려면 스케일 아웃 임계값과 스케일 인 임계값 간에 적절한 여백을 선택하는 것이 중요합니다. CPU 사용량에 상당한 차이를 제공하는 임계값을 설정하여 빈번하고 불필요한 스케일 인 및 스케일 아웃 작업을 방지할 수 있습니다.
배포 스탬프를 사용합니다. 워크로드 크기를 쉽게 조정할 수 있는 기술이 있습니다. 배포 스탬프 패턴을 사용하여 하나 이상의 배율 단위를 추가하여 워크로드 크기를 쉽게 조정할 수 있습니다.
위험: 크기 조정은 수요를 충족하기 위해 용량을 조정하여 비용을 최적화하는 데 도움이 되지만 수요가 많은 오랜 기간 동안 전반적인 비용 증가가 발생할 수 있습니다.
크기 조정 테스트
크기 조정 테스트에는 제어된 환경에서 다양한 워크로드 시나리오를 시뮬레이션하여 워크로드가 다양한 수준의 수요에 대응하는 방식을 평가해야 합니다. 워크로드를 효율적으로 확장하여 다양한 부하 중에 성능 효율성을 극대화하는 데 도움이 됩니다.
워크로드가 실제 조건에서 효율적으로 확장되도록 해야 합니다. 프로덕션 설정을 미러링하는 환경에서 부하 및 스트레스 테스트를 수행해야 합니다. 비프로덕션 환경에서 수행된 이러한 테스트를 통해 수직 및 수평 크기 조정 전략을 모두 평가하고 성능을 가장 효과적으로 최적화하는 전략을 결정할 수 있습니다. 스케일링을 테스트하는 데 권장되는 방법은 다음과 같습니다.
워크로드 시나리오를 정의합니다. 사용자 트래픽 증가, 동시 요청, 데이터 볼륨 또는 리소스 사용과 같이 테스트해야 하는 주요 워크로드 시나리오를 식별합니다.
프로덕션과 유사한 테스트 환경을 사용합니다. 인프라, 구성 및 데이터 측면에서 프로덕션 환경과 매우 유사한 별도의 테스트 환경을 만듭니다.
성능 메트릭을 설정합니다. 응답 시간, 처리량, CPU 및 메모리 사용률, 오류율 등 측정할 성능 메트릭을 정의합니다.
테스트 사례를 개발합니다. 다양한 워크로드 시나리오를 시뮬레이션하는 테스트 사례를 개발하여 부하를 점진적으로 늘려 다양한 수준에서 성능을 평가합니다.
테스트를 실행하고 모니터링합니다. 정의된 테스트 사례를 사용하여 테스트를 실행하고 각 부하 수준에서 성능 데이터를 수집합니다. 워크로드 동작, 리소스 사용량 및 성능 저하를 모니터링합니다.
크기 조정을 분석하고 최적화합니다. 테스트 결과를 분석하여 성능 병목 상태, 확장성 제한 또는 개선 영역을 식별합니다. 구성, 인프라 또는 코드를 최적화하여 확장성 및 성능을 향상시킵니다. 크기 조정이 완료되는 데 시간이 걸리므로 크기 조정 지연의 영향을 테스트합니다.
종속성을 해결합니다. 잠재적인 종속성 문제를 찾습니다. 워크로드의 한 영역에서 크기를 조정하거나 분할하면 종속성에 성능 문제가 발생할 수 있습니다. 데이터베이스와 같은 워크로드의 상태 저장 부분은 종속성 성능 문제의 가장 일반적인 원인입니다. 데이터베이스를 가로로 확장하려면 신중한 디자인이 필요합니다. 데이터베이스에 더 많은 처리량을 사용하도록 설정하려면 낙관적 동시성 또는 데이터 분할과 같은 측정값을 고려해야 합니다.
조정 후 다시 테스트합니다. 최적화를 구현한 후 확장성 테스트를 반복하여 개선 사항의 유효성을 검사하고 워크로드가 예상 워크로드를 효율적으로 처리할 수 있도록 합니다.
절충: 워크로드의 예산 제약 조건 및 비용 효율성 목표를 고려합니다. 수직적 스케일링에는 더 크고 강력한 리소스가 필요하기 때문에 비용이 더 많이 들 수 있습니다. 수평 크기 조정은 필요에 따라 추가하거나 제거할 수 있는 더 작은 인스턴스를 사용하여 비용을 절감할 수 있습니다.
파티션 워크로드
분할은 큰 데이터 세트 또는 워크로드를 파티션이라는 더 작고 관리하기 쉬운 부분으로 나누는 프로세스입니다. 각 파티션은 데이터 또는 워크로드의 하위 집합을 포함하며 일반적으로 별도로 저장되거나 처리됩니다. 분할은 병렬 처리를 가능하게 하고 경합을 줄입니다. 워크로드를 더 작은 단위로 분할하면 애플리케이션이 각 단위를 독립적으로 처리할 수 있습니다. 결과적으로 리소스를 더 잘 사용하고 처리 시간을 단축할 수 있습니다. 분할은 또한 여러 스토리지 디바이스에 데이터를 분산하여 개별 디바이스의 부하를 줄이고 전반적인 성능을 향상시키는 데 도움이 됩니다.
분할 이해
사용하는 특정 분할 방법은 가지고 있는 데이터 또는 워크로드의 유형과 사용 중인 기술에 따라 달라집니다. 분할에 대한 몇 가지 일반적인 전략은 다음과 같습니다.
수평 분할: 이 방법에서 데이터 세트 또는 워크로드는 값 범위 또는 특정 특성과 같은 특정 조건에 따라 구분됩니다. 각 파티션에는 정의된 조건을 충족하는 데이터의 하위 집합이 포함됩니다.
수직 분할: 이 방법에서 데이터 세트 또는 워크로드는 특정 특성 또는 열에 따라 구분됩니다. 각 파티션에는 열 또는 특성의 하위 집합이 포함되어 있어 필요한 데이터에 보다 효율적으로 액세스할 수 있습니다.
기능 분할: 이 접근 방식에서 데이터 또는 워크로드는 수행해야 하는 특정 함수 또는 작업에 따라 구분됩니다. 각 파티션에는 특정 함수에 필요한 데이터 또는 구성 요소가 포함되어 최적화된 처리 및 성능을 지원합니다.
분할 계획
분할할 때 데이터 배포, 쿼리 패턴, 데이터 증가 및 워크로드 요구 사항과 같은 요소를 고려하는 것이 중요합니다. 분할의 효율성을 보장하고 성능 효율성을 극대화하려면 적절한 계획과 설계가 필수적입니다. 분할을 사후 고려로 처리하는 경우 유지 관리할 라이브 워크로드가 이미 있기 때문에 더 어렵습니다. 데이터 액세스 논리를 변경하고, 파티션에 대량의 데이터를 배포하고, 데이터 배포 중에 지속적인 사용을 지원해야 할 수 있습니다.
분할(partitioning) 구현
사용할 분할 유형을 결정할 때 데이터의 특성, 액세스 패턴, 동시성 요구 사항 및 확장성 목표를 분석하는 것이 중요합니다. 분할의 각 유형에는 고유한 장점과 고려 사항이 있습니다. 다음은 각 분할 유형에 대해 고려해야 할 몇 가지 요소입니다.
수평 분할 은 확장성과 성능을 향상하기 위해 여러 리소스 또는 서버에 데이터를 분산하려는 경우에 적합합니다. 워크로드를 병렬화하고 각 파티션에서 독립적으로 처리할 수 있는 경우에 효과적입니다. 여러 사용자 또는 프로세스가 동시에 데이터 세트에 액세스하거나 업데이트할 수 있어야 하는 경우 수평 분할을 고려합니다.
수직 분할 은 특정 특성 또는 열에 자주 액세스하는 반면 다른 특성은 자주 액세스하지 않는 경우에 적합합니다. 수직 분할을 사용하면 불필요한 데이터 검색을 최소화하여 필요한 데이터에 효율적으로 액세스할 수 있습니다.
기능 분할 은 다른 함수에 데이터의 서로 다른 하위 집합이 필요하고 독립적으로 처리할 수 있는 경우에 적합합니다. 기능 분할은 각 파티션이 특정 작업에 집중할 수 있도록 하여 성능을 최적화할 수 있습니다.
분할 테스트 및 최적화
분할 체계를 테스트하여 성능 향상을 위해 조정할 수 있도록 전략의 효율성과 효율성을 확인합니다. 응답 시간, 처리량 및 확장성과 같은 요소를 측정합니다. 결과를 성능 목표와 비교하고 병목 상태 또는 문제를 식별합니다. 분석에 따라 잠재적인 최적화 기회를 식별합니다. 파티션 간에 데이터를 재배포하거나 파티션 크기를 조정하거나 분할 조건을 변경해야 할 수 있습니다.
데이터 기울이기: 분할은 데이터 기울이기로 이어질 수 있으며, 특정 파티션은 다른 파티션에 비해 불균형한 양의 데이터 또는 워크로드를 받습니다. 데이터 기울이기 때문에 특정 파티션에서 성능 불균형과 경합이 증가할 수 있습니다.
쿼리 성능: 제대로 디자인되지 않은 분할 체계는 쿼리 성능에 부정적인 영향을 줄 수 있습니다. 쿼리가 여러 파티션에서 데이터에 액세스해야 하는 경우 파티션 간의 추가 조정 및 통신이 필요할 수 있으므로 대기 시간이 증가합니다.
Azure 촉진
크기 조정 최적화. Azure에는 수직 및 수평 크기 조정을 지원하는 인프라 용량이 있습니다. Azure 서비스에는 SKU라고 하는 다양한 성능 계층이 있습니다. SKU를 사용하면 수직으로 크기를 조정할 수 있습니다. 대부분의 Azure 리소스는 자동 크기 조정 또는 기타 현재 위치 크기 조정 옵션을 지원합니다. 일부 리소스는 고급 메트릭 또는 사용자 지정 입력을 지원하여 크기 조정 동작을 미세 조정합니다. Azure의 대부분의 크기 조정 구현은 제한을 설정하고 변경에 대해 경고하는 데 필요한 가시성을 지원할 수 있습니다.
Azure Monitor 를 사용하면 애플리케이션 및 인프라의 다양한 메트릭 및 조건을 모니터링할 수 있습니다. 모니터를 사용하여 미리 정의된 규칙에 따라 자동화된 크기 조정 작업을 트리거할 수 있습니다. 예를 들어 AKS(Azure Kubernetes Service)에서 모니터를 사용하여 HPA(수평 Pod 자동 크기 조정) 및 클러스터 자동 크기 조정을 사용하도록 설정할 수 있습니다. 모니터의 모니터링 및 경고 기능을 사용하면 Azure에서 효과적으로 스케일링을 용이하게 하고 애플리케이션과 인프라가 수요에 맞게 동적으로 조정할 수 있도록 할 수 있습니다.
Azure에서 사용자 지정 자동 크기 조정을 빌드할 수도 있습니다. 자동 크기 조정 기능이 없는 리소스에 대한 모니터에서 경고를 사용할 수 있습니다. 이러한 경고는 쿼리 기반 또는 메트릭 기반으로 설정할 수 있으며 Azure Automation 사용하여 작업을 수행할 수 있습니다. Automation은 Azure, 클라우드 및 온-프레미스 환경에서 PowerShell 및 Python 코드를 호스팅하고 실행하기 위한 플랫폼을 제공합니다. 요청 시 또는 일정에 따라 Runbook 배포, 실행 기록 및 로깅, 통합 비밀 저장소 및 소스 제어 통합과 같은 기능을 제공합니다.
확장할 애플리케이션 디자인: Azure에서 애플리케이션 크기 조정 설계를 용이하게 하는 몇 가지 방법은 다음과 같습니다.
데이터 잠금 제거: Azure SQL 데이터베이스에서 최적화된 잠금을 사용하도록 설정하여 엄격한 일관성이 필요한 데이터베이스의 성능을 향상시킬 수 있습니다.
백그라운드 작업 사용: Azure는 백그라운드 작업을 구현하기 위한 서비스 및 지침을 제공합니다. 자세한 내용은 백그라운드 작업을 참조하세요.
부하 분산 구현: Azure는 클라이언트 선호도가 필요하지 않은 부하 분산 장치를 제공합니다. 이러한 부하 분산 장치에는 Azure Front Door, Azure Application Gateway 및 Azure Load Balancer 포함됩니다.
워크로드 분할: Azure는 다양한 데이터 저장소에 대한 다양한 분할 전략을 제공합니다. 이러한 전략은 여러 파티션에 데이터를 분산하여 성능 및 확장성을 개선하는 데 도움이 됩니다. 자세한 내용은 데이터 파티션 전략을 참조하세요.
관련 링크
성능 효율성 검사 목록
전체 권장 사항 집합을 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기