La resiliencia y la disponibilidad son aspectos fundamentales de todas las aplicaciones SaaS. Al crear sus servicios SaaS Serverless en la infraestructura de AWS, se implementan automáticamente en múltiples zonas de disponibilidad dentro de una sola región, lo que proporciona mayor resiliencia y mecanismos automatizados de conmutación por error de disponibilidad. Como ingenieros y arquitectos, es fundamental comprender estos conceptos y saber cómo configurar nuestros servicios correctamente.
En esta publicación, aprenderá sobre las zonas de disponibilidad (AZ), qué son, por qué son esenciales y mis consejos para configurar recursos en múltiples AZ dentro de una sola región.
Tabla de contenido
Definiciones y propiedades de las zonas de disponibilidad
Cuando creamos recursos en una región, los creamos en una o más zonas de disponibilidad.
Las AZ (zonas de disponibilidad) trabajan juntas detrás de escena para mantener nuestro servicio en funcionamiento compartiendo el tráfico, replicando los datos en las bases de datos y haciéndose cargo del tráfico de cada una en caso de una interrupción de la AZ.
A veces se nos ocultan los detalles, pero otras veces definimos explícitamente la cantidad de AZ que queremos usar: VPC, Aurora y Fargate me vienen a la mente.
Definamos qué es una zona de disponibilidad. Según la documentación de AWS :
Los recursos de AWS se alojan en varias ubicaciones en todo el mundo. Estas ubicaciones se componen de regiones de AWS, zonas de disponibilidad y zonas locales. Cada región de AWS es un área geográfica independiente. Cada región de AWS tiene varias ubicaciones aisladas conocidas como zonas de disponibilidad.
Como usted sabe, "todo falla todo el tiempo", como siempre dice Werner Vogles, por lo que el concepto de AZ es fundamental para garantizar que nuestro servicio funcione incluso si una AZ tiene problemas pero las otras están en línea.
Las AZ brindan mayor disponibilidad, tolerancia a fallas y escalabilidad que un solo centro de datos. En lugar de tener un único punto de falla, ahora tiene múltiples zonas en las que confiar en caso de que una de las AZ tenga problemas.
*También existe el concepto de servicios multirregionales, que aumenta un poco la disponibilidad del servicio, pero no lo abordaré aquí.
Propiedades de la zona de disponibilidad
Las AZ tienen características especiales según la documentación de AWS :
Cada región tiene un número diferente de AZ, pero todas tienen al menos 3.
Todas las AZ de una región están interconectadas a través de fibra metropolitana totalmente redundante, de alto ancho de banda y baja latencia.
El tráfico entre AZ está encriptado y admite la replicación sincrónica.
La partición de aplicaciones en distintas zonas de disponibilidad mejora la protección contra problemas como cortes de energía y desastres naturales.
Las AZ están separadas físicamente por una distancia significativa, generalmente dentro de los 100 km (60 millas) una de otra.
Es posible que su servicio no utilice TODAS las AZ.
Cuando una zona de disponibilidad tiene problemas en una región, AWS sabe cómo utilizar las demás zonas de disponibilidad para mantener el servicio y sus recursos en funcionamiento. El tráfico se trasladará "automáticamente" a otras zonas de disponibilidad que funcionen correctamente y a sus recursos. Además, una vez que la zona de disponibilidad defectuosa vuelva a estar en línea, replicará los datos que no tenía.
Todo esto lo gestiona AWS. Si me preguntas, es bastante sorprendente.
Por qué es importante comprender las zonas de disponibilidad
Los desarrolladores sin servidor no suelen pensar en las zonas de disponibilidad (AZ), ya que AWS gestiona esta información en segundo plano. Cuando se utilizan servicios sin servidor como Lambda y DynamoDB, las zonas de disponibilidad se seleccionan automáticamente y no es necesario que las administres ni las mantengas. Para obtener más información, consulta la documentación de AWS .
Sin embargo, cuando se utilizan VPC o servicios que no son completamente sin servidor (es necesario definir sus VPC y no se escalan a cero) como Aurora, OpenSearch o Fargate, las AZ entran en juego y es importante comprender su impacto.
Las AZ pueden aumentar el SLA y el SLI generales, ya que son más resistentes a una falla de una sola AZ. Aumentan la resiliencia y la disponibilidad ante fallas y tienen el potencial de mejorar el rendimiento, ya que AWS equilibra automáticamente el tráfico y el acceso entre las AZ.
Tomemos Aurora como ejemplo y revisemos algunas de las ventajas que trae la implementación en múltiples AZ:
Aurora almacena copias de los datos en un clúster de base de datos en varias zonas de disponibilidad en una sola región de AWS. Cuando los datos se escriben en la instancia de base de datos principal, Aurora replica de manera sincrónica los datos en las zonas de disponibilidad en seis nodos de almacenamiento asociados con el volumen del clúster. Documentación de AWS
Además de proteger sus bases de datos contra fallas cuando una AZ tiene problemas, también permite a AWS realizar conmutaciones por error en caso de problemas planificados. mantenimiento .
AZ y el caso de las identificaciones peculiares
Las zonas de disponibilidad tienen identificadores y nombres físicos :
AWS asigna las zonas de disponibilidad físicas de forma aleatoria a los nombres de las zonas de disponibilidad de cada cuenta de AWS. Este enfoque ayuda a distribuir los recursos entre las zonas de disponibilidad de una región de AWS, en lugar de que los recursos se concentren en la zona de disponibilidad "a" de cada región. Como resultado, la zona de disponibilidad us-east-1a de su cuenta de AWS podría no representar la misma ubicación física que us-east-1a de una cuenta de AWS diferente.
Cuando consideramos una escala mayor que una sola cuenta de AWS, como una organización de AWS con múltiples servicios implementados en múltiples cuentas, el problema se vuelve aún más significativo.
Si dos servicios en dos cuentas diferentes de esa organización se implementaran en zonas de disponibilidad específicas por sus nombres: "us-east-1a" y "us-east-1b", AWS se asignaría a diferentes zonas de disponibilidad físicas (sobre las que no tiene control) en las cuentas de su organización. Si bien cree que está implementando sus recursos en las mismas zonas de disponibilidad físicas, es probable que eso no sea cierto.
Para controlar en qué AZ específica se implementa, necesita saber la asignación correcta entre el nombre y la identificación física .
Cubriremos una solución alternativa con un ejemplo de código AWS CDK más adelante en esta publicación.
¿Cuándo puede una AZ o región dejar de funcionar?
Una AZ puede dejar de funcionar debido a fallas de hardware, desastres naturales, cortes de energía u otros desastres.
Una región deja de funcionar cuando TODAS sus zonas de disponibilidad sufren fallas y se marcan como "inactivas". Este tipo de desastre afecta a todos los clientes de AWS implementados en esta región. Consulte el historial de casos de AWS , que se remonta a 13 años atrás. ¡Estas cosas pasan!
Repasemos algunos casos de uso de fallas de servicio, desde los casos más simples hasta los más extremos.
El caso de uso simple es que su servicio se cae cuando todas las zonas de disponibilidad que utiliza dejan de funcionar.
Sin embargo, las cosas pueden complicarse más. Supongamos que no implementa en todas las zonas de disponibilidad de esa región. La región tiene 3 zonas de disponibilidad y usted utiliza solo 2 de las 3 zonas de disponibilidad: las zonas de disponibilidad A y B. Si las zonas de disponibilidad A y B no funcionan, experimentará una falla regional en su aplicación, aunque la región aún tenga una zona de disponibilidad en funcionamiento.
Pero la cosa puede complicarse aún más. Supongamos que su servicio SaaS depende de otro servicio SaaS en tiempo de ejecución. Ambos servicios se implementan en diferentes cuentas de AWS.
Supongamos que su servicio se implementa en AZ 1 y 2, y el servicio B, del que depende críticamente, se implementa en 1 y 3. En caso de que las regiones 1 y 3 estén inactivas, aunque todavía tenga disponible su AZ 2, esencialmente estará inactivo, ya que su dependencia crítica, el servicio B, está inactivo.
Es por eso que comprender las AZ y garantizar que la organización SaaS utilice la misma metodología y las mismas AZ garantiza la disponibilidad.
Como todo lo demás en el software, todo tiene ventajas, desventajas y restricciones. Implementar en todas las zonas de disponibilidad es la respuesta más sencilla, pero te costará mucho.
Analicemos mis recomendaciones para la selección de AZ.
Recomendaciones para la selección de zonas de disponibilidad
Como regla general:
Dos son mejores que uno. Implemente en un mínimo de dos AZ. Para lograr la coherencia en toda la organización, consulte el ejemplo de código a continuación para saber cómo lograrlo. Asegúrese de que todas las organizaciones utilicen las mismas AZ (1 y 2, por ejemplo). Consulte la sección "Selección de AZ mediante IaC" a continuación para ver cómo hacerlo mediante IaC.
Se recomienda a los servicios SaaS críticos que estén dispuestos a pagar más por un SLI y un rendimiento mejorados durante un mal funcionamiento parcial de una AZ que se implementen en tres o más AZ.
Antes de agregar una zona de disponibilidad, es fundamental calcular el costo de la TRANSFERENCIA DE DATOS y de la infraestructura adicional. Este paso garantiza que la implementación siga siendo rentable y se ajuste al presupuesto de la organización.
En el caso de los servicios SaaS críticos que se implementan en regiones con más de 3 zonas de disponibilidad, evalúe el costo para determinar si vale la pena agregar zonas de disponibilidad. Como referencia, dichas regiones han fallado antes, por lo que incluso una región con 6 zonas de disponibilidad puede funcionar.
Selección de AZ mediante IaC
Es imposible establecer identificadores físicos de AZ como "use-1az1" (para la región us-east-1) directamente en el código AWS CloudFormation/CDK. En su lugar, debe proporcionar los nombres de AZ; como sabemos, se asignan de manera diferente en cada cuenta a diferentes identificadores. Necesitamos determinar qué nombre de AZ se asigna a AZ1, AZ2, etc.
Puede hacerlo en el código CDK usando AWS SDK (boto3 para Python) para encontrar la asignación específica de la cuenta entre el nombre y la identificación de AZ.
Considere este ejemplo de código Python que crea una VPC que SIEMPRE se implementa en AZ1 y AZ2:
La magia ocurre en las líneas 48 a 57. Repasamos el mapeo y buscamos los nombres de AZ que coinciden con el ID en el que queremos implementar. ¡Simple y efectivo!
Consejos de selección de AZ para VPC
Al configurar una nube privada virtual (VPC), tiene más control y debe seleccionar explícitamente qué zonas de disponibilidad usar. Por lo general, la mejor práctica es implementar sus recursos (como instancias EC2 o balanceadores de carga elásticos) en varias zonas de disponibilidad regionales.
Utilice varias subredes dentro de la VPC, cada una de ellas ubicada en una zona de disponibilidad diferente. Esto le permite distribuir sus recursos entre las zonas de disponibilidad y mantener la redundancia en caso de que se produzca una falla en una zona de disponibilidad.
Como nota al margen, si tiene Lambdas dentro de su VPC, se implementarán de acuerdo con la definición de VPC; de lo contrario, depende del servicio Lambda configurar y elegir las AZ.
Consejos de selección de AZ para Aurora
Un clúster de base de datos Aurora es tolerante a fallas por diseño. El volumen del clúster abarca varias zonas de disponibilidad (AZ) en una sola región de AWS, y cada AZ contiene una copia de los datos del volumen del clúster. Esta funcionalidad significa que su clúster de base de datos puede tolerar una falla de una AZ sin ninguna pérdida de datos y solo una breve interrupción del servicio.
Le recomendamos que distribuya la instancia principal y las instancias de lectura en su clúster de base de datos en varias zonas de disponibilidad para mejorar la disponibilidad de su clúster de base de datos. - Documentación de AWS
Comprender el costo de una zona de disponibilidad
La implementación y creación de recursos en varias zonas de disponibilidad aumenta el costo. Usted paga por los recursos implementados (réplicas de Aurora, EC2, ALB, puerta de enlace NAT, etc.) y, en algunos casos, por el tráfico entre las zonas de disponibilidad.
Revisemos el siguiente escenario: implementamos una máquina EC2 y un clúster MySQL de Aurora RDS en una VPC con 2 AZ.
En este caso, pagaremos el doble del importe por los recursos de EC2, Aurora DB, VPC y otras partes de la red (ENI, etc.).
En cuanto a la transferencia de datos, no paga por la replicación de datos AZ entre las instancias de RDS ni por los datos enviados dentro de la misma región (entre EC2 y RDS).
Sin embargo, usted pagará cualquier costo de red entre EC2 y por cualquier dato que se encuentre entre EC2 y RDS desde una AZ diferente (en caso de que RDS no funcione en la primera AZ).
Como ves, en caso de tener 1 AZ y agregar otra, pagarás más del doble debido al despliegue de red e infraestructura.
Este costo se reducirá a medida que agregue más AZ, ya que el costo relativo de la implementación de la infraestructura representa un porcentaje menor del costo general.
En cuanto al costo de transferencia de datos en sí, el costo varía entre regiones, pero en su mayor parte,
La transferencia de datos entre zonas de disponibilidad dentro de la región cuesta 0,01 USD/GB y, si las actualizaciones se realizan en ambos sentidos, se paga el doble: 0,02 USD/GB. Más información aquí .
El costo varía según la región, así que asegúrese de verificarlo antes de agregar una AZ en su región.
Resumen
En esta publicación, abordamos la importancia de la resiliencia y la disponibilidad en aplicaciones SaaS creadas en AWS mediante zonas de disponibilidad (AZ). Definimos qué son las AZ y por qué son importantes, y escribimos código de IaC concreto para configurar recursos en varias AZ.
¡Gracias a Maxim Drobachevsky y Meitar Karas por su ayuda y reseña!