Diseño para la optimización del uso
 Maximice el uso de recursos y operaciones. Aplíquelos a los requisitos funcionales y no funcionales negociados de la solución. |
|---|
Los servicios y ofertas proporcionan diversas funcionalidades y planes de tarifa. Después de comprar un conjunto de características, evite infrautilizarlos. Encuentre formas de maximizar la inversión en el nivel. Del mismo modo, evalúe continuamente los modelos de facturación para encontrar los que mejor se alineen con el uso, en función de las cargas de trabajo de producción actuales.
Escenario de ejemplo
Contoso University está hospedando actualmente un producto comercial (COTS) que permite a los profesores universitarios crear y actualizar cursos para el año escolar y es el portal de registro principal que usan los alumnos para esos cursos. La solución tiene una integración personalizada con un sistema de administración de educación de software como servicio (SaaS), que esperan migrar finalmente todas sus funciones a en unos años. Mientras tanto, quieren optimizar los costos en los componentes de integración personalizados.
La solución tecnológica de la oferta de COTS se trata generalmente como una caja negra, excepto su base de datos que es Azure Database for MySQL. La integración personalizada es una instancia de Azure Durable Function, que se ejecuta en un plan de servicio estándar en Azure App Service. Esta instancia de App Service previamente hospedaba un sitio web universitario, pero ya no es el caso. Esta función duradera es una aplicación de Python respaldada por una cuenta dedicada de Azure Storage que realiza una sincronización nocturna desde la base de datos MySQL en la API de SaaS.
Uso de precios basados en el consumo cuando sea práctico
Puede haber servicios que ofrecen precios basados en el consumo, lo que significa que solo se le factura la utilización del servicio y puede apagar el servicio cuando no sea necesario para dejar de incurrir en costos. Si tiene componentes de carga de trabajo que solo se usan de forma esporádica, esto puede ayudar a minimizar los costos desperdiciados en comparación con el pago del componente para ejecutar el 24/7/365.
Mediante el uso de precios basados en el consumo, solo se paga por lo que se usa exactamente. Esta opción es una buena opción cuando no se espera que el proceso de carga de trabajo se use a tiempo completo.
Desafío de Contoso
- El trabajo de sincronización normalmente se ejecuta durante aproximadamente una hora cada noche, en un momento específico. La actuación ha sido históricamente satisfactoria. Los errores incorrectos son poco frecuentes y los errores transitorios se controlan bien en la configuración actual.
- Dado que el proceso necesario para el trabajo de sincronización solo se utiliza aproximadamente una hora al día y paga por 24 horas independientemente del uso, el equipo de carga de trabajo está interesado en una alternativa al diseño actual.
- El equipo ha considerado escribir un script para apagar el servicio cada noche después de que la sincronización se ejecute y vuelva a implementarlo el día siguiente, pero esta solución conllevaría un alto grado de riesgo y complejidad.
Aplicación del enfoque y los resultados
- El equipo analiza el historial de trabajos y descubre que la función más larga que se ejecuta ha estado apenas dos horas. Comparan el costo del plan dedicado con el costo del plan de consumo de Azure Functions para el peor escenario y concluyen que el plan de consumo será menos costoso.
- El equipo ejecuta una prueba de rendimiento para asegurarse de que el rendimiento es suficiente y observa un ligero aumento en el tiempo de ejecución, pero dentro de los límites aceptables.
- El costo total de la carga de trabajo se reduce mediante el uso del plan de consumo, ya que solo incurre en costos cuando se ejecuta el trabajo.
Optimización del diseño de alta disponibilidad
Priorice la implementación de modelos activo-activo o solo activo sobre los modelos activos-pasivos, como parte del plan de recuperación, si ya ha pagado por los recursos.
Si el diseño usa modelos activos-pasivos, es posible que tenga recursos inactivos que, de lo contrario, se podrían usar. La conversión a activo-activo puede permitirle cumplir los requisitos de expansión de escalado y expansión de carga sin sobrecargar. Si puede cumplir los objetivos de recuperación con un modelo de solo activo, los costos de esos recursos se pueden quitar completamente.
Desafío de Contoso
- La aplicación COTS usa el servidor flexible de Azure Database for MySQL configurado para alta disponibilidad de la misma zona, que proporciona un servidor en espera en la misma zona de disponibilidad que el servidor principal. También han habilitado copias de seguridad automáticas.
- El RPO de la carga de trabajo es relativamente largo en 12 horas y el RTO es de 3 horas durante el día escolar.
- En función de las pruebas de recuperación anteriores, el equipo sabe que puede cumplir sus objetivos de RPO y RTO a través de la conmutación automática por error al servidor en espera. También han probado la recuperación de la base de datos de una copia de seguridad y pueden cumplir los objetivos de este escenario.
Aplicación del enfoque y los resultados
- El equipo de carga de trabajo vuelve a evaluar la ventaja del diseño de alta disponibilidad frente al costo del servicio que es el doble que una sola instancia.
- El equipo prueba la creación de una nueva instancia y la recuperación de una base de datos de la copia de seguridad y está satisfecho con que seguirán cumpliendo sus destinos de recuperación, por lo que deciden eliminar la instancia en espera.
- El equipo actualiza el plan de recuperación ante desastres para reflejar la nueva estrategia de recuperación y ahorrar costos a través de la nueva configuración.
Mantener el entorno en la nube limpio de los datos y los recursos no utilizados
Revise periódicamente y rigurosamente las implementaciones de recursos y datos no utilizados y los retire. Con el tiempo, los recursos y los datos necesarios para algún propósito en el pasado, pero que ya no se usan, pueden persistir en los entornos de nube y acumular costos innecesariamente. Tenga cuidado de mantener limpios sus entornos para ayudar a optimizar la eficiencia de los costos.
Apagar los recursos no utilizados y eliminar datos cuando ya no los necesite reduce los residuos y libera fondos para poder invertirlos en otro lugar.
Desafío de Contoso
- Históricamente, la universidad ha adoptado un enfoque conservador para retirar soluciones, temiendo que puedan necesitar revertir a una configuración anterior. Esta precaución ha llevado a tener servicios abandonados que se ejecutan en uno o varios entornos durante meses que se han olvidado en algunos casos.
- Cuando se detectan servicios abandonados, suele ser por accidente, ya que no hay ningún proceso formal para revisar el entorno de dichos servicios.
Aplicación del enfoque y los resultados
- El equipo agrega la retirada de App Service al trabajo pendiente como parte de la migración de App Service al hospedaje de consumo de Durable Function. Como parte del siguiente sprint, se apagarán las implementaciones de App Service en todos los entornos.
- Para ayudar a detectar de forma proactiva los recursos abandonados, el equipo configura alertas en Azure Advisor para notificarles los recursos no utilizados.
- El equipo implementa una nueva directiva que requiere que el equipo realice revisiones completas mensuales de entornos de preproducción y revisiones trimestrales completas del entorno de producción para identificar los recursos abandonados. Los recursos abandonados encontrados se agregarán al trabajo pendiente para retirarlos.