용량 요구 사항을 충족하도록 디자인
 예상 수요를 충족할 만큼 충분한 공급을 제공합니다. |
|---|
성능을 적극적으로 측정해야 합니다. 성능 측정에는 기준을 측정하고 시스템 구성 요소 중 어떤 부분이 어려움을 겪을 가능성이 있는지에 대한 사전 이해를 포함하는 것입니다. 전체적인 성능 테스트를 실시하지 않고도, 세부적인 최적화를 통해서도 이를 달성할 수 있습니다. 이러한 초기 단계를 거치면 개발 수명 주기 초기에 효과적인 성능 관리를 위한 기반을 마련할 수 있습니다.
개별 구성 요소에 중점을 두기보다는 시스템 전체를 살펴봅니다. 이 단계에서는 미세 조정을 방지합니다. 세부적인 성능 개선을 하면 다른 영역에서 장단점이 깨지게 됩니다. 수명 주기를 거치며 사용자 승인 테스트를 시작하거나 운영 단계로 넘어가면 추가 최적화가 필요한 영역을 빠르게 파악할 수 있습니다.
예제 시나리오
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 표준 플랜을 선택했습니다. 앱당 최대 500개의 인스턴스를 지원하는 표준 플랜은 최대 예상 사용량에 충분한 컴퓨팅 용량을 제공할 수 있습니다.
- 또한 서비스는 필요에 따라 스케일 아웃되도록 구성할 수 있으며 추가 용량이 필요하지 않을 때는 컴퓨팅 리소스를 스케일 인합니다.
- 팀에서는 앱당 최대 1000개의 인스턴스까지 스케일 업할 수 있는 엔터프라이즈 계획을 살펴보았지만, 이 시점에서는 그 정도의 용량이 필요하지 않다고 결정했습니다. 또한 엔터프라이즈 계획이 제공하는 수준의 지원이나 그 외의 제외적인 기능이 필요하지 않다고 확신합니다.
용량 요구 사항을 적절히 예측
수요와 선택한 리소스의 기능에 따라 용량 계획을 세워 성능 모델을 보강합니다. 예측 모델링 기술을 사용하여 예측 가능한 변화와 예기치 못한 변화로 인해 발생할 수 있는 예측 용량 변화를 예측합니다. 기술 요구 사항으로 변환할 수 있는 성능 목표를 정의합니다.
이 방식을 채택하면 효율적으로 리소스를 사용하고 과도한 프로비전 없이 수요를 충족할 수 있으므로 불필요한 비용을 피할 수 있습니다. 또한 이를 통해 디자인 선택이 성능에 어떤 영향을 미치는지 이해하는 데 도움이 될 것입니다.
Contoso의 과제
- 프로덕션 컴퓨터의 효율적인 사용을 최대화하기 위해 Contoso의 생산 라인은 순환 일정에 따라 운영되어 하루 중 다른 시간에 다른 제품을 프로덕션합니다.
- 각 제품에는 서로 다른 작업이 필요하므로 제어 애플리케이션에 대한 계산 요구 사항도 서로 다릅니다. 제품 간 전환 중에 제어 애플리케이션은 이전 프로덕션 실행의 데이터를 분석하고 컴퓨터의 제어 알고리즘을 업데이트하는 등 증가된 컴퓨팅 용량이 필요한 다양한 작업을 수행해야 합니다.
접근 방식 및 결과 적용
- 전환 기간 동안 증가하는 수요를 충족하기 위해 팀은 먼저 전환 기능을 처리하는 흐름을 식별하고, 성능 요구 사항을 문서화하고, 온-프레미스 버전의 애플리케이션을 기반으로 트랜잭션량을 추정합니다. 이러한 데이터를 바탕으로 팀은 대상 흐름에 속하는 마이크로 서비스에 필요한 컴퓨팅 용량을 예상합니다.
- 이러한 구성 요소에 대해 자동 크기 조정이 구성되어 전환 기간 전에 추가 리소스가 프로비전되고 작업이 완료된 후 해제됩니다.
- 자동 크기 조정 설정은 앱을 프로덕션에 배포하기 전에 새 환경의 실제 성능에 따라 조정됩니다.
개념 증명 배포
기술 요구 사항과 디자인 선택의 유효성을 검사하는 POC(개념 증명)를 구현합니다.
개념 증명은 시스템이 성능 목표를 충족할 수 있는지, 그리고 그 대상이 현실적인지 확인하기 위해 디자인의 유효성을 검사하는 데 도움이 됩니다. 예상 부하를 기준으로 예상 용량이 성능 목표를 충족할 수 있는지 유효성을 검사할 수 있습니다.
또한 디자인 선택의 비용적 영향을 확인합니다.
Contoso의 과제
- 개발 과정에서 팀은 디바이스 시뮬레이터를 사용하여 애플리케이션 기능에 대한 광범위한 부하 및 성능 테스트를 수행하고 있으며, 이 정보를 사용하여 자동 크기 조정 구성을 최적화하고 있습니다.
- 자동 크기 조정 구성의 효과에 영향을 줄 수 있는 한 가지 측면은 Azure Spring 앱 환경에서 ExpressRoute를 통해 Azure에 연결된 제조 현장의 IoT 디바이스로 통신하는 데 발생할 수 있는 잠재적인 네트워크 대기 시간입니다. 해당 팀은 앱의 경우 온-프레미스 버전보다 Azure에서 대기 시간이 더 길 것이며, 대기 시간은 시간대나 디바이스 위치와 같은 다른 요인의 영향을 받을 수도 있다고 추측합니다.
- 대기 시간이 증가하면 각 마이크로 서비스 인스턴스가 처리할 수 있는 트랜잭션 볼륨에 영향을 미칠 가능성이 높습니다.
접근 방식 및 결과 적용
- 팀은 가설의 유효성을 검사하고 구성을 최적화하는 데 사용할 수 있는 메트릭을 수집하기 위해 POC를 Azure에 배포하기로 결정했습니다. 제조 현장 전반에 분산된 IoT 디바이스와 통신하기 위해 테스트용 Azure Spring 앱을 빌드합니다. IoT 디바이스는 온-프레미스 네트워크에 연결되고 Azure IoT Hub에 등록됩니다. 테스트 애플리케이션은 간단한 ping을 보내서 하루 종일 디바이스에 임의로 연결하고 응답을 받는 데 걸리는 시간을 기록합니다.
- 이 POC 동안 캡처된 데이터는 부하 테스트 결과와 결합되어, 팀이 초기 프로덕션 시작을 준비하면서 필요한 컴퓨팅 용량을 보다 정확하게 예상하는 데 도움이 될 것입니다.
- 또한 팀은 POC에서 얻은 교훈을 토대로 더욱 현실적인 응답 시간을 시뮬레이션하기 위해 부하 테스트에 사용되는 테스트 사례를 더욱 개선하는 방법을 모색하고 있습니다.