Devops RoadShow: load testing and autoscale
•Transferir como PPTX, PDF•
0 gostou•467 visualizações
Slides de la sesión de Load Testing and Autoscale, del evento de Microsoft DevOps Roadshow en Barcelona
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (15)
Mais de Fernando Escolar Martínez-Berganza
Mais de Fernando Escolar Martínez-Berganza (20)
Último
Último (20)
Devops RoadShow: load testing and autoscale
- 5. Scaling
- 6. Autoscaling Overview - Allocate resources dynamically - Minimize costs
- 7. Autoscaling Types of scaling - Vertical - Horizontal
- 8. Autoscaling Strategy - Capture key metrics - Decision-making - Components (provisioning or de-provisioning) - Testing, monitoring, and tuning
- 9. Autoscaling Considerations - To be horizontally scalable - The System - The long running tasks
- 11. Load Testing
- 12. Load testing Overview - From normal to peak load conditions Identifies - Maximum operating capacity - Bottlenecks
- 13. Load testing Measure service availability - MTTD - MTTR - MTTF - MTBF MTBF = MTTD + MTTR + MTTF Availability = MTTF / MTBF
Notas do Editor
- Cover Option 1
- Tokiota es una empresa joven que a lo largo de su año de vida ha conseguido un gran reconocimiento como especialistas en tecnologías Microsoft. Somos gold partners en movilidad (desarrollo de Windows pone y Windows Store), pertenecemos al azure circle y como partner preferente de Microsoft estamos especializados en: Arquitectura de software Soluciones Cloud Infraestructura Desarrollo en tecnologías Microsoft
- Autoscaling is the process of dynamically allocating the resources required by an application to match performance requirements and satisfy service-level agreements (SLAs), while minimizing runtime costs. As the volume of work grows, an application may require additional resources to enable it to perform its tasks in a timely manner. As demand slackens, resources can be de-allocated to minimize costs, while still maintaining adequate performance and meeting SLAs. Autoscaling takes advantage of the elasticity of cloud-hosted environments while easing management overhead. It does so by reducing the need for an operator to continually monitor the performance of a system and make decisions about adding or removing resources.
- Vertical (often referred to as scaling up and down). This form requires that you modify the hardware (expand or reduce its capacity and performance), or redeploy the solution using alternative hardware that has the appropriate capacity and performance. In a cloud environment, the hardware platform is typically a virtualized environment. Unless the original hardware was substantially overprovisioned, with the consequent upfront capital expense, vertically scaling up in this environment involves provisioning more powerful resources, and then moving the system onto these new resources. Vertical scaling is often a disruptive process that requires making the system temporarily unavailable while it is being redeployed. It may be possible to keep the original system running while the new hardware is provisioned and brought online, but there will likely be some interruption while the processing transitions from the old environment to the new one. It is uncommon to use autoscaling to implement a vertical scaling strategy. Horizontal (often referred to as scaling out and in). This form requires deploying the solution on additional or fewer resources, which are typically commodity resources rather than high-powered systems. The solution can continue running without interruption while these resources are provisioned. When the provisioning process is complete, copies of the elements that comprise the solution can be deployed on these additional resources and made available. If demand drops, the additional resources can be reclaimed after the elements using them have been shut down cleanly. Many cloud-based systems, including Microsoft Azure, support automation of this form of scaling.
- Implementing an autoscaling strategy typically involves the following components and processes: Instrumentation and monitoring systems at the application, service, and infrastructure levels. These systems capture key metrics, such as response times, queue lengths, CPU utilization, and memory usage. Decision-making logic that can evaluate the monitored scaling factors against predefined system thresholds or schedules, and make decisions regarding whether to scale or not. Components that are responsible for carrying out tasks associated with scaling the system, such as provisioning or de-provisioning resources. Testing, monitoring, and tuning of the autoscaling strategy to ensure that it functions as expected.
- Autoscaling isn't an instant solution. Simply adding resources to a system or running more instances of a process doesn't guarantee that the performance of the system will improve. Consider the following points when designing an autoscaling strategy: The system must be designed to be horizontally scalable. Avoid making assumptions about instance affinity; do not design solutions that require that the code is always running in a specific instance of a process. When scaling a cloud service or web site horizontally, don't assume that a series of requests from the same source will always be routed to the same instance. For the same reason, design services to be stateless to avoid requiring a series of requests from an application to always be routed to the same instance of a service. When designing a service that reads messages from a queue and processes them, don't make any assumptions about which instance of the service handles a specific message. Autoscaling could start additional instances of a service as the queue length grows. TheCompeting Consumers Pattern describes how to handle this scenario. If the solution implements a long-running task, design this task to support both scaling out and scaling in. Without due care, such a task could prevent an instance of a process from being shut down cleanly when the system scales in, or it could lose data if the process is forcibly terminated. Ideally, refactor a long-running task and break up the processing that it performs into smaller, discrete chunks. ThePipes and Filters Pattern provides an example of how you can achieve this.
- Load testing is the process of putting demand on a software system or computing device and measuring its response. Load testing is performed to determine a system's behavior under both normal and anticipated peak load conditions. It helps to identify the maximum operating capacity of an application as well as any bottlenecks and determine which element is causing degradation.
- MTTD(Mean Time To Diagonise) = The average time it takes to diagonise the problem MTTR(Mean Time To Repair) = The average time it takes to fix a problem MTTF(Mean Time To Failure) = The average time there is a correct behaviour MTBF(Mean Time Between Failures) = The average time between failure of service(average time between two failures)
- Cover Option 1