Transcription
Pilar de la fiabilidadMarco de Buena Arquitectura de AWS
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSPilar de la fiabilidad: Marco de Buena Arquitectura de AWSCopyright 2022 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's,in any manner that is likely to cause confusion among customers, or in any manner that disparages or discreditsAmazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may notbe affiliated with, connected to, or sponsored by Amazon.
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSTable of ContentsResumen . 1Resumen . 1Introducción . 2Fiabilidad . 3Principios de diseño . 3Definiciones . 3Resiliencia y los componentes de la fiabilidad . 4Disponibilidad . 4Objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO) . 6Comprender las necesidades de disponibilidad . 7Bases . 9Administrar Service Quotas y las limitaciones . 9Recursos . 10Planificación de la topología de red . 11Recursos . 13Arquitectura de las cargas de trabajo . 15Diseño de la arquitectura de servicios para la carga de trabajo . 15Recursos . 17Diseño de interacciones en un sistema distribuido para evitar errores . 17Recursos . 19Diseño de interacciones en un sistema distribuido para mitigar o tolerar errores . 19Recursos . 22Administración de los cambios . 24Monitoreo de los recursos de las cargas de trabajo . 24Recursos . 27Diseño de la carga de trabajo de forma que se adapte a los cambios en la demanda . 27Recursos . 29Implementación de cambios . 29Patrones de implementación adicionales para reducir los riesgos: . 31Recursos . 32Administración de los errores . 33Realizar copias de seguridad de los datos . 33Recursos . 35Utilice el aislamiento de fallas para proteger la carga de trabajo . 35Recursos . 38Diseñe su carga de trabajo para tolerar fallas de componentes . 39Recursos . 41Compruebe la fiabilidad . 42Recursos . 44Planificación para la recuperación de desastres (DR) . 45Recursos . 47Implementaciones de ejemplo para objetivos de disponibilidad . 48Seleccionar dependencias . 48Situaciones con una sola región . 48Escenario de dos nueves (99 %) . 49Escenario de tres nueves (99,9 %) . 50Escenario de cuatro nueves (99,99 %) . 53Escenarios en varias regiones . 55Tres y medio nueves (99,95 %) con un tiempo de recuperación de entre 5 y 30 minutos . 56Escenario de 5 nueves (99,999 %) o superior con un tiempo de recuperación menor a 1 minuto . 59Recursos . 62Documentación . 62Laboratorios . 62Enlaces externos . 62iii
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSLibros .Conclusión .Colaboradores .Documentación adicional .Revisiones del documento .Apéndice A: Diseño para disponibilidad de servicios exclusivos de AWS .iv626364656668
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSResumenPilar de fiabilidad: AWS WellArchitected FrameworkFecha de publicación: Julio de 2020 (Revisiones del documento (p. 66))ResumenEste documento se centra en el pilar de la fiabilidad de Marco de Buena Arquitectura de AWS. Ofreceasesoramiento para ayudar a los clientes a implementar las prácticas recomendadas en el diseño, laentrega y el mantenimiento de los entornos de Amazon Web Services (AWS).1
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSIntroducciónEl Marco de Buena Arquitectura de AWS ayuda a comprender las ventajas y las desventajas de lasdecisiones que se toman al crear cargas de trabajo en AWS. Mediante la utilización del marco, aprenderálas prácticas recomendadas de arquitectura para diseñar y operar cargas de trabajo en la nube fiables,seguras, eficientes y rentables. Ofrece una forma de medir de manera consistente sus arquitecturas enfunción de las prácticas recomendadas y de identificar las áreas que admiten mejora. Creemos que tenercargas de trabajo de buena arquitectura aumenta considerablemente la probabilidad del éxito empresarial.El Marco de Buena Arquitectura de AWS se basa en cinco pilares: Excelencia operativa Seguridad Fiabilidad Eficiencia de rendimiento Optimización de costosEste documento se centra en el pilar de la fiabilidad y en la manera de aplicarlo en sus soluciones. Lograrla fiabilidad puede significar un gran desafío para los entornos en las instalaciones tradicionales debido alos puntos únicos de errores, la falta de automatización y la falta de elasticidad. Si adopta las prácticas quese especifican en este documento, podrá crear arquitecturas con bases sólidas, arquitectura resistente,administración de cambios consistente y procesos de recuperación de errores comprobados.Este documento está destinado a personas con roles en el área de tecnología, como directores detecnología (CTO), arquitectos, desarrolladores y miembros de equipos operativos. Después de leer estedocumento, comprenderá las prácticas recomendadas y las estrategias de AWS que conviene utilizara la hora de diseñar arquitecturas en la nube para lograr la fiabilidad. Este documento incluye detallessobre implementación de alto nivel o patrones de arquitectura, así como también referencias a recursosadicionales.2
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSPrincipios de diseñoFiabilidadEl pilar de la fiabilidad incluye la capacidad de una carga de trabajo para llevar a cabo la función previstade forma correcta y consistente en el momento esperado. Esto incluye la capacidad de operar y probarla carga de trabajo a través de su ciclo de vida completo. Este documento ofrece orientación exhaustivasobre las prácticas recomendadas para implementar cargas de trabajo fiables en AWS.Temas Principios de diseño (p. 3) Definiciones (p. 3) Comprender las necesidades de disponibilidad (p. 7)Principios de diseñoEn la nube rigen varios principios que ayudan a mejorar la fiabilidad. Tenga en cuenta los siguientes amedida que analizamos las prácticas recomendadas: Recuperarse de los errores automáticamente: Si monitorea una carga de trabajo para obtener losindicadores clave de rendimiento (KPI), puede activar el proceso de automatización cuando se supera unlímite. Estos KPI deben ser una medida del valor comercial, no de los aspectos técnicos de la operacióndel servicio. Esto permite la notificación automática, el seguimiento de los errores y los procesos derecuperación automatizados que solucionan o reparan el error. Con una automatización más sofisticada,es posible anticipar y corregir los errores antes de que ocurran. Probar los procedimientos de recuperación: En un entorno en las instalaciones, a menudo se realizanpruebas para demostrar que la carga de trabajo funciona en una situación particular. Por lo general,las pruebas no se utilizan para validar las estrategias de recuperación. En la nube, puede realizarpruebas para detectar de qué forma se producen errores en su carga de trabajo y puede validar losprocedimientos de recuperación. Puede utilizar la automatización para simular diferentes errores o pararecrear las situaciones que causaron errores anteriormente. Este enfoque expone rutas de errores quepuede probar y arreglar antes de que ocurra un escenario real de error y, de esta forma, reducir losriesgos. Escalar horizontalmente para aumentar la disponibilidad de la carga de trabajo agregada: Reemplaceun recurso grande por varios recursos pequeños para reducir el impacto de un solo error en toda lacarga de trabajo. Distribuya las solicitudes en varios recursos más pequeños para asegurarse de que nocompartan un punto común de error. Dejar de suponer la capacidad: Una causa común de los errores en las cargas de trabajo en lasinstalaciones es la saturación de recursos cuando las demandas que se le asignan a una carga detrabajo exceden su capacidad (este suele ser el objetivo de los ataques de denegación de servicio).En la nube, puede monitorear la demanda y la utilización de la carga de trabajo. Además, puedeautomatizar el proceso de incorporación o eliminación de recursos a fin de mantener el nivel óptimo parasatisfacer la demanda sin llegar a un aprovisionamiento excesivo o insuficiente. Aún existen límites, peroalgunas cuotas se pueden controlar y otras se pueden administrar (consulte Administrar las cuotas yrestricciones de servicio (p. 9)). Administrar los cambios en la automatización: los cambios en su infraestructura se deben realizarmediante la automatización. Entre los cambios que deben administrarse se incluyen los cambios en laautomatización, que luego se pueden seguir y revisar.DefinicionesEn este documento técnico, se analiza la fiabilidad en la nube y se describen las prácticas recomendadaspara estas cuatro áreas:3
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSResiliencia y los componentes de la fiabilidad Bases Arquitectura de las cargas de trabajo Administración de los cambios Administración de los erroresPara lograr la fiabilidad, debe comenzar por las bases: un entorno donde todas las cuotas de servicio yla topología de red se adapten a la carga de trabajo. La arquitectura de la carga de trabajo del sistemadistribuido debe estar diseñada para prevenir y reducir los errores. La carga de trabajo debe controlarlos cambios en la demanda o los requisitos. Además, debe estar diseñada para detectar los errores yrecuperarse de forma automática.Temas Resiliencia y los componentes de la fiabilidad (p. 4) Disponibilidad (p. 4) Objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO) (p. 6)Resiliencia y los componentes de la fiabilidadLa fiabilidad de una carga de trabajo en la nube depende de varios factores, y el principal de ellos es laResiliencia: Resiliencia se refiere a la capacidad que tiene una carga de trabajo para recuperarse de interrupcionesen el servicio o la infraestructura, adquirir de forma dinámica recursos informáticos para satisfacerlas demandas y reducir las interrupciones, como los errores de configuración o los problemas de redtransitorios.Los otros factores que afectan a la fiabilidad de la carga de trabajo son los siguientes: La excelencia operativa, que incluye la automatización de los cambios, el uso de manuales de estrategiapara responder a los errores y las revisiones de disposición operativa (ORR) a fin de confirmar que lasaplicaciones están listas para las operaciones de producción. La seguridad, que incluye la prevención de daños a los datos o a la infraestructura por parte de agentesmalintencionados, lo que afectaría la disponibilidad. Por ejemplo, el cifrado de las copias de seguridadpara garantizar la seguridad de los datos. La eficiencia del rendimiento, que incluye tener un plan para tratar las tasas de solicitudes máximas yminimizar las latencias para su carga de trabajo. La optimización de costos, que incluye compensaciones, como decidir si gastar más en las instanciasEC2 para alcanzar la estabilidad estática o depender del escalado automático cuando se necesita máscapacidad.Este documento técnico se centra principalmente en la resiliencia.Los otros cuatro factores también son importantes y se analizan en sus respectivos pilares del Marco deBuena Arquitectura de AWS. Aquí se abordan junto con las prácticas recomendadas, pero este documentose centra en la resiliencia.DisponibilidadDisponibilidad (también se conoce como disponibilidad del servicio) es una métrica que se utilizafrecuentemente para medir de forma cuantitativa la fiabilidad. Disponibilidad es el porcentaje de tiempo que una carga de trabajo está disponible para su uso.4
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSDisponibilidadDisponible para su uso significa que realiza una función acordada cuando es necesario.Este porcentaje se calcula durante un tiempo, como un mes, un año o los últimos tres años. Si se aplicala interpretación más estricta posible, la disponibilidad se reduce cada vez que la aplicación no funcionanormalmente, incluidas las interrupciones programadas y no programadas. Definimos la disponibilidadmediante los siguientes criterios: Un porcentaje del tiempo de actividad (como el 99,9 %) durante un tiempo (normalmente un año) La abreviatura común solo hace referencia a la “cantidad de nueves”; por ejemplo, “cinco nueves” setraduce como un 99,999 % de disponibilidad Algunos clientes optan por no incluir el tiempo de inactividad del servicio programado (por ejemplo, elmantenimiento planificado) en el tiempo total de la fórmula en la primera viñeta. Sin embargo, esta sueleser una opción falsa porque es posible que los usuarios quieran utilizar el servicio durante este tiempo.A continuación, se muestra una tabla de los objetivos comunes de diseño de disponibilidad de la aplicacióny de la máxima cantidad de tiempo en que pueden ocurrir interrupciones en un año mientras se cumpleel objetivo. La tabla contiene ejemplos de los tipos de aplicaciones que se suelen ver en cada nivel dedisponibilidad. A lo largo de este documento, hacemos referencia a estos valores.DisponibilidadFalta de disponibilidad máxima(por año)Categorías de la aplicación99 % (p. 49)3 días, 15 horasProcesamiento por lotes,extracción de datos,transferencia y trabajos de carga99,9 % (p. 50)8 horas, 45 minutosHerramientas internas comoadministración del conocimiento,seguimiento del proyecto99,95 % (p. 56)4 horas, 22 minutosComercio electrónico, punto deventa99,99 % (p. 53)52 minutesEntrega de video, cargas detrabajo de transmisiones99,999 % (p. 59)5 minutosTransacciones en cajerosautomáticos, cargas de trabajode telecomunicacionesCalcular la disponibilidad con dependencias estrictas. Muchos sistemas tienen dependencias estrictasen otros sistemas, donde una interrupción en un sistema dependiente se convierte directamente en unainterrupción del sistema de invocación. Esto es lo contrario a una dependencia flexible, donde un error enel sistema dependiente se compensa en la aplicación. Cuando ocurren las mencionadas dependenciasestrictas, la disponibilidad del sistema de invocación es el resultado de las disponibilidades de los sistemasdependientes. Por ejemplo, si cuenta con un sistema diseñado para una disponibilidad del 99,99 % quetiene una dependencia estricta en otros dos sistemas independientes que están diseñados para unadisponibilidad del 99,99 % cada uno, la carga de trabajo en teoría puede alcanzar una disponibilidad del99,97 %:Availcarga de trabajo Availinvok Availdep1 Availdep299,99 % 99,99 % 99,99 % 99,97 %5
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSObjetivos de tiempo de recuperación (RTO)y objetivos de punto de recuperación (RPO)Por lo tanto, es fundamental comprender las dependencias y sus objetivos de diseño de disponibilidad amedida que calcula los propios.Calcular la disponibilidad con componentes redundantes. Cuando un sistema implica el uso decomponentes redundantes e independientes (por ejemplo, las zonas de disponibilidad redundantes), ladisponibilidad teórica se calcula como el 100 % menos el producto de la tasa de errores del componente.Por ejemplo, si un sistema utiliza dos componentes independientes, cada uno con una disponibilidad del99,9 %, la disponibilidad del sistema resultante es del 99,9999 %:Availcarga de trabajo AvailMAX ((100% Availdependencia) (100% Availdependencia))100% (0,1% 0,1%) 99,9999 %¿Pero qué sucede si no conozco la disponibilidad de una dependencia?Calcular la disponibilidad de la dependencia. Algunas dependencias ofrecen asesoramiento sobre sudisponibilidad, incluidos los objetivos de diseño de disponibilidad para muchos servicios de AWS (consulteel Apéndice A: Diseño para disponibilidad de servicios exclusivos de AWS (p. 68)). Pero en los casosdonde no está disponible (por ejemplo, un componente donde el fabricante no publica la información de ladisponibilidad), una forma de estimarla es determinar el Tiempo medio entre fallos (MTBF) y Tiempo mediode recuperación (MTTR). Se puede establecer una estimación de la disponibilidad con la siguiente fórmula:Por ejemplo, si el MTBF es de 150 días y el MTTR es de 1 hora, la estimación de la disponibilidad es del99,97 %.Para obtener más información, consulte este documento (Calcular la disponibilidad total del sistema), quepuede ayudarle a calcular la disponibilidad.Costos de la disponibilidad. Diseñar aplicaciones para niveles más altos de disponibilidad generalmentetiene como resultado un mayor costo, de modo que es apropiado identificar las verdaderas necesidadesde disponibilidad antes de embarcarse en el diseño de su aplicación. Los niveles de disponibilidad altosimponen requisitos más estrictos para las pruebas y la validación en situaciones de error exhaustivas.Requieren automatización para la recuperación de todo tipo de errores y requieren también que todoslos aspectos de las operaciones del sistema se creen y prueben de manera similar y con los mismosestándares. Por ejemplo, la incorporación o la eliminación de capacidad, la implementación o larestauración de un software actualizado o de cambios en la configuración, o bien, la migración de losdatos del sistema deben apuntar al objetivo de disponibilidad deseado. Lo que empeora la situación delos costos del desarrollo de software es que, en niveles de disponibilidad muy altos, la innovación se veafectada debido a la necesidad de avanzar más despacio en la implementación de los sistemas. Por lotanto, el asesoramiento debe ser detallado a la hora de aplicar los estándares y considerar el objetivo dedisponibilidad adecuado para todo el ciclo de vida del sistema operativo.La selección de dependencias es otra forma en la que se incrementan los costos en los sistemas quefuncionan con objetivos de diseño de disponibilidad más altos. En estos objetivos más altos, el conjuntode software o servicios que se pueden elegir como dependencias disminuye en función de cuáles de estosservicios ha recibido las grandes inversiones que se describieron anteriormente. A medida que aumentael objetivo de diseño de disponibilidad, se suelen encontrar menos servicios con fines múltiples (comouna base de datos relacional) y más servicios creados específicamente. Esto se debe a que estos últimosson más fáciles de evaluar, probar y automatizar. Además, tienen un potencial reducido de interaccionessorpresa con funcionalidades incluidas pero sin utilizar.Objetivos de tiempo de recuperación (RTO) y objetivosde punto de recuperación (RPO)Estos términos suelen asociarse con la Recuperación de desastres (RD), la cual consiste en un conjuntode objetivos y estrategias para recuperar la disponibilidad de la carga de trabajo en caso de un desastre.6
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSComprender las necesidades de disponibilidadObjetivo de tiempo de recuperación (RTO) Definido por la organización. El RTO es el retraso máximoaceptable entre la interrupción del servicio y la restauración del servicio. Esto determina qué se consideraun periodo de tiempo aceptable cuando un servicio no está disponible.Punto objetivo de recuperación (RPO) Definido por la organización. El RPO es la cantidad de tiempomáxima aceptable desde el último punto de recuperación de datos. Esto determina qué se considera unapérdida aceptable de datos entre el último punto de recuperación y la interrupción del servicio.La relación entre el RPO (objetivo de punto de recuperación), el RTO (objetivo de tiempo de recuperación),y el evento de desastre.El RTO es similar al MTTR (tiempo medio de recuperación) en el sentido de que ambos miden el tiempoentre el comienzo de una interrupción y la recuperación de la carga de trabajo. Sin embargo, el MTTR esun valor medio tomado en varios eventos que afectan la disponibilidad durante un tiempo, mientras que elRTO es un objetivo o el valor máximo permitido, para un solo evento que afecta la disponibilidad.Comprender las necesidades de disponibilidadEn un principio, es normal pensar en la disponibilidad de la aplicación como un objetivo único paratoda la aplicación. Sin embargo, luego de una inspección más cercana, solemos encontrarnos con queciertos aspectos de la aplicación o el servicio tienen requisitos de disponibilidad diferentes. Por ejemplo,algunos sistemas pueden darle prioridad a la capacidad de recibir y almacenar datos nuevos antes derecuperar datos existentes. Otros sistemas priorizan las operaciones en tiempo real sobre las operacionesque cambian el entorno o la configuración del sistema. Los servicios pueden tener requisitos de muyalta disponibilidad durante ciertas horas del día, pero pueden tolerar periodos de interrupción muchomás largos fuera de esas horas. Estas son algunas de las formas en las que puede descomponer unasola aplicación en diferentes partes y evaluar los requisitos de disponibilidad para cada una de ellas. Elbeneficio de esto es que puede concentrar sus esfuerzos (y gastos) en la disponibilidad de acuerdo con lasnecesidades específicas, en lugar de diseñar todo el sistema según los requisitos más estrictos.RecomendaciónEvalúe de forma crítica los aspectos únicos de sus aplicaciones y, cuando corresponda, diferencie losobjetivos de diseño de disponibilidad para que se reflejen las necesidades de su empresa.Dentro de AWS, normalmente dividimos los servicios en el “plano de datos” y el “plano de control”. El planode datos se encarga de entregar el servicio en tiempo real, mientras que los planos de control se utilizanpara configurar el entorno. Por ejemplo, las instancias de Amazon EC2, las bases de datos de AmazonRDS y las operaciones de lectura y escritura de tablas de Amazon DynamoDB son todas operaciones delplano de datos. Por el contrario, lanzar nuevas instancias EC2 o bases de datos de RDS, o bien, agregar ocambiar los metadatos de una tabla en DynamoDB se consideran operaciones del plano de control. Si bienlos niveles de disponibilidad altos son importantes para todas estas capacidades, por lo general, los planosde datos tienen objetivos de diseño de disponibilidad más altos que los planos de control.Muchos clientes de AWS adoptan un enfoque similar para evaluar de forma crítica sus aplicaciones eidentificar los subcomponentes con diferentes necesidades de disponibilidad. Los objetivos de diseño dedisponibilidad se adaptan a los diferentes aspectos y los esfuerzos de trabajo adecuados se ejecutan paradiseñar el sistema. AWS cuenta con una vasta experiencia en el diseño de aplicaciones con una variedadde objetivos de diseño de disponibilidad, incluidos los servicios con una disponibilidad del 99,999 % o más.Los arquitectos de soluciones (SA) de AWS pueden ayudarlo a diseñar sus objetivos de disponibilidad deforma adecuada. Involucrar a AWS al inicio del proceso de diseño mejora nuestra capacidad para ayudarloa cumplir sus objetivos de disponibilidad. La planificación de la disponibilidad no solo se realiza antes deque se lance la carga de trabajo. También se lleva a cabo de forma continua para mejorar su diseño a7
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSComprender las necesidades de disponibilidadmedida que adquiere experiencia operativa, aprende de los eventos reales y tolera diferentes tipos deerrores. Luego, puede aplicar el esfuerzo de trabajo adecuado para mejorar su implementación.Las necesidades de disponibilidad que se requieren para una carga de trabajo deben estar en consonanciacon las necesidades y la importancia de la empresa. Si en primer lugar define el marco de importanciade la empresa con un RTO, un RPO y una disponibilidad delimitados, luego puede evaluar cada cargade trabajo. Un enfoque como este requiere que las personas involucradas en la implementación de lacarga de trabajo conozcan el marco y el impacto que tiene su carga de trabajo en las necesidades de laempresa.8
Pilar de la fiabilidad Marco de Buena Arquitectura de AWSAdministrar Service Quotas y las limitacionesBasesLos requisitos básicos son aquellos cuyo alcance se extiende más allá de una sola carga de trabajo oproyecto. Antes de diseñar cualquier sistema, deben establecerse los requisitos básicos que influyen en lafiabilidad. Por ejemplo, debe tener suficiente ancho de banda de red para su centro de datos.En un entorno en las instalaciones, estos requi
El Marco de Buena Arquitectura de AWS ayuda a comprender las ventajas y las desventajas de las decisiones que se toman al crear cargas de trabajo en AWS. Mediante la utilización del marco, aprenderá las prácticas recomendadas de arquitectura para diseñar y operar cargas de trabajo en la nube fiables, seguras, eficientes y rentables.
