¿Cómo prevenir el abrazo de la muerte en la instancia EC2?

Tengo una aplicación de iOS en la tienda de aplicaciones y recientemente recibí una gran oleada de tráfico hacia mi página de destino alojada en EC2 y resultó en que la página no respondía, por suerte logré recuperarla reiniciando y actualizando la instancia a t2.medio.

Ahora estoy buscando contratar a alguien para implementar una tecnología para evitar la misma muerte nuevamente. Mi experiencia solo se extiende hasta ese punto, lo que me permite comprender cosas básicas de desarrollo, pero no lo suficiente para equilibrar la carga en AWS, quiero saber qué es una implementación asequible para mi instancia.

Mi página de destino y el backend de la aplicación de iOS están alojados en la misma instancia.

Si desea algo rápido para ordenar esto sin mucho más conocimiento, le recomendaría el beantalk elástico. Es otra aplicación de AWS que manejará la configuración del equilibrador de carga y el escalado de instancias por usted.

No hay ningún costo adicional además del equilibrador de carga y las instancias para que pueda seguir usando instancias de tipo t2, pero deje que el bean beanstalk se escale tanto como desee.

El escalado automático no es instantáneo y, en tiempos de tráfico vertiginoso, tomará una pequeña cantidad de tiempo, normalmente minutos, para poder manejar un pico, pero será mucho mejor que escalar manualmente el tamaño de la instancia y es realmente fácil de manejar. con.

Recomendaría el autoescalado como se mencionó anteriormente con la adición de algunas alarmas de CloudWatch para comenzar el proceso de autoescalado cuando los umbrales específicos comienzan a aumentar, no cuando ya está demasiado lejos.

Por ejemplo; configure CloudWatch para monitorear su servidor, cuando la CPU esté al 50% o más por un período de 30 segundos o más, inicie el proceso de escalado automático.

Esto puede no ser completamente perfecto, pero es fácil de hacer a través de algunas guías en línea y todo configurable a través de la GUI.

Además, si su página de destino es estática, ¿por qué no alojarla en un t2.micro de nivel libre y utilizar otro t2.micro de nivel libre para su aplicación?

Me encantaría ayudar con esto si estás buscando ayuda. Dependiendo de su página, es posible que no necesite ec2 en absoluto. Por ejemplo, si está sirviendo algo estático o JavaScript, se puede servir desde s3 con una distribución en la nube. O podríamos usar un grupo de escalado automático si es absolutamente necesario.

Existen dos estrategias generales para hacer frente a las oleadas de tráfico: aumentar la capacidad y reducir los costos.

Aumentar la capacidad significa autoescalar, lo que todos estaban muy entusiasmados cuando las nubes públicas estuvieron disponibles por primera vez. En su sentido más básico, esto iniciará más servidores web para usted en función de la carga y los agregará a un equilibrador de carga, pero como puede ser difícil de manejar, también hay soluciones más automáticas, como Elastic Beanstalk.

El problema con la expansión de capacidad automatizada es que también es una expansión de factura automatizada: 10 veces el tráfico normal significa que 10 servidores significa 10 veces más dinero que tiene que pagar. Es por eso que, si bien es una estrategia útil para tener en cuenta, creo que siempre debes comenzar por ver cuánto puedes hacer trampa.

Por trampa, me refiero a la memoria caché, que se basa en la idea de que la mayoría de las veces puede dar a los usuarios datos ligeramente desactualizados y que no se darán cuenta, y eso puede ahorrarle enormes cantidades de tiempo. Imagine que tiene una página que decide que está bien si está desactualizada en cinco segundos y obtiene 20 requisitos / s. Sin el almacenamiento en caché, está ejecutando ese cálculo 1200 veces por minuto, mientras que con el almacenamiento en caché solo son 12. Puede ver cómo esto puede marcar una gran diferencia.

Por supuesto, hay muchos tipos de almacenamiento en caché, y un sitio web exitoso utilizará varios de ellos. Pero para su caso de uso, hay dos opciones bastante buenas y fáciles.

El primero es hacer que el sitio sea completamente estático. Esto supone que puede hacerlo, pero si puede, entonces solo tiene que Nginx sirva el html directamente, y puede atender toneladas de solicitudes sin problemas.

Si necesita algún nivel de dinámica, entonces hacer un buen almacenamiento en caché de página completa es una buena opción. Nginx tiene cierta capacidad para hacer esto, pero realmente me gusta Varnish debido a su flexibilidad.

Cualquiera que sea la opción u opciones que elija, asegúrese de realizar pruebas de carga para validar que la ha configurado correctamente; a veces, arreglar un punto expone un nuevo cuello de botella.

Me gustaría compartir nuestra experiencia con AWS. Implementamos nuestra aplicación en EC2 y enfrentamos el mismo problema y también altos costos. Implementamos nuestra aplicación Amazon EC2 Container Service, aunque nuestra aplicación era monolítica, pero logramos

• Disponibilidad
• Económico
• Escalabilidad

El equilibrador de carga de aplicaciones manejará el tráfico y lo enrutará a la instancia saludable y puede ejecutar múltiples tareas de los mismos servicios sin preocuparse de escalar y equilibrar la carga.

Esta arquitectura facilita la implementación del aislamiento de fallas. Las técnicas como la verificación del estado, el almacenamiento en caché, los mamparos o los interruptores automáticos le permiten reducir el radio de explosión de un componente que falla y mejorar la disponibilidad general de una aplicación determinada.

Esto depende mucho de la arquitectura específica, pero por ejemplo:

• Carga frontal de su sitio web con CloudFront para reducir la carga en el host
• Use el servicio de alojamiento del lado del cliente en algo como S3 para escalar
• Elastic Load Balancer con un grupo de autoescalado