용량 요구 사항을 충족하도록 디자인
 예상 수요를 해결하기에 충분한 공급을 제공합니다. |
|---|
성능을 사전에 측정하는 것이 중요합니다. 성능 측정에는 기준을 측정하고 시스템의 어떤 구성 요소가 문제를 일으킬 수 있는지를 예비 이해해야 합니다. 전체 성능 테스트를 수행하거나 세분화된 최적화를 통해 수행할 수 있습니다. 이러한 초기 단계를 수행하여 개발 수명 주기 초기에 효과적인 성능 관리를 위한 기반을 설정합니다.
개별 구성 요소에 집중하지 않고 시스템 전체를 검사합니다. 이 단계에서는 미세 조정을 피합니다. 세분화된 성능을 개선하면 다른 영역에서 절충이 발생합니다. 수명 주기를 진행하면서 사용자 승인 테스트를 시작하거나 프로덕션으로 전환할 때 추가 최적화가 필요한 영역을 빠르게 식별할 수 있습니다.
예제 시나리오
Contoso Manufacturing은 제조 프로세스를 모니터링하고 최적화하는 데 사용되는 내부적으로 사용되는 Java Spring 기반 마이크로 서비스 앱을 개발했습니다. 워크로드 팀은 현재 온-프레미스에서 호스트되는 앱을 Azure로 마이그레이션하는 중입니다.
Azure 호스팅 앱은 Azure Spring Apps, Azure Database for MySQL 및 Azure IoT Hub를 기반으로 빌드됩니다. Contoso는 Azure에 ExpressRoute 연결이 있습니다.
워크로드를 효과적으로 디자인
성능 목표를 충족하고 시스템과 통합할 수 있는 기술 스택에서 적절한 리소스를 선택합니다. 예기치 않은 급증을 효율적으로 처리하기 위해 확장성 요구 사항을 충족하고 리소스 할당과 시스템 요구 사항 간의 적절한 균형을 찾을 수 있는 기능을 고려합니다.
리소스의 다양한 기능을 분석하여 각 구성 요소가 시스템의 전반적인 기능과 성능에 기여하는지 확인하고 활용할 수 있는 크기 조정 기능을 식별할 수 있습니다.
적절한 크기 조정 리소스는 과도하게 프로비저닝하지 않고도 수요 변화를 충족할 수 있으므로 비용을 절감할 수 있습니다.
Contoso의 과제
- 기존 온-프레미스 앱 환경 인프라는 Contoso에서 완전히 관리되므로 팀에 상당한 부담이 됩니다. 현재 서버, 네트워크 및 스토리지를 프로비전 및 기본 뿐만 아니라 Java Spring 서비스 런타임 및 모든 종속성을 구성하고 업데이트합니다.
- 팀은 Azure Spring Apps를 사용하여 PaaS 모델로 마이그레이션하기를 기대하고 있으며, 이를 통해 팀은 애플리케이션이 의도한 비즈니스 가치를 제공하고 인프라 관리에 더 적은 시간을 할애할 수 있도록 더 많은 에너지를 집중할 수 있기를 기대합니다.
- 이 애플리케이션은 Contoso의 비즈니스에 매우 중요하며 엄격한 성능 요구 사항이 있으므로 마이그레이션의 일부로 선택하는 기술을 통해 이러한 요구 사항을 충족할 수 있는지 확인해야 합니다.
접근 방식 및 결과 적용
- 사용 가능한 다양한 계획을 비교한 후 팀은 프로덕션 트래픽에 최적화된 Spring Boot 앱에 대해 완전히 관리되는 서비스를 제공하는 Azure Spring Apps Standard 계획을 선택합니다. 앱당 최대 500개의 인스턴스를 사용하는 표준 계획은 예상되는 최대 사용량에 충분한 컴퓨팅 용량을 제공할 수 있습니다.
- 또한 필요에 따라 규모를 확장하도록 서비스를 구성할 수 있으며 추가 용량이 필요하지 않은 경우 컴퓨팅 리소스를 스케일 인합니다.
- 팀은 앱당 최대 1,000개의 인스턴스를 확장할 수 있는 엔터프라이즈 계획을 살펴보았지만, 이 시점에서는 용량이 필요하지 않다고 결정했습니다. 또한 엔터프라이즈 플랜이 제공하는 지원 수준이나 나머지 전용 기능이 필요하지 않다고 확신합니다.
용량 요구 사항을 적절하게 예측
수요 및 선택한 리소스의 기능에 따라 용량 계획을 수행하여 성능 모델을 보강합니다. 예측 모델링 기술을 사용하여 예측 가능하고 예기치 않은 변경으로 발생할 수 있는 용량의 예상 변화를 예측합니다. 기술 요구 사항으로 변환할 수 있는 성능 목표를 정의합니다.
이 방법을 채택하면 리소스를 효율적으로 사용하고 과도하게 프로비전하지 않고 수요를 충족하여 불필요한 비용을 방지할 수 있습니다. 또한 디자인 선택이 성능에 미치는 영향을 이해하는 데 도움이 됩니다.
Contoso의 과제
- Contoso의 생산 라인은 생산 기계의 효율적인 사용을 최대화하기 위해 주기적 일정에 따라 작동하여 하루 중 다른 시간에 다른 제품을 생산합니다.
- 각 제품에는 서로 다른 작업이 필요하므로 제어 애플리케이션의 계산 요구 사항이 다릅니다. 제품 간 전환 중에 제어 애플리케이션은 이전 프로덕션 실행의 데이터를 분석하고 머신에 대한 제어 알고리즘을 업데이트하는 등 컴퓨팅 용량을 늘려야 하는 다양한 작업을 수행해야 합니다.
접근 방식 및 결과 적용
- 전환 기간 동안 더 높은 수요를 충족하기 위해 팀은 먼저 변경 기능을 처리하는 흐름을 식별하고, 성능 요구 사항을 문서화하고, 애플리케이션의 온-프레미스 버전을 기반으로 트랜잭션 볼륨을 예측합니다. 이 데이터를 사용하여 팀은 대상 흐름의 일부인 마이크로 서비스에 필요한 컴퓨팅 용량을 예측합니다.
- 자동 크기 조정은 이러한 구성 요소에 대해 구성되므로 추가 리소스가 전환 기간 전에 프로비전되고 작업이 완료된 후 해제됩니다.
- 자동 크기 조정 설정은 새 환경의 실제 성능에 따라 프로덕션에 앱을 배포하기 전에 조정됩니다.
개념 증명 배포
기술 요구 사항 및 디자인 선택 사항의 유효성을 검사하는 POC(개념 증명)를 구현합니다.
개념 증명은 시스템이 성능 목표를 충족할 수 있는지 여부와 해당 대상이 현실적인지 여부를 확인하기 위해 디자인의 유효성을 검사하는 데 중요한 역할을 합니다. 예상 부하에 따라 예상 용량이 성능 목표를 충족할 수 있는지 여부를 확인할 수 있습니다.
또한 디자인 선택 항목의 비용 영향을 확인합니다.
Contoso의 과제
- 개발 중에 팀은 디바이스 시뮬레이터를 사용하여 애플리케이션 기능에 대한 광범위한 부하 및 성능 테스트를 수행하고 이 정보를 사용하여 자동 크기 조정 구성을 최적화합니다.
- 자동 크기 조정 구성의 효과에 영향을 줄 수 있는 한 가지 측면은 Azure Spring Apps 환경에서 제조 현장의 IoT 디바이스로 통신하는 잠재적인 네트워크 대기 시간이며 ExpressRoute를 통해 Azure에 연결됩니다. 팀은 앱을 사용하는 경우 Azure에서 대기 시간이 온-프레미스 버전보다 더 높고 대기 시간이 시간 또는 디바이스 위치와 같은 다른 요인의 영향을 받을 수 있다고 추측합니다.
- 대기 시간이 증가하면 각 마이크로 서비스 인스턴스가 처리할 수 있는 트랜잭션 볼륨에 영향을 줄 수 있습니다.
접근 방식 및 결과 적용
- 팀은 가설의 유효성을 검사하고 구성을 최적화하는 데 사용할 수 있는 메트릭을 수집하기 위해 AZURE에 POC를 배포하기로 결정합니다. 제조 현장 전체에 분산된 IoT 디바이스와 통신하는 테스트 Azure Spring App을 빌드합니다. IoT 디바이스는 온-프레미스 네트워크에 연결되고 Azure IoT Hub에 등록됩니다. 테스트 애플리케이션은 간단한 ping을 전송하여 하루 종일 디바이스에 임의로 연결하고 응답을 받는 데 걸리는 시간을 기록합니다.
- 이 POC 중에 캡처된 데이터는 부하 테스트의 결과와 결합되어 팀이 초기 프로덕션 시작을 준비할 때 필요한 컴퓨팅 용량을 보다 정확하게 예측할 수 있게 해줍니다.
- 팀은 또한 POC의 학습에 따라 보다 현실적인 응답 시간을 시뮬레이션하기 위해 부하 테스트에 사용되는 테스트 사례를 더욱 개선하는 방법을 찾고 있습니다.